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

[Jerry Chu <[e-mail]>]

On Thu, Jul 30, 2009 at 1:27 AM, <[e-mail]> wrote:
> It's necessary to disambiguate which ACK is for which SYN -
> i.e. if you have a _very_ long-delay path, you might send out
> three SYNs before an ACK to the first SYN comes in. But it appears
> at the time to be an ACK to the third SYN, with other
> responses lost in transit. So SYN timestamps really are
> necessary to disambiguate in this situation. I can see
> a cascading sequence where the first ACK comes in just after say
> the fifth SYN goes out, and it's immediately necessary to
> bump the RTO up to tens of seconds.

One solution I proposed only requires the detection of  sprurious
retransmission so it doesn't need to match ACKs with their SYNs,
as long as any dupack is received...

Jerry

>
> related discussion of this is in our TCP Protocol Radius paper:
> http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/index.html#protocol-radius
> esp. Fig 2.
>
> L.
>
> <http://www.ee.surrey.ac.uk/Personal/L.Wood/><[e-mail]>
>
>
>
> -----Original Message-----
> From: [e-mail] on behalf of Mark Allman
> Sent: Tue 2009-07-28 19:35
> To: Jerry Chu
> Cc: [e-mail]
> Subject: Re: [tcpm] initial RTO (was Re: Tuning TCP parameters for the 21st
> century)
>
>
> Jerry-
>
>> So the active open side has retransmitted SYN, assuming initRTO of
>> 1sec, and eventually received a SYN-ACK but the TS option was
>> denied so no good RTT sample can be taken. It will continue to send
>> the init data with the initRTO.
>>
>> If the SYN retransmission has been unnecessary because the initRTO has
>> been too aggressive, more SYN-ACK will be triggered. Assuming these
>> dup SYN-ACKs are not lost, could they be used as a hint to the active
>> open side that the initRTO has been too short, so that the RTO timer
>> can be reverted back to 3secs immediately, in time to avoid further
>> RTO hell?
>
> So, you're saying that if you send N SYNs (N>1) and you get N SYN+ACKs
> then you take that to mean the initRTO was too short.
>
> Yeah, perhaps ...
>
> Are you suggesting something like this ...
>
>   (1) Use an initRTO of 1sec.
>
>   (2) If the RTO fires and you retransmit the SYN back the RTO to 3sec.
>       (And, if necessary you exponential backoff even more.)
>
>   (3) After the 3WHS you will either (a) have a good RTT sample from the
>       timestamp option and can therefore set the RTO reasonably or (b)
>       you retain the 3sec RTO until you get a good RTT sample.
>
> ??
>
> That means that if 1sec is not enough in the 3WHS you have to use 3sec
> until you have some idea about the network.  However, you also get a
> shot [*one shot*] to retransmit sooner based on the notion that most
> RTTs are less than 1sec.
>
> I think I buy that notion ... that both allows for more aggressiveness
> for the common case while also protecting against RTO Hell for the long
> path cases.  Is that the right walking of the line?
>
> allman
>
>
>
>
>
>