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 CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id C3CF821F0DA; Wed, 16 May 2012 02:59:22 -0700 (PDT) Received: by lbom4 with SMTP id m4so820953lbo.16 for ; Wed, 16 May 2012 02:59:20 -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=WXStfnq4hHu2MpFr0XxQvEP+ECFGSUe/uucfqkvP3qo=; b=0NEHYUrz+Nur6+lPMrFJDyKoiUap0+71PnoRNafUxJ12bsSoTmX/0P4HRcWBGS+mw3 owF9eg85mNFkaZ0xVd5bCiW9JHhRWlH5Oh520gD0+vwjMxD0JyzoKpERtDgEF116FhTt pO+xo1pLnHBOIEtuysbzIg03MtxVJlp7YpYi4NzoK0Hf67qHdL7EIWiW7TNRCpj2HVyJ 48MgZrLczJqpzON89qzoys5hVuRbKeozqdUF8YIni15tcB2XCcR2o9g1uZVdQ4uShmG7 op3reUDVY/bpR9N+R+99XHAFDm05y2COx91QOhbls0nc+a+JDXBrbqD7UOG+hA7R28wF HiFg== Received: by 10.152.128.201 with SMTP id nq9mr2343250lab.26.1337162360455; Wed, 16 May 2012 02:59:20 -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 gd9sm2876111lbb.15.2012.05.16.02.59.17 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 16 May 2012 02:59:19 -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> <1337161077.8512.1170.camel@edumazet-glaptop> In-Reply-To: <1337161077.8512.1170.camel@edumazet-glaptop> Mime-Version: 1.0 (iPhone Mail 8C148) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <07FA401E-06D8-4746-95A5-9AF675FD5402@gmail.com> X-Mailer: iPhone Mail (8C148) From: Jonathan Morton Date: Wed, 16 May 2012 12:59:43 +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:59:23 -0000 That's a pretty specific type of blackhole - one that can pass enough ECN in= formation to permit negotiation of an ECN flow, but which then squashes Cong= estion Experienced codepoints. How common are those? If fq_codel drops from the head of the longest flow when the queue is physic= ally full, rather than the next one to be serviced, all should be well even i= n that case.=20 The key to knowledge is not to rely on others to teach you it.=20 On 16 May 2012, at 12:37, Eric Dumazet wrote: > On Wed, 2012-05-16 at 12:31 +0300, Jonathan Morton wrote: >> There are two goals here. One: provide real feedback to TCPs so that >> they know when the link is full and thus don't also fill up the buffer >> constantly. Two: prevent flows from unduly interfering with each >> other, so they don't have to fill the buffer just to be sure of good >> throughput.=20 >>=20 >> What you seem to be saying is that you have a queue full of >> unresponsive flows that aren't being dropped because they have ECN >> support and are being marked instead. With FQ, that doesn't matter >> because other flows can still get through with low latency, and in >> fq_codel they are treated separately for mark/drop decision purposes. >> And if the queue really does fill up physically, codel already drops >> packets at head regardless of ECN capability.=20 >=20 > It matters because : >=20 > 1) We setup high limit for codel so "head drop" at enqueue time is a > last resort thing. >=20 > 2) If you have ECN blackhole _after_ you, flow can be non responsive not > because it doesnt want to, only because of the blackhole. Detecting a > too long delay in this flow queue and reverting to drops instead of > marks can help to recover from ECN blackhole. >=20 >=20 >=20