[AusNOG] TCP - Fast Retransmit / Normal Retransmit times

[Lawrence Stewart]

On 02/10/15 23:31, PRK wrote:
> On 2015-02-10 21:34, Edwin Groothuis wrote:
>> On 10/02/2015 6:13 pm, PRK wrote:
> 
>>> In particular, what's the expected behaviour if a Fast Retransmit (of a
>>> packet that's been lost/dropped) also gets lost/dropped?
>>>
>>> How long would be expected before a normal retransmit should be sent?
> 
>> The initiative for a Fast Retransmit lays by the receiver, while the
>> initiative for a normal retransmit lays by the sender.
>>
>> If a Fast Retransmit sequence (3 duplicate ACKs) doesn't get received by
>> the sender of the original packet, then the sender will detect the
>> timeout and retransmit the original packet with the normal 1.5, 3, 6 etc
>> seconds interval.
> 
> The scenario I'm taking about is when a packet gets dropped, so the
> receiver sends back duplicate acks, to indicate it missed that sequence.
> 
> The sender gets those three acks, so initiates a fast retransmit of the
> missing sequence.
> 
> However, that fast transmit also suffers the same fate as the original
> packet, and never reaches the receiver.
> 
> So the sender thinks it's initiated a fast retransmit, the receiver has
> dup acked all the packets it got in the window size as they weren't the
> missing sequence.
> 
> Now, how long does the sender wait, after sending that fast retransmit
> and not getting an ack, before it initiates a normal re-transmit.

TL;DR: The timer responsible for what you call a "normal" retransmit,
correctly known as a retransmit timeout (RTO), is reset when the fast
retransmit is sent, and will fire when the elapsed time since sending
the fast retransmit exceeds the RTO. What the RTO for a given connection
is depends on the connection's smoothed RTT and variance, and is
computed according to:

https://tools.ietf.org/html/rfc6298

Some more in depth information...

It obviously depends on the stack implementation you're using, but
here's some hopefully useful context based on (de-facto) standards
(which most common implementations follow more or less)...

https://tools.ietf.org/html/rfc5681 describes the relevant algorithms,
and section 3.2 in particular describes fast retransmit and fast recovery.

In a nut shell, the first 3 dup acks trigger the sender to fast
retransmit, reset the retransmit timeout (RTO) and enter fast recovery
mode. All dup acks past the 3rd inform the sender that a further segment
has likely been received, so the sender will typically (depending on the
stack implementation and congestion control algorithm being used)
transmit new data following the fast retransmit of the lost segment(s).
e.g. for "New Reno", the sender does so at the rate of 1 new packet for
every 2 dup acks i.e. half the pre-loss transmission rate.

(If selective acknowledgements have been negotiated by both peers for
the connection, the above behaviour changes if more than 1 packet was
lost, but let's assume only 1 was dropped.)

Regardless of the new segments eliciting new dup acks, if the fast
retransmit is lost, the dup acks will still be for the same missing
sequence number, so the sender won't advance snd_una (left edge of the
send window sequence space), won't reset the RTO timer and therefore the
big hammer will be applied to restart the connection when the RTO fires.
RTOs are very undesirable for connection performance, so the loss of a
fast retransmit packet is very unfortunate.

Cheers,
Lawrence