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

Re: Question on flow control for a single file transfer

From: Mike Bishop <Michael.Bishop@microsoft.com>
Date: Mon, 4 Nov 2013 22:15:04 +0000
To: Peter Lepeska <bizzbyster@gmail.com>, Amos Jeffries <squid3@treenet.co.nz>
CC: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <091e870f757b4296a471a1e00f0c4e0d@BY2PR03MB091.namprd03.prod.outlook.com>
No, the sender *doesn't* know if there's a single stream end-to-end.  It knows whether there's a single stream on the first hop, and it doesn't know whether that hop is the only hop.

If a client is directly connected to a server and that's the only request that will ever be made, then you're correct -- you may get some improved performance by disabling flow control, and we provide that option in the spec.  But the server, at least, doesn't know whether it's dealing with a proxy or a direct client.  The client can inform its next hop whether it wants flow control on that hop.  If that next hop is a proxy, it's the proxy's decision whether it wants flow control, and that's an independent choice.

Sent from Windows Mail

From: Peter Lepeska<mailto:bizzbyster@gmail.com>
Sent: ?Monday?, ?November? ?4?, ?2013 ?1?:?17? ?PM
To: Amos Jeffries<mailto:squid3@treenet.co.nz>
Cc: HTTP Working Group<mailto:ietf-http-wg@w3.org>

On Mon, Nov 4, 2013 at 1:02 PM, Amos Jeffries <squid3@treenet.co.nz<mailto:squid3@treenet.co.nz>> wrote:
On 2013-11-05 05:05, Peter Lepeska wrote:

I agree what you said, but again only when there is more than one active
stream. Again, HTTP 2 flow control is harmless at best when there is only
one active stream.

Part of my point was that there is absolutely no way to determine that one active stream cases existence all the way along the path. Middleware exists (whether it is visible to the endpoints or not) and the "single stream" may be sharing any HTTP hop with one or more other streams.

"At best" this single stream will be able to avoid contention in the more common cases where it ceases being a single end-to-end stream at some middel hop. So no I think the best-case is rather better than you are saying.

The sender knows if there are other active streams at the time it has data to send.

But you don't have to believe me. Just setup a test a browser that does
flow control and add a few % loss and 200 ms latency and see whether you
are able to download large files faster with flow control on or off. The
flow control off case should never lose, assuming the loss/latency are
regular and your test is long enough.

At what size data frames? and what relative size of TCP and HTTP layer buffer sizes? over how many hops?

In the grand scheme of HTTP, single client going to single server, with a single stream and nothing in between is a rather rare occurance. Just like it is a rather rare and artificial occurance to see only a single isolated TCP connection today.

Those questions will not impact your results. When there is available buffering at the TCP layer, HTTP flow control makes one of two decisions -- send now or send later. When flow control is disabled the answer is always send now. Therefore no HTTP flow control will always be as fast or faster.

Actually, I don't know for sure but I'd bet the single stream case is the most common from an overall bytes sent perspective due to http streaming movies from services like Netflix. In any case, there are many uses of HTTP that involve one at a time file transfers.


Received on Monday, 4 November 2013 22:15:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:19 UTC