Subject: RE: Silent Packet Loss & Header Compression

From: Ramana Gollamudi <[email-masked]>
Date: Wed, 23 May 2001 18:16:24 -0400

Agreed. However, most of internet seems to work reasonably well without
intermediate nodes doing providing any support for ensuring ordered
delivery. Best effort seems to enough. The argument in this mail chain
seemed to indicate that MP PPP spread over a multiple LACs is the driver for
sequencing in L2TP. So, I wondered how common this usage is, and what does
it really solve?

I would really appreciate any pointers to old discussions on this.

Ramana

-----Original Message-----
From: Ken Peirce [mailto:[email-masked]]
Sent: Wednesday, May 23, 2001 6:03 PM
To: 'Ramana Gollamudi'
Subject: RE: Silent Packet Loss & Header Compression

TCP has an intense dislike for resequencing.

> -----Original Message-----
> From: Ramana Gollamudi [mailto:[email-masked]]
> Sent: Wednesday, May 23, 2001 2:46 PM
> To: 'James Carlson'
> Cc: [email-masked]'
> Subject: RE: Silent Packet Loss & Header Compression
> 
> 
> A newbie question on this topic. Is sequencing in the data 
> plane used in
> existing popular implementations.  I wonder if there are significant
> performance implications due to sequencing?
> 
> Ramana
> 
> -----Original Message-----
> From: James Carlson [mailto:[email-masked]]
> Sent: Wednesday, May 23, 2001 12:04 PM
> To: Ignacio Goyret
> Cc: [email-masked]; Jonathan Goodchild; [email-masked]'
> Subject: Re: Silent Packet Loss & Header Compression
> 
> 
> Ignacio Goyret writes:
> > That would fail fatally if the client is using MP since no 
> single LAC is
> > guaranteed that it will have access to all the channels 
> composing an MP
> > link, which is one of many reasons why LACs should not do 
> anything like
> that.
> 
> Running MP over L2TP over a lossy or delay-prone network is a bad idea
> to begin with.  Having the MP links bundled in a LAC-local manner (as
> with Bay's MMP) and then representing the bundle as a single PPP
> session to the LNS is a much better answer.
> 
> Note that because of the Endpoint-Discriminator issues, MP over L2TP
> where the LAC endpoints are *not* reasonably local to each other just
> doesn't work anyway.
> 
> -- 
> 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: Thu, 24 May 2001 08:11:27 -0400 (EDT)

Ramana Gollamudi writes:
> delivery.

That assumption is false.  Well-designed routers take a great deal of
care to avoid reordering IP packets within a flow.  This is a
substantial concern even at high speeds with (presumably) high levels
of traffic aggregation.

It's true that reordering does sometimes occur, but it should be quite
rare and due to transient problems at the network level (i.e., route
flaps) and not due to design flaws.

> Best effort seems to enough.

"Best effort" does not mean "reorder at will."

> The argument in this mail chain

No.  The driver for sequencing in L2TP is two-fold.  RFC 1661 says:

1.  Introduction

   The Point-to-Point Protocol is designed for simple links which
   transport packets between two peers.  These links provide full-duplex
   simultaneous bi-directional operation, and are assumed to deliver
   packets in order.  It is intended that PPP provide a common solution
   for easy connection of a wide variety of hosts, bridges and routers
   [1].

The second reason is that some network layer protocols that run on PPP
cannot tolerate link-layer reordering of packets.  Reportedly, this is
a problem with SNA.  (I haven't worked with SNA in so many years now
that all of those brain cells have been recycled.  ;-})

-- 
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: Thu, 24 May 2001 08:17:44 -0400 (EDT)

Ramana Gollamudi forwarded this bit of apparently private email to the

> TCP has an intense dislike for resequencing.

That has little to do with L2TP data sequence numbers.  Reordering on
the order of magnitude that can be expected with a well-implemented
lower (sub-L2TP) IP layer is not a problem for TCP performance.  In
fact, the mechanism that you may use in L2TP to straighten out the
ordering (buffering and delays) is no better than what TCP would do,
and likely is a bit worse.

The problem with reordering, from TCP's perspective, is that it kicks
you out of the fast path in most implementations.  If you're going to
delay packets in the hope the you can resolve the ordering later,
you're already negating the gain seen by being in the fast path in the
first place.