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

From: "Chen, David" <[email-masked]>
Date: Fri, 15 Jun 2001 11:11:58 -0400

James,

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

Regards,

--- David

-----Original Message-----
From: James Carlson [mailto:[email-masked]]
Sent: Friday, June 15, 2001 11:05 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:
> LCP's PPP negotiation is sender sends out one LCP packet and wait for
> receiver respond back one LCP packet.

Not true.  Think retransmit.

> I am wonder why the l2tp has to provide in-order-packet delivery for 
> PPP's control packets?

It's a basic assumption of PPP itself.

> On the PPP's data packet, since it encapsulate the IP, 
> it seems no need for l2tp provide packet in-order delivery.

Assuming only plain IP over PPP, sure, that's true.  For bridging, VJ,
CCP, MP, and many other things PPP carries, that's not true.

> However, it is possible that PPP peers negotiated successive
> (state-sensitive) compression 
> that it requires compressed packet deliver in order. 
> Even it can recover form compressed packet drop,
> it will improve the data bandwidth usage 

The data compression protocols have been designed with *drops* in
mind.  Not 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 11:29:32 -0400

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

No, as it has no way of knowing that they are out of order, and could
therefor trigger a state transition that shouldn't happen.
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

---

From: James Carlson <[email-masked]>
Date: Fri, 15 Jun 2001 11:33:03 -0400 (EDT)

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