From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from g1t0027.austin.hp.com (g1t0027.austin.hp.com [15.216.28.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.hp.com", Issuer "VeriSign Class 3 Secure Server CA - G3" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 7D0A321F0C5; Wed, 16 May 2012 10:40:09 -0700 (PDT) Received: from g1t0039.austin.hp.com (g1t0039.austin.hp.com [16.236.32.45]) by g1t0027.austin.hp.com (Postfix) with ESMTP id 6CAB13851C; Wed, 16 May 2012 17:40:08 +0000 (UTC) Received: from [16.89.64.213] (tardy.cup.hp.com [16.89.64.213]) by g1t0039.austin.hp.com (Postfix) with ESMTP id 1CF82354D7; Wed, 16 May 2012 17:40:08 +0000 (UTC) Message-ID: <4FB3E677.7090304@hp.com> Date: Wed, 16 May 2012 10:40:07 -0700 From: Rick Jones User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: codel@lists.bufferbloat.net References: <4FA9FDC0.9010600@superduper.net> <1337148560.8512.1123.camel@edumazet-glaptop> <4FB3519D.3020809@gmail.com> <1337154417.8512.1147.camel@edumazet-glaptop> In-Reply-To: <1337154417.8512.1147.camel@edumazet-glaptop> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: bloat@lists.bufferbloat.net Subject: Re: [Codel] [Bloat] Exploring the potential of codel, fq_codel, and qfq X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 17:40:09 -0000 On 05/16/2012 12:46 AM, Eric Dumazet wrote: > On Wed, 2012-05-16 at 00:20 -0700, Dave Taht wrote: > >> With ecn: >> >> 64 bytes from 149.20.63.18: icmp_req=46 ttl=64 time=10.6 ms >> 64 bytes from 149.20.63.18: icmp_req=47 ttl=64 time=5.66 ms >> 64 bytes from 149.20.63.18: icmp_req=48 ttl=64 time=11.8 ms >> 64 bytes from 149.20.63.18: icmp_req=49 ttl=64 time=3.68 ms >> 64 bytes from 149.20.63.18: icmp_req=50 ttl=64 time=10.2 ms >> 64 bytes from 149.20.63.18: icmp_req=51 ttl=64 time=12.8 ms >> 64 bytes from 149.20.63.18: icmp_req=52 ttl=64 time=2.62 ms >> 64 bytes from 149.20.63.18: icmp_req=53 ttl=64 time=7.86 ms >> >> TCP_RR: 102 >> >> All of these sets of results need more rigor attached. > > On TCP_RR pure workload, you have one packet in flight per flow. > > ECN adds nothing in this case, only that no 'drops' occurs at all. > > It might be good to change fq_codel to perform ECN mark only if flow > queue has more packets. > > If not, plain drop. I like netperf as much as anyone :) but keep in mind that the TCP_RR test has only one segment outstanding at a time only when the request/response size is < MSS and/or one has not enabled burst mode to have multiple transactions in flight at one time. Are we really likely to see a situation where all the flows are one packet at a time? If all the flows are either that way naturally, or have gotten there thanks to a one segment cwnd are we not already in a very pathological situation? For the impossible to define "fair" question, is it fair to drop a flow's only packet if there are other, multiple-packet flows around? rick jones