Re: HTTP/2 and TCP CWND

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

Received on Friday, 19 April 2013 04:09:24 UTC