Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D454D28C1E6 for ; Thu, 30 Jul 2009 01:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQWMjogNpyKI for ; Thu, 30 Jul 2009 01:27:58 -0700 (PDT) Received: from mail83.messagelabs.com (mail83.messagelabs.com [195.245.231.83]) by core3.amsl.com (Postfix) with SMTP id 16EFB28C218 for ; Thu, 30 Jul 2009 01:27:57 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-8.tower-83.messagelabs.com!1248942476!50636918!1 X-StarScan-Version: 6.1.2; banners=-,-,- X-Originating-IP: [131.227.102.140] Received: (qmail 31697 invoked from network); 30 Jul 2009 08:27:56 -0000 Received: from ads40.surrey.ac.uk (HELO ads40.surrey.ac.uk) (131.227.102.140) by server-8.tower-83.messagelabs.com with SMTP; 30 Jul 2009 08:27:56 -0000 Received: from EVS-EC1-NODE4.surrey.ac.uk ([131.227.102.145]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Jul 2009 09:27:56 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA10EF.A382F661" Date: Thu, 30 Jul 2009 09:27:55 +0100 Message-ID: <4835AFD53A246A40A3B8DA85D658C4BE0136891A@EVS-EC1-NODE4.surrey.ac.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] initial RTO (was Re: Tuning TCP parameters for the 21st century) Thread-Index: AcoPskrFnef0JXkmSROcNgOfPDCsxgBPBIoP References: <20090728183556.A5820385088@lawyers.icir.org> From: To: , X-OriginalArrivalTime: 30 Jul 2009 08:27:56.0605 (UTC) FILETIME=[A3DF9ED0:01CA10EF] Cc: tcpm@ietf.org Subject: Re: [tcpm] initial RTO (was Re: Tuning TCP parameters for the 21st century) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 08:27:59 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA10EF.A382F661 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It's necessary to disambiguate which ACK is for which SYN -=20 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#p= rotocol-radius esp. Fig 2. L. -----Original Message----- From: tcpm-bounces@ietf.org on behalf of Mark Allman Sent: Tue 2009-07-28 19:35 To: Jerry Chu Cc: tcpm@ietf.org Subject: Re: [tcpm] initial RTO (was Re: Tuning TCP parameters for the = 21st century) =20 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. >=20 > 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 ...=20 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. =20 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 ------_=_NextPart_001_01CA10EF.A382F661 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [tcpm] initial RTO (was Re: Tuning TCP parameters for the = 21st century)

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/p= ublications/index.html#protocol-radius
esp. Fig 2.

L.

<http://www.ee.surrey= .ac.uk/Personal/L.Wood/><L.Wood@surrey.ac.uk>



-----Original Message-----
From: tcpm-bounces@ietf.org on behalf of Mark Allman
Sent: Tue 2009-07-28 19:35
To: Jerry Chu
Cc: tcpm@ietf.org
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

------_=_NextPart_001_01CA10EF.A382F661--