Re: HTTP/2 and TCP CWND

Hi Jitu,

Heh - I've been teasing the google team for a year over when someone
would raise a serious objection to this. I figured it just meant
nobody from TSV or sigcomm had really read the draft yet :) So welcome
and thanks!

While I can go either way, I think on balance all the persistent
settings should be removed because they provide a fairly minor benefit
at the cost of a new cookie mechanism and that trade probably isn't
worthwhile. But there are benefits here, I've seen them in practice.
My reasoning is quite different than what you presented, so I want to
explain why I have some disagreements - I think its important so we
don't close the door un-necessarily to similar approaches going
forward.

On Mon, Apr 1, 2013 at 1:50 PM, Jitu Padhye <padhye@microsoft.com> wrote:

> First, if a cwnd value is persisted at the client, then, after the connection ends, it needs to be gradually decayed with time, and completely discarded if the client changes networks (e.g. from wifi to 3G etc.). This adds additional complexity to client implementation.

perhaps it should be time decayed for efficiency - but it doesn't have
to. This is just an initial setting - analagous as you say to TCP IW.
It doesn't change any of the AIMD aspects of TCP so we're not delving
into anything serious that would touch on congestion collapse, etc..

It's the classic startup problem - start sending too conservatively
and you waste bandwidth that you can never get back , start sending
too aggressively and you do (fixable) damage to yourself and other
flows and waste time and bandwidth making those corrections. Its not
clear to me which scenario is worse - they're both tragic :(

TCP basically just punts and uses a constant (IW). It could be too
small or too large. Its always the same. The CWND cookie tries to give
it a little context. It could still be too large or too small - but at
least its based on a historical path between the end points.

We've got tons of data that says TCP on HTTP/1 generally sends too
conservatively. That's a big driver behind the crude hammer of
parallel connections. They are, in large part, an application layer
mechanism to game IW - right? SPDY goes back to a small number of
connections (thankfully!) and provides this as a way to get back some
of that lost window. Its not especially more or less legitimate than
current practice imo.

> Second, the server has to take any value reported by client with a large grain of salt, since it cannot trust the client to correctly decay/discard window. The client may even inflate the window in an attempt to get "better" service. So, at the very least, the server needs to check timeliness, which means it has to maintain additional state (e.g. remember when it last sent CWND to this client). This complicates server implementation.

The server has lots of options - it isn't obligated to do anything. It
could track this information locally and not send the cookie at all.
It could honor the cookie up to some kind of max. It could just leave
it all up to TCP. This is much like dos-prevention strategies - a
whole range of things are possible.

>
> Third, The clients who implement this may be able to grab a higher share of bandwidth, which is unfair to legacy clients (e.g. normal HTTP clients).

This is my big objection to your argument that I wanted to make.

I am opposed to making "HTTP/1 fairness" a requirement of HTTP/2.
making every change be "fair" on the network with legacy traffic both
ties the hands of new innovations and removes any incentives for
deployments of the new technology. Its a big mistake imo.

Each case has to be handled on its own merits, we obviously don't want
to be un-necessarily destructive. But perfect balance doesn't need to
be a goal.

>
> If the server wants to start with a higher initial cwnd, then that's already being discussed: http://tools.ietf.org/html/draft-ietf-tcpm-initcwnd-08.  I am not advocating for that proposal, but at least it is better than warm start, since there is no state to maintain and clients have no influence.

IW10 is probably important - but its still a constant.. the idea of
the cwnd cookie is that it isn't a constant. Very different.

>
> In general,  SETTINGS_CURRENT_CWND violates the basic layering principle. So, unless there is a really good reason to keep it, it should be removed.
>

layers are lovely ways of thinking about things - but they aren't
goals unto themselves. Much of SPDY is about doing parts of TCP in
HTTP anyhow in order to get a performant deployable application based
on years of previous experience seeing where the bottlenecks are. CWND
is just one more piece of that and isn't, at least to me,
objectionable on a fundamental level.

-Patrick

Received on Monday, 1 April 2013 18:58:47 UTC