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

Bob Briscoe <bob.briscoe@bt.com> Fri, 12 July 2013 16:43 UTC

Return-Path: <bob.briscoe@bt.com>
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 41C0021F9F75 for <aqm@ietfa.amsl.com>; Fri, 12 Jul 2013 09:43:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.372
X-Spam-Level:
X-Spam-Status: No, score=-3.372 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 qg8Nr00Lf20u for <aqm@ietfa.amsl.com>; Fri, 12 Jul 2013 09:43:20 -0700 (PDT)
Received: from hubrelay-by-03.bt.com (hubrelay-by-03.bt.com [62.7.242.139]) by ietfa.amsl.com (Postfix) with ESMTP id 99EBF21F9F77 for <aqm@ietf.org>; Fri, 12 Jul 2013 09:43:19 -0700 (PDT)
Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR03-UKBR.bt.com (10.216.161.35) with Microsoft SMTP Server (TLS) id 8.3.297.1; Fri, 12 Jul 2013 17:43:14 +0100
Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 12 Jul 2013 17:43:17 +0100
Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.2.342.3; Fri, 12 Jul 2013 17:43:14 +0100
Received: from BTP075694.jungle.bt.co.uk ([10.109.38.68]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id r6CGh8uS029097; Fri, 12 Jul 2013 17:43:09 +0100
Message-ID: <201307121643.r6CGh8uS029097@bagheera.jungle.bt.co.uk>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 12 Jul 2013 17:43:08 +0100
To: Scott Brim <swb@internet2.edu>
From: Bob Briscoe <bob.briscoe@bt.com>
In-Reply-To: <51E0017E.40200@internet2.edu>
References: <8C48B86A895913448548E6D15DA7553B850ECE@xmb-rcd-x09.cisco.com> <41E8D91E-658B-4B44-92D2-5EB0329781A5@ifi.uio.no> <20130506191725.GV23227@verdi> <6CCF558E-975C-4C86-9D67-CA431CC6FBA1@ifi.uio.no> <201307120122.r6C1MlTD026331@bagheera.jungle.bt.co.uk> <51E0017E.40200@internet2.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158
Cc: "Fred Baker (fred)" <fred@cisco.com>, aqm@ietf.org
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: Fri, 12 Jul 2013 16:43:27 -0000

Scott,

I think you get the point I'm making. It's only to ensure the 
word-smithing doesn't get misinterpreted in the future. Not the end 
of the world.


Bob

At 14:15 12/07/2013, Scott Brim wrote:
>On 07/11/13 21:22, Bob Briscoe allegedly wrote:
> > Fred,
> >
> > At 15:00 06/05/2013, Fred Baker (fred) wrote:
> >> Do we generally agree with the recommendation of
> >> http://tools.ietf.org/html/draft-baker-aqm-recommendation-01#section-4.4?
> >> 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 fundamental.
> >
> > 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.
>
>Bob, that's the meaning of SHOULD: do it ... unless there's a good
>reason why not (and explain why not).  Different transports use
>different algorithms.  Your rephrasing looks to be closer to a MUST.
>
> > "All transports" includes:
> > * unresponsive transports that aren't trying to be effective,
> > * and delay-based transports like VEGAS & LEDBAT that don't work well in
> > some circumstances.
>
>To the extent that AQM applies, it should be effective.  If it's not
>relevant, then that's a good reason not to, i.e. "SHOULD" applies.
>
> > 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.
>
>Is this a slippery slope argument?  If we allow it at all it will infect
>everything and ruin our great nation?  I don't believe this group is
>going to agree on a single algorithm. :-)
>
>Scott

________________________________________________________________
Bob Briscoe,                                                  BT