Re: [aqm] New Version Notification for draft-baker-aqm-recommendation-01.txt

Linda Dunbar <> Fri, 26 April 2013 14:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7D8EF21F9A00 for <>; Fri, 26 Apr 2013 07:43:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.072
X-Spam-Status: No, score=-5.072 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JcibCgJQn6bo for <>; Fri, 26 Apr 2013 07:43:10 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 74FE321F9A20 for <>; Fri, 26 Apr 2013 07:43:09 -0700 (PDT)
Received: from (EHLO ([]) by (MOS 4.3.5-GA FastPath queued) with ESMTP id AQV29001; Fri, 26 Apr 2013 14:43:08 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 26 Apr 2013 15:42:29 +0100
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 26 Apr 2013 15:43:05 +0100
Received: from ([]) by ([]) with mapi id 14.01.0323.007; Fri, 26 Apr 2013 07:43:01 -0700
From: Linda Dunbar <>
To: "Fred Baker (fred)" <>
Thread-Topic: [aqm] New Version Notification for draft-baker-aqm-recommendation-01.txt
Thread-Index: AQHOQgvnNM9dy0HyqESyRCfiFBkJ1pjokXTw
Date: Fri, 26 Apr 2013 14:43:01 +0000
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US, zh-CN
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645B147FDdfweml509mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: Anoop Ghanwani <>, "" <>
Subject: Re: [aqm] New Version Notification for draft-baker-aqm-recommendation-01.txt
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: Fri, 26 Apr 2013 14:43:14 -0000


Thank you very much for the detailed reply. A few more questions inserted below:

o   Why not add an extra field to the Ping reply to indicate congestion? especially the congestion is caused by hardware failure (e.g. N links in a LAG reduced to N-1 links in a LAG, or microwave transport drop bandwidth due to weather). Source node uses Ping to detect connectivity. Today's Ping reply only says "yes" or "no". But today with  LAG widely deployed, link bandwidth could fluctuate causing pre-longed congestion, which really need source nodes to throttle back for network to perform.

This wouldn't be too hard to prototype. I do wonder about the relationship to Source Quench; the reason that we abandoned Source Quench way back when was that while it might correctly detect that congestion was happening and send a message to somebody, it was difficult to get it sent to the guy that was causing the problem. If, for example, session #1 is using CUBIC and as a result keeping the queue at a bottleneck within epsilon of "full", and someone else fires off an IW=10 burst, it would be pretty easy to imagine the packet most likely to be hit being the last packet in the second session's slow-start.

[[Linda] Why not send the notification of "hard degradation" (e.g. LAG link bandwidth reduction due to some member link failure or Microwave links bandwidth reduction due to weather) to the "Ingress nodes" of the domain ? so that the "Ingress nodes" can choose different route or reduce the ingress rate? The notification doesn't have to be sent all the way to the hosts who initiate the traffic.

The most important question would be "so what". Ping is not something systems usually do automatically, it's something operators do when something has been bad for several minutes. What would you like a given end user session to do in the meantime? How does the operator use the information returned by ping?.

[Linda] Agree with you that "Ping" might not the best way. What do you think of encoding some bits in  the OAM frames traversing by (e.g. IP PM, BFD, ECN, etc) to reflect "hard degradation"?  Those "hard degradation" really need source nodes or Ingress nodes to throttle back traffic.

Therefore I feel that the benefit of refining router queue management may not provide any real improvement to end to end user sessions in today's grand internet network.


From:<> [<>] On Behalf Of Fred Baker (fred)
Sent: Tuesday, April 23, 2013 8:21 PM
To: Anoop Ghanwani
Subject: Re: [aqm] Fwd: New Version Notification for draft-baker-aqm-recommendation-01.txt

On Apr 23, 2013, at 4:57 PM, Anoop Ghanwani <<>>

Hi Fred,

Is there a preferred scheme for a self-tuning AQM?  I'm a bit out of
touch with the work in the area, but when I hear AQM, all think of
is RED (which is what most switches implement), but when I hear
self-tuning AQM, nothing comes to mind (and I'm not aware of anything
that's reasonably widely implemented or available).

ICCRG is hashing that discussion now. There are at least two technologies that could be applied, which are CoDel and PIE, and I think I could convince myself that AVQ fit the mould. That, in part, is why in this document I am focusing more on how the technology in question should behave than what the One Blessed technology should be. Who knows, fifteen years from now there might be a better algorithm available than we have now.

I want to make sure I understand the requirements that this imposes
on switches and routers.


On Tue, Apr 23, 2013 at 4:03 PM, Fred Baker (fred) <<>> wrote:
FYI, I have posted an update version of the draft we discussed last month. One thing I would appreciate is comments from those who commented before; did my updates address your concerns?

Begin forwarded message:

> From: <<>>
> Subject: New Version Notification for draft-baker-aqm-recommendation-01.txt
> Date: April 23, 2013 3:59:41 PM PDT
> To: Fred Baker <<>>
> A new version of I-D, draft-baker-aqm-recommendation-01.txt
> has been successfully submitted by Fred Baker and posted to the
> IETF repository.
> Filename:      draft-baker-aqm-recommendation
> Revision:      01
> Title:                 IETF Recommendations Regarding Active Queue Management
> Creation date:         2013-04-23
> Group:                 Individual Submission
> Number of pages: 17
> URL:   
> Status:
> Htmlized:
> Diff:  
> Abstract:
>   This memo presents recommendations to the Internet community
>   concerning measures to improve and preserve Internet performance.  It
>   presents a strong recommendation for testing, standardization, and
>   widespread deployment of active queue management in routers, to
>   improve the performance of today's Internet.  It also urges a
>   concerted effort of research, measurement, and ultimate deployment of
>   router mechanisms to protect the Internet from flows that are not
>   sufficiently responsive to congestion notification.
>   The note largely repeats the recommendations of RFC 2309, updated
>   after fifteen years of experience and new research.
> The IETF Secretariat

aqm mailing list<>

aqm mailing list<>

aqm mailing list<>