Subject: Re: Nr in data packets

From: Vernon Schryver <[email-masked]>
Date: Mon, 24 Jan 2000 15:02:49 -0700 (MST)

> From: David Chen <[email-masked]>

> IP service does not guarantee packet delivery in sequence.
> Clearly, UDP/IP does not neither and
> TCP treat out of sequence packet as if loss of packet. -
> as appose to buffering and re-ordering (packets).
> (therefore, TCP provides in sequence no-loss packet delivery)

I think I did not say that "TCP [treats an] out of sequence packet as if
[it were] loss of packet," and I think it is wrong.  Any reasonable TCP
implemention will save an out-of-order segment that is in the receive
window, and generate an ACK for the current edge of the window.  I did
say that out of order packets cause duplicate ACKs which cause
retransmissions and reduction of the congestion window.  The difference
between "treat out of order as loss" and what I said is technical, but I
think the difference is significant.

> As for L2tp, a packet such as PAYLOAD/TCP/IP/PPP/L2TP/UDP/IP on the 
> protocol stack,
> is clearly that L2TP does not need keeping the packet sequence and dropping 
> the packet for
> the same reason (keeping packet sequence).

Maybe that's clearly correct to you.  If I understand what you mean, the
opposite is clearly correct to me.  As I said before, PPP does not and
cannot drop control protocol packets when they are out of order.  Instead,
the PPP state machines must and do act on the miss-ordered stimuli.  TCP
also generally does not drop segments when they are out of order.  Also
as I keep pointing out, there are more PPP payloads than TCP/IP, and some
of them, such as bridging, do not tolerate reordering at all.

Have you read RFC 1661 and understood the state machine?  Do you know what
I mean by "congestion window" and "duplicate ACKs?"  Do you know what I
mean when I repeatedly mention bridging?  Perhaps you do, but I have the
nagging feeling that you are arguing based on how you think PPP and TCP
should or work or be specified instead of how they are specified and work.

Vernon Schryver    [email-masked]

---

From: David Chen <[email-masked]>
Date: Tue, 25 Jan 2000 18:32:46 -0500

1) It seems need more illustration to my point
   For a L2TP packet such as PAYLOAD/TCP/IP1/PPP/L2TP/UDP/IP2 on the 
protocol stack:
The IP1, IP2, and UDP services does not guarantee packet delivery in sequence
yet, TCP and PPP with flow control does.
if L2TP service guarantee packet in sequence delivery then it does not
help the PAYLOAD or TCP due to that the IP1 service still does not 
guarantee packet
delivery in sequence.
2) The argument about LCP,NCP needs underlying protocol provide packet 
delivery in
sequence is not so clear:
When sender send out Config-Req, it will not send any packet (to move the 
statemachine)
untill the receiver responds with Config-XXX....
Can you illustrate how the PPP state machine send out more than one different
protocol frame in one state... thereby need the packet sequence delivery 
service
3) For TCP's argument about needs packet sequence delivery service from IP 
is impossible
and its design drawback to handle this issue, please refer to the
page 536, 3rd paragraph about "what to do with out of order segments" of 
book "Computer Networks" by Andrew S. Tanenbaum, ISBN 0-13-349945-6.

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