On Mon, Jan 21, 2013 at 11:59 AM, Dave Taht wrote: > 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. > > 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... > > http://www.tcnj.edu/~bush/uftpmulticast ftpmulticast ftp.html > > 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. > > 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? > another option is pgmcc also mentioned in your email. It is a window based scheme that i designed back in '99-2000 http://tools.ietf.org/html/draft-ietf-rmt-bb-pgmcc-03 http://info.iet.unipi.it/~luigi/pgmcc.000608.ps.gz our original FreeBSD in-kernel implementation is at http://info.iet.unipi.it/~luigi/pgm-code/ (it worked on FreeBSD 4 and 5, there is even a test sender and receiver program to try it; but who has multicast anymore...) There is another implementation at https://code.google.com/p/openpgm/ and i am pretty sure i found another one some time ago but i cannot recall the URL. cheers luigi > Sources are here: > > http://snapon.lab.bufferbloat.net/~cero2/uftp4/uftp-4.0a4.tar.gz > > I just slammed that into cerowrt's latest version, which is looking closer > to stable by the day ( > http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/3.7.3-2/ ). It > compiles natively on linux but failed (for me, anyway) on OSX. > > He wrote in our exchange, about all the new stuff in uftp: > > ... > > As it turns out, I've been working on version 4 of UFTP. The main > features are: > > * Data transmission doesn't get interrupted when waiting for NAKs. The > server has separate threads for sending and receiving to handle this. > * 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. > * Protocol redesigned to be more extensible, so changes don't break > backward compatibility. And.... > * Full support for IPv6. > > 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. > > 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. > 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. > > 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. > > 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. > > For unicast mode, the -U option was removed. Instead, give a unicast > address for the server's -M option. > > 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". > > The -b option now specifies the block size (i.e. just the payload part) > rather than the full path MTU. > > 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. > > 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. > > > > -- > Dave Täht > > Fixing bufferbloat with cerowrt: > http://www.teklibre.com/cerowrt/subscribe.html > _______________________________________________ > Codel mailing list > Codel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/codel > > -- -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+-------------------------------