From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id EED8021F0F2 for ; Sun, 17 Mar 2013 22:53:45 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 007849C; Mon, 18 Mar 2013 06:53:43 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id EEE7C9A for ; Mon, 18 Mar 2013 06:53:43 +0100 (CET) Date: Mon, 18 Mar 2013 05:30:36 +0100 (CET) From: Mikael Abrahamsson To: Jim Gettys In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed ReSent-Date: Mon, 18 Mar 2013 06:53:41 +0100 (CET) ReSent-From: Mikael Abrahamsson ReSent-To: bloat@lists.bufferbloat.net ReSent-Subject: Re: Flow queuing performance (was: Re: [tsvwg] New Version Notification for draft-baker-tsvwg-aqm-recommendation-00.txt) ReSent-Message-ID: ReSent-User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Cc: Eric Dumazet , tsv-area@ietf.org, bloat , aqm@ietf.org Subject: Re: [Bloat] Flow queuing performance (was: Re: [tsvwg] New Version Notification for draft-baker-tsvwg-aqm-recommendation-00.txt) X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 05:53:46 -0000 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