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

[Dave Taht]

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/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?

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20130121/9d83a490/attachment-0002.html>