Re: multiplexing over more than one connection

Some quick 2c answers inline, cause I had to :)


Sincerely,
Rob Mattson, MACS (CT), MIEEE

Email: robert@mattson.com.au

On Thu, 7 Jun 2012, Safruti, Ido 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).
The effect of packet loss on a connection among many is an exercise in 
probability, it becomes complicated when we think about QoS and RED in the 
mix. RED signals a connection to slow down by dropping packets to trigger 
congestion control/flow back-off responses in the TCP stack.

> 
> Did anyone in this forum explored implementing something like link aggregation (or connection aggregation)?
This is comparable to multiplexing. think of HTTP-MPLEX & web bundles 
against something like Coordinated congestion controle (COCOON). You 
really want a single congestion control algorithm aware of multiple 
connections (response level multiplexing on a single TCP connection).
When you have multiple retransmit buffers that are sizeable because of 
high delay and high bandwidth it might take more segments to trigger 
something like fast retransmit. That is because other segments will be in 
flight delaying the arrival of out of order segments for a TCP connection 
experiencing the loss. Assuming unequal distribution of loss among open 
TCP connections.


> We can have an upgrade mechanism where the server and client can negotiate adding a connection to their channel.
yep. See HTTP-MPLEX. Although you have to wait for the current response to 
arrive before the next stream of responses, but you also reduce head of 
the line blocking with HTTP-MPLEX and also server side response 
prioritisation.


> 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.
HTTP-MPLEX does this in a backwards compatible and transparent manner.

> 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 would be happy to know what people think.
> 
> - Ido
> 
> 
>


Thanks for an opportunity to trumpet my own horn, but i'll wait for my 
current caffiene inspired sugar-rush to wear off and i promise to spell 
check my emails in the future and capitalise my 'I's.