- From: Simpson, Robby (GE Energy Management) <robby.simpson@ge.com>
- Date: Tue, 16 Apr 2013 14:59:31 +0000
- To: "Eggert, Lars" <lars@netapp.com>, Roberto Peon <grmocg@gmail.com>
- CC: Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>, Eliot Lear <lear@cisco.com>, Robert Collins <robertc@squid-cache.org>, Jitu Padhye <padhye@microsoft.com>, "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>, Martin Stiemerling <martin.stiemerling@neclab.eu>
It appears to me that the chief concern is in regards to HTTP/2's use of a single flow vs. HTTP/1's use of multiple flows. I fail to see how changing CWND is going to make a difference (except for a beginning, potentially nasty, burst) since, if the flows are sharing the same end-to-end paths, they will still be competing and will steady-state to "equal" CWND's. Further, this is not specific to HTTP/2. There are plenty of other applications out there using TCP that have suffered from HTTP/1's use of multiple simultaneous flows. I fail to see how HTTP/2 is in a better situation to correct that issue than any other application or, more importantly, than the appropriate layer (4) or the offender (HTTP/1). Am I missing something, or is the concern really that some folks are looking for a way to throttle or compete with HTTP/1 flows? - Robby
Received on Tuesday, 16 April 2013 15:00:20 UTC