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

Bob Briscoe <bob.briscoe@bt.com> Fri, 12 July 2013 01:22 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 B565311E80D9 for <aqm@ietfa.amsl.com>; Thu, 11 Jul 2013 18:22:59 -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=[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 KmSFOjR8mWTe for <aqm@ietfa.amsl.com>; Thu, 11 Jul 2013 18:22:54 -0700 (PDT)
Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id DA98D11E820C for <aqm@ietf.org>; Thu, 11 Jul 2013 18:22:53 -0700 (PDT)
Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 12 Jul 2013 02:22:51 +0100
Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) with Microsoft SMTP Server (TLS) id 8.3.297.1; Fri, 12 Jul 2013 02:22:50 +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 02:22:48 +0100
Received: from BTP075694.jungle.bt.co.uk ([10.109.157.20]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id r6C1MlTD026331; Fri, 12 Jul 2013 02:22:47 +0100
Message-ID: <201307120122.r6C1MlTD026331@bagheera.jungle.bt.co.uk>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 12 Jul 2013 02:22:14 +0100
To: "Fred Baker (fred)" <fred@cisco.com>
From: Bob Briscoe <bob.briscoe@bt.com>
In-Reply-To: <6CCF558E-975C-4C86-9D67-CA431CC6FBA1@ifi.uio.no>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158
Cc: 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 01:22:59 -0000

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

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.

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.


Bob

At 20:36 06/05/2013, Michael Welzl wrote:

>On May 6, 2013, at 9:17 PM, John Leslie <john@jlc.net> wrote:
>
> > Michael Welzl <michawe@ifi.uio.no> 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.
>
>Cheers,
>Michael
>
>
> >> 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 <john@jlc.net>
>
>_______________________________________________
>aqm mailing list
>aqm@ietf.org
>https://www.ietf.org/mailman/listinfo/aqm

________________________________________________________________
Bob Briscoe,                                                  BT