Subject: Re: Nr in data packets

From: "W. Mark Townsley" <[email-masked]>
Date: Tue, 25 Jan 2000 11:48:16 -0500

So, a router interface should queue all incoming IP packets while it
takes a large one and splits it into one or more IP fragments? 

Sigh, this discussion has veered away from the meaningful, and is headed
down a course of toward who misunderstood who like some bad comedy. 

The bottom line is this: L2TP data packets carrying PPP/IP is ultimately
an IP packet within an IP packet. Applying sequencing checking to a
tunneled IP packet would surely make a the original IP architects
shudder just as much as reordering PPP frames does for a PPP guru. Each
are fundamental, opposing, assumptions for each protocol, respectively. 

Together, we have identified cases where checking packet sequence and
not checking packet sequence can break the tunneled connection. We could
compare pathological examples all day. In practice, I have seen only one
of these occur in a repeatable fashion. If you want to avoid this, my
recommendation is to not check sequencing on tunneled IP packets. 

- Mark

Vernon Schryver wrote:
> 
> > From: "W. Mark Townsley" <[email-masked]>
> 
> > ...
> > > > We all know that, by design, IP may reorder packets. I see no reason why
> > > > it is L2TP's business to correct this for tunneled PPP/IP frames.
> > >
> > > That is a straw man.  No one said anything about correcting the
> > > order of already mis-ordered IP frames.
> >
> > Then I misunderstood you.
> 
> I do not see how you could have honestly believed I was talking about
> fixing the order of already out of order IP packets.  That task is
> obviously impossible.  There is no way that any intermediate box (or in
> the case of L2TP, 2 or 3 boxes) can know the correct order of IP payloads.
> An intermediate box cannot rely on IP ID's, and there is no other clue.
> Only the sending and receiving hosts know the correct order of UDP packets.
> 
> > ...
> > Yes. I was refuting using broken TCP/IP stacks as a design constraint on
> > L2TP.
> 
> Ok, it's good we're not arguing about that either.  Let's also apply that
> idea to not using broken TCP/IP stacks inside L2TP implementations as a
> design constraint on L2TP or as a justification for doing something wrong.
> 
> > > It is well known among that miss-ordering TCP/IP packets harms RFC
> > > compliant TCP/IP implementations  ...
> 
> > I don't believe L2TP should mis-order packets, but it should not have to
> > go out of its way to preserve the order of already mis-ordered IP
> > frames.
> 
> Again, that makes no sense to me.  L2TP obviously cannot do anything
> about already mis-ordered IP frames.  I thought the sequence number
> inside L2TP is to ensure the L2TP does not increase mis-ordering
> as the result of mis-ordering from layers below L2TP, and also to
> keep L2TP from breaking things that do not tolerate any mis-ordering
> including PPP bridging and PPP CP packets.
> 
> > ...
> > I don't think you understood. I was referring to fragmentation of an IP
> > packet transmitted from the client. The circumstance causes the two IP
> > fragments, each framed as individual PPP packets, to be repeatedly
> > misordered exiting the LAC (due to fragmentation of one of the two
> > already fragmented packets at the LAC). It was not actually L2TP that
> > was misordering the packets, it was the IP stack on the LAC. It did so
> > because of fragmentation of one of the two initial IP fragments.
> >
> > Perhaps more detail would help: The smaller of the two IP fragments
> > sequence checking of IP assumes that reordering is a random phenomena,
> > when in fact it is not. IP sequence checking in the face of a consistent
> > packet misordering situation results in an unrecoverable denial of
> > service (unless a route change or some such actually restores the order
> > by chance).
> 
> So you saw a router that consistently moves smaller packets ahead of larger
> packets?  I think that's compliant, but generally a bad idea, and certainly
> not justification for turning off L2TP sequence numbers.  Note that I've
> shipped PPP code that optionally ordered its transmit queue to send most
> *but not all* tinggrams ahead of big packets as an ad hoc type-of-service
> differentiation.  I no longer recommend that hack.
> 
> You are justifying a bad idea (turning off L2TP sequence numbers) based
> on the bad behavior a broken box (one that consistently mis-orders IP
> packets).
> 
> Put asside short term sales considerations and think about the long term.
> Which do you think would be the better course, fixing the broken box to
> not mis-order IP packets or turning off L2TP sequence numbers?  The broken
> box will cause significantly reduced TCP throughput and increased latency
> regardless of whether it uses L2TP sequence numbers.  It will also stress
> the IP fragmentation reassembly mechanisms in receivers, and that will
> cause increased IP packet losses.  Eventually even people who are so inured
> to garbage that they tolerate daily blue screens of death will notice the
> difference between using this broken box and others.  Since they won't be
> constrained by the availability of applications like MS Office and IE,
> and since the primary criteria on which routers are evaluated is speed
> and reliability, they'll switch.
> 
> > ...
> > > The standard problem of standards committee protocols is bloat with
> > > optional features and switches switches that no one will ever use because
> > > they cannot be used in real life.  As far as I can see, any switch that
> >
> > There is at least some notion of removal of features that never get used
> > as the document advances the standards track.
> 
> That sentiment is always offered to justify bloating a protocol with
> optional bad ideas.  Because in real life standards committees specifically
> including PPP working groups, optional bad ideas that get as far Proposed
> Standard are *NEVER* removed makes the sentiment at best uninformed.
> Consider the many bad optional ideas in and among PPP protocols, and notice
> how many have been removed.  Some have been proposed for deletion, but
> somehow the removal efforts always stall.
> 
> > What you say about committee-born protocols is true in many regards, and
> > L2TP is niether immune nor alone in this arena. The upside in our case
> > is a fairly large number of interoperable implementations, and general
> > industry acceptance.
> 
> That bit about "general industry acceptance" is usually said of protocols
> for which it is in fact false.  I hope it is true in this case, but I
> can't tell.  It's probably too early to say.
> 
> Vernon Schryver    [email-masked]

---

From: Vernon Schryver <[email-masked]>
Date: Mon, 24 Jan 2000 10:22:57 -0700 (MST)