In order to best understand how our modern queuing mechanisms work, it's good
to understand
where we came from.
And as part of this, we want to introduce a very important concept that we will
carry
forward, which is known as a priority queue.
But first of all, let's talk about the concept of first in, first out.
Otherwise known as FIFO.
First in first out is that queuing mechanism that essentially means that we're WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
First in first out is that queuing mechanism that essentially means that we're
doing no
queuing, which is kind of funny.
But it is the default setting on a Cisco network device interface.
And essentially what it's saying is that we're going to have a single queue.
First in first out simply means that the first packet to arrive is going to be
the first
packet that is sent.
Which makes sense.
If I have a queue or a buffer that is lined up like this, packet one arrives. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
If I have a queue or a buffer that is lined up like this, packet one arrives.
Well the scheduler, if we want to call it that at this point, the process
responsible
for sending the packets is going to start sending packet one out the egress
interface.
While packet one is being sent, three more packets arrive.
And so these are packets two, three and four.
And so as we see here, what we're doing is we're creating this queue of packets
that
get to be sent out in the order in which they arrived. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
get to be sent out in the order in which they arrived.
So after we've properly sent out packet number one, we're going to start
sending out packet
number two, and then we'll move to packet three and packet four and so on and
so forth.
First in first out is again the default setting.
And it gives us absolutely no control for QOS.
This is what we're trying to avoid.
For example, what if packet number four here, that this is a voice over IP WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
For example, what if packet number four here, that this is a voice over IP
packet.
And meanwhile packets one, two and three, these are all 1500 byte bulk traffic
operations.
Very low priority.
It's going to take a while relatively to send 1500 bytes.
And so this voice over IP packet is just going to have to sit in the back of
the queue waiting
its turn.
So we want to avoid that and Cisco started creating some options for how to
create multiple
queues.
The first option is known as custom queuing, which can be abbreviated as CQ. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
The first option is known as custom queuing, which can be abbreviated as CQ.
Custom queuing was created by Cisco and it leverages a basic form of scheduling
known
as weighted round robin or WR.
Weight round robin is going to be used across 16 different queues.
And the 16 queues are going to give us some basic control over our ability to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And the 16 queues are going to give us some basic control over our ability to
assign traffic.
So very basic level of control.
And it's going to be based primarily on IP precedence.
Now we've already said that we're not really using IP precedence anymore.
And we're really not using custom queuing in modern networks either.
So we don't expect to see much in the way of custom queuing these days.
There's really not a huge advantage to deploying it compared to some of our
better options. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
better options.
But the primary way this worked was we'd line our queues up here and we would
actually
assigned a byte count to each queue.
This byte count ensured that different traffic flows would actually get to be
serviced rather
than just waiting their turn.
And so a certain amount of bytes would get sent out.
Let's say it's just, I don't know, let's just say it's four kilobytes or
something like
that. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that.
So we send four kilobytes of data and then we move on to the next queue.
And so the next queue gets two kilobytes of data.
We send that much data and then we go to the next queue and so on and so forth.
And so based on the fact that we can sort our traffic by IP precedence, we can
effectively
put our voice over IP packets into one of these queues and that will ensure
that they
do get sent fairly, at least a little bit more fairly.
The problem with custom queuing as much as anything is that we don't actually WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
The problem with custom queuing as much as anything is that we don't actually
get to
say that, hey, a voice packet arrived, we should send it immediately.
It's still going to have to wait its turn, but at least it doesn't go into the
back of
the queue.
If there's a bunch of packets lined up in the standard queue here, voice over
IP can
go somewhere else so that once that standard queue has sent so much traffic,
now the voice
over IP packets can start to send.
So better than nothing, but again, in the modern network, we typically don't
see custom WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
see custom
queuing deployed anymore.
Now, our next mechanism is known as priority queuing and priority queuing set
out to solve
the problem that we just said that custom queuing didn't provide, which is to
provide
what we call strict priority to certain traffic flows.
Strict priority simply means that if a packet arrives, it gets sent immediately
.
It is sent first before any other packet gets set. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It is sent first before any other packet gets set.
So this is kind of interesting because essentially what we're saying here is,
well, first of
all, PQ gives us four queues.
So remember, custom queuing gave us 16 queues.
Priority queuing gives us four different queues.
Now these queues are going to be sorted by priority.
We have a high priority queue, a medium priority, normal priority, and then low
priority.
So the idea here is that while most of our traffic would go into the normal WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So the idea here is that while most of our traffic would go into the normal
queue, we
do have the ability to throw some traffic into the low priority queue.
If we so desire, if there's traffic out there, we just truly don't care whether
or not it
actually ever makes it through.
Now, here's the concept of the strict priority.
Strict priority means, remember that if it arrives, it is sent first, but this
is going
to be relative to the priority level. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to be relative to the priority level.
So what happens if a, let's just say we have a bunch of traffic in the normal,
here, we'll
draw like this.
We have a bunch of traffic in the normal queue and in the low queue.
So what's going to happen here, first of all, is that we're just going to be
sending
these normal packets.
The low priority queue isn't going to send anything until normal is completely
sent.
But what happens if a couple of packets show up in the medium queue? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But what happens if a couple of packets show up in the medium queue?
Well, now we're not going to service even the normal queue anymore.
We're going to start servicing the medium queue until it's empty.
And likewise, if packets start showing up in the high priority queue, which is,
assuming
that we'd place our voice over IP packets, well, now we're going to be sending
packets
from the high priority queue, not the medium, not the normal, and certainly not
the low.
This is a very interesting model.
And it, again, introduces the concept of strict priority, meaning that one WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And it, again, introduces the concept of strict priority, meaning that one
queue has a strict
priority over another, in our case, all of these have strict priority over
those queues
that are below them.
But the problem with this mechanism, as great as it is from a priority
perspective, our
voice over IP packets are always getting sent the moment they show up.
Maybe our video packets are in the medium queue.
So they're getting a wonderful amount of attention, prioritization, and amount
of bandwidth
on the link.
That's great.
The problem that we see here is the concept of starvation. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
The problem that we see here is the concept of starvation.
So we have created this problem.
We've solved one problem, created another one, and we've introduced this
concept of queue
starvation.
This low priority queue is very unlikely to ever get serviced.
That's why in this model, low priority is really meant to be that scavenger
class, like
we said, which traffic that we don't care if it ever actually makes it through.
So maybe we say, okay, that's fine then if we truly don't care whether it makes WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So maybe we say, okay, that's fine then if we truly don't care whether it makes
it through,
then it's not a big deal if it never makes it through.
Except what happens if we have so much traffic in our high and medium priority
queues that
we've just got a lot of video calls going and all of the bandwidth is being
consumed
by voice and video calls.
Well, now look at our normal traffic.
Our normal traffic is also getting starved.
This isn't just a matter of our scavenger class getting starved.
It's all of our normal internet operations, our downloads, just working with WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It's all of our normal internet operations, our downloads, just working with
applications
online, anything that doesn't fall into these categories up here is going to
face potential
queue starvation.
And so priority queuing is also not really used very often if ever in modern
networking.
Instead, what we're going to do is we're going to take the concept of a strict
priority
queue, focus in on the idea of making priority queues work out in our favor and
deploy those
in a couple of different ways as we'll see coming up in the next video when we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
in a couple of different ways as we'll see coming up in the next video when we
explore
what we do in the modern network.
Now lastly, we do have the concept of weighted fair queuing.
Weighted fair queuing, which can be abbreviated as WFQ, is a creation by Cisco
again.
The idea here is that we are going to create a massive number of queues WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
The idea here is that we are going to create a massive number of queues
automatically.
So we're going to create up to 4096 auto generated queues.
And the idea here is we're going to take every single traffic flow that comes
through the
network and we are going to place it into its own dedicated queue.
Pretty fascinating.
We're talking about 4096 on some platforms.
That many different traffic flows can be placed into their own queue.
And the idea of weighted fair queuing here, first of all, fair queuing, meaning WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And the idea of weighted fair queuing here, first of all, fair queuing, meaning
that every
single traffic or every single traffic flow is getting serviced fairly, meaning
that if
I've got, let's say, one, two, three different traffic flows, that I might have
a bunch of
packets lined up in one of the flows.
But look at this, as packets come into this other flow, I'm going to take
fairly from
each individual queue and then I'm going to go back to the top.
And that's the responsibility of the scheduler. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And that's the responsibility of the scheduler.
So it's fair, but Cisco added a little bit of weighting into it, meaning that
they're
also going to prioritize low bandwidth flows.
Now what major traffic type falls into the category of low bandwidth flows?
Well, voiceover IP certainly does.
So not only are we going to find that we're fairly balancing our traffic across WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So not only are we going to find that we're fairly balancing our traffic across
multiple
flows, but let's say this bottom flow happens to be voiceover IP traffic flow.
Well, that's going to qualify as low bandwidth and it's going to get a little
bit more love
than the other queues.
So what's wonderful about WFQ is it works really well from the perspective of
just a
very simple turn on a queuing mechanism and allow the system to do its thing.
The problem once again that we have with both of these queuing mechanisms is no WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
The problem once again that we have with both of these queuing mechanisms is no
prioritization
from the perspective that if a voiceover IP packet comes in, that it gets sent
out.
So really, we're talking about a strict priority concept.
Yes, there is a weighted concept here, but it's not prioritization.
It's not a priority queue that voiceover IP gets placed into.
So at this point, this gives us a really good foundation for some of the
struggles and trying
to come up with some good queuing mechanisms in the early days of quality of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to come up with some good queuing mechanisms in the early days of quality of
service.
In the next video, we're going to see what exactly we do these days in our
modern networks
that solve the problems that are in here and don't create new problems by
trying to solve
some of those problems.