Re: SSH v3?

[denis bider <ietf-ssh3%denisbider.com@localhost>]

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?

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.

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.

Bryan A Ford <brynosaurus%gmail.com@localhost> , 12/3/2015 9:18 AM:

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