QoS DSCP AF Class Comparisons

dscpqos

I'm having trouble wrapping my head around DSCP AF Classes and what–all else being equal–gets dropped first.

I understand packets are given a Class, 1-4. The higher the Class number, the higher priority that packet gets. I must assume that higher priority means lower chance of being dropped.

Is this assumption correct: Higher Class = Higher Priority = Lower chance of being dropped?

I also understand that packets are given a drop precedence, 1-3… and in this case the lower the drop precedence, the lower the chance of being dropped.

During congestion, does higher Class traffic have precedence over lower Class traffic, regardless of Drop Priority?

If so, this leads to the absolutely counter-intuitive scenario where, while AF32 is less likely to be dropped than AF13 (32 > 13), AF32 is more likely to be dropped than AF31 (despite 32 > 31)… and that's really throwing me for a loop!

Best Answer

I understand packets are given a Class, 1-4. The higher the Class number, the higher priority that packet gets. I must assume that higher priority means lower chance of being dropped.

Is this assumption correct: Higher Class = Higher Priority = Lower chance of being dropped?

During congestion, does higher Class traffic have precedence over lower Class traffic, regardless of Drop Priority?

Both of these are incorrect. Each class has a minimum amount of resources (e.g., bandwidth) allocated to it. Different classes will have different amounts. So for example, Class 4 may have 30% of the link bandwidth allocated to it, while class 3 has only 10%. That means during congestion, class 4 is guaranteed a minimum of 30% of the link bandwidth.

Note that class 4 doesn't have higher priority than 3, it just means it has a different amount of resources available to it.

Within each class, the drop priority indicates the probability that the traffic would be dropped.

Related Solutions

Cisco – DSCP trust boundary

The following policy-map would work. Just apply this to the inbound of the WAN interface.

policy-map MARKDOWN
  class class-default
    set dscp default

Interface Config:

interface gig 0/1
  service-policy input MARKDOWN

Just saw the bit about juniper. The following I believe will work for JunOS.

interfaces {
  so-1/2/3 {
    unit 0 {
      rewrite-rules {
        dscp default;
      }
    }
  }
}

Cisco – QoS woes – managed IP VPN

To answer your questions:

RDP traffic should get up to the 25% of the remaining bandwidth. Where the already reserved bandwidth is the 35% ( class-default gets 25% by default and EF get 10% ). So, if i'm right, you assigned ~665Kbps to RDP. Anyway you should check if you're dropping packets issuing the command below:

show policy-map <your wan interface> output class REMOTEDESKTOP

and checking for dropped packets.

Cisco assign a queue to each user-defined class that includes the bandwidth or police commands. To make a long-story simple those commands define the amount of bandwidth assigned to every queue during congestions.
In theory every TCP based stream should be OK with drops. In practice some of them aren't. Dropping precedence bits tell the routers what packets should be dropped, within a given class, before congestion happens. Since RDP is the only type of traffic defined in your REMOTEDESKTOP class, you should not worry about it.
Bandwidth percentage are not in order ( as Jeremy stated ).

That said, there are a lot of things that i would change in your configuration:

There are no matches between some of classes of the setTos and the useTos policy-map. For instance the one named AF-HIGH is processing no packets since no class in setTos sets DSCP to AF41.
BE class in setTos is somehow self-defeating since it makes the class-default class useless. Note that class-default is the only system-defined class and get the 25% of the bandwidth by default ( 100 - max-reserved-bandwidth ) .
bandwidth remaining percent is not the best options ( as Jeremy explained ). I would change it to bandwidth percent.
I would prefer to mark EF packets by myself and not to rely on the phones' settings.

Best Answer

Related Solutions

Cisco – DSCP trust boundary

Cisco – QoS woes – managed IP VPN

Related Topic