W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2013


From: Patrick McManus <mcmanus@ducksong.com>
Date: Mon, 15 Apr 2013 21:45:11 -0400
Message-ID: <CAOdDvNpidZwfMS_y_Hy56UjOaD9uNi-s=B9MErQSq4Msd3oBKw@mail.gmail.com>
To: Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>
Cc: Roberto Peon <grmocg@gmail.com>, "Simpson, Robby (GE Energy Management)" <robby.simpson@ge.com>, Eliot Lear <lear@cisco.com>, Robert Collins <robertc@squid-cache.org>, Jitu Padhye <padhye@microsoft.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, "Brian Raymor (MS OPEN TECH)" <Brian.Raymor@microsoft.com>, Rob Trace <Rob.Trace@microsoft.com>, Dave Thaler <dthaler@microsoft.com>, Martin Thomson <martin.thomson@skype.net>, "Eggert, Lars" <lars@netapp.com>, Martin Stiemerling <martin.stiemerling@neclab.eu>
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).

Received on Tuesday, 16 April 2013 01:45:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:10 UTC