netdev
[Top] [All Lists]

Re: TCP and SACK retransmissions

To: Ramón Agüero <ramon@xxxxxxxxxxxxxxx>
Subject: Re: TCP and SACK retransmissions
From: Andi Kleen <ak@xxxxxx>
Date: Wed, 13 Jun 2001 03:38:32 +0200
Cc: netdev@xxxxxxxxxxx
In-reply-to: <006701c0ee7f$892f2740$1bba90c1@tlmat.unican.es>; from ramon@tlmat.unican.es on Wed, Jun 06, 2001 at 01:55:08PM +0200
References: <006701c0ee7f$892f2740$1bba90c1@tlmat.unican.es>
Sender: owner-netdev@xxxxxxxxxxx
[Please use line breaks every 80 characters when writing email]

On Wed, Jun 06, 2001 at 01:55:08PM +0200, Ramón Agüero wrote:
>     When a Duplicate ACK arrives, the tcp_fast_retrans function is called. 
> Aparentely, this function does not trigger any retransmission unless 
> tp->dup_acks == 3 or tp->fackets_out > 3. In some ocassions this is the 
> behaviour I see (by tcpdump captures), but in other cases, the first dupack 
> triggers a retransmission, although the number of sacked segments is only 
> two. I have tried to see why this retransmission is trigerred, but I can't 
> find it. Can anybody put some light in this tunnel :-) ?

You're probably seeing the Hoe heuristic, which extends Fast Retransmit to
fix more than a single lost packet per RTT. See Janey Hoe,
"Improving the startup behavior of a congestion control scheme for tcp".
It is a variant of NewReno as described in RFC2582.


-Andi

<Prev in Thread] Current Thread [Next in Thread>