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

"Rong Pan (ropan)" <> Fri, 12 July 2013 01:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9889C21F9F17 for <>; Thu, 11 Jul 2013 18:45:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.372
X-Spam-Status: No, score=-10.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gz2fL8ycI-k6 for <>; Thu, 11 Jul 2013 18:45:22 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A6CE011E814B for <>; Thu, 11 Jul 2013 18:45:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=7337; q=dns/txt; s=iport; t=1373593506; x=1374803106; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=DikYBAV2FGcR8REEQ3a4mTn76gbpxuYV/9E5e5isUmE=; b=e/RlxfYEYAX8ixMaOT1LbEvLJEkh9Wm1hcWlIeo/LmrOYlMbv3vBMhXR T0CZw1Q6apeXabEzuKZJmj4qBhmB6PxTanXmzS5dEP1dkDIKIuRFkNBYV 5fYNw2n9oZuAsid+nDOvipUdFBnXmJWvv0cQM9dZYuv4pEwy3oubWmEwF w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.89,649,1367971200"; d="scan'208";a="233658518"
Received: from ([]) by with ESMTP; 12 Jul 2013 01:45:06 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r6C1j57M025741 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Jul 2013 01:45:05 GMT
Received: from ([]) by ([]) with mapi id 14.02.0318.004; Thu, 11 Jul 2013 20:45:05 -0500
From: "Rong Pan (ropan)" <>
To: Bob Briscoe <>, "Fred Baker (fred)" <>
Thread-Topic: [aqm] Question re draft-baker-aqm-recommendations recomendation #4
Thread-Index: AQHOfp5aSbtadc4LyUiiEoD2XBB3OplhH4uA
Date: Fri, 12 Jul 2013 01:45:03 +0000
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [aqm] Question re draft-baker-aqm-recommendations recomendation #4
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, 12 Jul 2013 01:45:27 -0000

Please see inlineŠ.

On 7/12/13 9:22 AM, "Bob Briscoe" <> wrote:

>At 15:00 06/05/2013, Fred Baker (fred) wrote:
>>Do we generally agree with the recommendation of
>>This is the question of ensuring that AQM
>>technologies are applicable to all Internet
>>traffic - not just TCP, but UDP, SCTP, and so on.
>I'm not as much a fan of recommendation #4 as
>everyone else seems to be. I think it's a wordsmithing issue, not
>I suggest wording such as: "AQMs SHOULD allow
>congestion controls to remain as effective as
>they are with other widely accepted AQMs or with tail drop."
>Reasoning: An AQM can't be effective with all
>transports, because congestion control is
>achieved by the e2e transport, not the AQM alone. "All transports"
>* unresponsive transports that aren't trying to be effective,
>* and delay-based transports like VEGAS & LEDBAT
>that don't work well in some circumstances.
>The suggested wording makes it clear we're
>talking about criteria for testing AQMs against
>transports that we already know are able to be
>effective. Not about the AQM forcing a 'normal'
>congestion control behaviour even if the
>congestion control doesn't want to play, or 'normal' has been redefined.
>The reason I care about the wording here is that
>some may read this as a licence to include
>per-flow rate policing within the AQM (cf AFD,
>XCHOKe, etc). I strongly believe that per-flow
>rate policers SHOULD NOT be in /every/ AQM.
>AFD (and similar algos) still wrongly hit more
>recent hi-performance transports like Cubic
>because it is so much faster than lame Reno
>transports, even tho the Reno transports wouldn't
>be able to use the extra capacity.

There might be some misunderstanding about AFD. AFD that is implemented in
Cisco products is not per-flow rate policing. It is class based. Also, AFD
would not enforce fair rate among different classes. If a class does not
use up its share, the extra share would go to other queues. So in your
example of Cubic and Reno, I don't think there would be an issue.



