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

Wesley Eddy <> Tue, 30 April 2013 16:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 102F321F9AD4 for <>; Tue, 30 Apr 2013 09:29:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.372
X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FnYxKbns0xMN for <>; Tue, 30 Apr 2013 09:29:51 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2DAD921F98F7 for <>; Tue, 30 Apr 2013 09:29:50 -0700 (PDT)
Received: from ([]) by (8.14.4/8.14.4) with ESMTP id r3UGTmZ2020033 for <>; Tue, 30 Apr 2013 12:29:48 -0400
Received: (qmail 24843 invoked by uid 0); 30 Apr 2013 16:29:48 -0000
Received: from unknown (HELO ? ( by 0 with ESMTPA; 30 Apr 2013 16:29:48 -0000
Message-ID: <>
Date: Tue, 30 Apr 2013 12:29:37 -0400
From: Wesley Eddy <>
Organization: MTI Systems
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: "Fred Baker (fred)" <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: "" <>
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:29:56 -0000

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

   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 if
   necessary; this possibility, while equipment must design for the end
   case, should in theory be very uncommon.

I'm basically good with both.

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, and it smells like another knob to be configured,
which we are hoping to avoid :).

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?

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