Subject: Re: Nr in data packets

From: Vernon Schryver <[email-masked]>
Date: Fri, 21 Jan 2000 10:56:35 -0700 (MST)

> From: "W. Mark Townsley" <[email-masked]>

> ...
> RFC 1661 states that all packets are assummed to be delivered in order.
> Some protocols (VJ header compression, PPP payload compression and
> encryption) were designed with this in mind.

You must also add RFC 1990 (MP) to that list of PPP protocols that assume
that the order of the stream of packets is preserved.  Re-ordering MP
fragments is not catastrophic in PPP systems that handle MP sequence number
roll-over robustly, but re-ordering can stall the delivery of the data
(e.g. IP) until the non-standard timers in robust MP implementations fire.

>                                              Further, the CPs that run
> on PPP may have a problem with out of order packets, though given their
> stop and wait nature and relatively long default timeout between
> retransmissions, it is unlikely. 

I think that is wrong.  The request-response nature of CP's makes
re-ordering unlikely on paths that does re-order packets, but does not
protect against re-ordering when it does happen.  Think about the
many places in the RFC 1661 state machine that break catastrophically
with any re-ordering.
There are also interactions among CP's that would be broken by packet
reordering, such between authentication and LCP, and between LCP and
everything else.

> The bottom line is, PPP has an in-order delivery assumption, thus L2TP
> must have some way of not breaking this. It is optional, so if the user
> understands the risks then sequence numbers may be omitted.

Who is the "user" that is doing that understanding of risks?  The typical
Windows 98 or even NT user does not have a clue about what an packet stream
might be.  Many technical people at ISP's are as well informed, although
they don't realize it and certainly won't admit it.

>                                                             We have
> found that, w/o the stateful protocols listed above, operating w/o
> guaranteed delivery order reduces L2TP overhead, and does not adversly
> affect the PPP stream.

What measurements have you made of the results of packet reordering
on PPP?  That reasonable PPP implementations will probably recover from
any single instance of reordered packets, possibly by tearing down the
link and restarting, is not the same as "does not adversely affect the
PPP stream."

Have you considered of bad effects that packet reordering has on TCP
performance?  Re-ordered TCP/IP segments cause retransmissions and reduce
the congestion window.  Those bad effects of re-ordered IP datagrams are
why official PPP multilink in RFC 1990 is much better than "BF&I" or "load
sharing" multilink, despite the greatly reduced complexity and theoretical
reliability of the latter.

Vernon Schryver    [email-masked]

---

From: David Chen <[email-masked]>
Date: Fri, 21 Jan 2000 14:40:13 -0500

Another related topic is "PPP over ethernet" that
the underline layer is not lossless and not serial transmission.
Also, MP has to re-ordering frames anyway when fan-in (reverse multiplexing)
all individual links.
--- David

>Vernon Schryver    [email-masked]

========================================
David Chen
Indus River Networks, Inc.
31 Nagog Park
Acton, MA 01720
U.S.A.
[email-masked]
(978) 266-8141
========================================