[AusNOG] TCP - Fast Retransmit / Normal Retransmit times

[PRK]

Thanks Lawrence, that's exactly what I was trying to understand.

prk.

On 2015-02-16 14:31, Lawrence Stewart wrote:
> On 02/10/15 23:31, PRK wrote:

>> 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