Re: [aqm] Question re draft-baker-aqm-recommendations recomendation #2

Dave Taht <> Tue, 30 April 2013 16:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3B78321F9C73 for <>; Tue, 30 Apr 2013 09:40:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.487
X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_OBFU_Q1=0.227]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YPRrx8hr0TD6 for <>; Tue, 30 Apr 2013 09:40:16 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c02::22d]) by (Postfix) with ESMTP id EE6EA21F9C72 for <>; Tue, 30 Apr 2013 09:40:15 -0700 (PDT)
Received: by with SMTP id 21so622829iay.32 for <>; Tue, 30 Apr 2013 09:40:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=T6m7gKJ+M9C0TlMMa0owtmZnx+3cZjXmW0eFFB6cC3M=; b=VQRpQ63SIm4f1OeGBT4WtvsxhQeZPMFibUm2EWDBN0R78Aq25xmM1H3MpGs9GtMU7K lGpV/4JL84hImaYTuyzxBjJJn153eBC2UQOADrrLp5MQBpeXu3s8Oobh/t7ACgvUSMRo My+fPEitiJ21Jokc0avdCDTffBBJcmkPAblNg8u64ONXEzVasYGwIxYXNWyLww73L94/ B8Rk8UfIlTy0mDyRwrYvxygigbaL/lbOVnZC8qoxY+soIWtmOSHG1BSbF0o+WDEuRepF hgyD6LIxhrv1oBZtDe9h9GNXgPq03T4k27uGOPdi/rOd97fuhRhYG1h++/xf8sGHxKkA RAVA==
MIME-Version: 1.0
X-Received: by with SMTP id i18mr10682416igh.86.1367340015488; Tue, 30 Apr 2013 09:40:15 -0700 (PDT)
Received: by with HTTP; Tue, 30 Apr 2013 09:40:15 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Tue, 30 Apr 2013 09:40:15 -0700
Message-ID: <>
From: Dave Taht <>
To: Wesley Eddy <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: "Fred Baker (fred)" <>, "" <>
Subject: Re: [aqm] Question re draft-baker-aqm-recommendations recomendation #2
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion list for active queue management and flow isolation." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 30 Apr 2013 16:40:20 -0000

On Tue, Apr 30, 2013 at 9:29 AM, Wesley Eddy <> wrote:
> On 4/29/2013 10:00 AM, Fred Baker (fred) wrote:
>> Do we generally agree with the recommendation of This is the question of signaling to an endpoint using both dropping and ECN.
> I think there are two recommendations embedded at the end of the
> section:
> """
>    Hence, network communication to the host regarding the moderation of
>    its traffic flow SHOULD use an AQM algorithm to determine which
>    packets it should affect, and then implement that effect by marking
>    ECN-capable traffic "Congestion Experienced (CE)" or dropping non-
>    ECN-capable traffic.
>    Due to the possibility of abuse, the queue must also impose an upper
>    bound, so that even ECN-capable traffic experiences tail-drop

>    necessary; this possibility, while equipment must design for the end
>    case, should in theory be very uncommon.
> """
> I'm basically good with both.

As soon as ECN markings are widely deployed and AQMs are widely
deployed that use it, attacks will use ECN marked packets. A
reflection attack like the recent DNS attacks for example, would do
more damage with ECN based AQMs than AQMs with ECN off.

> The second part (imposing an upper bound) might be worth expanding a
> bit.  I don't know what a reasonable upper bound is, for failing into
> a tail-drop mode,

No reason to specify "tail" drop here.

> and it smells like another knob to be configured,
> which we are hoping to avoid :).

It's not just a knob but another state to track in the AQM.

> So, there is a can of worms here.  Should the threshold be configurable?
> Should it be based on some margin computed from the queue depth, link
> rate, etc?  What should the defaults be?  What types of experiments
> would we do in order to test sensitivity of this parameter and tune it?

In the codel related experiments I found no operating point that made
sense for marking vs dropping other than equal. ECN marking at less
than the drop point resulted in ECN streams being outcompeted by drop
based tcp. ECN marking at more than resulted in the reverse.

I found some uses for ECN inside well protected networks on things
other than TCP, and for TCP at high rates, also inside well protected

Across the wild and wooly internet I do not have a lot of hope for
ECN. It has proved mildly useful on ingress into a network domain and
a hindrance on bandwidth limited egress, and in neither case copes
with the easy possibilities of abuse.

> I think all of these depend a bit on how the specific AQM works, and
> it's tough to say much concrete about it.
> --
> Wes Eddy
> MTI Systems
> _______________________________________________
> aqm mailing list

Dave Täht

Fixing bufferbloat with cerowrt: