From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com [209.85.214.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 DDE2C21F0D8; Wed, 16 May 2012 02:38:02 -0700 (PDT) Received: by bkty5 with SMTP id y5so879350bkt.16 for ; Wed, 16 May 2012 02:38:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; bh=hq8lYKXQ8EvqpsEI1TH3YV62vbH29vvObMOc0Zin01o=; b=AQvJxbdaI1VeSmtVvtjUJ1DVRdSZNb2cayu3Dw7GprL1rToFuFkpsk3cCTyQJQXe3M SX6HWkdppMYm9X2jFLvCLkD1arWY4q59rrbMHRMiG29ZJGCYpZIcOB57jHkdiLcVCtZS I94YjX95TQajRTJqkFynRmyh3djTNC1B3OaYGc0TarURI1HaeK/4KtKlC0E5IFgLGB+g bkp+wgZDcYHBr/8B6X/HDiHSYk1qcZF6mXWG+NoLyqx30SmpGvS9pkVKVIctR0XA4y3+ n5kmzQsGni9nW4qGFUYAg6VqSfUEfaa00nOAPeTZMfqDcfu5vPDIgWYAET0IVMXXwO8k C3zA== Received: by 10.204.152.13 with SMTP id e13mr927418bkw.46.1337161080753; Wed, 16 May 2012 02:38:00 -0700 (PDT) Received: from [172.28.91.41] ([74.125.122.49]) by mx.google.com with ESMTPS id m2sm3538773bkm.2.2012.05.16.02.37.59 (version=SSLv3 cipher=OTHER); Wed, 16 May 2012 02:37:59 -0700 (PDT) From: Eric Dumazet To: Jonathan Morton In-Reply-To: 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> Content-Type: text/plain; charset="UTF-8" Date: Wed, 16 May 2012 11:37:57 +0200 Message-ID: <1337161077.8512.1170.camel@edumazet-glaptop> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit 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:38:03 -0000 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. > > 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. It matters because : 1) We setup high limit for codel so "head drop" at enqueue time is a last resort thing. 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.