[Iccrg] Question on RFC 2988 - TCP Retransmission timer

[Mark Allman]

[I answered this on the TCPM list where Ian also posted it.  I am just
 now doing a little catchup on the ICCRG list and so I will replay my
 answer here.  --allman]


Ian-

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

I am not aware of any.

> It seems a very high timeout especially on two locally connected
> devices.

Well, a couple of things .... 

First, if the performance is driven by the magnitude of the RTO then
that is a more general problem than with the min RTO, I think.  We have
devised much better loss recovery than relying on the RTO and so one
would hope that RTOs are rare enough to not be driving performance.

Second, while I don't know of any recent research, I think [AP99] shows
that this is all a tradeoff and so one might want to be careful.  The
current algorithm (RFC 2988) does not often send spurious retransmits.
So, it stands to reason that when simply reducing the min and
calculating the time savings over the current min that things will in
fact be better.  I.e., you will not spend as much time waiting on
timeouts you need to take.  However, the flip side of the coin is that
by reducing the minimum you are also increasing the chances of the RTO
expiring needlessly.  I.e., if you had waited longer for the ACK then
you would not have needed the RTO at all.  The impact of this is harder
to gauge than simply computing the "wait time" because in this case the
cwnd will be needlessly collapsed to 1 segment and the connection will
have to build the window back up.

As an example, from the paper if you simply reduce the min from 1sec to
250msec (as close as we come to the 200msec you cite above) you see that
wait time is reduced by 36% and at the same time we experience 3.6 times
the number of spurious retransmits.

This is all a tradeoff it seems to me.  We could not find a magic 'sweet
spot' that seemed to be a win in terms of wait time and number of
spurious timeouts.

All that said, the data I am quoting is old.  Perhaps on modern networks
a smaller minimum would behave as 1sec did quite a while back.  I have
no idea.  I think it would be nice if someone did a study to find out.

I hope that helps in some way.

allman



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 185 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20070919/ae26b40e/attachment.bin