Re: multiplexing over more than one connection

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).
>
> Using such a mechanism we can ensure better redundancy and recovery
> mechanisms, but still dramatically reducing the number of connections.
>
>
I ran experiments using all numbers of connections.  What happens is
exactly what you'd expect with more connections:  compression ratios go
down, SSL overhead goes up, buffering goes up.  Packet loss is the hardest
to understand, as it depends on the correlated vs random packet loss
question.  With random packet loss, it is clear that more connections is
less negatively affected by losses when there are more connections.

If we let the app layer use multiple connections, we'll again prevent the
TCP guys from really being able to optimize.  I hope that we can push
forward on making a single transport connection just-as-good-or-better than
multiple transport connections rather than just throwing buffers at the
problem.

I realize that transports basically never change tho.  Sad!

mike




> I would be happy to know what people think.
>
> - Ido
>
>