"Eggert, Lars" <> Mon, 22 April 2013 08:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EF2BC21F85DB for <>; Mon, 22 Apr 2013 01:07:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KkgMJTk7GrGq for <>; Mon, 22 Apr 2013 01:06:59 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0644121F841D for <>; Mon, 22 Apr 2013 01:06:57 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UUBln-0007u4-7Y for; Mon, 22 Apr 2013 08:06:39 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UUBlk-0007nc-IJ for; Mon, 22 Apr 2013 08:06:36 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <>) id 1UUBlk-0001Jz-Gp for; Mon, 22 Apr 2013 08:06:36 +0000
Received: from ylafon by with local (Exim 4.72) (envelope-from <>) id 1UUBlk-0007a2-CK for; Mon, 22 Apr 2013 04:06:36 -0400
X-Return-path: <>
X-Received: from ([]) by with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) id 1URqZ7-0005Cy-Ei for; Mon, 15 Apr 2013 17:03:53 -0400
X-Received: from ([]) by with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) id 1URqZ7-0001Rx-B8 for; Mon, 15 Apr 2013 21:03:53 +0000
X-Received: from lists by with local (Exim 4.72) id 1URqZ7-0000pr-5Y for; Mon, 15 Apr 2013 21:03:53 +0000
Date: Mon, 15 Apr 2013 21:03:53 +0000
X-From_: Mon Apr 15 21:03:50 2013
X-Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1URqZ4-0000ow-Gr for; Mon, 15 Apr 2013 21:03:50 +0000
X-Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1URqZ3-0001R2-CK for; Mon, 15 Apr 2013 21:03:50 +0000
X-IronPort-AV: E=Sophos;i="4.87,479,1363158000"; d="scan'208";a="40859155"
X-Received: from ([]) by with ESMTP; 15 Apr 2013 14:03:20 -0700
X-Received: from ( []) by (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r3FL3IBk009099; Mon, 15 Apr 2013 14:03:18 -0700 (PDT)
X-Received: from ([]) by ([]) with mapi id 14.02.0342.003; Mon, 15 Apr 2013 14:03:17 -0700
From: "Eggert, Lars" <>
To: Gabriel Montenegro <>
CC: Roberto Peon <>, "Simpson, Robby (GE Energy Management)" <>, Eliot Lear <>, Robert Collins <>, Jitu Padhye <>, "" <>, "Brian Raymor (MS OPEN TECH)" <>, Rob Trace <>, "Dave Thaler" <>, Martin Thomson <>, Martin Stiemerling <>
Thread-Topic: HTTP/2 and TCP CWND
Old-Date: Mon, 15 Apr 2013 21:03:17 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-7.5
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.556, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1URqZ3-0001R2-CK 13f82581662a53f7684ca389a3fa8f38
Old-X-Envelope-To: ietf-http-wg
X-DSPAM-Result: Innocent
X-DSPAM-Processed: Mon Apr 15 17:03:55 2013
X-DSPAM-Confidence: 0.9983
X-DSPAM-Improbability: 1 in 60147 chance of being spam
X-DSPAM-Probability: 0.0000
X-DSPAM-Signature: 516c6b3b200301804284693
ReSent-Date: Mon, 22 Apr 2013 04:06:33 -0400 (EDT)
ReSent-From: Yves Lafon <>
ReSent-Subject: [Moderator Action] Re: HTTP/2 and TCP CWND
ReSent-User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
Subject: Re: HTTP/2 and TCP CWND
Archived-At: <>
X-Mailing-List: <> archive/latest/17463
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>


I had commented in an off-list discussion on this issue and was asked to summarize what I said to the list. So here we go.

I fully understand why the idea to bypass slow-start and instead start with the window used during the last connection instantiation sounds nice. But: it has been thought of before a dozen times and has huge issues.

This has the potential to generate large line-rate bursts into the network, which can can cause loss bursts and force TCP into timeout-based recovery, which has a huge impact on throughput. (Much more so than slow-starting with a smaller window.) That is, because you normally have no idea if the path conditions are at all comparable between when you cached that CWND and when you want to reuse it. So when you burst and create a series of losses - for yourself and other flows on the bottleneck! - they all go into timeout of a few hundred ms at least and then slow-start.

The TCP WG has been working on the Google "IW10" proposal (allowing TCP to start with an initial window of 10 segments rather than 1-3). That seems to mitigate much of the need for caching the CWND, since new connections wouldn't need to start with very small windows. A large part of the discussion around that proposal was exactly on the question of how large the initial window can be without significantly increasing the danger of line-rate bursts. There has been a pretty in-depth analysis by multiple folks into whether 10 is safe or not, and the consensus seems to be that it should be. Just caching and reusing any arbitrarily large CWND is certainly not safe.

The issue itself has been thought about for much longer, c.f. from 2002, which talks about the issue of what the window should be after a connection has been idle for a while and wants to resume sending.

Another related work item in TCP is, which attempts to specify what TCP should do during periods where it didn't send at a rate that used up the current window, which can also lead to bursting when traffic demands increase.

I'm mentioning this, because a lot of the work of the TCP WG revolves around mitigating these bursts in order to avoid stalls due to timeout-based recovery, and having HTTP go off and define knobs that would actively counteract that work seems, ahem, counterproductive.

I'm all for making HTTP and TCP work better together. Limiting the number of parallel connections, seeing if we can increase the initial window safely, and other similar things are all great examples of what we should be doing more of. But the TCP and HTTP folks will need to work together on this - we can't afford to get this wrong. 


PS: I'm not on the WG list, so please CC me if you'd like to respond.