W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2012

Re: multiplexing -- don't do it

From: Brian Pane <brianp@brianp.net>
Date: Thu, 29 Mar 2012 20:11:59 -0700
Message-ID: <CAAbTgTsKPH5yyCJpMtBYgqMvPeE-SmBz2OEA5Uw-CKbDS=opOg@mail.gmail.com>
To: Peter L <bizzbyster@gmail.com>
Cc: ietf-http-wg@w3.org
On Thu, Mar 29, 2012 at 7:07 PM, Peter L <bizzbyster@gmail.com> wrote:
> I'm new to this list but have been studying web performance over high
> latency networks for many years and multiplexing seems to me like the wrong
> way to go. The main benefit of multiplexing is to work around the 6
> connections per domain limit but it reduces transparency on the network,
> decreases the granularity/modularity of load balancing and increases object
> processing latency in general on the back end as everything has to pass
> through the same multiplexer, and introduces its own intractable
> inefficiencies. In particular the handling of a low priority in flight
> object ahead of a high priority object when packet loss is present is a step
> backwards from what we have today for sites that get beyond the 6
> connections per domain limit via domain sharding. Why not just introduce an
> option in HTTP 2.0 that allows clients and servers to negotiate max
> concurrent connections per domain? When web sites shard domains, aren't they
> essentially telling the browser that they will happily accept lots more
> connections? I'm sure this suggestion has long since been shot  down but
> browsing around on the web I'm not finding it.

There are a couple of practical problems that happen upon increasing
the number of concurrent connections:

- With N connections, the server or proxy has to be prepared to allocate
  N * receive_window_size bytes of memory for incoming packets.  Large
  values of N thus have a disadvantage for people operating high-traffic

- Congestion control happens independently for each of N connections.
  While I'm not a proponent of artificially throttling HTTP to compensate
  for "bufferbloat," multiplexing N HTTP streams over one TCP connection
  does make for easier congestion control (especially in low-end client
  devices) than running N TCP connections.

- If the client and server have to negotiate a value for N, it may add
  an additional round trip.

Received on Friday, 30 March 2012 03:12:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:01 UTC