One of my long term concerns with fairer queuing algos is the potentially enhanced effect of multicast on heavily bridged networks, as well as on wifi, which tends to run multicast at 1-6Mbit when "line rate" is 300Mbit, and has all sorts of interesting delayed behavior at CAP.<br>
<br>I'd stuck uftp into cerowrt ages ago in the hope that I'd have a tool that could measure end to end delay in multicast transfers as well as packet loss (particularly on complex, competing wifi networks). There's a web page on uftp, uftpd, and the proxy daemon here...<br>
<br><a href="http://www.tcnj.edu/~bush/uftp.html">http://www.tcnj.edu/~bush/uftp.html</a><br><br>Last week I had an exchange with the author, Dennis bush, and it turned out he'd been doing things like implementing neat stuff like RFC 4654 for "tcp friendly multicast congestion control", and IPv6 support. <br>
<br>He sent along an alpha copy and asked if I could roust up some testers and feedback... Anybody out there still dig multicast apps? In particular, given what we know now about delay based AQMs is there a better way to implement multicast congestion control than that RFC?<br>
<br>Sources are here:<br><br><a href="http://snapon.lab.bufferbloat.net/~cero2/uftp4/uftp-4.0a4.tar.gz">http://snapon.lab.bufferbloat.net/~cero2/uftp4/uftp-4.0a4.tar.gz</a><br><br>I just slammed that into cerowrt's latest version, which is looking closer to stable by the day ( <a href="http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/3.7.3-2/">http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/3.7.3-2/</a> ). It compiles natively on linux but failed (for me, anyway) on OSX. <br>
<br>He wrote in our exchange, about all the new stuff in uftp:<br><br>...<br><br>As it turns out, I've been working on version 4 of UFTP.  The main features are:<br><br>* Data transmission doesn't get interrupted when waiting for NAKs.  The server has separate threads for sending and receiving to handle this.<br>
* Adaptive congestion control and round trip timing.  This eliminates the need to specify timing parameters.  Transmission can optionally run at a fixed speed as before.<br>* Protocol redesigned to be more extensible, so changes don't break backward compatibility.  And....<br>
* Full support for IPv6.<br><br>The server sends a packet with a timestamp.  The client records the time the packet was received.  When the client sends a response, it takes the difference between the current time and the arrival time then adds that to the server's timestamp and sends that.  Upon receiving the response, the server subtracts the current time from the timestamp in the response to get the RTT to that client.  For data packets I don't include a timestamp, but instead send periodic congestion control messages which contain a timestamp as well as the RTT to each client as measured by the server.<br>
<br>One thing I noticed is that if a client gets bogged down handling data packets (the congestion control adds a fair amount of floating point operations), the RTT to that client could go way up.  Coupled with the server cutting the rate in the absence of feedback, it can take a long time for the RTT to go back down and the rate to go back up.<br>
I'm basically using TFMCC (RFC 4654), which uses a rate based scheme.  I was initially looking at the NORM implementation of it (RFC 5740), but decided to go with the base implementation, as that would be simpler to add in proxy support.  I'm also considering supporting PGMCC (draft-ietf-rmt-bb-pgmcc-03), which is window based and likely to be more responsive.<br>
<br>The round trip timing is also based on NORM and TFMCC with a few modifications, and is made to work even with congestion control turned off.  The protocol.txt file I'll include with the source will have all the gory details on the RTT timing and differences from straight TFMCC.<br>
<br>On the server, the timing parameters (-A, -S, -a, -s, -r, -d, -W, -m) are gone in favor of adaptive round trip time calculations.  The group round trip time starts at 0.5 seconds and is refined from there.<br><br>For unicast mode, the -U option was removed.  Instead, give a unicast address for the server's -M option.<br>
<br>The -C option, which used to take the name of a congestion control config file, now takes the name of the congestion control scheme.  Valid values are either "none" or "tfmcc".  <br><br>The -b option now specifies the block size (i.e. just the payload part) rather than the full path MTU.  <br>
<br>Clients are now always identified to the server by their unique ID as specified by -U.  If unspecified, the unique ID is taken from the 4 least significant bytes of the first IP on the system (could be either 4 or 6) that support multicast.<br>
<br>Be sure to take a look at the man pages for more details on changed arguments.  Also check out the protocol.txt file which contains detailed descriptions of the round trip time collections, message timings, and any deviations from pure TFMCC, as well as details of the new packet format.<br>
<br><br clear="all"><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>