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.
* 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?
* Lars and others make excellent points on the detrimental effects of large
bursts. The good news is that there are server side techniques to soften
bursts on the network in the absence of ACK clocking, so implementations
will need to handle this case effectively.
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.
Nandita
On Mon, Apr 15, 2013 at 6:45 PM, Patrick McManus <mcmanus@ducksong.com>wrote:
> Hi All,
>
> The problem being addressed here isn't a hypothetical one, nor is it
> resolved separately by IW10.. but it is one that specially impacts HTTP
> because of its history of parallel connection [ab]use and the goal of
> HTTP/2 to transition away from that. SETTINGS may or may not be the way to
> do it. Expertise is always welcome, but the topic is completely germane as
> far as I am concerned.
>
> One of the deficiencies of IW10 is derived from its adherence to layering
> separation - it works only on the TCP level. So you get IW=10 whether there
> is 1 connection (SPDY), 6 connections (HTTP/1), or 36 connections (6 way
> sharded HTTP/1). At the TCP level of course, the stack has no idea which to
> use - IW is just a default config for new connections. If it uses IW=3 and
> there is 1 SPDY connection then that decision likely has a large
> opportunity cost in terms of un-utilized bandwidth.. if it uses IW=10 and
> there are 36 HTTP/1 connections then congestion is self-induced and a train
> wreck of packet loss ensues and the cost is paid in retransmissions, out of
> order deliveries, timers, etc.. (This happens today on a fairly prominent
> CDN). Both scenarios are suboptimal, as there is no perfect constant, but
> in neither case does the Internet collapse or the page even fail to load.
>
> Its totally reasonable to experiment with how HTTP/2 can improve this
> unfortunate situation.
>
> As Roberto says, giving applications a knob to do this reasonably removes
> the need for them to do it unreasonably and less effectively with a hammer.
>
> If we break down the arbitrary layer barrier and inject some history into
> the algorithm, in this case via SETTINGS, you get something more powerful
> than a default constant. Part of what you inject is traditional L4
> information (what was our CWND before) which is much more interesting than
> a constant, but the other thing you implicitly inject is information that
> this flow carries SPDY and therefore won't be engaging in rampant
> parallelization. (This latter bit can actually be done by the
> implementation without help from the wire protocol, but being comfortable
> with that opens the door for the protocol to create a better implementation
> via the SETTINGS frame).
>
> -Patrick
>