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

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

James,
Thanks for the example.
However, it is a bit confusion.
It this what you mean?

(time laps from top to bottom)

	Peer A                  Peer B
	Configure-Ack ----+
	 (state 7->9)     |
	Terminate-Request |
	 (state 9->4) ----|---> reply Terminate-Ack
	                  |      (state 8->6)
	 (state 4->2) <---|----
	                  +---> (state 6->7) (irc)
				      (TO-)
					(state 7->3)

Looks like peer A is satisfied. (terminate the link)
The peer B is happy after time out. (stopped the link)

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

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

Regards,

--- David

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

Chen, David writes:
> If PPP state machine can recover from
> its packet drop,
> it seems able to treat out-of-order pakcets the same way?

The two events are rather different.  For one (random) example of
breakage, consider what happens if Configure-Ack and Terminate-Request
(transmitted in that order) are interchanged:

	Peer A                  Peer B
	Configure-Ack ----+
	 (state 7->9)     |
	Terminate-Request |
	 (state 9->4) ----|---> reply Terminate-Ack
	                  |      (state 8->6)
	                  |
	                  +---> (state 6->7)

From then on, A is stuck in Closed (2) and B is stuck in Req-Sent (6)
(both due to Terminate-Ack) until B eventually gives up.  That's not
at all what was intended.

I can't say I've plumbed the depths of this topic.  There's a lot
that's possible when you have fundamentally undetectable reordering.

Also, for MP, bridging, and other non-IP applications, reordering is
decidedly fatal.

-- 
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: James Carlson <[email-masked]>
Date: Fri, 15 Jun 2001 12:26:40 -0400 (EDT)

> 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.

> 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.