<font face="times new roman" size="2"><p style="margin:0;padding:0;">I have not investigated UDT in detail.   My sense is that it is pretty much like TCP but assumes that the bottleneck is actually a fixed rate link, rather than one with significant variability in the capacity-per-flow available.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">I don't think it uses the "biggest gun" that can improve things when the end-to-end latency gets long: non-ordered delivery acknowledgement coupled with Fountain Codes (or some other rateless erasure code).</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">For file transfer (where the only goal is complete delivery of the entire file), sending every file block independently and using rateless erasure coding to ensure that any sufficiently large subset of the packets will give the contents of the file, one can allow the bottleneck link to use packet drops to signal congestion, while not requiring sequential retransmission.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">So if I were starting with fq_codel in the network, I would use a rate-controlled UDP with Fountain Coding on the file contents, per-file-block acknowledgment (using a run-length-coded bitstring for blocks correctly received), and a rate-controller that uses the number of blocks received vs. blocks sent to detect drops due to buffer overflow to set window size to limit the number of blocks in transit.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">That would maximize FTP, while still allowing "mice" and "ants" and other FTPs to get great, low-latency, service.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">-----Original Message-----<br />From: "Dave Taht" <dave.taht@gmail.com><br />Sent: Friday, February 22, 2013 11:48am<br />To: cerowrt-devel@lists.bufferbloat.net, "bloat" <bloat@lists.bufferbloat.net><br />Subject: [Cerowrt-devel] Fwd: High Speed WAN Rsync now possible via UDT<br /><br /></p>
<div id="SafeStyles1361645588">
<p style="margin:0;padding:0;">Since we are essentially observing "wan" latencies anyway I am curious as to how the UDT protocol functions... has anyone tried it?<br /><br />If useful (or scary) I'll try to find the time to package it up for cero. <br /><br />I liked how mosh solved the terminal emulation problem over lousy links (in fact, reflecting on it, had it existed in 1998 when I was mucking with the strip protocol, I'd have not bothered with getting tcp to work at all. :) ) I also get a kick out of people using ssh to "authenticate" and then dropping to something else....<br /><br /><br /></p>
<div class="gmail_quote">---------- Forwarded message ----------<br />From: <strong class="gmail_sendername">Erich Weiler</strong> <span dir="ltr"><<a href="mailto:weiler@soe.ucsc.edu">weiler@soe.ucsc.edu</a>></span><br /> Date: Fri, Feb 22, 2013 at 10:54 AM<br />Subject: High Speed WAN Rsync now possible!!!<br />To: <a href="mailto:rsync@lists.samba.org">rsync@lists.samba.org</a><br /><br /><br />Folks-<br /><br /> Just wanted to plug a totally awesome software package from a group I know: UDR (UDT Enabled Rsync).<br /><br /> For those not familiar with UDT, it is a low level network protocol based on UDP that allows for high speed transfers over high latency WAN networks:<br /><br /><a href="http://udt.sourceforge.net/" target="_blank">http://udt.sourceforge.net/</a><br /><br /> For a while the UDT API was available, developed by the Laboratory for Advanced Computing at the University of Chicago, but there were little development around it for actually developing a software suite to allow for high speed WAN transfers, such as can be achieved by Aspera, GridFTP, FDT, and a couple others.  The problem with those often is:<br /><br /> Aspera: Great but *crazy* expensive<br /> GridFTP: Not bad but non-trivial to set up<br /> FDT: Java (Eh...)<br /><br /> But the awesome thing here is that UDR is a lightweight wrapper for rsync that allows for rsync functionality, but uses UDT as the underlying protocol for transfer (no rsh or ssh).  It authenticates over ssh and then transfers the data over UDT streams.  And supports encryption.<br /><br /> Right now it is kind of in beta but we've been using it for a while and it's very stable.  It has been tested on Linux, BSD and OSX.  It may compile on other platforms but not much testing has been done on those.  Written in C++.<br /><br /><a href="https://github.com/LabAdvComp/UDR" target="_blank">https://github.com/LabAdvComp/<span style="text-decoration: underline;"> </span>UDR</a><br /><br /> You can clone the repo with 'git clone' and build the code.  It compiles very easily and only requires the OpenSSL library as a dependency.<br /><br /> As an example:  We have been trying to transfer data from California to our servers in Germany for a while, and have only be getting 10Mb/s. With UDR we get 700Mb/s.  Not bad.<br /><br /> There are details on the GitHub page.  Check it out!!<span class="HOEnZb"><span style="color: #888888;"><br /><br /> -erich<br /> -- <br /> Please use reply-all for most replies to avoid omitting the mailing list.<br /> To unsubscribe or change options: <a href="https://lists.samba.org/mailman/listinfo/rsync" target="_blank">https://lists.samba.org/<span style="text-decoration: underline;"> </span>mailman/listinfo/rsync</a><br /> Before posting, read: <a href="http://www.catb.org/~esr/faqs/smart-questions.html" target="_blank">http://www.catb.org/~esr/faqs/smart-questions.html</a><br /></span></span></div>
<br /><br /><br />-- <br />Dave Täht<br /><br />Fixing bufferbloat with cerowrt: <a href="http://www.teklibre.com/cerowrt/subscribe.html" target="_blank">http://www.teklibre.com/cerowrt/subscribe.html</a></div></font>