diff options
author | Aki M Nyrhinen <anyrhine@cs.helsinki.fi> | 2006-06-11 21:18:56 -0700 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2006-06-11 21:18:56 -0700 |
commit | 79320d7e14900c549c3520791a297328f53ff71e (patch) | |
tree | bd2c9cc7f2d4b7790ad1e18fb9a00aad621c0354 /Documentation/cdrom | |
parent | afec35e3fee900b3016519d0b5512064e4625b2c (diff) |
[TCP]: continued: reno sacked_out count fix
From: Aki M Nyrhinen <anyrhine@cs.helsinki.fi>
IMHO the current fix to the problem (in_flight underflow in reno)
is incorrect. it treats the symptons but ignores the problem. the
problem is timing out packets other than the head packet when we
don't have sack. i try to explain (sorry if explaining the obvious).
with sack, scanning the retransmit queue for timed out packets is
fine because we know which packets in our retransmit queue have been
acked by the receiver.
without sack, we know only how many packets in our retransmit queue the
receiver has acknowledged, but no idea which packets.
think of a "typical" slow-start overshoot case, where for example
every third packet in a window get lost because a router buffer gets
full.
with sack, we check for timeouts on those every third packet (as the
rest have been sacked). the packet counting works out and if there
is no reordering, we'll retransmit exactly the packets that were
lost.
without sack, however, we check for timeout on every packet and end up
retransmitting consecutive packets in the retransmit queue. in our
slow-start example, 2/3 of those retransmissions are unnecessary. these
unnecessary retransmissions eat the congestion window and evetually
prevent fast recovery from continuing, if enough packets were lost.
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'Documentation/cdrom')
0 files changed, 0 insertions, 0 deletions