Subject: Re: SDP> Suggestions for discussion at SDP session next week

From: Carl Kugler <[email-masked]>
Date: Thu, 14 May 1998 14:51:58 -0400

Hi Jay,

You wrote:
>
>Hi Carl,
>
>A couple of comments to your reply to Bob Herriot's recent
>posting regarding Microsoft's requirements/concerns for an
>SDP-like protocol:
>
>Carl Kugler wrote:
>>
>> Bob Herriot wrote:
>>
>>  > I talked to Paul Moore yesterday to learn what problems IPP doesn't
>>  > currently solve.
>>  >
>>  > There were four main problems:
>>  >
>>  >     a) no notification
>>  >     b) if a connection fails, there is no way to know if it because the
printer
>>  >         is down or just busy.
>>
>> Socket implementations typically provide for a "backlog".
>>   The following program fragment illustrates the use of the listen subroutine
>>   with 5 as the maximum number of outstanding connections which may
>>   be queued awaiting acceptance by the server process.
>>
>>   listen(s,5)
>
>This is true, but all too many times folks in the PWG point out
>the reality that if you set the queue depth to "n", then there
>will likely be situations in which ">n" requests come in.  When
>the n+1 connection attempt is made, the result (as seen by the
>client) is usually the same as a "device not present", i.e.,
>no response to the connection attempt.

I don't see what good it does to have an unbounded queue for incoming requests.
If requests come in at a rate faster than they can be served, the storage
requirements and turn-around time will both approach infinity. Is this
desirable?

For short term bursts, the backlog buffers the connection attemps long enough
for the server to respond.  In sophisticated printers this response might
consist of handing the connection off to a new process or thread and going
back to the backlog for more connections.

>
>Use of SNMP and the Printer MIB can alleviate this problem;
>it also provides a great degree of scalability.
>
>
>>  >     c) if a write times out, there is no way to know if it because the
>>  >         printer is down or just busy
>>
>> In many (most?) cases you'll least get a TCP reset when the connection goes
down.
>> The exceptions would be things like total power failure on the Printer, or OS
>> kernel hang on the Printer.
>
>As I recall (and someone please correct me here, if necessary),
>a TCP Reset is the indication that the other end of the connection
>has consciously closed the connection.  So, any kind of network
>problem can cause serious grief; unfortunately, when it comes to
>network problems, the use of alternate IP techniques (such as SNMP)
>doesn't usually do much good.

Okay, but "consciously closed the connection" doesn't necessarily mean that
an application process survived to call "shutdown()" on the connection.  If
a process dies, the OS (or runtime environment) can, and normally will,
reset the connection.

If a backhoe cuts the cable, no protocol can save you.

>
>What we do in our driver technology is to put a degree of tolerance
>in the write process, whereby the driver accepts a certain period
>of write-timeout (so to speak), afterwhich it starts alerting
>interested parties in potential problems.  After a configured
>period has been reached in which no writing has been possible,
>the driver considers the situation to be terminal, and attempts
>to restart the print job from the beginning.

Nothing here you can't do with TCP sockets.

>It would be interesting to hear how others handle this situation.
>
>
>> But isn't this one of the SDP requirements:
>>
>>   7. The SDP protocol must be completely Transport independent.
>>
>> and wouldn't this solution be dependent on UDP and IP?
>
>Yeah, you're right.  Use of SNMP in transport environments
>that don't currently support SNMP will require the use
>of some other similar technique.  This is the reason we
>added SNMP OID access into TIP/SI, thereby making it work
>quite well in serial/parallel applications.
>

If we're going to require TCP/IP, we might as well run IPP 1.0
and SNMP instead of inventing a new SDP.

> ...jay
>
>----------------------------------------------------------------------
>--  JK Martin               |  Email:   [email-masked]          --
>--  Underscore, Inc.        |  Voice:   (603) 889-7000              --
>--  41C Sagamore Park Road  |  Fax:     (603) 889-2699              --
>--  Hudson, NH 03051-4915   |  Web:     http://www.underscore.com   --
>----------------------------------------------------------------------
>

 -Carl

---

From: Roger K Debry <[email-masked]>
Date: Thu, 14 May 1998 17:38:33 -0400

Bob Herriot wrote ...

snip ...

Yes I expect any other transport to provide reliability, ordering, etc.  It
should not be IPP/SDP job to do this.

I find it interesting that an old TIPSI requirements document dated 9/94
states the intention of removing transport layer functionality that is still
in TIPSI and that some people still want to add to IPP.

<RKD> Bob, I agree 100%, but let's all be sure
<RKD> we understand and agree on what belongs in
<RKD> each layer.

---

From: Harry Lewis <[email-masked]>
Date: Fri, 15 May 1998 11:53:03 -0400

Agreed - same for everyone.

>...let Microsoft speak for themselves.
>
>Comments from others on this position?

Harry Lewis - IBM Printing Systems

[email-masked] on 05/15/98 09:24:21 AM
Please respond to [email-masked]
To: [email-masked]
cc: [email-masked]
Subject: Re: SDP> Suggestions for discussion at SDP session next week

Bob,

> I just talked with Paul about the requirement for a separate data channel.

Given the size, presence and impact Microsoft has in and on the
marketplace, I know I'm not alone in requesting (demanding? begging?)
that Microsoft speak for themselves on this DL regarding requirements
concerns, etc.  It's not right that others submit Microsoft's
comments on key requirements...let Microsoft speak for themselves.

Comments from others on this position?  Agree?  Disagree?  Don't care??

> I think that Paul and I are in agreement that "separate data channel" does
> not necessarily mean that an operation gets a separate channel for data in
> the midst of an IPP/SDP operation. It has at least some elements of the
following.:
>
>     a)  each operation opens a new socket and gets its own channel, or uses
>         an existing socket after the preceding operation has completed.

