Re: HTTP/2 and TCP CWND

[Roberto Peon <[e-mail]>]

I'll point out that it is very clear that we have (and have had) consensus
to remove this feature as it exists today.
So, we should.
It is and always has been a tool for research for the transport layer.

If it was defined as an opaque blob that the transport layer delegates to
the application layer to transmit and cache, would it seem as scary?


On Mon, Apr 15, 2013 at 2:03 PM, Eggert, Lars <[e-mail]> wrote:

> Hi,
>
> 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.
>

I've been a part of that research-- the measurement apparatus for the
proposal was done on my machines and code!
There is still an issue of how many connections get opened. Given current
implementations, with an initcwnd of 10, you are likely to get bursts of
between 10 and 60 packets, as the browser often opens up connections in
parallel, and the server responds with static content with alacrity.



>
> The issue itself has been thought about for much longer, c.f.
> http://tools.ietf.org/html/draft-hughes-restart-00 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.
>

Good stuff that is ignored when we have lots of (6-36) connections starting
up simultaneously or nearly so. :/


>
> Another related work item in TCP is
> http://tools.ietf.org/html/draft-ietf-tcpm-newcwv-00, 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 think you mistake the intent. The intent is to make it easy for transport
experimentation by giving a mechanism that can be implemented today of
storing transport-related data, and by giving that back to the transport
layer upon session resumption.
While an ugly thing (which should hopefully be a short-term band-aid for
the lack of this mechanism in the transport today), it works and does allow
for transport-level experimentation today. What would the transport folks
like stored for use by the transport layer? :)


>
> 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.
>

Agree (and I believe that I said as much earlier), however, I can't think
of a good mechanism for limiting the number of parallel connections for
HTTP/1.1.
That is really my boogeyman.

-=R