Re: [tcpm] initial RTO (was Re: Tuning TCP parameters for the 21st century)

[Mark Allman <[e-mail]>]

> I can think of a number of variations. The one-shot 1-sec-initRTO idea
> you described above also came through my mind but the drawback is you
> only get one-shot even though we know statistically > 98% of
> connections have RTT < 1 sec so most likely the continuous use of
> 1-sec-initRTO will turn out to be better. (A counter argument might be
> one-shot is "good enough", benefitting > 90% of the cases
> statistically...) The advantage of it is its simplicity, restricting
> the max # of spurious retransmissions caused by the reduced initRTO to
> 1, and obviously avoiding the RTO hell problem.

Two responses to "one shot":

(1) Yes, one-shot ought to be enough.  Considering losing the SYN,
    retransmitting it using an initRTO of 1sec and reseting the initRTO
    to 3sec.  Now, if there is actually loss in the first RTT of data
    transmission talking about fine-grained performance (i.e., that we
    can get from using 1sec again instead of 3sec) doesn't make a lot of
    sense because 1sec vs. 3sec doesn't matter because performance is
    going to suck no matter what.  So, why bother with anything terribly
    "smart" here?

(2) Using the numbers on your slides it seems to me that the fraction of
    hosts with an RTT of > 1sec is roughly the same as the SYN
    retransmit rate (at an RTT of 3sec, I assume).  To me that says that
    if you use an initRTO of 1sec and then retransmit then the reason
    for that retransmit is just as likely to be loss as it is to be a
    long path.  So, your approach of preferring more than one-shot
    assumes loss.  But, I don't see the measurements you gave as
    suggesting that is the right approach.  The notion of going back to
    3sec just sort of punts.  I.e., the notion is that we have hit a
    situation whereby we don't know what is going on and so let's not
    dogmatically try to push forward, but let's throw up our hands and
    try to do things that ultimately will figure out what is going on.
    And, further, one mistake does not propagate.

So, for me one-shot is just about the right balance here.  Any more than
that we're getting into the corner of a corner case and further in that
corner the empirical evidence is not suggestive of a clear path.  So,
let's just do something that will allow the protocol to get a handle on
things as they are in the specific situation and not try to make guesses
that propagate further.

allman