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

[Michael Welzl <[e-mail]>]

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