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

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

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 4867 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 5346 bytes --]

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

[Luigi Rizzo]

[-- Attachment #1: Type: text/plain, Size: 6408 bytes --]

On Mon, Jan 21, 2013 at 11:59 AM, Dave Taht <dave.taht@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@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)
-----------------------------------------+-------------------------------

[-- Attachment #2: Type: text/html, Size: 8386 bytes --]