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
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature