[Codel] fiddling with multicast file transfer with an alpha of uftp 4

Mon Jan 21 17:54:17 EST 2013

On Mon, Jan 21, 2013 at 11:59 AM, Dave Taht <dave.taht at gmail.com> 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<http://www.tcnj.edu/~bush/uftp.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 at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/codel
>
>

-- 
-----------------------------------------+-------------------------------
 Prof. Luigi RIZZO, rizzo at 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)
-----------------------------------------+-------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/codel/attachments/20130121/8ce2b3b9/attachment-0002.html>