[e2e] Is RED dead?

[John Kristoff]

On Tue, 18 Oct 2005 14:47:09 +0800 (CST)
Jing Shen <jshen_cad at yahoo.com.cn> wrote:

> Because we are not sure how much bandwidth high
> priority traffic needs ( number of subscriber may vary
> with time), bandwidth allocation policy between
> different QoS level has to be ajusted from time to
> time. So, there comes a problem,  how to minimize the
> cost of network management? 

This is a good question.  If you could trust all the endpoints to
mark correctly it wouldn't be a problem, but you can't.  Ultimately
they could mark a link full of DoS traffic as EF so you need some
type of ingress function to sanitize what the network gets.  The
simplest approach is to rate limit a traffic profile (based on a
simple packet filter), but this is problematic for at least two
reasons.  One, if the filter is too broad, the host can make all
traffic look like the profile and get it into the EF queues.  Two,
what is the rate at which you set the limit?

There is a whole class of work on dynamically setting the rate
based on available capacity and some type of authorization scheme,
but none of these have been practical in networks I've worked on
and no operators I know are very interested in deploying such
schemes.

Also note I didn't mention re-marking excess traffic that fits the
EF profile.  While at first thought this may seem like a good
approach, it can be harmful to real EF traffic.  If you need these
queueing mechanisms to be activated during congestion, a traffic
flow where some packets fall in a different queue may result in
re-ordering or unacceptable jitter for that application.

> My question is, could those default queueing policy
> adjust bandwidth allocation policy according to real
> traffic requirement automatically? if not, how to
> control the network management complexity when QoS &
> WRED are deployed ? 

You could do that and I'm sure there are plenty of papers describing
how to do so.  Your second question is more relevant to me though.
I don't think you can really deploy too much of this stuff today and
get much value out of it.  You can do some simple things like RED and
EF queues for a very strict traffic profile, but even there as we're
seeing, very few seem to have much motivation to bother doing so.
At the heart of it is, the problem these knobs solve is a problem most
people don't seem to be having, or at least one not painful enough to
justify deployment over some other, presumably simpler, solution.

John