attachment

Inconsistency is a more serious problem (in my experience) than efficiency (which I THINK is Paul's hot button). I think it would be great if we addressed both, but these may require separate efforts. ---------------------------------------------- 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 ---------------------------------------------- <table width=100%> <tr valign=top> <td width=40%>"McDonald, Ira" <imcdonald@sharplabs.com> Sent by: pmp-owner@pwg.org 02/15/2006 08:04 PM <td width=59%> <table width=100%> <tr valign=top> <td> <div align=right>To</div> <td>"'Bergman, Ron'" <Ron.Bergman@rpsa.ricoh.com>, ptykodi@tykodi.com, pmp@pwg.org <tr valign=top> <td> <div align=right>cc</div> <td> <tr valign=top> <td> <div align=right>Subject</div> <td>RE: Feedback - PMP> Minutes of the MFP Teleconference 20060214</table> <table> <tr valign=top> <td> <td></table> </table> <tt>Hi, I spoke with Rick Landau (Dell) this afternoon and he's getting some input from Dell management software implementors who have observed implementation inconsistencies in Printer MIB - he said he'll pass these along pretty soon - I think that cross-vendor management software implementors are some of the best allies for a PWG Best Practices document on the Printer MIB. Note that the PWG Process/2.0 requires that Implementors Guides be subject to the full process and Formal Approval and final publication as Best Practices in '/pub/pwg/informational' (i.e., unlike IETF Implementors Guides they are NORMATIVE). Cheers, - Ira 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@sharplabs.com > -----Original Message----- > From: pmp-owner@pwg.org [mailto:pmp-owner@pwg.org]On Behalf > Of Bergman, > Ron > Sent: Wednesday, February 15, 2006 12:37 PM > To: ptykodi@tykodi.com; pmp@pwg.org > Subject: RE: Feedback - PMP> Minutes of the MFP > Teleconference 20060214 > > > Hi Paul, > > I have also observed poorly designed SNMP based applications > that consume > enormous amounts of network bandwith.  For example, reading > large portions > of the input and output tables at a fairly high frequency to > determine the > available paper sources and destinations.  In many cases I > believe this is > the result of a desire to simplify the application, through > the use of a > single query loop, by developers that are not experienced in > real-time code > practices. > > As chairman of the PWG MIBs Working Group I would be glad to > work with you > to define and present this as a project proposal to the PWG. > >                  Regards, >                  Ron Bergman > > > -----Original Message----- > From: pmp-owner@pwg.org [mailto:pmp-owner@pwg.org]On Behalf Of Paul > Tykodi > Sent: Wednesday, February 15, 2006 6:13 AM > To: pmp@pwg.org > 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@tykodi.com > WWW:     http://www.tykodi.com > > -----Original Message----- > From: pmp-owner@pwg.org [mailto:pmp-owner@pwg.org] On Behalf > Of McDonald, > Ira > Sent: Wednesday, February 15, 2006 1:06 AM > To: 'ptykodi@tykodi.com'; pmp@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@sharplabs.com >   > -----Original Message----- > From: pmp-owner@pwg.org [mailto:pmp-owner@pwg.org]On Behalf > Of Paul Tykodi > Sent: Tuesday, February 14, 2006 10:50 PM > To: pmp@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@tykodi.com > WWW:  http://www.tykodi.com > > > > From: pmp-owner@pwg.org [mailto:pmp-owner@pwg.org] On Behalf Of > wamwagner@comcast.net > Sent: Tuesday, February 14, 2006 10:33 PM > To: ptykodi@tykodi.com; pmp@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@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@tykodi.com > WWW:  http://www.tykodi.com > > > > From: pmp-owner@pwg.org [mailto:pmp-owner@pwg.org] On Behalf > Of Bergman, Ron > Sent: Tuesday, February 14, 2006 7:02 PM > To: pmp@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 > > </tt>