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

[Jerry Chu <[e-mail]>]

On Wed, Jul 29, 2009 at 9:05 AM, Mark Allman<[e-mail]> wrote:
>
>> 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?

Guess we have some disagreement here and it's not surprise - although
we seem to agree upon the general principles - keep it simple, focus on
the main benefit not the corner cases, but both principles involve some
degree of subjective calls. E.g., the exit condition to initRTO of 1sec
suggested in my previous email doesn't seem all that complex to me.
It only involves a simple check of dupack (or dup SYN/SYN-ACK).

Also I'm not sure why performance has to suck just because a connection
experience early (e.g., SYN/SYN-ACK) loss? I don't remember if TCP
spec requires a connection to go into congestion avoidance mode after
SYN/SYN-ACK loss? Even if so, for short lived connections with small
amount of data (e.g., HTTP/TCP), a speedy recovery from a more optimal
RTO value does still seem matter. Also the reason for a possible speedy
recovery for a loss event AFTER 3WHS seems equally valid as the one
for 3WHS, assuming these loss events are stochastically independent
of each other..,

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

Again I agree with your statements in general but I just feel one-shot
is a little weak, shy of being "good enough". How about allowing N
shots where N is some TBD (> 1) number? I suspect N=2 may satisfy
the "good enough" criterion, taking cue from MacOS (see my slides on
MacOS's repeated 1sec RTO 5 times...) There may be a couple of
different flavors of allowing N shots, either consecutive-only or not but
that's details.

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

The N-shot solution doesn't add any complexity (just log(N) more bits to
the TCP structure) and seems a strong enough dose for those HTTP
connections suffering the dreadful 3sec pause.

Jerry

>
> allman
>
>
>
>