Interop has been our key goal, but efficiency is also a legitimate
concern. I'm not sure the focus should be limited to SNMP... as we have
put a great deal of effort into evolving a common semantic model and new,
web-services based approaches to imaging service and device management. In
either case, an Implementer's Guide would be helpful and I'm happy to see
you volunteer to play a role.
Paul, I recommend you structure a short presentation outlining the problem
space and potential solutions and plan to present at the April (5/6) PWG
meeting which will be hosted by Oki in Mt. Laurel, NJ. If you cannot be
there in person, Ron or I will be happy to deliver the presentation. I
will arrange a time slot for a BOF as part of the PWG Plenary (or
separately).
----------------------------------------------
Harry Lewis
IBM STSM
Chairman - IEEE-ISTO Printer Working Group
http://www.pwg.org
IBM Printing Systems
http://www.ibm.com/printers
303-924-5337
----------------------------------------------
"Paul Tykodi" <ptykodi at tykodi.com>
Sent by: pmp-owner at pwg.org
02/15/2006 07:13 AM
Please respond to
<ptykodi at tykodi.com>
To
<pmp at pwg.org>
cc
Subject
RE: Feedback - PMP> Minutes of the MFP Teleconference 20060214
Hi Ira,
I am willing to be a co-editor for such a project. Is this something the
PWG
would likely want to pursue in the near term future?
Thanks.
Best Regards,
/Paul
--
Paul Tykodi
Principal Consultant
TCS - Tykodi Consulting Services LLC
Tel/Fax: 603-343-1820
Mobile: 603-866-0712
E-mail: ptykodi at tykodi.com
WWW: http://www.tykodi.com
-----Original Message-----
From: pmp-owner at pwg.org [mailto:pmp-owner at pwg.org] On Behalf Of McDonald,
Ira
Sent: Wednesday, February 15, 2006 1:06 AM
To: 'ptykodi at tykodi.com'; pmp at pwg.org
Subject: RE: Feedback - PMP> Minutes of the MFP Teleconference 20060214
Hi Paul,
Harry Lewis (IBM, chair of PWG) has repeatedly suggested that a
good project would be a PWG standard "Printer MIB Implementor's
Guide" - similar in purpose and scope to the IETF Proposed Std
"IPP/1.1 Implementor's Guide" (RFC 3196, November 2001).
Volunteer PWG editor bandwidth is the problem - that and the very
complicated problem space of SNMP optimization biased by MIB
optimization biased by the fact that printers (and spoolers) are
supposed to "print first and bother me later".
A first step was that Printer MIB v2 (RFC 3805) contained a great
many improved DESCRIPTION clauses that clarified and recommended
implementation choices for many of the columnar objects.
But the problem you've identified is a whole system problem, not
just a Printer MIB implementation problem.
Cheers,
- Ira (co-editor of Printer MIB v2)
Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221 Grand Marais, MI 49839
phone: +1-906-494-2434
email: imcdonald at sharplabs.com
-----Original Message-----
From: pmp-owner at pwg.org [mailto:pmp-owner at pwg.org]On Behalf Of Paul Tykodi
Sent: Tuesday, February 14, 2006 10:50 PM
To: pmp at pwg.org
Subject: RE: Feedback - PMP> Minutes of the MFP Teleconference 20060214
Dear Bill,
The host I was most recently analyzing was an IBM iSeries - AS/400 host.
The
MIB itself worked flawlessly. I am not suggesting that it was somehow the
culprit for the slow printing or that it did not work correctly. The
communication started OK and then the host was concerned that a response
packet was not received in a timely fashion. It began a significant SNMP
based questioning process to determine the current hardware status of the
device and interspersed with the SNMP questions about whether the device
was
in error or not came a re-transmission of a potentially lost packet just
to
be safe.
Pretty soon the majority of the communication on the wire revolved around
SNMP discussions as to the device's status and data packet
re-transmissions
and confirmations from the printing device that it had indeed received the
packet re-transmissions. As you mention, the whole idea of printing
information had become unfortunately a secondary concern.
In the end, all of the data was printed and no errors were reported by the
host. Unfortunately the method utilized to determine that everything was
actually fine was so intrusive on the printing process that I feel
comfortable saying I believe that a typical customer (having paid a fee
for
their printing device related to its rated engine performance) would
probably not have accepted the result as commercially viable.
So my previous comment is directed more towards device managing software
product's use of MIB capabilities (especially if more interesting things
to
check are added into future MIB's) and the impact that significant device
status verifications can have on the actual process (in this case
printing),
which is being monitored.
Thus in the future if some type of RFC or other standards document were to
be produced, my suggestion would be to include some examples that tried to
help steer software developers implementing use of MIB data away from
creating the issue you outline in point b. below.
Thanks.
Best Regards,
/Paul
--
Paul Tykodi
Principal Consultant
TCS - Tykodi Consulting Services LLC
Tel/Fax: 603-343-1820
Mobile: 603-866-0712
E-mail: ptykodi at tykodi.com
WWW: http://www.tykodi.com
From: pmp-owner at pwg.org [mailto:pmp-owner at pwg.org] On Behalf Of
wamwagner at comcast.net
Sent: Tuesday, February 14, 2006 10:33 PM
To: ptykodi at tykodi.com; pmp at pwg.org
Cc: Paul Tykodi
Subject: RE: Feedback - PMP> Minutes of the MFP Teleconference 20060214
Paul,
Thanks for sending in your observation. I have worked with printers and
SNMP
management for many years and have not seen anything like the sort of
slowdown that you cite. Perhaps this is because I have worked with slower
machines and printers/MFPs with separate NICs. At any rate, a basic SNMP
tenet is that servicing of SNMP is secondary to the main purpose of the
device. Indeed, reflecting this, I have seen missed or late SNMP responses
during periods of high print activity.
Of course, it is desirable to have efficient MIBs, something that
sometimes
gets lost in this era of "human readability". Although you may have
contradicting data, I would suggest that the current public MIBs are not
in
themselves inefficient and that the problem you observed may be due to
other
factors such as:
a. certain private MIBS use an indirect addressing approach,
particularly for writes, which may make for some elegance but does
complicate interaction
b. many management applications are terribly inefficient, repeatedly
querying the same (sometimes status) variable, and often unnecessarily
dumping blocks of data.
c. Drastically underpowered controllers and/or poor handling of
priorities
Although I understand that it may be difficult to release such
information,
it would be useful to have some information on the specifics of the
slow-down... the condition the management station was querying, the
objects
being queried, etc.
Bill Wagner, TIC
-------------- Original message --------------
From: "Paul Tykodi" <ptykodi at tykodi.com>
Dear List,
During the last year, I have been involved in some network analysis
looking
at how certain hosts use the current printer MIB to determine device
status
(including that of MFP's) and what effect a significant number of SNMP
queries and responses can have on effective printing throughput (at times
rather dramatic reduction in achievable throughput).
In looking at the minutes from today's meeting, I would suggest that it
might be a good idea to consider whether MIB optimization should be a
category for an MFP alerts project. The idea would be to at least
minimally
describe some best practices for MIB usage, which would result in the host
obtaining the required information using the smallest SNMP query and
response packet transmission overhead possible.
In case people are wondering how dramatic a reduction in PPM I have
observed
when SNMP traffic is significant (host trying to determine whether device
is
in error or not - multiple queries are sent asking more and more specific
questions of the printer MIB), I have seen printers and MFP's with rated
speeds in the 75 - 125 PPM range reduced to achieving actual throughput in
the 10 to 20 PPM range.
HTH
Best Regards,
/Paul
--
Paul Tykodi
Principal Consultant
TCS - Tykodi Consulting Services LLC
Tel/Fax: 603-343-1820
Mobile: 603-866-0712
E-mail: ptykodi at tykodi.com
WWW: http://www.tykodi.com
From: pmp-owner at pwg.org [mailto:pmp-owner at pwg.org] On Behalf Of Bergman,
Ron
Sent: Tuesday, February 14, 2006 7:02 PM
To: pmp at pwg.org
Subject: PMP> Minutes of the MFP Teleconference 20060214
The minutes can be found at:
ftp://ftp.pwg.org/pub/pwg/pmp/minutes/mfp/MFP_Minutes_20060214.pdf
Ron Bergman
Chairman, Printer MIBs Working Group
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pwg.org/archives/pmp/attachments/20060215/f61663be/attachment.html