Subject: Re: Update rfc1974?

From: Bill Palter <[email-masked]>
Date: Fri, 20 Feb 1998 11:04:36 -0800

> 
> Bill,
> 
> Yes, but none of these occur over the internet.  
> 
> I tried to be general by using the word proposed vs required.  STAC 3 is
> required, but this is not a good idea for tunneling over the internet.
> Can you suggest some words to satisfy both our needs ?
> 
> Philip
> 

	I think that rfc1974 probable should not reference l2tp directly 
at all. Since its a general problem, 1974 probably should talk about 
optimizations over lossy networks (such as tunneling PPP over other 
transports), as time goes by I would be surprised if this problem does not 
show up in other places. In the l2tp draft I dont really see the need to 
reference STAC specificly, but we can beef up the warnings about the 
stateful compression schemes over the Internet. I feel that cross referencing
warnings in RFC tends to make things get dated over time as protocol evolve 
into uses that they were not originally intended to do....

> 
> 
> 
> On Fri, 20 Feb 1998, Bill Palter wrote:
> 
> > > 
> > > 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
> > 
> > 	This is a little over generalized, there are many cases of using 
> > l2tp tunnels where loss and/or resequencing of packets does not occur.
> > 
> > 
> > > 
> > > 
> > > On Fri, 20 Feb 1998, W. Mark Townsley wrote:
> > > 
> > > > On Thu, 19 Feb 1998, Philip Rakity wrote:
> > > > 
> > > > > 
> > > > > 
> > > > > 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 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. 
> > > > 
> > > > > 
> > > > > 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
> > > > > 
> > > > > On Thu, 19 Feb 1998, Robert Friend wrote:
> > > > > 
> > > > > > 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]
> > > > > > 
> > > > > > 
> > > > > 
> > > > > 
> > > > 
> > > 
> > --
> > Bill Palter ([email-masked])
> > Network Alchemy,    Santa Cruz, CA
> > 
> 
--
Bill Palter ([email-masked])
Network Alchemy,    Santa Cruz, CA

---

From: Robert Friend <[email-masked]>
Date: Fri, 20 Feb 1998 17:58:25 -0800

Hi Guys,

Thanks for the insight.  I can add something about tunneling rfc1974
over lossy networks somewhere in the draft.  However, I am still not
clear on whether any changes *need* to be done?  I.e. I haven't gotten
my questions answered.

Can anybody help here?

Thanks,

Robert C. Friend              Hi/fn

> -----Original Message-----
> From:	Bill Palter [SMTP:[email-masked]]
> Sent:	Friday, February 20, 1998 11:05 AM
> To:	Philip Rakity
> Cc:	Bill Palter; [email-masked]; [email-masked];
> [email-masked]
> Subject:	Re: Update rfc1974? 
> 
> > 
> > Bill,
> >