Re: [aqm] adoption call: draft-welzl-ecn-benefits

David Collier-Brown <davec-b@rogers.com> Fri, 29 August 2014 13:52 UTC

Return-Path: <davec-b@rogers.com>
X-Original-To: aqm@ietfa.amsl.com
Delivered-To: aqm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 493091A0382 for <aqm@ietfa.amsl.com>; Fri, 29 Aug 2014 06:52:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.7
X-Spam-Level:
X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5veAytG0ywb for <aqm@ietfa.amsl.com>; Fri, 29 Aug 2014 06:52:32 -0700 (PDT)
Received: from nm23-vm4.access.bullet.mail.gq1.yahoo.com (nm23-vm4.access.bullet.mail.gq1.yahoo.com [216.39.63.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B3A21A038F for <aqm@ietf.org>; Fri, 29 Aug 2014 06:52:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rogers.com; s=s1024; t=1409320352; bh=aNnwIunfo1xKwrrWPRmyHUwGlCRLDROEy7zqu5vFm6A=; h=Received:Received:Received:DKIM-Signature:X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=ZgzgrAIw0BXs8dfwvR7LO9xF5m9NI55iv3qEGtuSs+XM3QRlN+DHbOxNLNQN5Oy5dlkC40Na/mNf9YSOHZvbi4S1O6eiegNwXgHF/9AEPnrZ6xFqR2DfNMFcKNzYROFRAM3Z9p+5j1Crmr5rGNiMYh3RsI7xIX2F7EHCw85wjXU=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; b=eo7QsAf9dFNlzRlp8YRAAyZvpqjuZuNgYtjNyQWd8zM9yMI1cRdLxxuHLsnRgdgUioeLr6OB9tVDpkUPUckXuNkzRmn8gWJ6SeSKeIg/5zciUixWPCkTlPiDLKlW1ZO5HGv02TMnD4Q6ROSO9iqYp+9WVZRnbu6m740q8rnRei0=;
Received: from [216.39.60.172] by nm23.access.bullet.mail.gq1.yahoo.com with NNFMP; 29 Aug 2014 13:52:32 -0000
Received: from [67.195.22.116] by tm8.access.bullet.mail.gq1.yahoo.com with NNFMP; 29 Aug 2014 13:52:32 -0000
Received: from [127.0.0.1] by smtp111.sbc.mail.gq1.yahoo.com with NNFMP; 29 Aug 2014 13:52:32 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rogers.com; s=s1024; t=1409320352; bh=aNnwIunfo1xKwrrWPRmyHUwGlCRLDROEy7zqu5vFm6A=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=UIZeivr61B5ohxJud8hrZsFTXonwlc1demkaTtzoyaNYKl6hfceRKHa3wjKs5DlIX5cqER03HkungYw93mfs2+sQltRVELcMZdd2gynMV5DIf2aB6U3gUGBgHqUaqR18D0eHvpwgUPrZvrDj1a00BaipPt27CTIlPWiQxFu+Lco=
X-Yahoo-Newman-Id: 67672.94784.bm@smtp111.sbc.mail.gq1.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: qmeRxwkVM1kMSZ8.Y1ujfKXOrN72iw5TE.vsU7swySlcguJ qc301UAXYwqZ2ZfgO1rUMgZ5_f0yXVB_4C0_E3FMZvfb7sV_yAcd8F5HUyjx DV4es_za2RIb.QXGaImtyxzZ3bvg9oRXngVFaJ7eaBYZre1Y5XMwqZbHNjEb GlE50opoX.0hG_KWSFbsFDUMAlz9owBnWeFmrC0j2tw53339FUN3WqRb6vw0 n02n7S12DYJgYoubeZ.EAzd4JEQwqPdGtJQDK4XjJAvfHOFRpjDF.kkZK0ZU l_uJI3aLZUPiwgNGLnvUTkGQfF.nGphleyOQ2SxFYVQEAB0H1Mn6Yjbl9WQl RHXvCLs32Rzpfzcy2bX4peth54.qli2sJGoyt95_2PidBeFOJYAUGw4m8FPT LGmVUqLLZPb39DjESgXrmGeWBR.bOU0AyEwwfU1JTuC.kXsedcobfAayFrkq 54filSFlT8R1nAHd.Jvu2evONLN6b92nR1REsgl9SadELbZ0kQiq5CS0s_pS jvFSI66qjtGSbS4TMX7T981x2JoWmiASiLg--
X-Yahoo-SMTP: sltvjZWswBCRD.ElTuB1l9j6s9wRYPpuyTNWOE5oEg--
Message-ID: <5400859E.6070202@rogers.com>
Date: Fri, 29 Aug 2014 09:52:30 -0400
From: David Collier-Brown <davec-b@rogers.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: aqm@ietf.org
References: <53E8D7B0.9040007@mti-systems.com> <CAA93jw7ufoEdfGexKMwkSOGLj7LMYBq-nGVPGJt+5G+OHx+ayA@mail.gmail.com> <20140811233857.GL45982@verdi> <201408120943.s7C9hRvV024419@bagheera.jungle.bt.co.uk> <53E9EB49.9040509@erg.abdn.ac.uk> <16141ccda1c843ab8f03fb5f478db010@hioexcmbx05-prd.hq.netapp.com>
In-Reply-To: <16141ccda1c843ab8f03fb5f478db010@hioexcmbx05-prd.hq.netapp.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/ECuk-ZE0g7YVgBFSIySUHvUdZd4
Cc: bloat <bloat@lists.bufferbloat.net>
Subject: Re: [aqm] adoption call: draft-welzl-ecn-benefits
X-BeenThere: aqm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: davecb@spamcop.net
List-Id: "Discussion list for active queue management and flow isolation." <aqm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aqm>, <mailto:aqm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/aqm/>
List-Post: <mailto:aqm@ietf.org>
List-Help: <mailto:aqm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aqm>, <mailto:aqm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Aug 2014 13:52:34 -0000

On 08/29/2014 09:16 AM, Scheffenegger, Richard wrote:
> Hi Gorry,
>
>>> Given QUIC includes FEC to hide losses, I guess it is a good example to
>>> consider whether ECN still offers sufficient benefits over and above
>>> just removing losses.
>>>
>> GF: And then, isn't the implication of AQM to significantly increase the
>> number of "losses" unless we use ECN?
>>
>> Indeed, I have the impression we are confusing many on these points -
>> ECN could change the reaction to congestion signal, and FEC (even
>> opportunistic CC-friendly FEC) can also change the way things react to
>> congestion signals.
> I don't think that an AQM's implication is automatically to increase the number of losses; that may happen to specific flows (in particular, unresponsive ones), but for responsive (non-ECN) ones, the expectation would be to de-correlate the losses, and for TCP, to only have around 1 loss per window when necessary - instead of a burst loss of one window and the expensive recovery...
>
> Perhaps it's that perception that also poses an obstacle to AQM deployment, because of the believe that a dynamic but lower mark/drop threshold will cause more losses?

Goodness gracious, from the point of  view of a queuing network, AQM
reduces losses overall, in the process of minimizing delay and keeping
bandwidth use just below the theoretical maximum.

Oversimplifying, we try to keep the buffers empty, so that if we get a
burst we can handle it without losses and without affecting other
communications. We signal via a loss or other indicator if the
non-bursty flow is enough to cause congestion, which keeps the buffers
near-empty and the system uncongested.

Failing to do so fills the buffers without signalling there is
congestion, and induces delay on everyone who's dependant on the buffer.
Not to mention allowing the congestion to go unreported!

It's not a tradeoff discussion: it's arguably one about correctness.

--dave
[Somebody like Neil Gunther could explain the math of this better, but
the behaviour is well-known in the trade, and cordially hated.
Congestion control is superior to admission control, which is what I
often use to prevent the server equivalent of congestive collapse (:-))]



-- 
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
davecb@spamcop.net           |                      -- Mark Twain