Subject: RE: Few questions on L2TP..

From: Keyur Parikh <[email-masked]>
Date: Wed, 7 Mar 2001 13:37:12 -0500

ok, I am glad I included the excerpt from the RFC, I assumed you were aware
of the background.  While on clarification, you should also clarify what the
LNS should do, if it had enabled sequencing, but the LAC is sending data
messages without the inclusion of the Ns (i.e drop the call, disable
sequencing on its end etc..)

comment on your following statement
"
An implementation that is performing any sort of reordering MUST be able
to handle packet loss. This should be clear from RFC2661. 

This includes loss of a single packet, 1000 packets, 65535 packets, or
more. If you stop at a given sequence number, switchover, and pickup at
0, at worst you look like you dropped a bunch of packets, or sent a few
duplicates. Your tunnel peer may discard some packets on receipt, queue
some packets waiting for the "lost" one, etc. but the numbers should
sync up fairly quickly."

KRP - ok, so what you are saying is that it is ok to lose  up to 65k data
packets, but a sequence number resetting mechanism is unwarranted.
Interesting!

Also on the point of expanding the protocol for explicit signaling - IMO,
inband mechanism with a bit in the common header is more efficient. This
way, any control message (call control, tunnel control or Hello) can be used
for this purpose.  Obviously, all the race conditions have to be worked out.

-----Original Message-----
From: W. Mark Townsley [mailto:[email-masked]]
Sent: Wednesday, March 07, 2001 11:07 AM
To: Keyur Parikh
Cc: Andy Koscinski; [email-masked]
Subject: Re: Few questions on L2TP..

Keyur Parikh wrote:
> 
> >Repeat after me: "Data messages do not need synchronizing", "Data
> >messages do not need synchronizing", "Data messages do not need
> >synchronizing"...
> 
> OK, then how do you explain the following from RFC2661 (section 5.4)
> 
> "
> Unlike the L2TP control channel, the L2TP data channel does not use
>    sequence numbers to retransmit lost data messages. Rather, data
>    messages may use sequence numbers to detect lost packets and/or
>    restore the original sequence of packets that may have been reordered
>    during transport.  The LAC may request that sequence numbers be
>    present in data messages via the Sequencing Required AVP (see Section
>    4.4.6). If this AVP is present during session setup, sequence numbers
>    MUST be present at all times. If this AVP is not present, sequencing
>    presence is under control of the LNS. The LNS controls enabling and
>    disabling of sequence numbers by sending a data message with or
>    without sequence numbers present at any time during the life of a
>    session. Thus, if the LAC receives a data message without sequence
>    numbers present, it MUST stop sending sequence numbers in future data
>    messages. If the LAC receives a data message with sequence numbers
>    present, it MUST begin sending sequence numbers in future outgoing
>    data messages. If the LNS enables sequencing after disabling it
>    earlier in the session, the sequence number state picks up where it
>    left off before.
> 
>    The LNS may initiate disabling of sequencing at any time during the
>    session (including the first data message sent). It is recommended
>    that for connections where reordering or packet loss may occur,
>    sequence numbers always be enabled during the initial negotiation
>    stages of PPP and disabled only when and if the risk is considered
>    acceptable. For example, if the PPP session being tunneled is not
>    utilizing any stateful compression or encryption protocols and is
>    only carrying IP (as determined by the PPP NCPs that are
>    established), then the LNS might decide to disable sequencing as IP
>    is tolerant to datagram loss and reordering.
> "
> The above clearly indicates that the Ns value for each end is present at
the
> other end to re-order and detect lost packets. Also, if the LNS disables
it
> and then re-enables it, the sequence number MUST start from where it left

There is no "MUST" in this sentence:

"If the LNS enables sequencing after disabling it earlier in the
session, the sequence number state picks up where it left off before."

But, having seen this text again here, I certainly agree that it would
not hurt for it to be clarified a bit overall. I will put this on my
list of things to do for l2tpbis. Thanks.

- Mark

> off.  THIS IS ALL STATEFUL INFORMATION THAT NEEDS TO BE RESET (I used the
> word resynch to really mean reset). I am fully aware of the difference in
> the use of the sequence numbers for control and data channel.
> 
> -----Original Message-----
> From: W. Mark Townsley [mailto:[email-masked]]
> Sent: Tuesday, March 06, 2001 8:22 PM
> To: Keyur Parikh
> Cc: Andy Koscinski; [email-masked]
> Subject: Re: Few questions on L2TP..
> 
> > Just a thought: How about ensuring that your hot standby router has full
> > state before even acknowledging the control message from your primary?
> > This doesn't require any changes to the protocol.
> >
> > KRP - This is not a very scalable solution.  Specially for the session
> data
> 
> Repeat after me: "Data messages do not need synchronizing", "Data
> messages do not need synchronizing", "Data messages do not need
> synchronizing"...
> 
> > messages. IMO, the RFC2661 should state what the LNS MUST do when it
> > receives session data messages without Ns when it was enabled by the
LNS.
> I
> 
> Sequencing on data packets within any tunneling protocol is a tricky
> subject.
> 
> IMHO, the LNS SHOULD accept them. One could argue that the LNS should
> have this wiggle room if it "knows" that sequencing is vital for the
> particular state of the protocol being carried or not. I suppose it
> would not hurt to make this more clear in the spec, though there are no
> easy answers here.
> 
> > agree with andy that some mechanism should be recommended for resetting
> the
> > stateful information between LAC and LNS.  How about assigning a bit in
> the
> > common header for this purpose. Anytime either end want to reset the
> > applicable sequence numbers they can set this bit in the control
message.
> 
> And then you have to check this bit for every single data packet just to
> enable the failover feature? Probably not a good choice. Error recovery
> should not slow down your data packet performance.
> 
> > This should trigger the other end reset its internal variables for the
> > control and all the data session of the tunnel.  Again this is just an
> > initial thought.
> 
> If we have the freedom to modify the protocol, this can probably all be
> done with explicit signalling. Also, you could decouple the tunnel
> control connection and sessions within if you wish. Bottom line, we
> didn't consider this when designing the protocol at the beginning. If we
> are going to modify the protocol to handle semi-full state failover,
> then we should step back and approach it from a fresh perspective.
> 
> - Mark

---

From: "W. Mark Townsley" <[email-masked]>
Date: Wed, 07 Mar 2001 14:16:34 -0500

> sequencing on its end etc..)

OK.

> packets, but a sequence number resetting mechanism is unwarranted.

Precisely. If you *were* to draw a line at how much percieved data loss
had occured at the LNS (or LAC) was acceptable, where would you draw it?
Fairly impossible, given the variety of data rates for L2TP and
considering that even an "in-order" packet is really just *perceived* to
be in order. Even without failover, you could have flushed exactly
65,535 packets down the tubes somewhere in transit and never have even
realized it! Unreliable data sequencing is just that, unreliable. It's a
shot at *trying* to get packets in order within a window, or at least
detecting that they were out of order within that window.

> for this purpose.  Obviously, all the race conditions have to be worked out.

I think there are even more ways to skin this cat....