Time for some quality of service, folks. QOS. So what exactly is quality of service? Well, it is a feature we have available to us. Why do we have this feature? Because not all packets are created equal. You know, you and I all know that we, us, downloading a movie on company time is far more important than any CEO on a voice over IP call. So it's imperative that we make sure that we have this feature available to us. So let's take a look at how we can make sure that we have this feature available to us.
So it's imperative that we ensure that we prioritize the packets that are being used to download the movie. You paying attention? It's kind of backwards there, isn't it? No. We all know that the CEO on a voice over IP call is way more important than us downloading a movie on company time using company equipment. But the thing is, is our network devices don't know that, right? They don't know the difference between the CEO on a voice over IP call and someone downloading a movie.
And so they treat, these network devices treat all of our traffic the exact same way. They use a best effort method. So whatever order you arrive on the device is the order you're processed in. So whatever order you arrive is the order you're processed in. That's best effort. And we got first in, first out type of scenario there.
The thing is, is that all these packets are not equal. They're all different. And therefore, quality of service gives us the ability to differentiate between these different packet types and then prioritize certain packet types over others. When you think about our data traffic, typically that's TCP traffic. So it might be smooth or bursty or benign or greedy. It's drop insensitive when it's TCP based, that traffic. It's delay insensitive when it's TCP, meaning we can drop it.
We can delay it. It's not a big deal because TCP can retransmit if we drop it and TCP can hang on for a bit. It's not in a hurry when communication is happening. So we can have a little bit of delay when it comes to that TCP traffic. But then something like voice traffic is the complete opposite. It is hyper delicate. It's hypersensitive. It's UDP based. Therefore, it can't be retransmitted. If it can't be retransmitted, it can't be dropped.
It can't be delayed because if it's delayed, it destroys the voice conversation that's going on between two people or more people in a conference, that is. So the traffic, the network has to be smooth. And that way there we can support that voice traffic.
But when you got voice traffic and data traffic competing for the exact same links, the same devices, well, things can go wrong, terribly wrong. And typically voice is going to suffer before your TCP traffic suffers unless you step in and make sure things are being done right.
When it comes to video, it really depends on the type of video, folks. But typically video is bursty, greedy, drop sensitive, delay sensitive. It is UDP based. But we have to realize that video comes in really two different categories. We have a real time video, things like our video that's going to be part of our conferences, video that's part of our Zoom calls, our Skype calls, different things like that.
But then you also have video that is being downloaded, is being buffered. For example, when you go to YouTube or you go to Netflix or you go to Disney Plus or Amazon Prime and you're watching those videos, those videos are essentially being downloaded to your device into a buffer and then you're watching that movie or watching that video.
And as long as you are not watching it faster than it is being downloaded, then you are always staying within that buffer and not catching up to the end of the buffer, meaning that you are going to have a perfect experience. And so it doesn't really matter what the network traffic is like or the networks like in that case, as long as you are not faster than the video being downloaded.
But when it comes to real time traffic, you don't have that buffer. Whatever is sent to you is being processed and shown to you right away. So there's no buffer. It's real time. So the difference here between real time and non real time video is really what we're talking about in this case.
So the real time video is really going to need to be treated almost like voice. Where the non real time video is not going to be treated like voice because it doesn't have to be, but it's not going to be treated like data either because we still need to kind of prioritize that or we could end up with a poor viewing experience with that particular video.
So voice and video are sensitive in nature, with voice being the most sensitive and real time video streaming conferencing applications being the second most sensitive. But when you think about it and compare it to TCP, TCP can be retransmitted, whereas voice and video definitely can't be retransmitted because if they were retransmitted, it would mess the whole conversation up.
So when does quality of service actually kick in to help us out with all of this? Quality of service kicks in when there is congestion. That's right. So if all of a sudden stuff's coming in faster than it can be processed and sent out, that's when quality of service has to kick in.
Because quality of service is going to define what gets to move to the front of the line, what gets to be expedited, what's going to have to be delayed, what's going to have to be dropped. So that way there the voice traffic is not negatively affected by this congestion. So typically what's going to happen is the TCP traffic is the one that's going to take the hit more than any other type of traffic in your environment.
So if all of a sudden you're having excessive jitter, you're having excessive bandwidth related packet loss, maybe you are seeing that you have some interface saturation in your environment, then quality of service needs to be implemented in strategic areas. So that way there you can ensure that voice is not being negatively affected. The real time video is not being negatively affected.
So it doesn't matter if it's traffic in your network or entering your network or leaving your network or crossing a WAN interface. If the network interface is congested, it's saturated. It makes sense to have quality of service policies applied because when we're dealing with voice traffic specifically, we want to meet certain requirements.
We want to make sure that the delay from mouth to ear is less than 150 milliseconds one way. We want to make sure the jitter is less than 30 milliseconds. We want to make sure the packet loss is less than 1%. So in order to achieve that, we are going to have to ensure that we are prioritizing those voice packets over all other types of traffic.
So what is bandwidth, by the way? In case you need to recall some of these terms and definitions on the exam, the amount of data that can be transmitted over the link is bandwidth. Delay is the amount of time it takes traffic to traverse the link. So the latency, there's another way to say delay and latency about the same thing. Amount of time it takes traffic to traverse the link. Jitter is the variation time it takes over a link due to queuing. And loss is the amount of traffic dropped in transit due to congestion.
So you may or may not need to recall these on the certification exam. So know them.
Now, when it comes to our devices, we have devices that are best effort first in, first out by default. That's what they are. So all of our end user devices, our phones, our PCs, everything that's going on are going to be fighting for the bandwidth.
And all the traffic is treated the exact same way. It's treated equally. So we are queuing information up. And as information gets queued and backed up and slowed down, then that's when we are going to start having problems. So congestion is when those queues are backing up. Those buffers are backing up on our device. Why? Because we can't process the information as fast as it's arriving or as fast as it needs to be sent.
So even once we process it, it might be sitting in an output queue. But if we can't send it on the link because the link is backed up, well, then what does that mean? It means that it's stuck in the queue. So we could be stuck in an input queue. You could be stuck in an output queue. And as a result of that, we are going to have various parts of our network that start to suffer.
Voice typically is the first that's going to start suffering because that's where the human beings actually experience it right then and there. Whereas TCP, we don't really see TCP suffering. It just means that it might take seven minutes to download something instead of six and a half minutes. Well, those extra 30 seconds, we probably didn't even notice them go by because we were doing something else or talking to somebody at the exact same time.
So the important thing here is to realize that QoS is kicking in. It's kicking in when the congestion happens. So if we didn't have congestion, is QoS kicking in? The answer to that is no. If we are able to process and forward as fast as traffic is arriving, then QoS does not have to kick in.
Let me repeat that. If nothing is backing up in the queue, meaning that we are receiving and processing and sending at line rate as fast as we possibly can and nothing is stuck in the queue, then first in first out because you're in, you're out, you're in, you're out, you're in, you're out, you're in, nobody's waiting, nothing's waiting. Therefore, QoS doesn't have to do anything.
So QoS is there to help us and save us when congestion occurs.
So does that mean if I wasn't so cheap, I could simply forget about QoS? Pretty much. What do you mean?
Well, if I had deep pockets, I had unlimited money, could I not buy the best Cisco gear that exists with the highest interfaces all the time, the most bandwidth on an interface-by-interface basis? Sure.
And then I would probably more than likely be forwarding traffic faster than it ever arrives.
One terabyte links for all.
And for the longest time, there would be no issues with voice, video, data, nothing.
But we don't have that much money. So QoS is the next best thing.
So with that in mind, we need to know about things like classification, marking, congestion management, traffic policing, traffic shaping, weighted random early detection for the certification exam.
A lot of this is a repeat of CCNA, folks.
Get you ready for Encore.
So let's begin here by talking about classification.
If you're following along with the slides or anything, I'm going to be jumping around in the slides.
So classification first.
So classification is all about identifying within the chassis the different types of traffic.
So we need to have a way to look at that packet, look at that frame, and ultimately determine what is it.
Are you voice? Are you video? Are you data? Are you control plane? What are you?
That's one of the primary fundamental aspects of QoS.
If you can't classify what that traffic is, then you can't QoS it.
So when we classify traffic, it could be based on the type of application.
It could be based on the source or destination IP address.
It could be based on simply the incoming interface.
It could be based on what?
Class of service values in Ethernet headers.
Type of service values in packets.
Type of service values in packet headers.
The IP precedence or the DSCP values.
It could be an MPLS, EXP value, and an MPLS header.
So let's just go take a peek at our headers right now.
So there is our packet header.
Service type field.
We could have a marking in there that classifies it as voice, video, data, control traffic,
other traffic, best effort traffic, right?
Type of service type field in our packet.
But then down here, what do we have?
We have our class of service field that would be in our 802.1Q tags.
So frames don't have the ability to be classified unless they have an 802.1Q tag.
So any frames without a tag are just going to be treated best effort.
Whereas if they have a tag, then we could prioritize them, classify them, apply quality of service to them.
That would be the class of service field.
So now your TOS, DSCP, COS field, your TID for wireless, and the MPLS, EXP value for MPLS,
those are all examples of ways that we can classify our traffic based on markings that exist in our headers already.
But then we can also just simply base our classification on things like access control lists.
So we could have an access control list applied on our device,
and that access control list says if the traffic is coming from this source, going to this destination,
or maybe just this source range, or any source range going to a particular destination,
or maybe if it has these particular values or these port numbers,
or this protocol in use, everything that we can specify in an ACL.
If it has these particular parameters associated with it based on the ACL,
then classify it as voice, or video, or data, or best effort, or whatever you want to classify it as.
In addition, we have ways to look at the actual application data in the packets
using something like NBAR, network-based application recognition.
Look at layers 4, 5, 6, 7, and we can identify that by examining the payload of the actual application
based on what a signature database that exists.
So just different ways to classify our traffic.
So where are we going to want to classify?
Well, we're going to want to classify everywhere. Everywhere.
Why? Because I want to make sure that this device can classify the traffic to apply quality of service.
I want to make sure this device can classify the traffic to apply quality of service.
I want to make sure this device can classify the traffic to apply quality of service, and so on and so forth.
So all of my networking devices have to have the ability to classify, to identify,
hey, what type of traffic are you?
All right, so now let's talk about marking.
So what is marking?
Well, I already gave you an example of marking.
That would be information that is inside of our packet header or our frame header.
And marking is the ability to modify or alter that value in the packet header or in the frame header,
the 802.1Q frame header.
So going back to this slide right here, marking is about changing the value that's in there.
Marking is about changing the COS values that's there.
Marking is about changing the TID value.
Marking is about changing the MPLS EXP value.
So by default, that would be empty.
It would be blank. It would be best effort.
And so marking would be, hey, I've identified this as voice.
Let me put the voice value in there.
With COS, for example, by default, it would be zero.
But then it's like, hey, it's voice.
Let's put a COS value of five in there to represent our voice traffic.
So marking is a way for us to modify the actual header information.
And then when it's marked, we can use that for classification purposes.
So the deal is you can classify.
Once you figure it out, you can mark.
So if you are not classifying based on this information, you have the ability to classify and mark.
But if you're classifying based on this information and this is the right information,
then you don't have to mark because you're just classifying based on already existing markings.
So what does that mean?
It means that when it comes to classification and marking, there's a time and a place to do each of them.
So like we said, we're going to classify everywhere.
I want to classify, classify, classify, classify, classify, classify, classify, classify.
Because as I am classifying everywhere in my environment, I have the ability to identify,
are you this type of traffic or are you that type of traffic?
But the thing is we don't want to mark everywhere.
Because what is marking?
Marking is altering, altering.
So the deal is, is we want to mark as close to the entry point of that environment as possible.
So for example, as the traffic's coming in, we can classify and mark, classify and mark.
But over here, I just want to classify.
I do not want to classify and mark there because there's no need to mark.
I'm going to use the markings to classify, but I'm not going to mark again
because there's already markings in the header information.
On the way in, classify and mark.
But if the traffic's going this way, then I only want to classify.
I don't need to mark it again, right?
Just classify it as it's going through over to my devices down here.
So classify and mark in here.
I might have to mark coming in, but if the traffic's going this way, as an example,
well, classify and mark here, and then just classify, classify, classify, classify on the way out.
So we want to make sure that we are minimizing the amount of marking we're doing
because marking is resource intensive.
Anytime you have to modify the packet, CPU has to get involved.
Now, in higher end devices, we can mark and do things like that
based on our TCAM tables and so on and so forth, which is great.
But still, we want to ensure that we are minimizing the amount of marking in our environment.
So typically marking the entry and exit points, classifying everywhere
is typically the way that we are going to perform these two different items.
So classification and marking, know that stuff for the certification exam.
Definitely make sure you know, folks, those different marking options.
Like I said, TOS, COS, DSCP, those are all layer three.
You got MPLS experimental for MPLS.
You got TID for wireless.
You got COS for layer two frames.
Make sure you know that.
Let's talk about traffic policing and traffic shaping right now.
So traffic policing is all about what?
Marking or dropping excessive traffic.
So if we have traffic that is not behaving,
it's exceeding what we wanted to.
And as a result of it exceeding its rates, its bandwidth, its rates,
it is now causing potential congestion on the network.
Well, then we might want to police that traffic.
We might want to drop that excess traffic that is causing problems.
So we would then drop it, which would,
if it's TCP-based traffic, cause TCP retransmissions.
And as a result, it does not introduce any type of delay
or does not introduce any type of jitter.
Because what I always want to remember is that delay and jitter
is based on that packet.
If I drop it, is the packet gone? Yes.
So there's no more delay.
There's no more jitter because it's gone, right?
Keep that in mind.
So it doesn't introduce delay or jitter because the packet is gone.
So when we're dropping those TCP packets,
base packets, I should say, TCP-based packets,
we got no delay or jitter introduced
because the packet is gone.
And typically, we're going to try to police
as near the source as possible.
So that way, our traffic's not going all the way near the end
to just get dropped.
We try to drop it as near the source as we possibly can.
Now, how does that compare to something like traffic shaping?
Well, traffic shaping is really about what?
It's really about buffering and queuing packets
and slowing packets down that have exceeded
a certain committed information rate.
So we can simply hold on to that packet longer.
In our buffer.
And then when is the most appropriate time to send it?
Or when it is the most appropriate time to send it,
we go ahead and we send it at that point in time.
So this will introduce delay and jitter
because the packet still exists, the packet's still alive,
but we're hanging on to it.
And when we hang on to it, that introduces delay.
And based on the variation in delay,
then that introduces jitter as well.
So remember that shaping buffers and queues packets
above a certain committed information rate for us,
whereas policing drops packets above the committed rate
and helps you control the max rate of traffic
that is received or sent on any given interface.
So here's an example of what it might look like for us.
So in this case here, you can see as we're policing,
the traffic rate will definitely change
because as we drop, the traffic rate goes down,
then it comes back up, we drop, it goes down,
it comes back up, we drop, it goes down,
it comes back up, whereas shaping,
you see how shaping shapes it out for us?
It ensures that we meet a certain level.
So in this case, we said we're exceeding
the committed information rate, so we drop everything that exceeds,
whereas in this case, we slow down everything that exceeds instead.
So that line would be our committed information rate line.
We're dropping, dropping, dropping, dropping,
so retransmit, retransmit, and so on and so forth,
whereas over here, we're just hanging on to it longer,
so we're shaping it so it conforms to that speed we want.
So really important things for you to remember here, folks.
Please, please, please make sure you are well aware
of policing and shaping in this particular case.
So back to here, let's talk about congestion management now.
So congestion management is a way that we can now
divvy up our device in a virtualized way
by creating queues, so that way there,
we can manage how traffic is handled
when the congestion actually starts to occur.
So think about our device.
By default, it's first in, first out,
so you have all these packets arriving,
and this is our queue right here.
We have all these packets in our queue,
and first in, first out, first, next, next, next, next, next,
like you see here, and away you go.
So we're processing in that order,
but what if these ones here,
what if these were voice,
and these were video, and this was all data,
and these are like 1,500 bytes,
and these are more like 200.
There's a big difference there.
This definitely would have a negative effect
on that voice traffic.
So instead, with our congestion management
and our queues, we can create queues,
and therefore now we can put voice, video, data,
everything else as an example.
So we have now a queuing system
that has a classifier,
and that classifier is going to help us
choose what traffic is placed in each queue.
So by being able to classify that traffic,
oh, your voice traffic,
based on our classification we're doing,
then you go in this queue.
Oh, your video traffic, you go in here.
Oh, your data traffic, you go in here.
So by simply looking at the headers
that are already in our packets and our frames,
our devices are going to know
which queue do you belong to.
And then we need to set up our schedule.
Our schedule performs what?
The prioritization that we need.
So how much from this queue,
how much from this queue,
like what order, at what speed,
and we do all this using something called the MQC
that we'll talk about here momentarily.
The MQC,
Modular Quality of Service Command Line Interface.
So we use the MQC,
and then we use what we call the service policy
to apply it to our interfaces.
So I put together a little chart here
for some of the different queuing options
that we have, folks,
to help you get ready for the certification exam.
First in, first out
is our default queuing option.
If there's no congestion,
we are using first in, first out.
Let's be very clear about that.
Default queuing method
where packets are processed and forwarded
out an interface in the order they arrive
without any specific prioritization.
If you choose to implement
a different queuing strategy,
like priority queuing,
what does that mean?
What are you actually getting
if you use priority queuing?
So priority queuing allows you
to have four priority-based queues.
I wonder why Raymond has highlighted stuff
and italicized stuff
and underlined stuff.
So four priority-based queues.
And you'll see here
that there's a different priority level assigned
to each of those different queues
based on our traffic classes.
So, for example,
you're going to have a high-priority queue
for high-priority traffic.
So your high-priority queue
has your voice traffic in it.
And all of that is going to be forwarded
ahead of the interface.
To the other lower-priority traffic.
So you've got four queues.
So one, two, three, four.
One's the best, for example,
with voice in one,
maybe video in two,
maybe data in three.
It's a simple strategy,
priority queuing.
Custom queuing,
let's go down to the bottom,
allows you to configure
a specific number of queues
and allocate bandwidth
to each queue manually.
So you could set up, for example,
let's say you wanted 16 queues.
And then for each of those queues,
set up specific bandwidth values,
bandwidth requirements
for each and every single one of those queues.
So you can specify the number of bytes
in a specific queue
that should be dealt with
before working on the next queue.
So you could say,
okay, my top queue,
which is going to have my voice traffic,
I want these many bytes processed
before you move on to the next.
However, if you turn around
and you process everything that's in there
and there's nothing else,
then go on to the next anyways.
And then once you've done that one,
then go on to the next,
then back to the top.
So we're just going through them,
going through them, right?
And based on the amount of bandwidth,
you're going to be able to do that.
All right, next one on our list here
I want to talk about.
So we've covered this one,
we've covered this one,
we've covered this one.
Okay, let's talk about weighted-fair queuing now.
So weighted-fair queuing is classified
as a flow-based queuing method
that uses store-and-forward queues
and allocates bandwidth.
So this one was bytes,
and this one is bandwidth
proportionally to different flows
based on a weight system
and weighted-fair queuing
takes weighted-fair queuing
a step further.
And it allows you to define traffic classes
based on various criteria.
So you can then allocate bandwidth
and apply your policies
to each and every single different class
that you have.
In addition, with weighted-fair queuing,
this is a good one,
you have the LLQ, the low-latency queue,
low-latency queue,
provides guaranteed bandwidth.
Guaranteed bandwidth.
Your LLQ provides guaranteed bandwidth
and strict priority servicing
to a specified class of traffic
such as voice.
So with weighted-fair queuing,
you are going to put your voice traffic
in the LLQ, the low-latency queue,
so that way there, in the end,
it has the guaranteed bandwidth
that it needs, that voice traffic.
So a lot of good information here for you.
You don't have to be an expert
with each and every single one of these queues
for the certification exam,
but you do get through
the queuing questions that may,
if they do show up
on the certification exam.
All right, back to this page here.
We got last on our list here,
WRED,
Weighted Random Early Detection,
W-R-E-D,
a technique for congestion avoidance.
So what is happening here
with weighted random early detection?
So it's a congestion avoidance feature
that gives us the ability
to selectively drop packets
based on an assigned weight.
Why do I want to do this?
I want to do this so I can help prevent congestion
by discarding lower-priority packets first.
So what you need to realize
is that you have your queue on your device.
So if you have your queue on your device,
and packets are backing up in the queue,
what happens if the queue
becomes 100% full?
Well then, what happens to all these packets
that are trying to get in?
They get what is called tail drop.
Tail drop.
Why this is the tail of our queue.
So all of the queuing strategies
we just talked about,
they're really for the head.
The head of our queue, it's called.
So based on the head of our queue,
how do we organize everything
at the head of our queue
to make sure we get things prioritized and through?
So at the head of the queue,
we could still experience tail drop,
even though at the head of the queue
we have our queuing strategy.
And so we want to stop this tail drop from happening
because if voice packets are being dropped,
that's no good.
If real-time video packets are being dropped,
that's no good.
So this queue is being filled up.
So what weighted random early detection does for us
is it has the ability to,
let me erase some of this first,
so it has the ability to monitor the queue.
And as it's monitoring the queue,
all right, we're filling up.
So based on the fact we're like 25% full,
let's go ahead and drop
X number of TCP packets out of here.
There you go.
So it's dropped X number of 1500 byte TCP packets
out of there, freeing up some space.
So now we're no longer 25% full.
We are now maybe 15% full.
So we just freed up a little bit of space.
So hopefully that little bit of space now
gets filled in with some voice packets,
maybe some other things,
and we don't get back to 25%.
But let's say we got back to 25%,
drop a little bit more.
But what if all of a sudden it filled up to 50%?
Well, then we're going to be more aggressive.
We're going to drop maybe twice as many,
1500 byte TCP packets.
What if we get even more?
Well, then maybe we'll drop even like
maybe quadruple the amount
or five times the amount or six times the amount
of TCP base packets.
Drop those packets that could be retransmitted.
Drop those TCP large 1500 byte packets
that could be retransmitted.
So that way we're freeing up space
for what, the voice packets to come in
so they never get tail dropped,
those voice packets.
So it's a congestion avoidance feature.
So that way when our queue is filling up,
it can determine which packets are high priority
and which packets are low priority,
and then drop those low priority packets,
those 1500 byte TCP packets as an example.
MQC.
What is the MQC,
modular quality of service command line interface?
So the MQC allows us to build a construct,
a structure that's going to implement
the quality of service for us.
And I'm not going to go through the MQC here
and show you how to create a class map
or a policy map or a service policy for QoS.
And the only reason why is because
it is not exam relevant.
And knowing the MQC is used is important,
but not the actual MQC construct for QoS.
Now, policy-based routing,
we talked about the MQC.
You remember that in policy-based routing?
If you haven't watched the policy-based routing videos yet,
we talked about the MQC there.
And I talked about class map, policy map,
service policy, and we applied the
policy, the service policy,
or the policy map, I should say,
to the control plane interface.
Did I say policy-based routing?
I meant control plane policing.
So, not policy-based routing,
control plane policing videos.
Do you remember those control plane policing videos
that you went through earlier?
If not, go watch them later.
But we talked about the MQC for control plane policing,
that's what it was,
class map, policy map, service map.
So, same idea,
but now instead of dealing with it
from a security standpoint,
you'd be dealing with it from a quality of service standpoint,
and you'd be dealing with,
well, how much of this bandwidth for this queue,
how much bytes for this queue,
and so on and so forth as you're using it.
So, the class map is used
to identify the traffic to match.
So, match the voice traffic,
match the data traffic,
match the video traffic,
match this traffic type,
and management traffic as well,
and control traffic and everything else.
And then the policy map
is going to be what you use
to define or create your scheduler.
So, what happens here now
is you are in your policy map saying,
okay, so if it matches that class map,
then I want you to give it
this amount of bandwidth,
or I want you to police it this way,
or so on and so forth.
So, that's where you're setting the actual values
when it comes to how you treat
that traffic in the policy map.
So, if you have class maps
for your management traffic,
your control traffic, your data traffic,
your voice traffic, your video traffic,
then in your policy map,
you're going to be specifying different policies
for each and every single one of those classes.
And then once that's all said and done,
you can apply the policy map to the interface,
and we call that our service policy.
So, the service policy applied to the interface,
so that way we can apply the QoS policy
to that device's interface.
The policy map defines our schedule,
and our class map defines our traffic.
That's what I want you to know
for the certification exam.
All right, so that's our QoS coverage, folks,
for Encore.
If you want to know more about QoS,
then it's best to take a collaboration course
where you're going to be covering things
like voice and video in your environment.
So, it'd be best to take
one of those courses
to get into the actual voice, video,
and then more importantly,
the quality of service that goes along
with those in the environment.
All right, so, for the exam,
be sure to know classification,
marking, policing, shaping,
congestion avoidance, congestion management.
Know the terms and definitions
that we covered earlier on.
Know why you want to use quality of service.
Know where you want to classify,
where you want to mark why,
because those are the things
that could be a simple multiple choice question,
or maybe even a drag and drop, folks,
that is going to test you on
do you understand at a very, very,
very fundamental high level
what QoS is and what all these things are.
So, same thing with your queuing strategies.
Just having a basic understanding
of those queuing strategies
and what each of those can kind of do for you
is what you want to get ready for
for the certification exam.