Re: SSH v3?

[denis bider <[e-mail]>]

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 <[e-mail]> , 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