Giuseppe,

Are the AF values themselves arbitrary? There are 4 classes of AFs with 3 drop probabilities:

AF11, 12, 13

AF21, 22, 23

AF31, 32, 33

AF41, 42, 43

Are all of these essentially equal? What is the desirable scenario to use AFxy instead of DSCP or IP Prec values?

Thanks,

John

Hello John,

in AFxy the x index is roughly the class selector, y the drop probability.

the difference is in how they are treated in a DiffServ model.

AF33 is processed in queue with AF31 AF32.

AF33 < AF32 < AF31 drop probability is better for AF31 then for AF32 then for AF33.

AF33 can be treated better then any AF2y.

AF2y can be treated better then any Af1y.

note: if you use AFxy you are using DSCP indeed.

with DSCP you have more granularity up to 64 different classes can receive a differentied treatment.

With IP Prec taking in account that IP Prec 7 is not used, IP prec 6 is reserved to routing protocols you can accomodate up to 6 classes: 0,1,2,3,4,5.

Hope to help

Giuseppe

By you saying "treated better then", do you mean by want I place in the policy map that the class is assigned to?

Are the AFxy classes better than IP Prec? I understand that I can have more classes, but is one more preferred (technology-wise) over the other? Would I use one in a certain scenario over the other?

Thanks Giuseppe!

John

Hi John,

You will usually see CS (Class Selector) used on call-signaling. As Giuseppe stated, using AF is intended for flows that could be subject to markdown and aggressive dropping of marked-down values.

Marking down and aggressively dropping Call-Signaling could result in noticeable delay to dial tone (DDT) and lengthy call-setup times, both of which generally translate into poor user experiences, thus the general recommendation is to use CS3 for call-signaling.

HTH,

__

Edison.

Thanks Edison

Aside from those, when is a good time to use "set ip prec" commands under a policy map or using "set dscp <0-63>" vs. "set dscp af31"?

Like Giuseppe said, there are 64 values for DSCP <0-63>; are these arbitrary? The router doesn't do anything with these numbers other than the action that I tell it to perform under my policy map, right?

Thanks,

John

When defining end-to-end QoS, it's recommended to follow pre-defined guidelines often found in RFCs.

There isn't a rule to use one type of marking over another but when configuring an enterprise network, you often will have to deal with other entities where they will also have QoS.

If both entities followed a pre-defined guideline on how packets should be marked, any QoS implementation between these entities will be much easier.

One thing about the values, as I mentioned on another post on this thread, the values mean something as switches have a table-map as to where to place these packets based on their values.

HTH,

__

Edison.

John

AFxy

where x = the class

y = the drop probability

The higher the x is the better treatment the traffic gets but note that is a convention. There is nothing within the AF classes that inherently supplies QOS so it is up to you. The convention states that AF41 gets better treatment that AF31 but that treatment is defined by your policy so there is nothing stopping you giving better treatment to AF31 than AF41 if you really wanted to.

Jon

That's what I'm seeing :-)

I'm taking from this thread that the numbers for all of the classes really mean nothing, and it's more for the engineer to be able to look at most configs and say "that's a higher number, so it must be a higher priority class." Either way, the numbers don't do anything other than "label" the traffic type for the engineer looking at it. You would actually set your policy however you wanted to be able to do whatever you wanted to whatever number you want.

Sound right?

Thanks,

John

"and it's more for the engineer to be able to look at most configs and say "that's a higher number, so it must be a higher priority class."

Kind of yes. You could not really look at the DSCP values in isolation and say which has better treatment. As i say convention dictates that EF is better than AF41 which is better than AF31 etc... but you really need to check the policy map to find out how this traffic is being treated eg. you usually map EF to the prioriry or LLQ but you can if you want to confuse everybody map AF11 to that queue :-).

Jon

The numbers mean something as the internal pre-defined QoS values in switches will use those numbers as a reference for packet->queue placement.

HTH,

__

Edison.

Edison

Good point. But what i was getting at was that you can override these values if you want to so that they mean entirely different things. So again it is convention rather than any inbuilt QOS for the values.

Or do you mean something else ?

Jon

Jon,

If you want to change every single switch cos-dsp map or prec-dscp map setting to something unique in your network, by all means go ahead :)

What happens when you are sending those markings to switches that you have no control of?

What happens if you are sending those markings to, say, MPLS providers where they have their own established markings?

We are basically saying the same thing but I wanted to point out the values mean something as some of those values are already pre-defined by RFCs - i.e. EF = voice.

__

Edison.

Edison

"If you want to change every single switch cos-dsp map or prec-dscp map setting to something unique in your network, by all means go ahead :)"

Not really no :-)

"We are basically saying the same thing"

Yes, i think we are..

Jon