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

["Rong Pan (ropan)" <[e-mail]>]

Please see inlineŠ.

On 7/12/13 9:22 AM, "Bob Briscoe" <[e-mail]> 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 <[e-mail]> wrote:
>>
>> > Michael Welzl <[e-mail]> 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 <[e-mail]>
>>
>>_______________________________________________
>>aqm mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/aqm
>
>________________________________________________________________
>Bob Briscoe,                                                  BT
>
>_______________________________________________
>aqm mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/aqm