Re: network device and tcp-flow packet ordering

[Lloyd Wood <[e-mail]>]

On Sat, 10 Jun 2000, Craig Partridge wrote:

> There's no RFC that says it.

thank goodness. hurrah. etc.


> However, Jon Bennett, Nick Shectman and I published a paper showing how
> packet reordering really trashes TCP performance in IEEE/ACM Trans. on
> Networking last year.

imo this really indicates a problem with the state of the art of TCP's
congestion algorithms; TCP deserves to be trashed, and fast recovery
could be a lot more flexible here. (cf section IV C of that Dec. 1999
paper.)

relevant work I don't think has been mentioned in this thread yet:

http://www.ietf.org/internet-drafts/draft-allman-tcp-lossrec-00.txt

draft-allman-tcp-lossrec-00.txt [Enhancing TCP's Loss Recovery Using
Early Duplicate Acknowledgment Response, M. Allman, H. Balakrishnan,
S. Floyd]

This draft discusses selectively _lowering_ the fast recovery
threshold under certain specific low-window conditions (and cites the
paper Craig mentions above).

AFAIK there are as yet no concrete implementation proposals for TCP to
selectively _raise_ this threshold in the face of continual
misordered delivery.

(no doubt because that's a much less conservative and open-ended
 change that would require a lot more study of the dynamics under a
 wide range of conditions, and probably some experimental operational
 observation as well).

Raising the TCP sender's 3-dupack threshold to increase its tolerance
when experiencing packet/ack reordering won't restore the level of TCP
goodput to that of a perfectly ordered flow, which is the maximum
bound - but you can improve throughput and gradually approach that
bound as you raise the threshold. (I've shown this in simulation for
part of a submitted paper.)

Work done within the network reordering a flow of in-transit packets
is work wasted on not doing useful delivery.

imo any packet network should be _encouraged_ to gratuitously misorder
packets (especially if locally appropriate for delivery efficiency)
without worrying about the endeffects - it's the easiest way to keep
the equipment simple (cf the workconserving appendix to Bennett et
al's paper).

Having all the network work like hell to maintain the illusion that an
ordered circuit-like flow can be maintained all the time is a Crime
Against Nature. (Well, entropy.)

Put reordering complexity in the receiver where it belongs. Once.
Not in every implementation of every protocol in every switch.
Improve TCP, and build *simpler* fast packet networks.

L.

read can this understand you perfectly the point you if. Yoda as does.

<[e-mail]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>