Comments on: SSH over UDP: How to swallow an elephant http://www.loligo.com/blog/ssh-over-udp-how-to-swallow-an-elephant/ Practical, Technical, Theoretical Tue, 24 Mar 2015 21:24:20 +0000 hourly 1 http://wordpress.org/?v=4.2.2 By: jtodd http://www.loligo.com/blog/ssh-over-udp-how-to-swallow-an-elephant/comment-page-1/#comment-22982 Fri, 06 Apr 2012 05:33:27 +0000 http://www.loligo.com/blog/?p=104#comment-22982 Update on the HPN-SSH tests: we tried this at TED 2012, or at least Bog tried it. He was unable to get the kernel tuned with MacOS 10.7 in a way that moved files at greater than (IIRC) around 20mbps. Clearly, not a win, but this may have been due to MacOS 10.7 changing some of the parameters to rely upon each other in the kernel that previously had not. The instructions for MacOS were for an older version of the software, so this was not a big win and the Aspera software was used along with a 1gbps uplink provided by CENIC (thanks, CENIC!)

I have not had any time to really look at this in more detail, because I’m pretty much swamped with the day job. But still the question remains: why isn’t this part of SSH as a default? This would speed up transfers immensely. I have yet to hear anyone come up with a reason that would be suitably significant to block development on a project like this.

I’ve also come up with another idea, which I had while discussing this issue with a CDN vendor yesterday: why isn’t there any CDN that has created a “helper” app that would run on the local user’s computer and intercept packets destined for certain IP addresses, and then shim them through a UDP accelerator? This could run almost entirely transparently, and if it had appropriate fallback mechanisms it would work under any network conditions, even where UDP was blocked. (It wouldn’t be able to help where proxies were configured, but that’s an edge case.) For game or media delivery, this would be _amazing_. This would truly be a “viral” application, meaning that anyone who used that content network could encourage users to use the helper app, and they would get the amazing performance transparently. In the game industry, that kind of thing spreads like wildfire in the community – whoever gets better performance on the network, wins more. So why no magic from a CDN? Well, chalk this up to yet another idea of mine that will make someone else millions of dollars that I won’t have time to do – it’s a long and sad list. (It’s also an idea that I’m sure someone else has already had, but… I don’t see it on the market, nor have I ever seen it, so I’ll call it “mine”.)

]]>
By: jtodd http://www.loligo.com/blog/ssh-over-udp-how-to-swallow-an-elephant/comment-page-1/#comment-18097 Wed, 22 Feb 2012 04:53:44 +0000 http://www.loligo.com/blog/?p=104#comment-18097 Almost a year later, I’ve found another project which seems to fit the bill perfectly. It’s the “High Performance SSH” aka HPN-SSH project, run by the Pittsburgh Supercomputing Center (PSC). It appears fairly well maintained. Why isn’t this code part of OpenSSH? It seems to be a no-brainer if it does what it says it does. Right now, I don’t have the time to test, but in the next week or so that may change.

http://www.psc.edu/networking/projects/hpn-ssh/

]]>
By: jtodd http://www.loligo.com/blog/ssh-over-udp-how-to-swallow-an-elephant/comment-page-1/#comment-1653 Tue, 08 Mar 2011 21:53:18 +0000 http://www.loligo.com/blog/?p=104#comment-1653 I was also told about this: HyperIP, which is available as a VMWare image:

http://www.vmware.com/appliances/directory/va/155643

I did experiment a bit with the Aspera software last week on a licensed version, but apparently it was licensed only for the Mac “GUI client” and did not include a license for the “command line” client. WTF? I really, really hate licensed software head-pounding. There are options only availble in the command-line version that aren’t available in the GUI version. Anyway, it worked well enough for a single stream – we reached 80mbps, which was maximum for the upstream path (two stream-balanced 80mbps links.) But we could have gone to 160mbps if we were able to use the command line version, which allows files to be split and sent as multiple chunks, each using a different UDP stream. But the cost for this stuff is eye-popping – it’s not that difficult. This should be free, since it is a common problem with multi-hundred megabit and gigabit (and 10-gigabit) networking becoming commonplace now with transcontinental ACK latency, or steady low-level errors on radio/satellite connections that cause TCP to be useless.

