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

HTTP/2 and TCP CWND

From: Jitu Padhye <padhye@microsoft.com>
Date: Mon, 1 Apr 2013 17:50:00 +0000
To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
CC: "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>, Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>
Message-ID: <8e7e9a7db6204492afde5d8883570579@BN1PR03MB006.namprd03.prod.outlook.com>
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
Received on Monday, 1 April 2013 17:51:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:12 UTC