Subject: Re: SSH v3?

From: Bryan A Ford <[email-masked]>
Date: Thu, 3 Dec 2015 10:18:23 +0100

On 12/3/15 3:46 AM, denis bider wrote:
> Hey Bryan -
> 
> thank you for sharing this, I was not previously aware of Minion.
> 
> The main issue I see is that Minion /does/ in fact seem to require
> modification at the OS level. Even though the changes needed might be
> small, this won't fly unless Linux and Windows both decide to support it.

Yes, that's indeed the catch.  And even though the kernel change
required is only like a pretty trivial hundred lines or so (can't
remember precisely), we have the chicken-and-egg problem that Linux and
Windows kernel devs don't want to upstream it until a "major" user-space
application wants to use it, but "major" user-space applications don't
want to adopt it until it's supported in mainstream kernels. :/

But if (say) OpenSSH expressed serious interest in adopting Minion, I
think that could easily break this chicken-and-egg deadlock.  And it
shouldn't constitute any "risk" that I can see, since Minion is
backward-compatible and incrementally deployable in pretty much all the
ways I can envision caring about, including in particular:

- (a) if the user-space SSH implementation supports it but the kernel
patch isn't present, nothing bad happens other than that endpoint
doesn't get the performance benefit of being able to receive packets
out-of-order.  The SSH implementation basically just calls a setsockopt
that the kernel doesn't support, the kernel returns an error, and the
SSH implementation returns to in-order business as usual.

- (b) if one SSH endpoint (and its kernel) supports Minion but the other
endpoint (or its kernel) doesn't, you still get out-of-order performance
benefits for traffic flowing in one direction but just not for traffic
on the same connection flowing in the other direction.

> Most SSH implementations I'm aware of are user-mode implementations, by
> organizations and/or volunteers who are not familiar with, and do not
> have access to modify, the TCP stack on systems where their SSH
> implementation runs. This is certainly true for me, I can't change the
> TCP implementation in Windows.

I wouldn't suggest it to be the task of SSH developers to implement the
Windows/Linux/FoozleOS kernel patches required to support Minion, and
there's no reason we should expect every mainstream OS to incorporate
the kernel patch any time soon, but you still get incremental benefits
as soon as even one OS and one user-space application (e.g., OpenSSH)
supports it.  And if the SSH community showed enough interest in
adopting Minion to consider supporting it in the (next) protocol spec
and prototyping it (even experimentally) in at least one SSH
implementation, that would provide a much stronger basis on which to
argue for the Minion kernel enhancement to be adopted in kernels,
breaking the chicken-and-egg problem.

> Without underlying platform support, it seems to me the best that SSH
> can do is to either (1) implement support for UDP as an ancillary
> transport for latency-sensitive traffic, or to (2) migrate wholesale to UDP.
> 
> My "EST" suggestion rebuilds the whole protocol on top of UDP. But
> perhaps, implementing support for UDP as an ancillary transport would be
> a more compatible fit with current SSH usage. And also, as you point out
> in your paper, it would be a better fit for connections where UDP is not
> available due to firewall/routing issues.

I'm definitely not against designing protocols to be operable atop UDP
as well; there are certainly tradeoffs each way.

> If you can get Windows + Linux to implement uTCP though, that would have
> the benefit of avoiding even the firewall/routing issues still faced by UDP.

Exactly, that's one such tradeoff.  Another is power efficiency for
mobile devices: you can keep a mostly-idle TCP connection open for a lot
longer than a mostly-idle UDP connection before typical middleboxes
silently time-out and forget the state.  (e.g., the BEHAVE spec requires
TCP timeouts to be on the order of hours, as I recall, whereas UDP
middlebox-state timeouts are typically on the order of minutes.)

Cheers
Bryan

---

From: Bryan Ford <[email-masked]>
Date: Fri, 4 Dec 2015 11:20:13 +0100

