From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 36BE6201261 for ; Tue, 4 Sep 2012 08:25:34 -0700 (PDT) Received: by lbol12 with SMTP id l12so7008573lbo.16 for ; Tue, 04 Sep 2012 08:25:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=wcubSzSBfWDac34tQymbpNSgv1SqC7TRdk/Liu7SK9U=; b=FbxeD81usWWGiHyVDQHekYH6jRiq+c20WFYfuIO7xyGmhdmfZ1Yy5xSQCJU/FPlSVr Vr7EV53KTLb9lIrBDLahpp0JIEVCDg3vrZYyVDDc83iXTP7pN98vkssV4huTwQ4br64v G8/ojZhcnTt7moyFIdzjG7485nBomU7oN05p08QUS4ZHtN64NiMfW1AIt1YgPE5lgU/5 sHTCanPdxhuPG4OnjKWYhQtpP93ZDaY6DrAk3XWoGXEJcy/r+M+Z0IGmNdIuahLDLCUS ON9AbvMZSfY4M0+f94DtivslNJQLha3M3Gy6gWC6YyhxH7rBmX8adtGySFs3l4+nKiQC tekQ== Received: by 10.152.112.138 with SMTP id iq10mr17477721lab.13.1346772331494; Tue, 04 Sep 2012 08:25:31 -0700 (PDT) Received: from [10.232.10.49] (37-219-31-21.nat.bb.dnainternet.fi. [37.219.31.21]) by mx.google.com with ESMTPS id xx8sm16802546lab.10.2012.09.04.08.25.28 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 04 Sep 2012 08:25:30 -0700 (PDT) References: <1346396137.2586.301.camel@edumazet-glaptop> <1346421031.2591.34.camel@edumazet-glaptop> <1346421466.2591.38.camel@edumazet-glaptop> <1346503884.7996.65.camel@edumazet-glaptop> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8C148) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <1C18E243-42BC-46F0-A336-EAD9BC881C45@gmail.com> X-Mailer: iPhone Mail (8C148) From: Jonathan Morton Date: Tue, 4 Sep 2012 18:25:18 +0300 To: Nandita Dukkipati Cc: netdev , "codel@lists.bufferbloat.net" , Tomas Hruby Subject: Re: [Codel] [RFC v2] fq_codel : interval servo on hosts 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: Tue, 04 Sep 2012 15:25:34 -0000 I think that in most cases, a long RTT flow and a short RTT flow on the same= interface means that the long RTT flow isn't bottlenecked here, and therefo= re won't ever build up a significant queue - and that means you would want t= o track over the shorter interval. Is that a reasonable assumption? The key to knowledge is not to rely on others to teach you it.=20 On 4 Sep 2012, at 18:10, Nandita Dukkipati wrote: > The idea of using srtt as interval makes sense to me if alongside we > also hash flows with similar RTTs into same bucket. But with just the > change in interval, I am not sure how codel is expected to behave. >=20 > My understanding is: the interval (usually set to worst case expected > RTT) is used to measure the standing queue or the "bad" queue. Suppose > 1ms and 100ms RTT flows get hashed to same bucket, then the interval > with this patch will flip flop between 1ms and 100ms. How is this > expected to measure a standing queue? In fact I think the 1ms flow may > land up measuring the burstiness or the "good" queue created by the > long RTT flows, and this isn't desirable. >=20 >=20 > On Sat, Sep 1, 2012 at 5:51 AM, Eric Dumazet wrot= e: >> On Fri, 2012-08-31 at 18:37 -0700, Yuchung Cheng wrote: >>=20 >>> Just curious: tp->srtt is a very rough estimator, e.g., Delayed-ACks >>> can easily add 40 - 200ms fuzziness. Will this affect short flows? >>=20 >> Good point >>=20 >> Delayed acks shouldnt matter, because they happen when flow had been >> idle for a while. >>=20 >> I guess we should clamp the srtt to the default interval >>=20 >> if (srtt) >> q->cparams.interval =3D min(tcp_srtt_to_codel(srtt), >> q->default_interval); >>=20 >>=20 >>=20 > _______________________________________________ > Codel mailing list > Codel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/codel