Subject: Update rfc1974?

From: Robert Friend <[email-masked]>
Date: Thu, 19 Feb 1998 15:17:44 -0800

Hi All,

I have been trying to work with the Microsoft representatives on this
issue since the Memphis meeting, but I never received a response.  My
questions to this group are:

1) Are these 2 issues real issues with the document?
2) Do we want to change the rfc to reflect this updated information on
these 2 issues?
3) Is the information below accurate for issue #3?
4) Does anyone know the answers to questions #1 or issue #2 below?

Here are the issues:

>From the Memphis meeting we had an issue with rfc1974, extended mode.
Also, I have a question about extended mode.

1) First my question: In section 5. on page 15, it says that extended
mode only supports a history count of 1.  Does this mean that a history
count of 0 will be protocol rejected?  Alternatively, can the
implementation negotiate a history count of 1 and set the bit-A on every
packet?  Will either of these 2 approaches break Win 95?

2) From the Memphis meeting in April, there was confusion about how
Win95 deals with (or doesn't deal with) protocol field compression
(PFC).  I don't know if this ever got resolved (I couldn't find any
email to document this).  So, I thought I would ask you how Win95 deals
with PFC.  Assuming PFC is negotiated first, then does PFC need to be
un-negotiated on the link if extended mode is negotiated?  It seems that
the second to last paragraph of section 5.1  must change, but I don't
know what to change this paragraph to.

3) Lastly, here is the text from Phil Rakity. I don't know if it has
been blessed by you [Microsoft].  Could you [Microsoft or PPPEXT] please
bless it.

ORIGINAL TEXT
=============

5.4. Extended Mode Synchronization

   Packets may be lost during transfer. If the decompressor maintained
   coherency count does not match the coherency count received in the
   compressed packet or if the decompressor detects that a received
   packet is corrupted, the decompressor drops the packet and sends a
   CCP Reset-Request packet. The compressor on receiving this packet
   resets the history buffer and sets the PACKET_FLUSHED bit in the next
   frame it sends. The decompressor on receiving a packet with its
   PACKET_FLUSHED bit set, resets its history buffer and sets its
   coherency count to the one shipped by the compressor in that packet.

   Thus synchronization is achieved without a Reset-Ack packet.

NEW TEXT
=======

5.4. Extended Mode Synchronization

   	Packets may be lost during transfer. If the decompressor
maintained
   	coherency count does not match the coherency count received in
the
   	compressed packet or if the decompressor detects that a received
   	packet is corrupted, or if the decompressor is waiting for 	
	synchronization and the coherency count is correct but the 	
	PACKET_FLUSHED bit is not set, the decompressor drops the packet
and 	
	sends a CCP Reset-Request packet. The compressor on receiving
the 	
	CCP Reset-Request Packet packet resets the history buffer and
sets 	
	the PACKET_FLUSHED bit in the next frame it sends. The
decompressor 	
	on receiving a packet with its PACKET_FLUSHED bit set, resets
its 	
	history buffer and sets its coherency count to the one shipped
by 	
	the compressor in that packet.

   	Thus synchronization is achieved without a Reset-Ack packet.

	Implementation Note:  The decompressor should reset the history
when 	
	a corrupted packet was received (eg no end marker) to ensure
that 	
	the decompressor is in a well known state and not rely on the 	
	protocol to flush the history. 

P.S. There is a PPP bakeoff by the San Francisco Airport next week.
Will there be a Microsoft representative there for a discussion about
this?  I plan to be there Wednesday & Thursday.  I would like to resolve
these issues.

Thanks,
_____________________________________________________________

Robert C. Friend              Hi/fn
Applications Engineering      5973 Avenida Encinas, Suite 110
voice: (760) 827-4542         Carlsbad, CA 92008
FAX:   (760) 827-4577         email: [email-masked]

---

From: Philip Rakity <[email-masked]>
Date: Thu, 19 Feb 1998 23:11:08 -0800 (PST)

Bob,

If you are going to change rfc1974, there is one more item that may need
changing.  I am not sure if it belongs in rfc1974 or in L2TP, but it
certainly belongs somewhere.

The problem is that using STAC LZS (type 3) compression, or any
compression method that contains a sequence number; is not a good idea if
there is a good chance that packets will be dropped (eg: as in tunneling
through) the internet.  The cost of recovery is very high (reset req, ack,
etc).  It is better to use STAC 0 (no history).  So, where should we put
in text about what is recommended.  

It is certainly is a good idea to require everyone support STAC LZS (as is
in the spec), but we need for words that an implementation requesting
compression when connected through a tunnel should request STAC 0 (no
history).

regards,

Philip Rakity
FlowPoint

---

From: "W. Mark Townsley" <[email-masked]>
Date: Fri, 20 Feb 1998 04:14:53 -0500 (EST)

> certainly belongs somewhere.

The current L2TP draft speaks to the pros and cons of stateful compression
and encryption techniques over an [L2TP][UDP][IP] tunnel in section 8.1.

---

From: Philip Rakity <[email-masked]>
Date: Fri, 20 Feb 1998 10:15:29 -0800 (PST)

Mark,

You are correct that the draft talks about the use/non-use of state based
compression schemes.  However, no mention is specifically made of STAC
compression (rfc 1974).  

I believe that if rfc1974 is used with a tunnel, then STAC 0 should be
proposed.  The rfc1974 text (if revised) should include words this effect.

Philip Rakity

---

From: "W. Mark Townsley" <[email-masked]>
Date: Fri, 20 Feb 1998 13:55:15 -0500 (EST)

> compression schemes.  However, no mention is specifically made of STAC

Stating the relative dangers of using stateful protocols in general is as
far as I would like to go in the l2tp draft.  I have no desire to get into
specifying any particular compression algorithm(s) as you seem to be
suggesting (I also might point out that Stac is an informational RFC that
uses a licensed compression technique). A more proper place is in the Stac
RFC itself.