Re: network device and tcp-flow packet ordering

Sally Floyd <floyd@aciri.org> Mon, 12 June 2000 17:44 UTC

Message-Id: <200006121744.KAA65040@elk.aciri.org>
To: Luigi Rizzo <luigi@info.iet.unipi.it>
cc: tcp-impl@grc.nasa.gov
From: Sally Floyd <floyd@aciri.org>
Subject: Re: network device and tcp-flow packet ordering
Date: Mon, 12 Jun 2000 10:44:23 -0700
Sender: owner-tcp-impl@lerc.nasa.gov
Precedence: bulk
Status: RO
Content-Length: 1138
Lines: 28

Luigi -

>Overnight thinking on TCP and reordering.

...
>wouldn't it make sense for the receiver who sees out-of-sequence
>delivery of packets to withold the ACKs for such packets until
>a) the hole is filled, or b) a small timeout has elapsed (this can be
>of the same order of the delayed ack timer, or half the RTT if we have
>a local estimate available).

I think that the Limited Transmit approach in
draft-allman-tcp-lossrec-00.txt makes more sense, of the receiver
sending dup ACKs, and the sender responding to the first and second
dup ACKs by sending new packets.  To my mind, this is closer to what
I would see as the ideal behavior, of the receiver's advertised
window being used to prevent overflow of the receiver's buffer,
and the congestion window being used to control the number of
packets outstanding in the pipe.

And if small timeouts turn out to be valuable before inferring a
packet loss from dup ACKs, then the sender could do that as well
as the receiver (assuming sufficient resources on the sending
machine).

- Sally
--------------------------------
http://www.aciri.org/floyd/
--------------------------------