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

From: "Bergman, Ron" <[email-masked]>
Date: Wed, 15 Feb 2006 09:37:16 -0800

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: [email-masked] [mailto:[email-masked]]On Behalf Of Paul
Tykodi
Sent: Wednesday, February 15, 2006 6:13 AM
To: [email-masked]
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:  [email-masked]
WWW:     http://www.tykodi.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of McDonald,
Ira
Sent: Wednesday, February 15, 2006 1:06 AM
To: [email-masked]'; [email-masked]
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: [email-masked]
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Paul Tykodi
Sent: Tuesday, February 14, 2006 10:50 PM
To: [email-masked]
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:  [email-masked]
WWW:  http://www.tykodi.com

From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Tuesday, February 14, 2006 10:33 PM
To: [email-masked]; [email-masked]
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" <[email-masked]> 
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:  [email-masked]
WWW:  http://www.tykodi.com

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bergman, Ron
Sent: Tuesday, February 14, 2006 7:02 PM
To: [email-masked]
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

---

From: "McDonald, Ira" <[email-masked]>
Date: Wed, 15 Feb 2006 13:47:37 -0800

Hi,

While a generic PWG "Network Printer Implementors Guide"
(not limited to one protocol is a lofty goal), it's NOT
the needed thing:

(1) IPP/1.0 and IPP/1.1 both have Implementors Guides
(2) PSI/1.0 has most of a draft Implementors Guide
(3) WIMS/1.0 isn't even finished, so there's no need yet
(4) Printer MIB does NOT have anything

I don't agree that broadening the scope to the abstract
Semantic Model (which hasn't even incorporated ANY of
the Printer MIB semantics for PrintDevice yet) is very 
helpful.

My two cents,
- Ira

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Harry Lewis
Sent: Wednesday, February 15, 2006 12:56 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: Feedback - PMP> Minutes of the MFP Teleconference 20060214

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" <[email-masked]> 
Sent by: [email-masked] 
02/15/2006 07:13 AM Please respond to
<[email-masked]>

To<[email-masked]> 
cc
SubjectRE: Feedback - PMP> Minutes of the MFP Teleconference 20060214

Hi Ira,

Thanks.

Best Regards,

/Paul

Tel/Fax: 603-343-1820
Mobile:  603-866-0712

-----Original Message-----

Hi Paul,

Cheers,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Paul Tykodi
Sent: Tuesday, February 14, 2006 10:50 PM
To: [email-masked]
Subject: RE: Feedback - PMP> Minutes of the MFP Teleconference 20060214

Dear Bill,

Thanks.

Best Regards,

/Paul

Tel/Fax: 603-343-1820
Mobile:  603-866-0712

Paul,

Bill Wagner, TIC

-------------- Original message -------------- 

HTH

Best Regards,

/Paul

Tel/Fax: 603-343-1820
Mobile:  603-866-0712

---

From: "McDonald, Ira" <[email-masked]>
Date: Thu, 16 Feb 2006 07:15:22 -0800

Hi,

First, the primary purpose of _any_ implementors guide
is to foster interoperable, consistent implementations.

Second, a Printer MIB v2 interoperability testing event
is a necessary prerequisite to any well-grounded effort
to produce a PWG Printer MIB Implementors Guide, IMHO.

Third, efficiency is largely in the "eye of the beholder".

Fourth, excellent books and articles already exist about
how to do efficient SNMP (and more generally, management
protocol) implementations.  The PWG members are not (with
rare exceptions) subject matter experts here.  A section
in the proposed PWG Printer MIB Implementors Guide that
identifies good SNMP and other management software design
references would be sufficient and appropriate.

Cheers,
- Ira

-----Original Message-----
From: Paul Tykodi [mailto:[email-masked]]
Sent: Thursday, February 16, 2006 9:18 AM
To: 'Harry Lewis'
Cc: [email-masked]; 'Bergman, Ron'; 'McDonald, Ira'
Subject: RE: Feedback - PMP> Minutes of the MFP Teleconference 20060214

Hi,
 
