aboutsummaryrefslogtreecommitdiff
path: root/Documentation/cdrom
diff options
context:
space:
mode:
authorAki M Nyrhinen <anyrhine@cs.helsinki.fi>2006-06-11 21:18:56 -0700
committerDavid S. Miller <davem@davemloft.net>2006-06-11 21:18:56 -0700
commit79320d7e14900c549c3520791a297328f53ff71e (patch)
treebd2c9cc7f2d4b7790ad1e18fb9a00aad621c0354 /Documentation/cdrom
parentafec35e3fee900b3016519d0b5512064e4625b2c (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