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

Michael Welzl <> Mon, 06 May 2013 19:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 750DA21F9283 for <>; Mon, 6 May 2013 12:36:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -99.886
X-Spam-Status: No, score=-99.886 tagged_above=-999 required=5 tests=[AWL=-0.114, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QUXq9-RYNpAN for <>; Mon, 6 May 2013 12:36:22 -0700 (PDT)
Received: from ( [IPv6:2001:700:100:10::57]) by (Postfix) with ESMTP id 4FFB221F9121 for <>; Mon, 6 May 2013 12:36:22 -0700 (PDT)
Received: from ([]) by with esmtp (Exim 4.75) (envelope-from <>) id 1UZRCq-0002Dw-Bn; Mon, 06 May 2013 21:36:16 +0200
Received: from ([] helo=[]) by with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from <>) id 1UZRCp-0007fx-M3; Mon, 06 May 2013 21:36:16 +0200
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Michael Welzl <>
In-Reply-To: <20130506191725.GV23227@verdi>
Date: Mon, 06 May 2013 21:36:15 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <20130506191725.GV23227@verdi>
To: John Leslie <>
X-Mailer: Apple Mail (2.1503)
X-UiO-Ratelimit-Test: rcpts/h 8 msgs/h 2 sum rcpts/h 16 sum msgs/h 5 total rcpts 4159 max rcpts/h 40 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: A762A3F404346226190B215503796387E9642B0F
X-UiO-SPAM-Test: remote_host: spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 513 max/h 8 blacklist 0 greylist 0 ratelimit 0
Cc: "Fred Baker (fred)" <>,
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: Mon, 06 May 2013 19:36:28 -0000

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 it
> ]  is by far the predominant transport in the Internet today.  However,
> ]  we have significant use of UDP [RFC0768] in voice and video services,
> ]  and find utility in SCTP [RFC4960] and DCCP [RFC4340].  Hence, Active
> ]  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 transports.
>   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 <>