Wesley Eddy <> Fri, 19 April 2013 04:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E93BF21F8B16 for <>; Thu, 18 Apr 2013 21:11:13 -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 xxZcNZ5Vbh9a for <>; Thu, 18 Apr 2013 21:11:13 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E3A7021F8A85 for <>; Thu, 18 Apr 2013 21:11:12 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UT2dd-0004GR-CB for; Fri, 19 Apr 2013 04:09:29 +0000
Resent-Date: Fri, 19 Apr 2013 04:09:29 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UT2dY-0004El-Qq for; Fri, 19 Apr 2013 04:09:24 +0000
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UT2dY-0004Op-2J for; Fri, 19 Apr 2013 04:09:24 +0000
Received: from ([]) by (8.14.4/8.14.4) with ESMTP id r3J493wR021325 for <>; Fri, 19 Apr 2013 00:09:03 -0400
Received: (qmail 4278 invoked by uid 0); 19 Apr 2013 04:09:03 -0000
Received: from unknown (HELO ? ( by 0 with ESMTPA; 19 Apr 2013 04:09:03 -0000
Message-ID: <>
Date: Fri, 19 Apr 2013 00:08:44 -0400
From: Wesley Eddy <>
Organization: MTI Systems
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Nandita Dukkipati <>
CC: Patrick McManus <>, Gabriel Montenegro <>, Roberto Peon <>, "Simpson, Robby (GE Energy Management)" <>, Eliot Lear <>, Robert Collins <>, Jitu Padhye <>, "" <>, "Brian Raymor (MS OPEN TECH)" <>, Rob Trace <>, Dave Thaler <>, Martin Thomson <>, "Eggert, Lars" <>, Martin Stiemerling <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Received-SPF: none client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-3.450, RCVD_IN_DNSWL_NONE=-0.0001
X-W3C-Scan-Sig: 1UT2dY-0004Op-2J 22ab9856c80c480b2b42ee628f71219c
Subject: Re: HTTP/2 and TCP CWND
Archived-At: <>
X-Mailing-List: <> archive/latest/17352
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Hi Nandita, here are some thoughts inline:

On 4/18/2013 7:55 PM, Nandita Dukkipati wrote:
> Nice points Patrick.
> To me these are the high order bits for letting CWND cookie feature remain-
> *  As you correctly note, apps get around the static value of initcwnd
> per connection by using an arbitrarily large number of parallel
> connections -- compared to this crude hammer, CWND cookie feature is a
> saner way to start.

I think that logic isn't considering other options.  I agree this is
the "less bad" of the two options you mention, but there are more than
two bad ideas (and maybe even a couple good ones) to choose from.

In this case, it doesn't appear that the story has yet been well put
together to show that this is more helpful than harmful.  There are
strawman arguments in both directions, but certainly more research
to be done before it could be suitable for a Internet standard.

> * It's always arguable on how valid the CWND is... but then, this is
> true of any starting condition. So the question really is: Is past value
> from some XXX time ago less/more wrong on average than starting with an
> arbitrary constant?

It is a great research question, and very interesting.

The things to look at are what the impact of being wrong on different
granularities is, and what the likelihood of being wrong at different
granularities is.

> CWND-SETTING is an API which gives the transport access to long term
> persistent information. As such its efficacy may be subjective without
> data, so it only seems reasonable to me to let the feature remain. In an
> ideal world, we would have a holistic design of a transport that
> understands its application well, but short of this ideal, CWND-SETTING
> is a way to take us forward.

If the prior state variables can be utilized, they should be utilized by
code that has a more global view of the set of simultaneous connections
and other things going on in the host, and provide information to TCP
for potential use.  I don't think simply exporting the variable for
some other unspecified code to control is a good design decision.

In general though, Lars made the point that TCPM would be a good place
to get rapid feedback on this ... the startup problem is well-known and
has been beat upon for many years.

Wes Eddy
MTI Systems