RE: HTTP/2 and TCP CWND

I agree that for *existing* issues we need advice and collaboration with the transport folks, and am glad Mark is looping them in.

Issue #65, however, is a *new* potential issue with transport, so we should simply not add it to the list of transport problems to solve.  In response to Mark, yes, this feature is marked as experimental. But experimental features are there, because presumably they might have a future within the spec if we judge it works well.

There are two problems with that in this case. (1) HTTPbis does not have the expertise to decide if any modification to TCP works well or not. Beyond layering violations, I'm talking about expertise. The folks who understand those TCP dynamics do not participate in the working group. Even if we decided that the experiment goes swimmingly, I don't believe the feature has any future in the spec. IESG would likely trip on it and not allow it anyways. Again, this is from my interaction off line as I said before, but I agree that it would be best to hear from transport folks directly.

That is why I'm saying this particular feature is not even worth experimenting with. Especially, if transport already has an RFC that provides an alternative.

From: Roberto Peon [mailto:grmocg@gmail.com]
Sent: Monday, 15 April, 2013 08:18
To: Simpson, Robby (GE Energy Management)
Cc: Eliot Lear; Gabriel Montenegro; Robert Collins; Jitu Padhye; ietf-http-wg@w3.org; Brian Raymor (MS OPEN TECH); Rob Trace; Dave Thaler; Martin Thomson; Eggert, Lars; Martin Stiemerling
Subject: Re: HTTP/2 and TCP CWND

One way or another, we will most certainly need significantly more interaction and thought between the Transport and Application groups with respect to this topic.
The fact that most sites end up with a CWND which is 36 times larger than the default (by opening up that many connections on average) means that the interaction between transport and application layer is totally broken today.
This really needs addressing, else all the wonderful pictures we have about separation of layers are already defunct and broken...

To be absolutely clear, the problem that Gabriel stated here is far less scary (it still converges, we rarely see large windows requested, we do see *smaller* windows requested) given the one connection of HTTP/2 that the current behavior is with the many connections of HTTP/1 as it exists today.
If the one connection of HTTP/2 fails to compete with the many of HTTP/1, implementors will "work around" this limitation and make things strictly worse for everyone.
-=R

On Mon, Apr 15, 2013 at 7:59 AM, Simpson, Robby (GE Energy Management) <robby.simpson@ge.com<mailto:robby.simpson@ge.com>> wrote:
At the risk of piling on, I'd like to elaborate (some of) my concerns with SETTINGS_CURRENT_CWND:

When I saw this thread start 2 weeks ago, I thought of replying with a simple "+1 layer violation".  However, I have seen the argument that "layers are lovely ways of thinking about things - but they aren't goals unto themselves" so I took some time to think about some problems this could cause.

User-land vs. Kernel-land - HTTP (and likely HTTP/2.0) is often (at least partially) implemented in user-land.  Most TCP implementations are implemented in "kernel-land".  From a pragmatic implementation approach, this could be problematic.  I'll grant that many parameters are passed from one layer to another, but in this case, where is the history or state preserved?  This could get nasty.  Bottom line, this does cross some typical implementation boundaries.

Multiple applications, threads, or whatever - If HTTP/2.0 is going to be tracking settings from previous flows, these settings will need to persist across multiple threads, processes, or whatever (where flow properties may differ - think caches) as well as different applications (I personally use multiple HTTP/1.1 applications simultaneously).

Other applications - While I recognize that HTTP/1.1 is a large contributor to TCP traffic, it is not the only application that uses TCP.  I realize we may all be excited with the optimizations we can provide as part of HTTP/2.0, but wouldn't it be better if all applications that use TCP could utilize these improvements?

Other TCP flavors - Most of my interest in HTTP/2.0 is in the embedded space.  Sometimes in the embedded space we use other TCP flavors and do various "weird" things.  I think this group would be best-served not having to consider all of those various scenarios and the impact that SETTINGS_CURRENT_CWND may have.

I'm quite glad that folks are thinking about ways to improve TCP flows.  I really hope that continues.  However, I'd suggest that work not occur here, but within the transport area, and that SETTINGS_CURRENT_CWND be removed from HTTP/2.0.

Thanks,
Robby



Robby Simpson, PhD

System Architect

GE Energy

Digital Energy

M: +1 404 219 1851

Robby.Simpson@GE.com<mailto:Robby.Simpson@GE.com>


From: Eliot Lear <lear@cisco.com<mailto:lear@cisco.com><mailto:lear@cisco.com<mailto:lear@cisco.com>>>
Date: Monday, April 15, 2013 12:55 AM
To: Gabriel Montenegro <Gabriel.Montenegro@microsoft.com<mailto:Gabriel.Montenegro@microsoft.com><mailto:Gabriel.Montenegro@microsoft.com<mailto:Gabriel.Montenegro@microsoft.com>>>
Cc: Roberto Peon <grmocg@gmail.com<mailto:grmocg@gmail.com><mailto:grmocg@gmail.com<mailto:grmocg@gmail.com>>>, Robert Collins <robertc@squid-cache.org<mailto:robertc@squid-cache.org><mailto:robertc@squid-cache.org<mailto:robertc@squid-cache.org>>>, Jitu Padhye <padhye@microsoft.com<mailto:padhye@microsoft.com><mailto:padhye@microsoft.com<mailto:padhye@microsoft.com>>>, "ietf-http-wg@w3.org<mailto:ietf-http-wg@w3.org><mailto:ietf-http-wg@w3.org<mailto:ietf-http-wg@w3.org>>" <ietf-http-wg@w3.org<mailto:ietf-http-wg@w3.org><mailto:ietf-http-wg@w3.org<mailto:ietf-http-wg@w3.org>>>, "Brian Raymor (MS OPEN TECH)" <Brian.Raymor@microsoft.com<mailto:Brian.Raymor@microsoft.com><mailto:Brian.Raymor@microsoft.com<mailto:Brian.Raymor@microsoft.com>>>, Rob Trace <Rob.Trace@microsoft.com<mailto:Rob.Trace@microsoft.com><mailto:Rob.Trace@microsoft.com<mailto:Rob.Trace@microsoft.com>>>, Dave Thaler <dthaler@microsoft.com<mailto:dthaler@microsoft.com><mailto:dthaler@microsoft.com<mailto:dthaler@microsoft.com>>>, Martin Thomson <martin.thomson@skype.net<mailto:martin.thomson@skype.net><mailto:martin.thomson@skype.net<mailto:martin.thomson@skype.net>>>, "Eggert, Lars" <lars@netapp.com<mailto:lars@netapp.com><mailto:lars@netapp.com<mailto:lars@netapp.com>>>, Martin Stiemerling <martin.stiemerling@neclab.eu<mailto:martin.stiemerling@neclab.eu><mailto:martin.stiemerling@neclab.eu<mailto:martin.stiemerling@neclab.eu>>>
Subject: Re: HTTP/2 and TCP CWND
Resent-From: <ietf-http-wg@w3.org<mailto:ietf-http-wg@w3.org><mailto:ietf-http-wg@w3.org<mailto:ietf-http-wg@w3.org>>>
Resent-Date: Monday, April 15, 2013 12:55 AM


On 4/12/13 11:52 PM, Gabriel Montenegro wrote:
I've opened issue #65 to track what we should do about SETTINGS_CURRENT_CWND:
https://github.com/http2/http2-spec/issues/65

As for my opinion about what to do: I think we should delete this TCP congestion window setting from HTTP/2.0.

+1 for all the reasons Gabriel mentioned.

Eliot