Re: [tcpm] TCP tuning

[Mark Allman <[e-mail]>]

[These are re-sends from long ago... they never made it to the list.
 But, that seems to have been worked out, now.  --allman]

> " (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."
> 
> Is it time to reconsider a smaller minimum RTO as well? 

One problem with the minimum is we don't know what to set it at [*].
The finding in [AP99] is that as you reduce the min you take more
spurious timeouts.  The tradeoff seemed fundamental to us.  But, given
our methodology (trace driven simulation) we could not really tell the
impact of the spurious timeouts.  So, we just sought to minimize them in
the spec.  I know some TCP implementations are being pretty aggressive
with the min these days.  But, it is not at all clear to me whether this
is a net win or net lose.  I.e., is the win in terms of peppiness to
needed retransmits still a win when it is played against the
consequences of a spurious transmit (i.e., setting cwnd = 1)?  Perhaps
there is a sweet spot that is < 1sec whereby this tradeoff better
balances and we should be using that.  But, it'd take a big experiment
to show that, I think.

[*] Maybe there is work that I just don't know about and if so I'd like
    to be pointed at it.

Another thing I have wondered about from time to time .... Much like
Early Retransmit could we have some sort of early RTO when the cwnd size
is small?  When the window size is small it seems that the downside of
making a bad rexmt decision is not as bad as when the cwnd is large so
it might pay in terms of responsiveness to RTO sooner.  Also, as the
cwnd gets larger we have better loss recovery techniques that should
come into play that can repair lots of loss without involving the RTO
and so perhaps by being overly aggressive in the RTO we just hurt
ourselves.  Finally, as the cwnd gets bigger that means we are
transferring more data.  And, the longer a connection goes the less
important the fine-grained responsiveness matters.  Just a random
thought ...

allman