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

From: Carl Kugler <[email-masked]>
Date: Thu, 14 May 1998 11:54:28 -0400

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)

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

 >     d) if a write operation succeeds, there is no way to be 100% sure that
 >          the bytes made it to their final destination  The success of a
write only
 >          means that the TCP/IP layer succeeded.
 >
 > 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.

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?

 >    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 the
problem.
 >    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?

 >
 > I hope that we can discuss these ideas via the DL and next week in DC.
 >
 > The solution that I suggest with b) is a new IPP operation over a different
route from
 > other IPP operations, so the syntax for request and reponse could be similar
or different.
 > This solution allow IPP for other operations to remain unchanged.
 >
 > Bob Herriot
 >

Carl Kugler

---

From: Jay Martin <[email-masked]>
Date: Thu, 14 May 1998 12:23:08 -0400

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:
>  >     b) if a connection fails, there is no way to know if it because the printer
>  >         is down or just busy.
> 

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.

Use of SNMP and the Printer MIB can alleviate this problem;
it also provides a great degree of scalability.

> In many (most?) cases you'll least get a TCP reset when the connection goes down.

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.

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.

It would be interesting to hear how others handle this situation.

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

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

---

From: Robert Herriot <[email-masked]>
Date: Thu, 14 May 1998 14:04:02 -0700

My comments are below

Bob Herriot

printer
>  be queued awaiting acceptance by the server process.

Yes, and clients end up timing out when this listen queue is full.  But
'listen' is 
for TCP, and I am proposing a UDP solution for the printer status so that 
there is the least amount of overhead for the printer.

>kernel hang on the Printer.

Actually, I should have said "there is no way to know if it is because the
printer
is HUNG or just busy".  We need a separate query to determine if the printer is
making progress on something.
write only
> >         did the connection fail because the printer is down or just
busy.One
port.  If
will
able to let
Then if the
address is bad.
>and wouldn't this solution be dependent on UDP and IP?

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.

>
> >    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.
problem
this problem.
>Again, Transport independent?

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.

Layering is an important concept.  We need to use it for IPP/SDP.

route from
> > other IPP operations, so the syntax for request and reponse could be
similar or different.
>Car