I believe the two concepts may actually work together to cause difficulties.
The case I am thinking about is where a software product is developed, which
makes an assumption that all Printer MIB implementations will provide a
particular response to a certain question given a particular condition
exists within the device, and the assumption turns out to be false. Each
time the software encounters a situation where the design assumption turns
out to be incorrect (device returns some unexpected response from the
perspective of the software),  the possibility exists for significantly
increased SNMP traffic because the software needs to learn more about the
condition of the device in order to decide whether to continue the operation
currently being processed.
 
Thus I believe we could probably link the two concepts together in one
document should the PWG consensus be that this idea was the best option to
pursue.
 
Best Regards,
 
/Paul

Tel/Fax: 603-343-1820
Mobile:  603-866-0712

From: Harry Lewis [mailto:[email-masked]] 
Sent: Thursday, February 16, 2006 2:14 AM
To: McDonald, Ira
Cc: [email-masked]; [email-masked]; 'Bergman, Ron'
Subject: RE: Feedback - PMP> Minutes of the MFP Teleconference 20060214

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

"McDonald, Ira" <[email-masked]> 
Sent by: [email-masked] 
02/15/2006 08:04 PM To"'Bergman, Ron'" <[email-masked]>,
[email-masked], [email-masked] 
cc 
SubjectRE: 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

> From: [email-masked] [mailto:[email-masked]]On Behalf 
> Of Bergman,
> Ron
> Sent: Wednesday, February 15, 2006 12:37 PM

---

From: "Bergman, Ron" <[email-masked]>
Date: Thu, 16 Feb 2006 09:07:58 -0800

To all,

Some excellent points have certainly been raised here to justify the proposed effort.
And I strongly agree with Ira that an interop test will be an essential part of the
program.  Due to the extremely large installed base of printers containing the Printer
MIB and to a lesser degree, the Finisher and Job MIBs, this program should be a very
high priority within the PWG.

Paul, you certainly have opened our eyes to a serious deficiency.

	Ron

-----Original Message-----
From: McDonald, Ira [mailto:[email-masked]]
Sent: Thursday, February 16, 2006 7:15 AM
To: [email-masked]'; 'Harry Lewis'
Cc: [email-masked]; Bergman, Ron; McDonald, Ira
Subject: RE: Feedback - PMP> Minutes of the MFP Teleconference 20060214

Hi,

Cheers,
- Ira

-----Original Message-----
From: Paul Tykodi [mailto:[email-masked]]
Sent: Thursday, February 16, 2006 9:18 AM
To: 'Harry Lewis'
Cc: [email-masked]; 'Bergman, Ron'; 'McDonald, Ira'
Subject: RE: Feedback - PMP> Minutes of the MFP Teleconference 20060214

Hi,

 
Best Regards,
 
/Paul

Tel/Fax: 603-343-1820
Mobile:  603-866-0712

  

Hi,

Cheers,
- Ira

> Of Paul Tykodi

---

From: "McDonald, Ira" <[email-masked]>
Date: Thu, 16 Feb 2006 13:00:20 -0800

Hi Bill,

I too have certainly seen apparent instances of intentional
poor implementation of open standard MIBs to preserve (STUPID)
proprietary advantage.

But I've also seen instances where I know that the MIB was
implemented by a third party ISV (for example, a NIC vendor)
who was clueless about printing (and often SNMP as well).

When a printer engine is built by one division, rapidly glued
to a NIC by another division, and then accessed by client apps
developed by yet a third division, incoherence is inevitable.

US vendors in particular now spend less on QA than ever before.
And product lifecycles are ridiculously short.  Their SNMP and
MIB implementations are still sadly considered peripheral and
unimportant by most Product Managers and Marketing people.

Educating customers and third-party ISVs would help, but the
printing industry needs to get a lot more professional about
the quality of the software they develop, IMHO.

Thus, my urging of a PWG Printer MIB Interoperability Event.

Cheers,
- Ira

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, February 16, 2006 11:56 AM
To: McDonald, Ira; [email-masked]'; 'Harry Lewis'
Cc: [email-masked]; 'Bergman, Ron'; McDonald, Ira
Subject: RE: Feedback - PMP> Minutes of the MFP Teleconference 20060214

