Use of DSCP-based WRED

[Djule2804]

Hi,

I'm trying to configure QoS policy on test plateform. I have two FTP clients doing file transfert on the same server. I would like to have a different treatment between this two client. One of them would be a gold service whereas the second would have a silver service. The first client would have a better service than the other in case of congestion. So, I used drop precedence : packet from the gold client have a AF11 marking and the silver client have a AF12 marking.

I used CBWFQ as scheduling algorithme and, I allocate 45 percent of the total bandwidth for the AF1 class.

Then, I configure WRED algorithm in order to drop silver_packet before gold packet in case of congestion.

So, I put the max_threshold to 4096 and I put the indivual threshold to AF11 and AF12.

Here is the configuration :

class af1

bandwidth percent 45

random-detect dscp-based

random-detect dscp 10 2500 4096 5000

random-detect dscp 12 5 20 5000

Then, I performed test. My first test was in optimal use of the network (non-congestion). In this case , each FTP client have the same bandwidth (half of the maximal bandwith)

I do the same test in congestion state, but I obtained the same result, the two FTP client share equally the AF1 allocated bandwidth (45% of the total bandwidth). The two client have the same download speed. So, I can't succeed to offer better service to the gold_user.

The simpliest solution would be to separate the AF11 and AF12 classes and offer more bandwith to the AF11 classes.

But in this case , I don't use WRED algorithm. The DSCP-based WRED haven't been created for this use??!!

Is something can help me about use of WRED

[Joseph W. Doherty]

When you had a "congestion state", was there congestion in class af1? Such as, was the mean queue depth within that class > 20? If so, did you see tail drops for DSCP 12? If the answers for the last couple of questions were "no", then both flows within the class would get about 50% of the class bandwidth.

If the mean queue depth was only about 20 and you don't see a very high rate of tail drops for AF12, its possible that the two flows will still get about 50% of the class bandwidth.

For WRED to provide the effect you're looking for, the AF11 flow has to create enough congestion that most to all of the AF21 flow's packets are dropped.

[Djule2804]

Actually, I can't really create congestion state with the AF11 flow, simply because it's TCP flux (from FTP application). So, I don't control TCP windows.

I just said that I created congestion states with UDP flux of my second class(class-default)

Here is my classes :

class af1

bandwidth percent 45

random-detect dscp-based

random-detect dscp 10 2500 4096 5000

random-detect dscp 12 5 20 5000

class class-default

bandwidth percent 55

So, AF11 and AF12 TCP flux can't use more than 45 percent of the total bandwidth.

So, when I start to emit flux from my second class, the two TCP (AF11 and AF12) flux decrease and share equally the 45 percent of the total as if there wasn't WRED configured.

I wonder what is the real interest of WRED. And which result should I have obtained?

PS : I changed the threshold like this and I still obtained the same result. No difference between the two flux.

class af1

bandwidth percent 45

random-detect dscp-based

random-detect dscp 12 2 10 5000

[Joseph W. Doherty]

Unless you get a flow or flows to overrun your af1 class, you'll likely not see drops.

If you want to see WRED in action, try your UDP flow with a marking of AF12. See if it drops the UDP packets but still allows AF11 through.