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

"Rong Pan (ropan)" <ropan@cisco.com> Fri, 12 July 2013 01:46 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 0EF6F21F9E11 for <aqm@ietfa.amsl.com>; Thu, 11 Jul 2013 18:46:38 -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 hmwBiplPXevI for <aqm@ietfa.amsl.com>; Thu, 11 Jul 2013 18:46:33 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id C2BD621F9CD9 for <aqm@ietf.org>; Thu, 11 Jul 2013 18:46:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7722; q=dns/txt; s=iport; t=1373593593; x=1374803193; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=cyvU1J6R2IjF0eeC0VPvb9jq8BYlMxtIYgk6kwmEyfU=; b=W9oW0fcODTxSn1n40zJasrN7I2Cq036CTjNW4WUGFEQp6NfNHVCwStJh 4STIJj4uX+RfHVMqEZNEjQKR0RAfaAWkHtCLHiEn335Ke6LtNP6JDFplQ 61NfMB5Mx1ltSCuk7pj0KQe8XyszrfZSMAUbxft2FzutRjFfvEkWzHFvY w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFAPRe31GtJV2Y/2dsb2JhbABagwY0T8FVgQcWdIIjAQEBBAEBAWQHCxIBCBgKSwslAgQBCQQFCBOHdAy3B48wMQeDCWwDlAWFAZAkgxGCKA
X-IronPort-AV: E=Sophos;i="4.89,649,1367971200"; d="scan'208";a="233853127"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 12 Jul 2013 01:46:26 +0000
Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6C1kQGF001800 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Jul 2013 01:46:26 GMT
Received: from xmb-aln-x15.cisco.com ([169.254.9.152]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Thu, 11 Jul 2013 20:46:26 -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: AQHOfp5aSbtadc4LyUiiEoD2XBB3OplhH4uAgAAAYIA=
Date: Fri, 12 Jul 2013 01:46:24 +0000
Message-ID: <BF2CBE9A994B89438F7F3B9FD58C2B7F26D3197A@xmb-aln-x15.cisco.com>
In-Reply-To: <BF2CBE9A994B89438F7F3B9FD58C2B7F26D31968@xmb-aln-x15.cisco.com>
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="iso-8859-2"
Content-ID: <9DE3AF0DF2009D489248E16ED48C152B@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:46:38 -0000

On 7/12/13 9:45 AM, "Rong Pan (ropan)" <ropan@cisco.com> 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.


Sorry typo, extra share would go to other classes (NOT queues) that are
sharing the same queue.




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