On 03 Dec 2015, at 10:53, denis bider <[email-masked]> wrote:
> On the Linux side, perhaps OpenSSH might indeed have an interest in Minion, as an improvement to its existing capabilities of layer 2 and layer 3 tunneling?

Indeed I think that’s a perfect fit and motivation for Minion, and if there’s interest I would be happy to do whatever I can to assist in making that happen.

> On the Windows side, it seems a good bet might be Skype. It's owned by Microsoft, is a major application, and experiences TCP-related problems that Minion would solve.

Agreed, although I personally have less experience with Windows and no immediate contacts with the Skype folks that I know of.

> I'm not sure how hard it might be to attract the attention of some Skype developers, but sometimes it can be as easy as Twitter.

Indeed, worth a try!

B

---

From: denis bider <[email-masked]>
Date: Thu, 3 Dec 2015 02:46:10 +0000

Hey Bryan -

The main issue I see is that Minion does in fact seem to require modification at the OS level. Even though the changes needed might be small, this won't fly unless Linux and Windows both decide to support it.

Most SSH implementations I'm aware of are user-mode implementations, by organizations and/or volunteers who are not familiar with, and do not have access to modify, the TCP stack on systems where their SSH implementation runs. This is certainly true for me, I can't change the TCP implementation in Windows.

Without underlying platform support, it seems to me the best that SSH can do is to either (1) implement support for UDP as an ancillary transport for latency-sensitive traffic, or to (2) migrate wholesale to UDP.

My "EST" suggestion rebuilds the whole protocol on top of UDP. But perhaps, implementing support for UDP as an ancillary transport would be a more compatible fit with current SSH usage. And also, as you point out in your paper, it would be a better fit for connections where UDP is not available due to firewall/routing issues.

If you can get Windows + Linux to implement uTCP though, that would have the benefit of avoiding even the firewall/routing issues still faced by UDP.

denis

----- Original Message -----
From: Bryan Ford 
Sent: Wednesday, December 2, 2015 03:39
To: Niels Möller 
Cc: denis bider ; [email-masked] 
Subject: Re: SSH v3?

On 02 Dec 2015, at 09:34, Niels M?ller <[email-masked]> wrote:
> denis bider <[email-masked]> writes:
>> - TCP prevents efficient tunneling of datagram flow over an SSH
>> session: introduces unnecessary lag to maintain stream abstraction for
>> applications that don't need it.
> 
> It's definitely possible to tunnel udp over tcp (with or without ssh
> being involved). Whether or not that's good enough depends on the
> application. What are the usecases for udp-tunneling over ssh? You also
> have dtls, which might solve your problem in a better way than ssh (I'm
> sorry I don't know the details of that protocol).

TCP?s enforced in-order delivery on protocols like SSH and TLS that are sometimes used to forward datagrams can indeed create latency problems - and especially ?freezes? in audio/video protocols like Skype that easily tolerate a single dropped frame but freak out when a whole RTT worth of frames gets delayed. 

For that reason I?ve been hoping for a while now that some of these protocols would adopt something like our Minion approach, which allows TCP-based protocols to deliver tunneled datagrams out-of-order:

Fitting Square Pegs Through Round Pipes: Unordered Delivery Wire-Compatible with TCP and TLS
http://dedis.cs.yale.edu/2009/tng/papers/nsdi12-abs

I suspect it wouldn?t be that difficult to evolve OpenSSH protocol to be compatible with Minion and hence able to forward tunneled UDP datagrams out-of-order.  I?d be happy to hear if there?s any interest.  I think it would be easy to incorporate Minion support in OpenSSH in a way that would make things no more complicated for implementations that don?t support it, only a little more complicated for implementations that want to, and ensure that all implementations still interoperate perfectly regardless of which endpoints do and don?t support the out-of-order delivery extension.

Cheers
B

---

From: denis bider <[email-masked]>
Date: Thu, 3 Dec 2015 09:53:52 +0000

Bryan A Ford <[email-masked]> , 12/3/2015 9:18 AM:

 

 

 

Cheers 
Bryan