What is quality of service or QoS? Well quality of service is a way for us to differentiate
among different traffic types on the network and ultimately the idea is to prioritize or
give preferred treatment to different types of traffic. Most commonly we're really looking at
real-time applications. Applications that are very dependent on things like latency
and jitter and traffic loss and of course when we're talking about real-time applications,
voice over IP and probably video as well are the first categories for us to really mention.
Voice over IP especially is very very sensitive to network latency, network loss and again we'll
throw jitter in there as well. So for example if I'm on my PC, here I am on my PC and I decide I
want to download a video game or something like that so I send my request to the internet and
my traffic download starts so I'm downloading this file. Meanwhile I also get on a phone call
and I'm communicating out to somebody using voice over IP. So I'm on the phone while my internet
download is going on. So here's the big question. If these two traffic streams are going through the
same network device here, maybe it's a router, maybe it's a switch and we're not showing
preferential treatment between the two, what happens if I end up introducing let's say 200
milliseconds of latency into the equation? Which one of these network transactions is going to be
impacted the most or for that matter at all? I mean if my download is behind by 200 milliseconds
or even 500 milliseconds or even five full seconds, am I going to notice? Not really, not unless it's
a really super small download. Maybe I would notice that it took five seconds and it should
have taken half a second or something like that. But 200 milliseconds of latency for most internet
downloads is not going to be anything noticeable. But what about a voice over IP call? 200 milliseconds
of latency will actually potentially destroy that phone call. It'll make it so we're sitting here
whoever I'm talking to over here on the other line or on the other end of the line we're sitting here
talking and we're stepping on each other's toes. I think they're done talking. I start talking but
then they start talking and then it gets really awkward and we've all been on those types of phone
calls where latency is a problem. Whether it's voice over IP or potentially just on the cellular
connections that we have. So we know that this 200 milliseconds of latency will absolutely destroy
certain types of traffic while not affecting other types of traffic. And furthermore what if
this download right here is what actually introduced the latency into the voice over IP call?
Well this is exactly why we need QoS because we have to be able to differentiate and prioritize
our different traffic types. Because what can happen here is we might have a network device
here and every interface is going to have by default a network queue. We have to line up our
packets in order to send them out. By default we might just assume that hey a packet just arrived
boom send it out and it's instant. But it's not an instantaneous process. We not only have to
serialize that information putting it onto the line but while we're doing that other packets
are also arriving here. There we go. Other packets are also arriving and so we need to queue them up.
So again what happens if both of these traffic types are arriving on this router and they both
need to go out the same interface? Well what we end up doing is we put them in this traffic queue.
So I've got the my very small voice over IP packet and then maybe I've got a bunch of these much
larger let's say internet download packets that that I'm sending out. I guess in this case I'd
be like maybe pushing something up since they're arriving on the network not on the other one the
other way around. But either way we understand maybe I'm sending traffic so we've got these
very large 1500 byte packets and then a voice over IP packet shows up over here.
So this packet really goes out super fast that's awesome. But then this packet back here has no
choice but to wait for all three of these very large packets to send. And then maybe we have
the same problem where we've got more voice over IP packets showing up behind a bunch of these
larger packets. So we start to see the problem here and so we need a set of mechanisms in order
to help us resolve the situation. So we're going to very quickly talk about several of these QoS
mechanisms. I want to be clear we're not in this skill in this course going to dive deep into QoS.
We just need to understand the concepts and how it applies to SD-WAN. So I'm going to link a couple
of different places where we can go much deeper into quality of service if we so desire. But again
even though we're not going to go super deep we are going to cover some of these basic concepts.
And so these mechanisms include first of all classification. Classification is the starting
point of all of this. We said that we need to be able to differentiate among traffic types
and so we're going to talk about classifying those packets into different classifications.
There are several ways to mark a packet as it arrives here. So we've got our router and it's
seeing this packet show up and it doesn't know what application that belongs to at least in
traditional networking. It has no clue whether a phone sent it or a PC or whatever type of device
and so it needs a way to know what on earth this packet is. Now we do have things like deep packet
inspection with SD-WAN as we've talked about but traditionally again we're going to look at a tag.
So that means that whatever device originally sent this packet must provide the tag when it
sends it. It's part of the packet headers. We have three different tag types. We have class
of service which goes into the ethernet frame and this is a layer two marking. We have a more legacy
type of layer three marking. This is called IP precedence. This goes into the IP header at layer
three but again I would call this legacy. We don't really use it anymore. Instead what we use is DSCP
which stands for differentiated services code point. Quite a mouthful and we'll just call it
DSCP. This also goes in the IP header and this is how we do layer three in modern networking. I'll
call it modern networking but it's been this way for a very long time. We haven't used IP precedence
in quite a while but we do need to be aware of that if we were to dive deep into quality of
service. So what is DSCP? Well we'll talk a lot more about DSCP in the next video because
it is very important for us and we do use it in our SD-WAN environments. We're not going to use
certainly IP precedence but we're also not going to use a layer two mechanism like class of service
when it comes to SD-WAN. So now the router knows that hey maybe based on this tag this is a voice
over IP packet. Cool. What's it going to do about it? Well what we're going to do about it is we're
going to change our queuing methodology. We just show down here that a single queue is bad news
because we can't actually say that I'm just going to come over here and pull this packet out.
The router has to take whatever is in the front of the queue and so when we have a single queue
like this this becomes known as first in first out queuing or FIFO meaning that because this packet
arrived first it's the first one out and that's well and good when it's a voice over IP packet
but that means that these packets get to be sent first before this one all the way in the back.
So we want to avoid a single queue and first in first out queuing. So again what are we going to
do about it? Well we're going to create many queues using one of several different methodologies.
Typically in Cisco networks we're going to look at something called class-based weighted
fair queuing or possibly low latency queuing which is really just an enhanced version of
class-based weighted fair queuing. The enhanced version provides voice over IP protections.
So now the way this works is we create let's just say three queues here and so we're going to as
the router again get in a packet and we're going to look at the tag and the tag is going to tell
us which queue to place this packet into. So let's say we've got voice over IP here let's say that
we've got bulk traffic those large internet packets that we're sending and then maybe a best effort
queue for everything else and so now I can put my small voice over IP packets into one queue and I
can put my large bulk packets into another queue and then everything else from large to small
whatever's kind of fitting into the best effort queue doesn't really matter it's the catch-all.
And then we have what's known as the scheduler. The scheduler is going to decide which of these
queues to service at any given time and as we might imagine we want to send these voice over
IP packets as much as possible if they're in this top queue. Now what we call this queue when
it's voice over IP enabled is the low latency queue which is a priority queue. We're going to
send it first but all of these different queues are bandwidth limited. This is an important concept
and when it comes to software-defined WAN we're going to see that when we create these different
queues we define how much bandwidth goes into each queue. We want to avoid something called
starvation where maybe I prioritize this bulk traffic queue it's very important that I be able
to send my backups or whatever I'm sending but imagine if there's so much backup traffic and so
much voice over IP traffic that my best effort traffic never goes through. We can't look at best
effort traffic and say well it doesn't matter that's not best effort traffic. If I'm just doing
my job and I'm accessing cloud services that's best effort and if best effort traffic never goes
through that means we're going to have a lot of problems. So we do want to still limit our
prioritized traffic flows and say yeah okay we want you to go through you're important but you
can't starve the other queues. So we're going to limit bandwidth to all of these queues ensuring
that all of them get some amount of the link. So we've solved most of our problems that we've
talked about but there is one other problem we have to worry about and this especially affects
our service provider links and as we can imagine when we're talking SD-WAN our WAN links are going
to be an important part of this. So here's the idea we might have this great quality of service
policy set we're going to provide all of this queuing and classification and everything to
make sure that the traffic gets prioritized as we send it out to in our case let's say a WAN
service router. So what if this WAN service router or this WAN really service provider
has given us a 100 megabit per second connection
and this connection is being made via a one gigabit per second ethernet port. So we see that
we only have 100 meg of the one gig traffic. So if we have 150 megabits per second all of a sudden
coming in a one gig link will allow 150 megabits per second. So we are now sending 150 megabits
per second. What is the WAN service router service provider router going to do? Well it's going to
abide by what we refer to as the service level agreement and it's going to perform something
known as policing and it's going to allow of our 150 megabits per second it's going to allow
100 megabits per second and 50 megabits per second is going to get blocked and dropped.
This is a problem because this is not based on tag it's not based on prioritization this is
typically indiscriminate. That's a really fancy word for saying that it doesn't care whether it's
dropping voice over IP packets or whether it's dropping bulk data traffic packets. So we
have to be very careful about this scenario. Namely if I'm getting 150 megabits per second in
and I know I only get to send 100 I need to make sure I'm only sending 100 at a time.
Now this might mean I have to drop packets still but this is okay
because if I'm the one dropping the packet I can perform my prioritization. I can't prevent
the dropping of packets in this situation but I can choose which packets to drop.
So this is okay we're happy with this ability but what is this mechanism called? This mechanism
is called shaping. I'm going to take my 150 megabits per second that's coming in and I'm
going to shape it down to 100 megabits per second. This might mean one of two things. First of all I
might just be able to spread this data out a little bit and maybe I can absorb some of these
fluctuations in traffic and maybe I can still get all of those packets out just taking a little bit
longer. I'm going to introduce some delay and still get those packets out but the reality is
in a lot of situations I'm still going to have to again drop 50 megabits per second but now I can
make sure that those 50 megabits per second are best effort and bulk traffic and that the voice
over IP packets are always allowed in there. So now I can apply my QoS policy in such a way that
this policing mechanism never drops a packet and that is very important for us because we don't
want our upstream service provider to decide which of our packets to drop. We would rather decide
that ourselves if packets need to be dropped. So as I started to say earlier we do have courses
available to go much deeper into all these concepts. I think every single one of these I've
done entire videos on classification and queuing and shaping and policing and all of that so you can
go check those videos out and those skills out in our on-core CL core courses, CCNA course as well.
I'm going to go ahead and link some of these in the skill right below this video but again as long
as we have a comfortable level of understanding of these different mechanisms we can now proceed
into talking about how this impacts our SD-WAN environment. But first we do need
to go a little bit deeper into those DSCP tags so let's go ahead and do that.