I agree that inconsistent and incorrect Printer MIB implementations are
rampant, and possibly dealing with these increases the inefficiency of
management applications. Ira's suggestion that interoperability testimg as a
prerequisite would be helpful in exposing  these inappropriate
implementations, at least to the products' manufacturers. 

This may or may not have an effect. I beleive that most printer MIB
inconsistencies are not a result of misunderstanding the standard, but a
result of intentional decisons either to not invest the expense in doing it
right or to willfully obfuscate access to certain attributes to encourage
the use of the manufacturer's proprietary solutions.

Also, some of the very inefficient SNMP interactions I have observed are
between applications and printers from the same manufacturer, where the
application engineers presumably know the specifics of the MIB
implementations. Although this may be a result of internal miscommunication
or the intentional use of arcane private MIBS for product differentiation, I
suspect that the effect on products' performance is just not recognized or
is not a concern.  

In short, I think the problem is that it is not clear to the manufacturers
that the benefits to them of having:
  1. good standard MIB implementations allowing effective management by any
proper application, and 
  2. mangement applications that are efficient with all properly impelmeted
MIBs

outweigh the benefits of having possible proprietary advanatges for their
own products. Indeed, until users recognize the benefits of and demand
consistent standardized  management capabilities, there probably is no
advanatge to manufacturers in implementing them.

Bill Wagner, TIC
-------------- Original message -------------- 
From: "McDonald, Ira" <[email-masked]> 

> identifies good! SNMP and other management software design 
> parti! cular response to a certain question given a particular condition 

> E-mail: [email-masked] > WWW: http://www.tykodi.com 
> 
> 
> 

> "McDonald, Ira" 
> Sent by! : [email-masked] 
> 02/15/2006 08:04 PM To"'Bergman, Ron'" , 
> Ch! eers, 
> > of the input and output tables at a fairly high frequency to 
&g! t; > determine the 
> > available paper sources and destin ations. In many cases I 
> > believe this is 
> > I am willi! ng to be a co-editor for such a project. Is this 
> > something the PWG 
>! > 
> > Harry Lewis (IBM, chair of PWG) has repeatedly sug gested that a 
> &! gt; - Ira (co-editor of Printer MIB v2) 
> > 
> > culprit for the slow printing or that it did not work correctly! . The 
> > communication started OK and then the host was con cerned that 
> > a response 
> > In the end, ! all of the data was printed and no errors were 
> > reported by the 
> > which is being monitored. ! 
> > 
> > Cc: Pau! l Tykodi 
> > gets lost in this era of "human readability". Al! though you may have 
> > slow-down... the condition the management station was 
> > q! uerying, the objects 
> > being queried, etc. 
> > 
> > Bill Wagner, TIC 
> > 
> > From: "Paul Tykodi" 
> > category for an MFP alerts project. The idea w! ould be to at 
> > least minimally 
> > describe som e best practices for MIB usage, which would 
> > result in the host 
> >! TCS - Tykodi Consulting Services LLC 
> > 
> > Tel/Fax: 603-343-1820 
> > Mobile: 603-866-0712

---

From: [email-masked]
Date: Thu, 16 Feb 2006 21:46:18 +0000

Ira,

We are in general agreement. Indeed, the degree of participation in a MIB interopability event would be one indication of what companies care, at least a little. But don't get me wrong; companies try to provide what their customers ask for. If users don't see what advantage it is to them to have a good, consistent, standard management capability, why should companies exert effort to provide it? 

And, in defenseof NIC suppliers (since I was attached to the primary NIC supplier for many years, ) I would observe that the NIC can handle the protocol and most communication parameters by itself, but it still needs access to the printer data base for most of the object values. Many printer companies were not interested in providing this except for a minimal set of objects necessary for some visability with major applications. Indeed, some companies had us identify the unit as an HP Jet Direct unit to get that minimum visiblity but were happy to ignore most of the Printer MIB set.

Bill Wagner, TIC

-------------- Original message -------------- 

> From: "McDonald, Ira"