That was amazing. You laid it our so clearly. I was so confused about QoS from other sources. This allowed me to see the big picture of how it all works , in the correct order. Thank you
Thank you so much for a supurb explanation of QoS!!! This is such a complex subject and you broke it down so well and I finally can see what is going on! Very well taught and laid out sir! Cheers and keep these tutorials coming if you can!!!!
Thank you for this brief intro to the QoS. I believe It will be helpful for my ability to ask the right questions and find the right answers about tuning QoS. Thank you and I wish you well.
33:00 RFC791 does not support your statement of always being 0, in your drawing that is bit 5, in RFC791 page 12 bit 5 is Bits 5: 0 = Normal Reliability, 1 = High Reliability. isn't it? No requirement for it to be 0 is mentioned. It is bits 6 & 7 that are set to 0 because they were reserved for future use.
Sorry for the late reply. You're correct - that bit is only locked to 0 for Assured Forwarding values. It can be 0 or 1 when using raw DSCP values. I apologize for the confusion!
So regarding the TOS field, bit values are read right-to-left? e.g. the the left-most IPP bit if set to one would be a value of 4. I was initially confused by this but that's what it sounds like you are doing. To contrast, at 46:56, you refer to the 5th bit--and it looks as though you are referring to the (left-to-right) 5th bit. Other than that, I am really enjoying the video. Great tutorial.
There are six bits that are used for DSCP, but only the first three are used for IPP. So if the first three bits are 100, that would be an IPP of 4, so that is correct. However, since DSCP uses all six bits, 100 000 would be a DSCP value of 32. I hope that helps!
Generally I'd say that AF31-AF33 is used more for mission critical traffic, rather than multimedia. AF41-43 is used for video, and EF is used for voice.
IETF came up with a number (21) of predefined values and called them PHBs - per hop behaviors, not like you say AF. Assured forwarding is one of the 21 predefined PHBs. Here's the list ov PHBs: Default EF (expedited frwarding) CS1-CS7 AF11-AF13, AF21-AF23, AF31-AF33, AF41-AF43 AF11, AF21, AF31, AF41 will all be treated the same way. Prio has nothing to do with the drop probability portion of DSCP mark! IMO it's better to consider reading a good manual/book to avoid confusion. Overall, very very high level.
I appreciate the comment! PHBs are defined values with recommended behaviors, but we as the network admins get to define the policy that is deployed against them. That said, the industry recommendation is to treat the X in AFXY as relative priority (priority ranging from 1-4), and Y is the the drop probability (1-3). The higher the priority field, the more 'important' (subjectively speaking) the traffic is. But again, we get to define the policy. Queues with higher priority should be given the resources that they need, generally at the expense of other queues. But how we configure that is up to us and dependent on the traffic in our network. Also note that this is different from 'strict priority' settings, which I suspect is the source of confusion. The only 'strict priority' queue should be given to EF traffic, which is generally reserved for VOIP. We don't give strict priority to AF traffic, regardless of the relative priority (i.e. X values) in their PHBs.
I see what you're saying, but it's a bit more involved than that. If they're placed into the same queue, then that should be the case, but again it depends on how we configure it. However, if they're placed into different queues (which should generally be the case), then it depends on the configuration for the respective queues. While I do agree that AF43 should be dropped before AF11 if all things are equal, the two tags are technically unrelated as their respective queues will be at different levels and be dropping at different rates. But yes, to be clear - the drop priority (the Y value) determines drop likelihood independent of relative priority (X value). In that sense, we're in agreement.
You totally dissed Keith, yet tried to take credit of his recognition - I hope he never paid mind to you again. You didn't explain clearly that we're talking about 2 separate 3 but segments.
I'm not gonna lie, it may be have a petty slight (or maybe something I just didn't get the humor behind), I just don't have time to review the video to find it, and I maybe had a drink or 2 too many, and was being a bit sensitive, or dumb. Whatever it was, it was at some point before 42min (cuz that was all I had time to watch). Wish I could be more helpful, but maybe I can find what provoked my comment in the next few days, when less busy with school and work. Probably just me being touchy and a bit drunky (if so, my apologies).
That was amazing. You laid it our so clearly. I was so confused about QoS from other sources. This allowed me to see the big picture of how it all works , in the correct order. Thank you
Thank you so much for a supurb explanation of QoS!!! This is such a complex subject and you broke it down so well and I finally can see what is going on! Very well taught and laid out sir! Cheers and keep these tutorials coming if you can!!!!
Thank you for this brief intro to the QoS. I believe It will be helpful for my ability to ask the right questions and find the right answers about tuning QoS. Thank you and I wish you well.
33:00 RFC791 does not support your statement of always being 0, in your drawing that is bit 5, in RFC791 page 12 bit 5 is Bits 5: 0 = Normal Reliability, 1 = High Reliability. isn't it? No requirement for it to be 0 is mentioned. It is bits 6 & 7 that are set to 0 because they were reserved for future use.
Sorry for the late reply. You're correct - that bit is only locked to 0 for Assured Forwarding values. It can be 0 or 1 when using raw DSCP values. I apologize for the confusion!
So regarding the TOS field, bit values are read right-to-left? e.g. the the left-most IPP bit if set to one would be a value of 4. I was initially confused by this but that's what it sounds like you are doing. To contrast, at 46:56, you refer to the 5th bit--and it looks as though you are referring to the (left-to-right) 5th bit. Other than that, I am really enjoying the video. Great tutorial.
There are six bits that are used for DSCP, but only the first three are used for IPP. So if the first three bits are 100, that would be an IPP of 4, so that is correct. However, since DSCP uses all six bits, 100 000 would be a DSCP value of 32. I hope that helps!
Best QOS class I've seen
I had to watch this a few times but I get it now. Time to lab it up.
Superb explanation on what is QoS, why QoS, how QoS. It would be nice if you come up with configuration of QoS part as well. Thank you.
So multimedia is CBWFQ with DSCP AF3?
Generally I'd say that AF31-AF33 is used more for mission critical traffic, rather than multimedia. AF41-43 is used for video, and EF is used for voice.
Thats really amazing
Great Stuff!
Thanks for video, it is very usefull resource for entriy level
Thanks a lot
IETF came up with a number (21) of predefined values and called them PHBs - per hop behaviors, not like you say AF. Assured forwarding is one of the 21 predefined PHBs.
Here's the list ov PHBs:
Default
EF (expedited frwarding)
CS1-CS7
AF11-AF13, AF21-AF23, AF31-AF33, AF41-AF43
AF11, AF21, AF31, AF41 will all be treated the same way. Prio has nothing to do with the drop probability portion of DSCP mark!
IMO it's better to consider reading a good manual/book to avoid confusion.
Overall, very very high level.
I appreciate the comment! PHBs are defined values with recommended behaviors, but we as the network admins get to define the policy that is deployed against them. That said, the industry recommendation is to treat the X in AFXY as relative priority (priority ranging from 1-4), and Y is the the drop probability (1-3). The higher the priority field, the more 'important' (subjectively speaking) the traffic is. But again, we get to define the policy. Queues with higher priority should be given the resources that they need, generally at the expense of other queues. But how we configure that is up to us and dependent on the traffic in our network.
Also note that this is different from 'strict priority' settings, which I suspect is the source of confusion. The only 'strict priority' queue should be given to EF traffic, which is generally reserved for VOIP. We don't give strict priority to AF traffic, regardless of the relative priority (i.e. X values) in their PHBs.
Again, drop probability has nothing to do with the prio part of assured forwarding. For example, AF43 will be dropped earlyier than say AF11.
I see what you're saying, but it's a bit more involved than that. If they're placed into the same queue, then that should be the case, but again it depends on how we configure it.
However, if they're placed into different queues (which should generally be the case), then it depends on the configuration for the respective queues. While I do agree that AF43 should be dropped before AF11 if all things are equal, the two tags are technically unrelated as their respective queues will be at different levels and be dropping at different rates.
But yes, to be clear - the drop priority (the Y value) determines drop likelihood independent of relative priority (X value). In that sense, we're in agreement.
10 likes. thanks
thanks a lot it was very helpful
You totally dissed Keith, yet tried to take credit of his recognition - I hope he never paid mind to you again. You didn't explain clearly that we're talking about 2 separate 3 but segments.
Hi there, can you give me a timestamp? Keith is a colleague and friend and I hate the idea that something I said could be taken that way.
I'm not gonna lie, it may be have a petty slight (or maybe something I just didn't get the humor behind), I just don't have time to review the video to find it, and I maybe had a drink or 2 too many, and was being a bit sensitive, or dumb. Whatever it was, it was at some point before 42min (cuz that was all I had time to watch). Wish I could be more helpful, but maybe I can find what provoked my comment in the next few days, when less busy with school and work. Probably just me being touchy and a bit drunky (if so, my apologies).