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

[<[e-mail]>]

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.

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