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

John Leslie <> Mon, 06 May 2013 19:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9519321F87D2 for <>; Mon, 6 May 2013 12:17:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.773
X-Spam-Status: No, score=-103.773 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id q4kIOa38zFy2 for <>; Mon, 6 May 2013 12:17:28 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 44FFD21F87CD for <>; Mon, 6 May 2013 12:17:25 -0700 (PDT)
Received: by (Postfix, from userid 104) id 4526933C22; Mon, 6 May 2013 15:17:25 -0400 (EDT)
Date: Mon, 06 May 2013 15:17:25 -0400
From: John Leslie <>
To: Michael Welzl <>
Message-ID: <20130506191725.GV23227@verdi>
References: <> <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.4.1i
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:17:33 -0000

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

   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

   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...

> 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 <>