Need help understanding IP Precedence traffic types

[rwharris13]

I was reading through the different IP Precedence values and most seemed to be fairly straight forward, but I'd like to make sure I have my facts correct. According to the list below, IP Precedence treats traffic lowest to highest priority with numbers 0-7, respectively, is that correct?

Is it a matter of drop rates increase with the IP precedence value then as well?

What type of traffic would fall under 4? I've never heard of Flash, or Flash Overide type traffic, a little clarity would be much appreciated.

[Rolf Fischer]

Hi,

the use of the fields for QoS-marking in the IP-header has changed several times over the years.

IPP is somewhat outdated; with RFC 2474 (1998) the more granular DSCP values were introduced.

Useful link: Enterprise Medianet Quality of Service Design 4.0

Tabel 1.1 shows the IPP/DSCP mapping.

Figure 1-7 and 1-8 show recommendations for marking traffic classes.

Note that the standards and Cisco as well only provide recommendations, of course you can mark and treat your traffic as you like.

Hope that helps

Rolf

[rwharris13]

Thanks, I'm aware of the change of the ToS byte and its use over the years, this is more of a side project and learning for myself.

So with that being said, is there actually any "built-in" function of a router to treat one precedence value different from another or is that entirely based on your policy map and bandwidth assigned, priority, etc.

[Rolf Fischer]

The marking and treatment of IPP 0 - 5 depend on the local configuration, most router control traffic (e.g. routing protocol traffic.) is automatically set to 6.

Many platforms support a "auto-qos" command which applies a complete QoS configuration following the best practices.

What QoS scheme is enabled by default also depends on the platforms (and interfaces).

[rwharris13]

Got it, so realistcally a router will mark routing protocol traffic with 6, everything else is based on my configuration and what I want it to be, although there are best practices available to follow.

Does the same go for L3 DSCP markings? Ive always read that AF11 has a lower droprate than AF12, and AF22 has a lower droprate than AF23 and so forth, but is that just best practices, or is it actually a hardware function to treat those different?

[cadet alain]

Hi,

Best practice dictates what type of traffic to mark with corresponding DSCP value and if you don't configure a Qos policy for your traffic the router doesn't care about the marking.The drop precedence is encoded in the DSCP value and when Qos is enabled WRED will take these into account.

Regards

Alain

Don't forget to rate helpful posts.

[rwharris13]

WRED is configured by the "random-detect" command correct? So without that command we would just be using taildrop as a way to deal with congestion?

[Rolf Fischer]

There are so many concepts in QoS and furthermore it's vendor/platform/interface-type dependend.

So unfortunately it's hard to make general statements, there's always a "it depends ...".

So without that command we would just be using taildrop as a way to deal with congestion?

With QoS, we have a great toolbox to treat different classes of traffic in different ways, depending on the our (respecively the application's) requirements.

For congestion management, we can configure queueing. We can define how long the scheduler samples an idividual queue (=> "bandwidth") and the depth of each queue (it doesn't make sense to queue real-time or transactional traffic as long as normal bulk date; transmitting real time traffic with to much delay is a waste of bandwidth because the application can't use it when it's not delivered in time).

Another concept is congestion avoidance (RED, WRED). Instead of taildropping, you can define several thresholds per queue to start dropping different types of traffic at different fill levels. This is a mechanism to force TCP-streams to reduce their window size. TCP, by nature, is somewhat aggressive in occupying bandwith and congestion avoidance is our instrument to regulate that.

Hope that helps

Rolf

[Joseph W. Doherty]

Disclaimer

The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any purpose.  Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind. Usage of this  posting's information is solely at reader's own risk.

Liability Disclaimer

In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.

Posting

Interface fair-queue treats IP Prec marked traffic differently.  As interface FQ was the default on serial interfaces E1 or slower, you might consider it as "automatic".  (NB: FQ within pre-HQF class default, works the the later interface WFQ.)

Explicitly configured QoS WRED (on interface or within CBWFQ), with defaults, treats IP Prec marked traffic differently.