On 02 Dec 2015, at 09:34, Niels Möller <nisse%lysator.liu.se@localhost> wrote: > denis bider <ietf-ssh3%denisbider.com@localhost> 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
Attachment:
smime.p7s
Description: S/MIME cryptographic signature