Subject: Re: IPP>PRO another reason for needing byterange and documen

From: Roger K Debry <[email-masked]>
Date: Mon, 12 May 1997 09:23:03 -0400

The normal meaning of checkpointing is that the client determines the
boundaries upon which it will restart. It then must organize the data to be
sent on those boundaries.  Boundaries are arbitrary.

Roger K deBry
Senior Techncial Staff Member
Architecture and Technology
IBM Printing Systems
email: [email-masked]
phone: 1-303-924-4080

---------------------- Forwarded by Roger K Debry/Boulder/IBM on 05/12/97 07:07
AM ---------------------------

        ipp-owner @ pwg.org
        05/10/97 07:13 PM
Please respond to [email-masked] @ internet

To: Robert.Herriot @ Eng.Sun.COM @ internet, jkm @ underscore.com @ internet
cc: ipp @ pwg.org @ internet
Subject: Re: IPP>PRO another reason for needing byterange and documen

At 11:10 PM 5/9/97 -0400, JK Martin wrote:
>Is IPP expected to support checkpointing to the point where the
>client will resume submission of document at *precisely* the point
>where the transmission failed?
>
>I wouldn't think so.  Rather, the client would resume transmission
>at the *start* of the document that failed.
>
>Is this true?
>
> ...jay
>

Jay,

starting over from the beginning is not checkpointing in my book.
The whole point of checkpointing is so that you do not have to
start a big transmission over again from the beginning.

Carl-Uno

---

From: Roger K Debry <[email-masked]>
Date: Mon, 12 May 1997 09:25:01 -0400

Yes, I thought we had already agreed to this.

>Jay Martin write ...
>Feature-rich, configurable checkpointing/recovery could very well be
>something we defer to a future release of IPP.
>
>Just my pennies worth.

 ...jay

---

From: Roger K Debry <[email-masked]>
Date: Mon, 12 May 1997 09:58:14 -0400

Bob, I'm glad that someone else finally realizes that we need
something in the IPP layer to help with recovery. If you would
go back to the protocol proposal that I presented in the San
Jose PWG meeting, you will see that what we are getting very
close to that proposal. However, that proposal used a
sequence number, rather than byte range.  I believe that
byte range is definate overkill, and a sequence number
would be simpler (especially for a re-director) to
generate.

Bob Berriot Wrote:

> A WebNFS client should follow the example of conventional
>NFS clients and handle server or network outages gracefully.
>If a reply is not  received  within a given timeout, the client
>should retransmit the request with its original XID (described
>in Section 8 of RFC 1831). The XID can be used  by the server
>to detect duplicate requests and avoid unnecessary work.
>While it would seem that retransmission over a TCP connection
>is unnecessary (since TCP is responsible for detecting and
>retransmitting lost data), at the RPC layer retransmission is
>still required for recovery from a lost TCP connection, perhaps
>due to a server crash or, because of resource limitations, the
>server has closed the connection.  When the TCP connection
>is lost, the client  must re-establish the connection and
>retransmit pending requests. It seems to me that this same issue
> exists with regard to IPP operations including those that send
>document data.  Thus a client may send a block of document
>data where the transmission succeeds at the TCP level, but
>the server crashes before sending a "data received and
>processed"  reponse.  In such a case, the server may or may
>not have processed the  data. Since the client will have to
>retransmit the data, the server  needs to know whether it is new
>data or another copy of the last data, thus the need for byte ranges
>and document numbers to identify the  piece of data.

>Comments?
>Bob Herriot

---

From: Roger K Debry <[email-masked]>
Date: Mon, 12 May 1997 10:08:21 -0400

>Jay Martin wrote:

 ...jay

There are several places you could restart:

1) The entire job (not adequate for large production
     environments.

2) The document that failed (also not adequate for
     large production jobs.  Although there was some
     argument that large jobs could be broken up into
     multiple documents, I doubt that we want IPP to
     have that kind of impact on existing production
     applications. At least I'm not willing to go and tell
     my customers that they have to rewrite their apps.)

3)  The last Send Document - this doesn't seem
      too difficult, especially with sequence numbers
      to identify each segment.  This also seems like a
      rational boundary to build checkpoints on.

4) bytes within a Send Document -  much harder to do,
    requires some dialogue between the client and the
    server to synchronize data.

5) You could also restart on a page boundary, but
    this is really much harder to do.