SSH supports connection multiplexing which allows sharing a single TCP
connection for multiple sessions. Inverse multiplexing would let a
single session to span multiple TCP connections.

Potential benefits:

1. Reduced latency - buffered data on one channel will not delay data
on another channel.
2. Surviving dropped connections (e.g. buggy NATs)
3. Increase total throughput (like "download accelerators")

An inverse multiplexing layer would be added between the the connection
layer and multiple instances of the transport layer. The imux layer
would appear to the connection layer as a transport layer with relaxed
ordering guarantees: SSH packets with the same channel id would be
delivered in order but packets from separate channels can have
different latencies.

The imux layer would use acknowledge packets to monitor the buffering
status of each connection and prioritize latency-sensitive information
(e.g. interactive keystrokes) to idle or lower-latency connections. If
a connection times out or is is dropped the packets must be
retransmitted over another channel. This means that in some cases there
may be duplication of packets which should be filtered out by the imux
layer.

When used with tunneling this should reduce the performance
problems associated with the behavior of TCP congestion control when
the underlying transport is also TCP.

Oren

Oren Tirosh <oren@hishome.net> wrote:
>SSH supports connection multiplexing which allows sharing a single TCP
>connection for multiple sessions.

It does? I guess you could call the ability to handle multiple distinct
tunnels over the same TCP connection multiplexing.

>Inverse multiplexing would let a
>single session to span multiple TCP connections.

Or to let a single TCP tunnel span multiple SSH connections.

>An inverse multiplexing layer would be added between the the connection
>layer and multiple instances of the transport layer. The imux layer
>would appear to the connection layer as a transport layer with relaxed
>ordering guarantees: SSH packets with the same channel id would be
>delivered in order but packets from separate channels can have
>different latencies.

Why bother doing this inside the ssh protocol? Wouldn't it be much cleaner
to use tcp-level multiplexing and run ssh on top of that (or that on top
of SSH tunnels)?
--
Mark Rafn dagon@dagon.net <http://www.dagon.net/>

>>>>> "MR" == Mark Rafn <dagon@dagon.net> writes:

MR> Oren Tirosh <oren@hishome.net> wrote:
>> SSH supports connection multiplexing which allows sharing a single
>> TCP connection for multiple sessions.

MR> It does? I guess you could call the ability to handle multiple
MR> distinct tunnels over the same TCP connection multiplexing.

Indeed we could, and do. From RFC 4254:

This document describes the SSH Connection Protocol. It provides
interactive login sessions, remote execution of commands, forwarded
TCP/IP connections, and forwarded X11 connections. All of these
channels are multiplexed into a single encrypted tunnel.

--
Richard Silverman
res@qoxp.net

Mark Rafn wrote:
> Oren Tirosh <oren@hishome.net> wrote:
> >SSH supports connection multiplexing which allows sharing a single TCP
> >connection for multiple sessions.
>
> It does? I guess you could call the ability to handle multiple distinct
> tunnels over the same TCP connection multiplexing.

It does. RTFM.
( http://www.openbsd.org/cgi-bin/man.cgi?query=ssh and search for
"master")

> >Inverse multiplexing would let a
> >single session to span multiple TCP connections.
>
> Or to let a single TCP tunnel span multiple SSH connections.

Exactly.

> >An inverse multiplexing layer would be added between the the connection
> >layer and multiple instances of the transport layer. The imux layer
> >would appear to the connection layer as a transport layer with relaxed
> >ordering guarantees: SSH packets with the same channel id would be
> >delivered in order but packets from separate channels can have
> >different latencies.
>
> Why bother doing this inside the ssh protocol? Wouldn't it be much cleaner
> to use tcp-level multiplexing and run ssh on top of that (or that on top
> of SSH tunnels)?

Because of latency. If you build some kind of generic tcp inverse
multiplexer ("download accelerator") and run ssh over it the total
throughput will improve but since everything goes through a single
queue a file transfer over a forwarded port will still hurt the latency
of your interactive session.

Oren

>> Oren Tirosh <oren@hishome.net> wrote:
>> >An inverse multiplexing layer would be added between the the connection
>> >layer and multiple instances of the transport layer.

>Mark Rafn wrote:
>> Why bother doing this inside the ssh protocol? Wouldn't it be much cleaner
>> to use tcp-level multiplexing and run ssh on top of that (or that on top
>> of SSH tunnels)?

Oren Tirosh <oren@hishome.net> wrote:
>Because of latency. If you build some kind of generic tcp inverse
>multiplexer ("download accelerator") and run ssh over it the total
>throughput will improve but since everything goes through a single
>queue a file transfer over a forwarded port will still hurt the latency
>of your interactive session.

I must be missing something. TCP stacks can include QoS reordering of the
queue, which is pretty much what you'd need to do inside this proposed ssh
extension, isn't it?
--
Mark Rafn dagon@dagon.net <http://www.dagon.net/>