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

Re: multiplexing over more than one connection

From: Yuchung Cheng <ycheng@google.com>
Date: Thu, 7 Jun 2012 20:57:32 -0700
Message-ID: <CAK6E8=ftcmdiD=Y8HWfddZF0YHSZBX4H7sus2fSjAC3k1qgoHg@mail.gmail.com>
To: "Safruti, Ido" <ido@akamai.com>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On Thu, Jun 7, 2012 at 6:40 PM, Safruti, Ido <ido@akamai.com> wrote:
> Hi,
> I know this is a long discussed issue when multiplexing (specifically around
> SPDY): the benefits of one optimized connection vs multiple.However, as we
> most likely will use TCP as an underlying protocol, using one connection
> exposes us to packet loss impacts. (It is also true that in cases of packet
> loss  it may impact all established connections).
> Did anyone in this forum explored implementing something like link
> aggregation (or connection aggregation)?
> We can have an upgrade mechanism where the server and client can negotiate
> adding a connection to their channel.
> The server can publish, or announce that it supports it, and the client can
> try to establish an additional connection with some
> identification/verification, and only once this is verified the channel
> could be "upgraded" to utilize the additional connection.
> Basically establishing link aggregation.
> If the upgrade isn't supported, or won't work, we can always remain with a
> single connection. (and we know it may break in some connection with
> loadbalancers, or if we can't assure server stickiness).

You might want to take a look at SST
(http://pdos.csail.mit.edu/uia/sst/) and SCTP

> Using such a mechanism we can ensure better redundancy and recovery
> mechanisms, but still dramatically reducing the number of connections.
> I would be happy to know what people think.
> - Ido
Received on Friday, 8 June 2012 03:58:22 UTC

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