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

Bob Briscoe <bob.briscoe@bt.com> Fri, 12 July 2013 17:08 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 2A4EC11E812D for <aqm@ietfa.amsl.com>; Fri, 12 Jul 2013 10:08:57 -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 cFn1aENi4I97 for <aqm@ietfa.amsl.com>; Fri, 12 Jul 2013 10:08:51 -0700 (PDT)
Received: from hubrelay-by-04.bt.com (hubrelay-by-04.bt.com [62.7.242.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3F71F21E80A1 for <aqm@ietf.org>; Fri, 12 Jul 2013 10:08:46 -0700 (PDT)
Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR04-UKBR.bt.com (10.216.161.36) with Microsoft SMTP Server (TLS) id 8.3.297.1; Fri, 12 Jul 2013 18:08:42 +0100
Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) with Microsoft SMTP Server (TLS) id 8.3.297.1; Fri, 12 Jul 2013 18:08:44 +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 18:08:41 +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 r6CH8cSI029184; Fri, 12 Jul 2013 18:08:39 +0100
Message-ID: <201307121708.r6CH8cSI029184@bagheera.jungle.bt.co.uk>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 12 Jul 2013 18:08:39 +0100
To: "Rong Pan (ropan)" <ropan@cisco.com>
From: Bob Briscoe <bob.briscoe@bt.com>
In-Reply-To: <BF2CBE9A994B89438F7F3B9FD58C2B7F26D31968@xmb-aln-x15.cisco .com>
References: <201307120122.r6C1MlTD026331@bagheera.jungle.bt.co.uk> <BF2CBE9A994B89438F7F3B9FD58C2B7F26D31968@xmb-aln-x15.cisco.com>
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: "Fred Baker (fred)" <fred@cisco.com>, "aqm@ietf.org" <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 17:08:57 -0000

Rong,

OK, correction accepted.

Bob

At 02:45 12/07/2013, Rong Pan (ropan) wrote:
>Please see inlineŠ.
>
>On 7/12/13 9:22 AM, "Bob Briscoe" <bob.briscoe@bt.com> 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. "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.
>
>
>There might be some misunderstanding about AFD. AFD that is implemented in
>Cisco products is not per-flow rate policing. It is class based. Also, AFD
>would not enforce fair rate among different classes. If a class does not
>use up its share, the extra share would go to other queues. So in your
>example of Cubic and Reno, I don't think there would be an issue.
>
>
>Regards,
>
>Rong
>
>
>
>
> >
> >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
> >
> >_______________________________________________
> >aqm mailing list
> >aqm@ietf.org
> >https://www.ietf.org/mailman/listinfo/aqm

________________________________________________________________
Bob Briscoe,                                                  BT