Re: HTTP/2 and TCP CWND

Which is worse, starting with 1 connection with a cwnd of 32, or starting 6
connections each with a cwnd of 6?

-=R


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

> In the original SPDY draft (and the current HTTP2-01 draft), there is a
> TCP CWND setting exposed:
>
>          5 - SETTINGS_CURRENT_CWND allows the sender to inform the
>          remote endpoint of the current TCP CWND value.
>
> It is not clear what the client is supposed to do with this information.
> There was a follow up post from Mile Belshe (
> https://groups.google.com/forum/?fromgroups#!topic/spdy-dev/XRkL7FlIOW4)
> in which he indicated that the client could persist the CWND stored by the
> server, and the server could later user it to "warm start" connections to
> the same client. This can potentially cut transfer time by several RTTs.
>
> I have several concerns about warm start, and if that is the only use for
> SETTINGS_CURRENT_CWND, then maybe we should not have the setting at all.
>
> 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.
>
> 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.
>
> 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).
>
> 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.
>
> 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.
>
> Jitu
>
>
>
>