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

"Rong Pan (ropan)" <ropan@cisco.com> Fri, 12 July 2013 01:45 UTC

Return-Path: <ropan@cisco.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 9889C21F9F17 for <aqm@ietfa.amsl.com>; Thu, 11 Jul 2013 18:45:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.372
X-Spam-Level:
X-Spam-Status: No, score=-10.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 gz2fL8ycI-k6 for <aqm@ietfa.amsl.com>; Thu, 11 Jul 2013 18:45:22 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id A6CE011E814B for <aqm@ietf.org>; Thu, 11 Jul 2013 18:45:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7337; q=dns/txt; s=iport; t=1373593506; x=1374803106; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=DikYBAV2FGcR8REEQ3a4mTn76gbpxuYV/9E5e5isUmE=; b=e/RlxfYEYAX8ixMaOT1LbEvLJEkh9Wm1hcWlIeo/LmrOYlMbv3vBMhXR T0CZw1Q6apeXabEzuKZJmj4qBhmB6PxTanXmzS5dEP1dkDIKIuRFkNBYV 5fYNw2n9oZuAsid+nDOvipUdFBnXmJWvv0cQM9dZYuv4pEwy3oubWmEwF w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFADtf31GtJXG9/2dsb2JhbABagwY0T8FVgQcWdIIjAQEBBAEBAWQHCxIBCBgKSwslAgQBCQQFCBOHdAy3CI8wMQeDCWwDlAWFAZAkgxGCKA
X-IronPort-AV: E=Sophos;i="4.89,649,1367971200"; d="scan'208";a="233658518"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 12 Jul 2013 01:45:06 +0000
Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6C1j57M025741 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Jul 2013 01:45:05 GMT
Received: from xmb-aln-x15.cisco.com ([169.254.9.152]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Thu, 11 Jul 2013 20:45:05 -0500
From: "Rong Pan (ropan)" <ropan@cisco.com>
To: Bob Briscoe <bob.briscoe@bt.com>, "Fred Baker (fred)" <fred@cisco.com>
Thread-Topic: [aqm] Question re draft-baker-aqm-recommendations recomendation #4
Thread-Index: AQHOfp5aSbtadc4LyUiiEoD2XBB3OplhH4uA
Date: Fri, 12 Jul 2013 01:45:03 +0000
Message-ID: <BF2CBE9A994B89438F7F3B9FD58C2B7F26D31968@xmb-aln-x15.cisco.com>
In-Reply-To: <201307120122.r6C1MlTD026331@bagheera.jungle.bt.co.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.2.1.120420
x-originating-ip: [10.21.148.146]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <B727084CAC3B85418CE5099FFE56FDDC@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "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 01:45:27 -0000

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