Subject: RE: Qos and L2TP (was: Do we want a new L2TP Header?)

From: "Chen, David" <[email-masked]>
Date: Fri, 15 Jun 2001 12:35:27 -0400

James,
Since peer A send out Terminate-Request,
Peer A is expecting closing the session.

I am wondering if anyone on this thread can make an example that
out-of-order PPP control messages (very few cases) can
break the PPP's state machine since most of the time the control
messages are sent one at a time. (re-transmit only count one message event)

Regards,

--- David

-----Original Message-----
From: James Carlson [mailto:[email-masked]]
Sent: Friday, June 15, 2001 12:27 PM
To: Chen, David
Cc: 'Evan Caves'; [email-masked]
Subject: RE: Qos and L2TP (was: Do we want a new L2TP Header?)

Chen, David writes:
> Looks like peer A is satisfied. (terminate the link)
> The peer B is happy after time out. (stopped the link)

Peer B isn't happy until after possibly very many timeouts -- it needs
to get TO- to get there.  Restarting A (which thinks that the layer
has stopped) makes the problem worse.  I'm not positive that there
aren't possible paths that lead to either looping or (worse)
inconsistent sets of options negotiated.

This was just one example of how the state machines don't function as
intended with reordering.  There are likely very many others.

> I don't see why out-of-sequence delivery will stop 
> PPP's state machine function correctly.

It's listed as a design constraint.  I think if you want to violate
it, then you really do need to put forward proof that a violation of
this constraint *never* leads to an inconsistent set of options or
other untoward behavior.  Simply saying that it doesn't appear so
isn't enough, and I'm afraid I don't have the spare cycles to chase
down all the paths at the moment.

Note that we were talking about the PPP state machine alone.  Things
are demonstrably worse for MP and the network layers.

> Is this case mentioned in the P.14 of RFC1661 under Stopped state?

Sort of.  But not with reordering.

-- 
James Carlson, Internet Engineering       <[email-masked]>
SUN Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677

---

From: Jeff Mcadams <[email-masked]>
Date: Fri, 15 Jun 2001 12:51:44 -0400

Also sprach Chen, David
>out-of-order PPP control messages (very few cases) can break the PPP's
>state machine since most of the time the control messages are sent one
>at a time. (re-transmit only count one message event)

And if noone steps forward with proof that re-ordering causes control
messages real problems?  What are your intentions?  Declare that we
don't need sequence numbers at all in L2TP?

What are you shooting for so aggressively here?

Putting sequence numbers on PPP control protocols just isn't going to be
that big of a deal really...I can't imagine that there would be any need
to apply differing QoS to control protocol messages, so go ahead and
sequence them, there's virtually no downside to it.

I do hope that you don't plan to suggest that PPP control protocols
don't need sequencing so we can ditch sequence numbers altogether as you
have yet to address the point that I and James Carlson have made (don't
remember which of us made it first...probably him :) that there are
other protocols carried by PPP which are *definitely* harmed by
re-ordering, thus requiring sequence numbers, thus we have to maintain
that capability, thus you might as well use it for PPP control messages.
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456