Re: [tcpm] New ID available: RFC2988bis (RTO calculation)

[Mark Allman <[e-mail]>]

[This is a re-send.  My original note did not make it to the list.  I
 made a tweak to my mail setup.  Lets see if this works. --allman]

> currently the document only suggests lowering the initial RTO.
> IMHO we should also discuss if we want to lower the minimal RTO, too.

I have two responses to this ...

  - First, I sent a technical note to the list on Feb/11 about changing
    the min.  I am appending that to this note.

  - Second, it seems that we should keep these two questions independent
    to me.  It seems to me that changing the initRTO is pretty minor and
    well-scoped, whereas changing the minRTO has more unknowns.  So, I
    am not at all opposed to thinking about both changes as you suggest,
    but coupling them is likely to hinder progress on the initRTO
    (IMO). 

Just my 2c.

allman




> 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