From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 63269208A7C for ; Fri, 29 May 2015 01:35:14 -0700 (PDT) Received: by lbcue7 with SMTP id ue7so43939376lbc.0 for ; Fri, 29 May 2015 01:35:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=G8D/XuCnYJiUYLPM6mzABdoMvvr+xLxFLhRL4MQtHiM=; b=YSQyBJP6+ehUiCvfdOYHuzITlv/a4uYDKxqNL+YxObzJ5zh/POACr1UiOf6ypj1MAJ Gwio+VK5lHhDy62Or/8cWAxRV3taIXSh0H1+Pz7gaah2zZei9NtB49+YCcYO3Zc5Lkvn O7Sid210IGUY3VIzTk7Igpakur2C/Yz3nG8rx29uTxVc2gsuACosuEhUk2kGfDAnblYn CjCehS1fMUPBIHV/t9UO1rkJcp6rUExashDO+QlJ3phJyTlhKTgWQ9rTZqw8yAvXob5D lhe/NLGwNgv3qilY0QPsvCp39rQKNc+A4uElgiD1tbVnWm+lB9D55W2CbsYOT8kyKVap DBGQ== X-Received: by 10.112.140.231 with SMTP id rj7mr6823684lbb.76.1432888508204; Fri, 29 May 2015 01:35:08 -0700 (PDT) Received: from bass.home.chromatix.fi (87-95-58-74.bb.dnainternet.fi. [87.95.58.74]) by mx.google.com with ESMTPSA id xg8sm1208170lac.17.2015.05.29.01.35.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 29 May 2015 01:35:07 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Jonathan Morton In-Reply-To: Date: Fri, 29 May 2015 11:35:02 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <5315D91E-AEE5-4782-A83F-37D48C749AD9@gmail.com> References: To: Mikael Abrahamsson X-Mailer: Apple Mail (2.2098) Cc: bloat@lists.bufferbloat.net Subject: Re: [Bloat] CDG X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 08:35:55 -0000 > On 26 May, 2015, at 14:31, Mikael Abrahamsson = wrote: >=20 > I just read https://lwn.net/Articles/645115/ about CDG congestion = control. >=20 > After reading the article, I am left wondering how this kind of = congestion control mechanisms handles being exposed to a token bucket = policer: >=20 > = http://www.cisco.com/c/en/us/support/docs/quality-of-service-qos/qos-polic= ing/19645-policevsshape.html >=20 > With this kind of rate limiting, there is never any buffering or = increase in latency, you're only seeing packet drops, no other = congestion signal. >=20 > Anyone have any insight? It doesn=E2=80=99t have to be a policer - most properly-configured AQMs = also start to mark or drop packets before significant extra delay can be = measured by the endpoints, which is why LEDBAT behaves like a = conventional TCP under AQM. I would hope that CDG responds = appropriately to ECN marks, even if it assumes packet loss might not be = congestion-related. I happen to believe that the ultimate goal of zero induced delay can = *only* be achieved using a combination of network and endpoint = intelligence, not one or the other alone. Lots of work has been done so = far on endpoint intelligence, using the assumption that the network uses = only dumb FIFOs (which is, at present, a reasonable observation). CDG = is merely another example of this. - Jonathan Morton