attachment

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:st1="urn:schemas-microsoft-com:office:smarttags" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv=Content-Type content="text/html; charset=us-ascii"> <meta name=Generator content="Microsoft Word 11 (filtered medium)"> <o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="City"/> <o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="place"/>  <style>  </style> </head> <body lang=EN-US link=blue vlink=blue> <div class=Section1> Dear Bill,<o:p></o:p> <o:p> </o:p> 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.<o:p></o:p> <o:p> </o:p> 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.<o:p></o:p> <o:p> </o:p> 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.<o:p></o:p> <o:p> </o:p> 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.<o:p></o:p> <o:p> </o:p> 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.<o:p></o:p> <o:p> </o:p> Thanks.<o:p></o:p> <o:p> </o:p> Best Regards,<o:p></o:p> <o:p> </o:p> /Paul<o:p></o:p> <div> --<o:p></o:p> <tt>Paul Tykodi</tt> <tt>Principal Consultant</tt> <tt>TCS - Tykodi Consulting Services LLC</tt> <tt>Tel/Fax: 603-343-1820</tt> <st1:City w:st="on"><st1:place w:st="on"><tt>Mobile</tt></st1:place></st1:City><tt>:  603-866-0712</tt> <tt>E-mail:  <a href="mailto:ptykodi@tykodi.com">ptykodi@tykodi.com</a></tt> <tt>WWW:  </tt><tt><a href="http://www.tykodi.com/" target="_blank">http://www.tykodi.com</a></tt><o:p></o:p> </div> <div> <div class=MsoNormal align=center style='text-align:center'> <hr size=2 width="100%" align=center tabindex=-1> </div> 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<o:p></o:p> </div> <o:p> </o:p> <div> Paul,<o:p></o:p> <o:p> </o:p> 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.<o:p></o:p> <o:p> </o:p> 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:<o:p></o:p> a.       certain private MIBS use an indirect addressing approach, particularly for writes, which may make for some elegance but does complicate interaction<o:p></o:p> b.      many management applications are terribly inefficient, repeatedly querying the same (sometimes status) variable, and often unnecessarily dumping blocks of data.<o:p></o:p> c.       Drastically underpowered controllers and/or poor handling of priorities<o:p></o:p> <o:p> </o:p> 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.<o:p></o:p> <o:p> </o:p> Bill Wagner, TIC<o:p></o:p> </div> <div>  <o:p></o:p> </div> <blockquote style='border:none;border-left:solid #1010FF 1.5pt;padding:0in 0in 0in 4.0pt; margin-left:3.75pt;margin-top:5.0pt;margin-bottom:5.0pt'> -------------- Original message -------------- From: "Paul Tykodi" <ptykodi@tykodi.com> <o:p></o:p> Dear List,<o:p></o:p> <o:p> </o:p> 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).<o:p></o:p> <o:p> </o:p> 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.<o:p></o:p> <o:p> </o:p> 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.<o:p></o:p> <o:p> </o:p> HTH<o:p></o:p> <o:p> </o:p> Best Regards,<o:p></o:p> <o:p> </o:p> /Paul<o:p></o:p> <div> --<o:p></o:p> <tt>Paul Tykodi</tt> <tt>Principal Consultant</tt> <tt>TCS - Tykodi Consulting Services LLC</tt> <tt>Tel/Fax: 603-343-1820</tt> <u1:City u2:st="on"><u1:place u2:st="on"><st1:City w:st="on"><st1:place w:st="on"><tt>Mobile</u1:place></u1:City></tt></st1:place></st1:City><tt>:  603-866-0712</tt> <tt>E-mail:  <a href="mailto:ptykodi@tykodi.com" !>ptykodi@tykodi.com</a></tt> <tt>WWW:  </tt><tt><a href="http://www.tykodi.com/" target="_blank">http://www.tykodi.com</a></tt><o:p></o:p> </div> <div> <div class=MsoNormal align=center style='text-align:center'> <hr size=2 width="100%" align=center tabIndex=-1> </div> 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<o:p></o:p> </div> <o:p> </o:p> The minutes can be found at: <o:p></o:p>         <a href="ftp://ftp.pwg.org/pub/pwg/pmp/minutes/mfp/MFP_Minutes_20060214.pdf">ftp://ftp.pwg.org/pub/pwg/pmp/minutes/mfp/MFP_Minutes_20060214.pdf</a> <o:p></o:p> Ron Bergman Chairman, Printer MIBs Working Group <o:p></o:p> </blockquote> </div> </body> </html>