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

From: Bob Briscoe <[email-masked]>
Date: Fri, 12 Jul 2013 02:22:14 +0100

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.

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 <[email-masked]> wrote:
>
> > Michael Welzl <[email-masked]> 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 <[email-masked]>
>
>_______________________________________________
>aqm mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/aqm

________________________________________________________________
Bob Briscoe,                                                  BT

---

From: "Rong Pan (ropan)" <[email-masked]>
Date: Fri, 12 Jul 2013 01:45:03 +0000

Please see inlineŠ.

>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

>> > IPv6 flow label can give us what we need, but that's optimisticŠ
>>

---

From: "Rong Pan (ropan)" <[email-masked]>
Date: Fri, 12 Jul 2013 01:46:24 +0000

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

---

From: Scott Brim <[email-masked]>
Date: Fri, 12 Jul 2013 09:15:42 -0400

On 07/11/13 21:22, Bob Briscoe allegedly wrote:
>> 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.

Bob, that's the meaning of SHOULD: do it ... unless there's a good
reason why not (and explain why not).  Different transports use
different algorithms.  Your rephrasing looks to be closer to a MUST.

> "All transports" includes:
> * and delay-based transports like VEGAS & LEDBAT that don't work well in
> some circumstances.

To the extent that AQM applies, it should be effective.  If it's not
relevant, then that's a good reason not to, i.e. "SHOULD" applies.

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

Is this a slippery slope argument?  If we allow it at all it will infect
everything and ruin our great nation?  I don't believe this group is
going to agree on a single algorithm. :-)

Scott

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 12 Jul 2013 17:43:08 +0100

Scott,

I think you get the point I'm making. It's only to ensure the 
word-smithing doesn't get misinterpreted in the future. Not the end 
of the world.

Bob

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 12 Jul 2013 18:08:39 +0100

Rong,

OK, correction accepted.

Bob