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

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

On 7/12/13 9:45 AM, "Rong Pan (ropan)" <[e-mail]> wrote:

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


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