I read your "a)" item several times, but still come away confused.
That is, I don't see the value or implication of the statement.
Am I missing something here?

Some of us still want to see the use of a separate data
channel for clean, low-overhead transmission of large
amounts of relatively opaque data (ie, job data).  This
lesson was learned by the FTP folks many years ago, and
we should learn from that experience.

 ...jay

---

From: "Caruso, Angelo " <[email-masked]>
Date: Fri, 15 May 1998 08:43:24 PDT

I believe that in practice this problem would rarely occur. Get Bulk is
appropriate during discovery operations but not generally necessary.
Besides, most implementations are still SNMP v1 and therefore don't use Get
Bulk anyway. The thought of inventing a brand new mechanism instead of SNMP
is preposterous. Can't we please stop reinventing the wheel here?

Thanks,
Angelo

-----Original Message-----
From: Harry Lewis [mailto:[email-masked]]
Sent: Thursday, May 14, 1998 4:34 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: SDP> Suggestions for discussion at SDP session next week

Bob stated...

>The concern I have about SNMP is that a client's "get status" query could
>be
behind several GetBulk requests and thus not get processed fast enough >for
the
client to determine that the printer is alive but very busy.

This is one reason notifications are useful rather than polling.

[email-masked] on 05/14/98 01:43:48 PM
Please respond to [email-masked]
To: [email-masked], [email-masked]
cc: [email-masked]
Subject: Re: SDP> Suggestions for discussion at SDP session next week

In my solution, I assume that there is a port dedicated to returning printer
status only and it has higher priority for processing than the normal IPP
port or the SNMP port.  I want to keep the probability of a reply near 100%
even when the printer is very busy with other network requests.

The concern I have about SNMP is that a client's "get status" query could be
behind
several GetBulk requests and thus not get processed fast enough for the
client
to
determine that the printer is alive but very busy.

Can an SNMP request have as good a guarantee of a quick response as a
dedicated port?

Also in my proposal, I assume that the data returned is in an IPP compatible
format.

Bob Herriot

At 08:15 PM 5/13/98 , Jay Martin wrote:
>Regarding solution "b":
>
>>     b) the primary issue is being able to determine the printer status,
i.e.
>>         did the connection fail because the printer is down or just busy.
One
>>         simple solution is to have a printer read on a UDP port dedicated
to
>>         returning a status summary whenever it receives a request on the
port.  If
>>         the incoming bytes are limited and have simple options, the
printer
will
>>         never be tied up for long on each transaction and will always be
able to let
>>         a client know if it is alive and whether there are any problems.
Then if the
>>         connection fails, it is because the printer is down or the IP
address is bad.
>
>Sounds like a fixed SNMP query.  Why don't we just use
>SNMP and the Printer MIB for this kind of thing?
>
>       ...jay
>
----------------------------------------------------------------------------
----

---

From: Carl Kugler <[email-masked]>
Date: Fri, 15 May 1998 13:09:25 -0400

>Robert Herriot ([email-masked])
>Thu, 14 May 1998 12:37:39 -0700
>
What assumptions are you making about the platform to allow this kind of tuning
(some ports processed at higher priority)?

>several GetBulk requests and thus not get processed fast enough for the client
>to
This seems like a worst-case scenario.  Who would be doing these GetBulks and
why?  How often?  What are the consequences when the query is not processed
fast enough?

>Can an SNMP request have as good a guarantee of a quick response as a
How good a guarantee is required for this application?  No response is
guaranteed over UDP anyway.  Is tuning of the snmp server allowed?

>Also in my proposal, I assume that the data returned is in an IPP compatible

Carl Kugler

---

From: Carl Kugler <[email-masked]>
Date: Fri, 15 May 1998 14:24:21 -0400

On Thu, 14 May 1998 14:04:02 -0700 , Robert Herriot
([email-masked]) wrote:
>
>My comments are below
>
>
>Bob Herriot
>
>...
>
>> > The solutions:
>> > a) notification: the IPP group is close to a solution
>> > b) the primary issue is being able to determine the printer status, i.e.
>> > did the connection fail because the printer is down or just busy.One
>> > simple solution is to have a printer read on a UDP port dedicated to
>> > returning a status summary whenever it receives a request on the port. If
>> > the incoming bytes are limited and have simple options, the printer will
>> > never be tied up for long on each transaction and will always be able to
let
>> > a client know if it is alive and whether there are any problems.  Then if
the
>> > connection fails, it is because the printer is down or the IP address is
bad.
>My point is that IPP/SDP is and should be transport independent but not
>transport absent. We should not define mechanisms in an IPP/SDP layer that
>are better handled at a lower transport layer, particularly when those lower
>layers already are already defined to do the work for us for transports,
>such as TCP/.IP and UDP/IP, and are likely to do so for parallel, USB and 1394.

Then I think it would be clearer if you talked in terms of "streaming",
"datagrams" (discrete messages), and "multiplexing" instead of specific
protocol names and concepts like TCP, UDP, and ports.

>
>
>>
>> > c) this is essentially the same problem as b) and has the same
solution.Namely,
>> > if a write times out, the client can query status and determine theproblem.
>> > d) I think that we should rely on TCP/IP to get the bytes to their
>> > destination. The most likely failure between client and paper is the
>> > network. Loss of data inside the printer seems like such a remote problem
>> > that it isn't worth making the protocol more complicated to solve this
problem.
>>
>>Again, Transport independent?
>
>
>Layering is an important concept. We need to use it for IPP/SDP.
>
>

Then I think your proposal should state that it prereqs a duplex transport
that facilitates reliable streaming, datagrams, multiplexing.

  -Carl