Re: draft-heath-ppp-v44-02.txt

Thomas & James

Sorry, I have been too busy to reply to the last email from James.   The 
basic point of discussion is whether or not this ID should have the same 
sequence number and dictionary synchronization mechanisms that other PPP 
compression RFC's (like 1974, 1977, etc) have defined for those modes that 
require reliable, in-sequence delivery.

Firstly, this ID does not require that PPP Reliable Transport or LAPB be 
used, it just requires a reliable, in-sequence mechanism of some kind.  I 
can change the ID to make that more clear if necessary.

Secondly, if such a reliable, in-sequence mechanism is not already in 
place, or is too complex to implement just for compression then the other 
option is to use Datagram Mode as defined in the ID which does not require 
a reliable, in-sequence mechanism.  Albeit the compression ratio may not 
be quite as good.

I could add the sequence number and dictionary synchronization mechanisms 
used by RFC'c 1974, 1977, etc. but in my mind that brings up a host of 
issues that need to be addressed as follows:

- do real implementations of RFC 1974, for instance, use single or 
multiple compression history modes that require sequence numbers and 
dictionary sequencing?  Or do most real implementations just go with no 
history and compress each packet individually such that reliable, 
in-sequence delivery is not required. 

- just adding a sequence number to each packet does not seem to resolve 
the problem.  What does the peer decompression function do when it 
receives an out of sequence packet?  It must somehow tell the peer 
compressor function that transmitted the packet and try to get the 
dictionary back into sync, which is why  RFC1977 and others rely on 
Reset-Request and Reset-Ack CCP packets or on renegotiation of the 
Compression Control Protocol to indicate loss of sync between transmitter 
and receiver.  In the meantime the decompressor function must discard all 
packets received until dictionary sync between the transmitter and 
receiver is restored.

- do we really want the compression function to be discarding packets 
without any mechanism to have them re-transmitted by the PPP link?  And 
expect a higher layer like TCP to recover?  What if it is UDP? Compression 
is supposed to save bandwidth, and in my mind the compression function 
itself should not add to bandwidth usage by tossing out of sequence 
packets and requiring feedback messages to indicate loss of dictionary 
syncronization.  It seems that in that case Datagram Mode would be better 
since even though the compression ratio may be slightly worse it may 
improve bandwidth efficiency in the long run over a more complex , 
potentially bandwidth wasting, mechanism.

If the answer to these issues is that:

(1) yes, in real implementations of RFC 1974 single and multi compression 
histories are used, i.e. sequencing is used
(2) yes, rely on Reset-Request and Reset-Ack CCP packets or on 
renegotiation of the Compression Control Protocol and let the receiver 
discard packets in the meantime.  We don't want to use Datagram Mode 
instead.
(3) yes, we want the compression function to discard packets and let the 
higher layer worry about them, regardless of the possible affect on 
bandwidth.  We don't want to use Datagram Mode instead.

then end of discussion, I will add that same capability to the V.44 draft 
if that is what is needed to make sure V.44 is used over PPP in all of its 
operating modes.

If the answer to those issues is no, then I recommend we change the ID to 
make it clear that Datagram Mode should be used in the absence of a 
reliable transport.  V.44 gets excellent compression doesn't suffer as 
much as other algorithms when compressing one packet at a time.

regards
Jeff







Thomas Narten <narten@xxxxxxxxxx>
01/15/2003 09:14 AM

 
        To:     jheath@xxxxxxx
        cc:     James Carlson <james.d.carlson@xxxxxxxxxxxx>, Karl Fox 
<karlfox@xxxxxxxxxxxxxxx>, border@xxxxxxx
        Subject:        Re: draft-heath-ppp-v44-02.txt


Just to clarify the status of this, I'm assuming that the document is
still under active discussion and I should continue to wait for more
followup? I.e., it's not quite ready for publication as an RFC yet?

Thomas