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

grenville armitage <garmitage@swin.edu.au> Mon, 13 May 2013 22:56 UTC

Return-Path: <garmitage@swin.edu.au>
X-Original-To: aqm@ietfa.amsl.com
Delivered-To: aqm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E04021F9239 for <aqm@ietfa.amsl.com>; Mon, 13 May 2013 15:56:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.668
X-Spam-Level:
X-Spam-Status: No, score=-1.668 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, SARE_SUB_OBFU_Q1=0.227]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZX8YwIZniJcG for <aqm@ietfa.amsl.com>; Mon, 13 May 2013 15:56:03 -0700 (PDT)
Received: from gpo3.cc.swin.edu.au (gpo3.cc.swin.edu.au [136.186.1.32]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE8521F9234 for <aqm@ietf.org>; Mon, 13 May 2013 15:56:01 -0700 (PDT)
Received: from [136.186.229.37] (garmitage.caia.swin.edu.au [136.186.229.37]) by gpo3.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id r4DMtxsC002144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 May 2013 08:55:59 +1000
Message-ID: <51916F7F.1020601@swin.edu.au>
Date: Tue, 14 May 2013 08:55:59 +1000
From: grenville armitage <garmitage@swin.edu.au>
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121107 Thunderbird/16.0.2
MIME-Version: 1.0
To: aqm@ietf.org
References: <8C48B86A895913448548E6D15DA7553B850ECE@xmb-rcd-x09.cisco.com> <41E8D91E-658B-4B44-92D2-5EB0329781A5@ifi.uio.no> <8C48B86A895913448548E6D15DA7553B8512B5@xmb-rcd-x09.cisco.com> <20130507133724.GY23227@verdi>
In-Reply-To: <20130507133724.GY23227@verdi>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [aqm] Question re draft-baker-aqm-recommendations recomendation #4
X-BeenThere: aqm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion list for active queue management and flow isolation." <aqm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aqm>, <mailto:aqm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/aqm>
List-Post: <mailto:aqm@ietf.org>
List-Help: <mailto:aqm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aqm>, <mailto:aqm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 May 2013 22:56:09 -0000

On 05/07/2013 23:37, John Leslie wrote:
> Fred Baker (fred) <fred@cisco.com> wrote:
>> On May 6, 2013, at 7:25 AM, Michael Welzl <michawe@ifi.uio.no> wrote:
>>
>>> ...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...
>>
>> I certainly agree that we should not be making transport-specific
>> modifications...
>> My point in this, if you can think of a better way to phrase it, is
>> that the AQM algorithm someone implements needs to demonstrably work
>> with the transports and applications it will be affecting.
>
>     Hearing no differing suggestions, those words seem appropriate. Thus
> Section 4.4 might become:
> "
> " 4.4. Active Queue Management algorithms deployed SHOULD be effective on
> "      all common Internet traffic
> "
> " Active Queue Management algorithms typically are verified to work with
> " TCP [RFC0793] and a limited number of applications of it. This no
> " longer represents a sufficient selection of actual traffic. We have
> " significant use of UDP [RFC0768] in voice and video services, as well
> " as SCTP [RFC4960] and DCCP [RFC4340]. Hence, Active Queue Management
> " algorithms should demonstrably work with other transports as well as
> " TCP, and with a wide variety of applications.

I see a difference between the scope of Fred's "...demonstrably
work with the transports and applications it will be affecting"
and the scope of the section heading ("...be effective on all
common Internet traffic") or even "..as well as TCP, and with
a wide variety of applications."

I certainly agree that an AQM algorithm ought not necessarily
be  transport-layer aware. But the wording above could lead to
a situation where acceptance of a future AQM scheme is derailed
because it doesn't "work" with some (yet to be defined) "wide
variety of applications".

I prefer the wiggle room allowed by "..the transports and
applications it will be affecting" rather than "...all common
Internet traffic".

cheers,
gja