Re: [Bloat] Flow queuing performance (was: Re: [tsvwg] New Version Notification for draft-baker-tsvwg-aqm-recommendation-00.txt)

[Mikael Abrahamsson <swmike@swm.pp.se>]

On Sun, 17 Mar 2013, Jim Gettys wrote:

> Secondly, an extremely important factoid about why we got so excited 
> about fq_codel (which is really DRR, in term derived from SFQ, combined 
> with CoDel along with detecting thin vs. thick flows) is its 
> performance:

I can imagine! One thought, have tests been done that indicate that 
generally an all-TCP-ACK "flow" (as seen in the egress direction) is still 
considered a "thin" flow? In the ADSL case with 20 meg down and 1 meg up, 
I seem to remember that ACKing 20 megabit/s of traffic uses 30-40% of the 
upstream bandwidth so it's a matter of opinion if this is actually a thick 
flow or not?

I'm trying to understand how codel handles the use case of 100 upload 
torrent TCP sessions (all trying to run max upload speed) and a single tcp 
http/ftp download. This is one of the most common complaints I've seen 
over the years about bufferbloat, uploading destroys download performance.

Another thing that I would like to see tested on Linux is the combination 
of fq_codel and shaping the speed. This is for the use case in ETTH 
selling for instance a 100/10 connection, where the 10 upstream connection 
is achieved by policing the bw in the ETTH access switch (the physical 
port is 100/100. It would give the user a better experience if the CPE 
could shape the traffic outgoing to 10 megabit to avoid the packet loss 
caused by the policing. This is something I would like to put in as an RFQ 
requirement, so it would be good if any AQM standard actually defined this 
mechanism and it was part of the description.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se