From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lpp01m010-f43.google.com (mail-lpp01m010-f43.google.com [209.85.215.43]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 9E86221F0D6; Wed, 16 May 2012 02:31:21 -0700 (PDT) Received: by lahg1 with SMTP id g1so769586lah.16 for ; Wed, 16 May 2012 02:31:18 -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=Fey3WSc9uYzRKT6H2dOsHNLY2URqMF80XQETFFcgnzY=; b=Ep1VQkC6qS7gPFjOUONgjOQbgkeC9mDf2S1+6eTrSysghUyhu0WPdl6P9w0Ln4+zwI o0ZInBx3xbd3Oy1Al6qzF+zbTdMpJnvs2VkYgZ/p/i3do4/B+PWMCUehQ9xvXHJ7QWBn UGx0AphnJdYjFBtRYHqozZz+/G7lKY2VvgZYW4DtgB5Kjh2EAvYcc4a+8DsHAhQPTg2P PICU0td2SddepLy+C3dxXLiJ2gVm9MpwsJfLWhmLDXuCCQGf6FooqlzeOAx71c5r8KZG UefZQ9D036DErOI5yqr50h0HEk8etGRP9yrwvhDsTm0KC49L6H9uiJSjapG8DJmyKsLO XGOQ== Received: by 10.152.132.166 with SMTP id ov6mr2379726lab.35.1337160678663; Wed, 16 May 2012 02:31:18 -0700 (PDT) Received: from [176.93.81.139] (176-93-81-139.bb.dnainternet.fi. [176.93.81.139]) by mx.google.com with ESMTPS id tt8sm2772422lbb.16.2012.05.16.02.31.07 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 16 May 2012 02:31:17 -0700 (PDT) References: <4FA9FDC0.9010600@superduper.net> <1337148560.8512.1123.camel@edumazet-glaptop> <4FB3519D.3020809@gmail.com> <1337154417.8512.1147.camel@edumazet-glaptop> <1337156271.8512.1163.camel@edumazet-glaptop> <1337159673.8512.1164.camel@edumazet-glaptop> In-Reply-To: <1337159673.8512.1164.camel@edumazet-glaptop> Mime-Version: 1.0 (iPhone Mail 8C148) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8C148) From: Jonathan Morton Date: Wed, 16 May 2012 12:31:25 +0300 To: Eric Dumazet Cc: "codel@lists.bufferbloat.net" , "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 09:31:22 -0000 There are two goals here. One: provide real feedback to TCPs so that they kn= ow when the link is full and thus don't also fill up the buffer constantly. T= wo: prevent flows from unduly interfering with each other, so they don't hav= e to fill the buffer just to be sure of good throughput.=20 What you seem to be saying is that you have a queue full of unresponsive flo= ws that aren't being dropped because they have ECN support and are being mar= ked instead. With FQ, that doesn't matter because other flows can still get t= hrough with low latency, and in fq_codel they are treated separately for mar= k/drop decision purposes. And if the queue really does fill up physically, c= odel already drops packets at head regardless of ECN capability.=20 The key to knowledge is not to rely on others to teach you it.=20 On 16 May 2012, at 12:14, Eric Dumazet wrote: > On Wed, 2012-05-16 at 12:02 +0300, Jonathan Morton wrote: >> With FQ, I don't see what that would buy you.=20 >=20 > Sorry I dont understand your point. >=20