- From: Roberto Peon <grmocg@gmail.com>
- Date: Mon, 1 Apr 2013 11:31:36 -0700
- To: Jitu Padhye <padhye@microsoft.com>
- Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, "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: <CAP+FsNeG4ew88sWs6OL+PQXbqSANE6smRTJuVBzo8ppkLVPYtA@mail.gmail.com>
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 > > > >
Received on Monday, 1 April 2013 18:32:18 UTC