From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "rcdn-iport.cisco.com", Issuer "HydrantID SSL ICA G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 9102D208A7C for ; Fri, 29 May 2015 05:43:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3082; q=dns/txt; s=iport; t=1432903445; x=1434113045; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=zWemJ3d6/2eodKTGAL+XZdf8q2uRrSlcBppiE187NY0=; b=V9XRqgU7W3d5oE/TMYNb7qD+EK8VozP8WboXUYzqwArDBiwDNKCozqNl g49YzmVoYJEcI3r+Fa4cSBA/gXkuwCpSqhFR8NLm8eVWq/rY4cos+HsmY XwZHIKidxbF8/hP9eu+bbco3/0b1eq1m+DCifR6peHqGxRND72MJtQkWU E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AOBQDCXWhV/5FdJa1cgxBUXga/bgyFdQKBTEwBAQEBAQGBC4QiAQEBBAEBATc0FwQCAQgOAwQBAQsUCQcnAQoUCQgCBAESCIglDdRIAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4tDhCMRASAzBQaDEYEWBZMKhDWEIYNlhnCPGSNhgSkcgVJvAYELOoEBAQEB X-IronPort-AV: E=Sophos;i="5.13,517,1427760000"; d="scan'208";a="15803190" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-8.cisco.com with ESMTP; 29 May 2015 12:43:14 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t4TChDUC003255 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 29 May 2015 12:43:13 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.135]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Fri, 29 May 2015 07:43:13 -0500 From: "Bill Ver Steeg (versteb)" To: Mikael Abrahamsson , "bloat@lists.bufferbloat.net" Thread-Topic: [Bloat] CDG Thread-Index: AQHQmeP4Ytj7rdsrl0Wk8V3a0CsXO52S4BnA Date: Fri, 29 May 2015 12:43:13 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.247.67] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 12:44:08 -0000 Firstly, these algorithms use drop and ECN in addition to delay to trigger = congestion avoidance behaviors. Having said that...... Yup - using delay as= a trigger for a host-based congestion control algorithm has merit when del= ay has an unambiguous correspondence to congestion. In a tail-drop world, t= his was certainly the case. In an AQM world, this is much less clear.=20 There can be delay in the absence of congestion (noise driven loss being co= rrected by FEC on wireless networks, radio-driven changes in packet delay, = reconvergence/multipath, etc). There can be congestion in the absence of c= ongestion (AQM schemes that drop before building substantial delay). So, de= lay based algorithms will get ambiguous signals. I would add that packet lo= ss is also an ambiguous signal, as noise-driven loss is difficult to distin= guish from congestion driven loss.=20 Hopefully, the new AQM algorithms will fond wide adoption. This will lead t= o 10s of ms of variable buffer delay, rather than 100s of ms. If/when this = happens, a host will be much less likely to use delay as a signal for conge= stion. So ---- delay can be one of the signals that a host can use to trigger cong= estion avoidance, but this is becoming increasingly complex. The host also = needs to factor in packet loss, and ideally ECN markings. As we know, ECN h= as been very slow to roll out. I suspect that loss is going to be the domin= ant congestion signal in the future. This makes distinguishing between noise-driven loss and congestion-driven l= oss more important ---- I wonder if there is a way to have a middlebox that= experiences noise-driven loss do ECN-like stuff to tell the endpoints "Hey= , I just had some noise driven loss, so you may want to interpret at least = some of the recent packet loss as not related to congestion". This does req= uire flow-aware middleboxes, and introduces much of the ECN complexity. Per= haps there is a way to layer loss signaling onto the existing ECN infrastru= cture? I am torn on this notion, due to the low ECN uptake. Bvs -----Original Message----- From: bloat-bounces@lists.bufferbloat.net [mailto:bloat-bounces@lists.buffe= rbloat.net] On Behalf Of Mikael Abrahamsson Sent: Tuesday, May 26, 2015 7:31 AM To: bloat@lists.bufferbloat.net Subject: [Bloat] CDG Hi, I just read https://lwn.net/Articles/645115/ about CDG congestion control. After reading the article, I am left wondering how this kind of congestion = control mechanisms handles being exposed to a token bucket policer: http://www.cisco.com/c/en/us/support/docs/quality-of-service-qos/qos-polici= ng/19645-policevsshape.html With this kind of rate limiting, there is never any buffering or increase i= n latency, you're only seeing packet drops, no other congestion signal. Anyone have any insight? --=20 Mikael Abrahamsson email: swmike@swm.pp.se _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat