Re: Notes on draft-crocker-mast-analysis-01.txt

["Spencer Dawkins" <spencer@mcsr-labs.org>]

Hi, Iljitsch,

What Dave said, at least re: TCP.

If I send a segment that arrives out of order at the recipient, the
recipient decides that the "hole" may be a lost packet and begins
sending duplicate ACKs every time it receives a segment, until the
hole is filled in. When the sender receives the third duplicate ACK,
it says "oops, must be a lost packet", performs Fast Retransmit, and
then cuts its congestion window in half (Fast Recovery).

This does not make TCP run faster, since increases are additive (one
additional segment per RTT, building back up to a full congestion
window) while decreases are multiplicative (if you cut the congestion
window in half, have a couple of good RTTs, and then have another
out-of-order Fast Retransmit/Fast Recovery, the sender cuts the
congestion window in half AGAIN).

If your out-of-order-delivery problem is only one or two packets
before the hole is filled in, that's OK, but in the general case,
deployed TCPs don't handle much out-of-order-delivery before you start
seeing performance hits.

There are experimental proposals to make the Fast Retransmit/Fast
Recovery threshold adaptable, but they are not standardized or
deployed.

Spencer

p.s. Mark Allman - am I still telling the truth?

----- Original Message ----- 
From: "Dave Crocker" <dhc@dcrocker.net>
To: "Iljitsch van Beijnum" <iljitsch@muada.com>
Cc: "Spencer Dawkins" <spencer@mcsr-labs.org>; "Multi6 Mailing List"
<multi6@ops.ietf.org>
Sent: Thursday, October 30, 2003 6:16 PM
Subject: Re: Notes on draft-crocker-mast-analysis-01.txt


> Iljitsch,
>
> IvB> What is sensitive to out of order delivery? The GE interfaces
or TCP?
>
> TCP and IP.  Having packets arrive out of order hurts fast-path
performance.
> the inherent requirement is to take a packet and put it into a
holding
> position until it becomes 'in order'.  The required checking and
holding and
> retrieving hurt performance.
>
>
> IvB> If TCP has problems with out of order packets, then it hasn't
been
> IvB> implemented terribly well.
>
> If you know of a TCP implementation that does not take a performance
hit with
> out-of-order packets, please cite the data