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: swm...@swm.pp.se
