From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 9E97721F0F0; Mon, 21 Jan 2013 14:54:20 -0800 (PST) Received: by mail-lb0-f182.google.com with SMTP id gg6so4196495lbb.13 for ; Mon, 21 Jan 2013 14:54:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=wJQBqOhrGbA0CPXtFRoEOLhTrjyC2VcD7eSUquoIM0E=; b=vn5py5MVcdeaZHj6TNcI6GTduLIEL4MEAeSqakGXffFldylEvb66teFyCVYV2adAnR xtvZySkLPNo2kwBqcUKG6cLYxarcZm13U7y3z/M1uLdMHmJSfQUeyAXlh5Ku23qv9ZdI PMgnSrAcrbQL5iQgIsKT+26pt1EZnYusvijROR7Z4gFLJGydd97So959TFyBtg+XwrXw Gxq1XcBwQkTTPq+zLaXQLNsK1vO+qv6RnU3zCj6GCHnDyojWpx1DdAduuxC7mNUy7Jko Z6weEsZcWAjS7RIUGmnsvp4SXKaipFMYXqjOvMZ7sUQscSK/ROaKNGptzxNTnoDRmR/P j+tg== MIME-Version: 1.0 X-Received: by 10.112.46.70 with SMTP id t6mr8385277lbm.107.1358808858074; Mon, 21 Jan 2013 14:54:18 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.114.93.200 with HTTP; Mon, 21 Jan 2013 14:54:17 -0800 (PST) In-Reply-To: References: Date: Mon, 21 Jan 2013 14:54:17 -0800 X-Google-Sender-Auth: X2fVFmSJo-hyBG_whq4_EOnnyXA Message-ID: From: Luigi Rizzo To: Dave Taht Content-Type: multipart/alternative; boundary=f46d040121934d9ed504d3d45726 X-Mailman-Approved-At: Mon, 21 Jan 2013 22:57:28 -0800 Cc: codel@lists.bufferbloat.net, Dennis Bush , cerowrt-devel@lists.bufferbloat.net, bloat Subject: Re: [Cerowrt-devel] [Codel] fiddling with multicast file transfer with an alpha of uftp 4 X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 22:54:21 -0000 --f46d040121934d9ed504d3d45726 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 tha= t > could measure end to end delay in multicast transfers as well as packet > loss (particularly on complex, competing wifi networks). There's a web pa= ge > 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 an= d > 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 close= r > 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 t= o > the server's timestamp and sends that. Upon receiving the response, the > server subtracts the current time from the timestamp in the response to g= et > the RTT to that client. For data packets I don't include a timestamp, bu= t > instead send periodic congestion control messages which contain a timesta= mp > 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 ti= me > 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 a= dd > 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 th= e > 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=E4ht > > Fixing bufferbloat with cerowrt: > http://www.teklibre.com/cerowrt/subscribe.html > _______________________________________________ > Codel mailing list > Codel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/codel > > --=20 -----------------------------------------+------------------------------- 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) -----------------------------------------+------------------------------- --f46d040121934d9ed504d3d45726 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On M= on, 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, a= s 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 a= s 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 we= ek 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 "t= cp 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 impl= ement multicast congestion control than that RFC?

another option is pgmcc also mention= ed in your email.
It is a window based scheme that i design= ed back in '99-2000



our original FreeBSD in= -kernel implementation is at


(it worked on FreeBSD 4 and 5, there is even a test<= /div>
sender and receiver program to try it;
but who h= as multicast anymore...)

There is anot= her implementation at


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.bufferbl= oat.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.=A0 The m= ain features are:

* Data transmission doesn't get interrupted wh= en waiting for NAKs.=A0 The server has separate threads for sending and rec= eiving to handle this.
* Adaptive congestion control and round trip timing.=A0 This eliminates the= need to specify timing parameters.=A0 Transmission can optionally run at a= fixed speed as before.
* Protocol redesigned to be more extensible, so = changes don't break backward compatibility.=A0 And....
* Full support for IPv6.

The server sends a packet with a timestamp.= =A0 The client records the time the packet was received.=A0 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.= =A0 Upon receiving the response, the server subtracts the current time from= the timestamp in the response to get the RTT to that client.=A0 For data p= ackets I don't include a timestamp, but instead send periodic congestio= n control messages which contain a timestamp as well as the RTT to each cli= ent 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 operat= ions), the RTT to that client could go way up.=A0 Coupled with the server c= utting 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.= =A0 I was initially looking at the NORM implementation of it (RFC 5740), bu= t decided to go with the base implementation, as that would be simpler to a= dd in proxy support.=A0 I'm also considering supporting PGMCC (draft-ie= tf-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 modifi= cations, and is made to work even with congestion control turned off.=A0 Th= e 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) a= re gone in favor of adaptive round trip time calculations.=A0 The group rou= nd trip time starts at 0.5 seconds and is refined from there.

For un= icast mode, the -U option was removed.=A0 Instead, give a unicast address f= or the server's -M option.

The -C option, which used to take the name of a congestion control conf= ig file, now takes the name of the congestion control scheme.=A0 Valid valu= es are either "none" or "tfmcc".=A0

The -b opti= on now specifies the block size (i.e. just the payload part) rather than th= e full path MTU.=A0

Clients are now always identified to the server by their unique ID as s= pecified by -U.=A0 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) th= at support multicast.

Be sure to take a look at the man pages for more details on changed arg= uments.=A0 Also check out the protocol.txt file which contains detailed des= criptions of the round trip time collections, message timings, and any devi= ations from pure TFMCC, as well as details of the new packet format.



--
Dave T=E4ht

Fixing bufferbloat with= cerowrt: http://www.teklibre.com/cerowrt/subscribe.html=20
_______________________________________________
Codel mailing list
Codel@lists.bufferbloat.net<= /a>
= https://lists.bufferbloat.net/listinfo/codel




--
-----------------------------------= ------+-------------------------------
=A0Prof. Luigi RIZZO, rizzo@iet.unipi.it =A0. D= ip. di Ing. dell'Informazione
=A0http://ww= w.iet.unipi.it/~luigi/ =A0 =A0 =A0 =A0. Universita` di Pisa
=A0TEL = =A0 =A0 =A0+39-050-2211611 =A0 =A0 =A0 =A0 =A0 =A0 =A0 . via Diotisalvi 2 =A0Mobile =A0 +39-338-6809875 =A0 =A0 =A0 =A0 =A0 =A0 =A0 . 56122 PISA (= Italy)
-----------------------------------------+-------------------------------
--f46d040121934d9ed504d3d45726--