[Iccrg] Question on RFC 2988 - TCP Retransmission timer

[Gorry Fairhurst]

I'm surprised that anyone would judge "200ms" as "safe" for general 
deployment, and would like to understand why they believe this is desirable.

I'd also wonder why tuning the min RTO is needed (except to recover from 
quirky packet loss in the few initial RTTs), since modern TCP does a 
pretty good job of recovering packets without needing timer tuning.

Gorry

Lachlan Andrew wrote:
> Greetings Ian,
>
> Since you've had no replies, here's my $0.02 worth.
>
> I haven't seen any specific research on that.
>
> Linux currently uses much higher precision timestamps than the old BSD
> implementations to which the RFC refers, so it shouldn't really be an
> issue.
>
> The fact that Vegas works in Linux also shows that its timestamping
> doesn't have systematic errors that would require a more conservative
> timeout.
>
> I agree that 1s is a terribly high minimum.  It looks like time for an
> update to RFC 2988 :)
>
> Cheers,
> Lachlan
>
> On 29/08/2007, Ian McDonald <ian.mcdonald at jandi.co.nz> wrote:
>   
>> After some discussion on the Linux networking list I thought I'd ask
>> the question here.
>>
>> In RFC 2988 Section 2.4 says:
>>    (2.4) Whenever RTO is computed, if it is less than 1 second then the
>>          RTO SHOULD be rounded up to 1 second.
>>
>>          Traditionally, TCP implementations use coarse grain clocks to
>>          measure the RTT and trigger the RTO, which imposes a large
>>          minimum value on the RTO.  Research suggests that a large
>>          minimum RTO is needed to keep TCP conservative and avoid
>>          spurious retransmissions [AP99].  Therefore, this
>>          specification requires a large minimum RTO as a conservative
>>          approach, while at the same time acknowledging that at some
>>          future point, research may show that a smaller minimum RTO is
>>          acceptable or superior.
>>
>> Given that Linux, BSD etc use 200 milliseconds, not 1 second I am
>> wondering whether there has in fact been any research done as
>> mentioned in last sentence. It seems a very high timeout especially on
>> two locally connected devices.
>>     
>
>
>