>If an operator wants to deploy this flow-policing
>(please no), it is sufficient to have one on each
>path, at a 'customer edge' node, deployed as part
>of per-customer policy. Then there's a chance
>they can be turned off once the operator
>recognises they aren't helping. If we're
>successful enough to get AQM in every queue in
>the Internet, I don't want that to mean we've
>also got per-flow policers embedded in every
>queue too. Then, we're stuffed for future flexibility.
>At 20:36 06/05/2013, Michael Welzl wrote:
>>On May 6, 2013, at 9:17 PM, John Leslie <> wrote:
>> > Michael Welzl <> wrote:
>> >>
>> >> About this recommendation, I agree regarding what it actually
>> >> recommends, but I have a comment about the wording. This bit:
>> >>
>> >> "Hence, Active Queue Management algorithms that are effective with
>> >> all of those transports and the applications that use them are to be
>> >> preferred."
>> >> ...
>> >
>> >   I think some wordsmithing would help...
>> > ]
>> > ] 4.4. Active Queue Management algorithms deployed SHOULD be
>>effective on
>> > ] all common Internet traffic
>> >
>> >   At the outset, do we mean to say that AQM specifications SHOULD
>> > have, e.g., a "UDP Considerations" section? (That's one way to read
>> > this.)
>> >
>> >   Or do we mean that AQM SHOULD NOT be optimized for TCP?
>> >
>> >   Or do we mean there exist some magical principles which enable
>> > AQM designers to optimize for IP traffic we haven't thought of yet?
>> >
>> > ]  Active Queue Management algorithms often target TCP [RFC0793], as
>> > ]  is by far the predominant transport in the Internet today.
>> > ]  we have significant use of UDP [RFC0768] in voice and video
>> > ]  and find utility in SCTP [RFC4960] and DCCP [RFC4340].  Hence,
>> > ]  Queue Management algorithms that are effective with all of those
>> > ]  transports and the applications that use them are to be preferred.
>> >
>> >   I'm not the least bit sure that "target TCP" is the point. There's
>> > an incredible range of traffic carried over TCP. It's typical for an
>> > AQM proposal to be tested in terms of how a bulk-transfer TCP reacts
>> > vs. an "interactive" web session series of "short" TCP streams. This,
>> > IMHO, isn't "targetting" TCP, but rather comparing bulk transfer vs.
>> > on-demand short-transfer -- where both happen to use TCP transport.
>> > They could just as well be using SCTP or any of several other
>> >
>> >   Do we mean to say that things would be significantly better if the
>> > tests were altered to use SCTP for some of the sessions?
>> >
>> >   Besides, whether sessions are mixed transports or all TCP, the
>> > congestion-control algorithms are in fact varied. Don't we mean to say
>> > that AQM algorithms SHOULD work with a variety of congestion control
>> > algorithms?
>> >
>> >   If we do mean to require consideration of multiple _transports_,
>> > what do we wish to see considered? I don't get much of a hint from
>> > this text.
>> >
>> >   Back to Michael:
>> >
>> >> sounds as if it would be the most normal thing in the world for an
>> >> AQM algorithm to make a decision based on the transport protocol,
>> >> which I think it shouldn't.
>> >
>> >   That's certainly one "solution"... And I also dislike it.
>> >
>> >> To me, ECN is an IP-layer signal and routers shouldn't have to
>> >> investigate what's layered on it (which may go beyond just looking
>> >> at the "protocol" field in case of tunnels) in order to make their
>> >> decisions.
>> >
>> >   Yes, but...
>> >
>> >   It seems unlikely that we're going to get a fully satisfactory AQM
>> > without separate queues for different flows. I'd like to believe the
>> > IPv6 flow label can give us what we need, but that's optimisticŠ
>>Seems like a case of "more specific and more
>>complicated" vs. "more vague but perhaps good
>>enough" to me. I don't think that there's a
>>reasonable way to be more specific here, but maybe I'm just missing it.
>> >> I tried to come up with a better phrasing but failed... maybe it
>> >> could be an idea to just add a sentence after this one, saying
>> >> something like "Such algorithms do not need to consider any
>> >> information in the packet beyond its IP header."
>> >
>> >  I think more substantial rewording is needed. I'll be happy to
>> > suggest wording _after_ I see a better understanding of what we mean
>> > to say here.
>> >
>> > --
>> > John Leslie <>
>>aqm mailing list
>Bob Briscoe,                                                  BT
>aqm mailing list