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