I still want to see this embedded in SSH. SSH would have only a few additional options:

-U Send using UDP.
-Q[N] Aggressiveness level for transmission – how much packet loss is tolerated before back-off, in percent. Default: 1 (or 1% packet loss)

SCP could have more features, but rsync already provides a lot of the file-handling kind of stuff via SSH calls (which would be UDP-enhanced) so SCP would only need a few tweaks. Having options like this in SCP would be awesome:

-U Send using UDP
-s: Split files. Send Y chunks, with this session being chunk X. (i.e.: -s1:3 -s2:5 etc.) When last chunk is received, remote system will reassemble file.
-f Freshen files. If partial files have been received from prior aborted transmissions, delete segments on remote system and start anew. Applies to full file or chunk specified with “-:
-Q[N] Aggressiveness level for transmission – how much packet loss is tolerated before back-off, in percent. Default: 1 (or 1% packet loss)

The “-l” command already exists to limit bandwidth.

]]>
By: jzp http://www.loligo.com/blog/ssh-over-udp-how-to-swallow-an-elephant/comment-page-1/#comment-966 Sat, 12 Feb 2011 21:48:49 +0000 http://www.loligo.com/blog/?p=104#comment-966 UFTP has some bootstrapping issues. Our fixes to provide some CTS-style handshaking may or may not be acceptade by the maintainer.

]]>
By: jtodd http://www.loligo.com/blog/ssh-over-udp-how-to-swallow-an-elephant/comment-page-1/#comment-467 Mon, 10 Jan 2011 16:53:42 +0000 http://www.loligo.com/blog/?p=104#comment-467 For other people who find this post, here are some additional pointers people sent to me. I’ve not had time to test these TCP over UDP perl scripts:

Duat:
http://code.google.com/p/duat/

TCP over UDP:
http://www.jankratochvil.net/project/tcpoverudp/

]]>
By: jtodd http://www.loligo.com/blog/ssh-over-udp-how-to-swallow-an-elephant/comment-page-1/#comment-308 Thu, 23 Dec 2010 17:43:34 +0000 http://www.loligo.com/blog/?p=104#comment-308 Another solution (commercial, hardware-based) that was suggested several times in private conversation was the platform from http://www.storagedna.com/

]]>
By: jtodd http://www.loligo.com/blog/ssh-over-udp-how-to-swallow-an-elephant/comment-page-1/#comment-250 Fri, 17 Dec 2010 18:38:20 +0000 http://www.loligo.com/blog/?p=104#comment-250 It’s a single stream – several giant files that need to move quickly from point A to point B.
UFTP looks interesting. It has a single host unicast option, which I’ll try out. I’d still love to see UDP supported in SSH, since that would be widely available and easily adaptable to other features of SSH (port forwarding, scp, etc.)

What client applications support SCTP?

]]>
By: Dave Täht http://www.loligo.com/blog/ssh-over-udp-how-to-swallow-an-elephant/comment-page-1/#comment-248 Fri, 17 Dec 2010 14:20:39 +0000 http://www.loligo.com/blog/?p=104#comment-248 Are you moving major amounts of data across a single stream? If it is multiple streams, perhaps sctp might help. If it is a large dataflow that has to go to multiple locations, uftp is pretty neat.

http://www.tcnj.edu/~bush/uftp.html

I think it does FEC, but haven’t looked at it recently.

Otherwise, UDP does not seem like a good idea, as anything that you do over it is likely to break something, somewhere else, in the network.

Jim Gettys notes that “bufferbloat” is breaking TCP across the Internet by doing too much intermediate buffering: http://gettys.wordpress.com/category/bufferbloat/

]]>