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

[John Leslie <[e-mail]>]

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

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