RE: Feedback - PMP> Minutes of the MFP Teleconference 20060214

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Wed Feb 15 2006 - 22:04:59 EST

  • Next message: Harry Lewis: "RE: Feedback - PMP> Minutes of the MFP Teleconference 20060214"

    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
    >
    >



    This archive was generated by hypermail 2.1.4 : Wed Feb 15 2006 - 22:05:15 EST