We need to address a problem that we have, which is that a buffer, which allows
us to fill this up with packets.
It's only so large. And so while we're trying to send the packet at the front
of the buffer, or in our case, the queue,
we might find that we're completely out of space in this queue. So keep in mind
what we've said.
A couple of key things here. First of all, QOS does not mean that there are no
drops.
So this is my does not equal sign here. Does not equal no drops. However, what WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So this is my does not equal sign here. Does not equal no drops. However, what
it does equal is that we can choose which packets to drop.
We choose the drops. And this is a really good thing, because for example, if a
packet shows up and it needs to go into this queue,
well, we can actually decide in theory whether or not to drop that packet. But
here's the catch. If I want to evaluate this packet, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
here's the catch. If I want to evaluate this packet,
let's say this is a priority packet, I want to decide whether to put it into
that queue. If this queue is full,
this means that this packet must be dropped. I don't have a choice. I can
recognize that it's a priority packet,
but if it's completely full, then it's just going to get dropped. And so when
we're talking about we choose which packets get dropped,
this key emphasis here that I want to make is on the word choose. We want to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
this key emphasis here that I want to make is on the word choose. We want to
maintain our choice. And so that's the goal of pretty much this entire skill
is to understand that we want to maintain the choice over which packets we're
going to drop. But unfortunately,
maybe I should just say for better or worse, that's going to require us to
think through situations that remove the choice from us.
And therefore, we need to find out how to avoid those situations. So let's get WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And therefore, we need to find out how to avoid those situations. So let's get
back to thinking about things from a router or switch perspective.
Let's just say we have a router here, and I've got my four different queues.
And so this is really helpful because basically what we're saying now
is that each individual queue has its own buffer size. And merely we should
think of it as packet size or byte size.
It just depends on how we want to define it. And so if I have, let's say, voice
over IP up here in this queue,
if I only have a couple of packets here, and meanwhile, my best effort down WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
if I only have a couple of packets here, and meanwhile, my best effort down
here with all of the other types of traffic,
maybe we've got a few in here for whatever these queues are doing as well. But
if this is completely full down here and a priority packet arrives onto this
device,
and it needs to get sent out to this egress interface. So remember, we're
talking about sending it out an interface.
So this packet arrives in its priority. It's a voice over IP packet. Well, this
queue down here is full, but the queue up here is not. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
queue down here is full, but the queue up here is not.
We've got all of these spots available inside the voice over IP queue. So just
having multiple queues is going to be really helpful to making sure that I don
't have to drop packets of a particular priority.
Now, if I happen to fill up this voice over IP queue, and now it is completely
full, well, at that point, we don't have a choice.
We are going to have to drop this packet. And so if those are our two
conversation points, which is one, we want to maintain as much choice as WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
conversation points, which is one, we want to maintain as much choice as
possible.
But number two, if it fills up, it's going to be dropped on the individual
queues. Is the conversation done?
Is it just a matter of, hey, if it's empty, if we have space, we're good. If we
don't have space, we're not in good shape anymore.
And the answer is no, there's going to be a little bit more to this
conversation.
Because the reality is that while we might have a priority queue up here with
voice over IP, that is maybe checking for markings EF. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
voice over IP, that is maybe checking for markings EF.
And then we have the best effort, which is sort of the catch all, but we'll say
also that it's a label of zero.
This is kind of all or nothing for these two queues.
Either a packet is voice over IP and it goes in or it's not voice over IP and
it doesn't go into the top queue and same with down here with the best effort.
But what about these queues in the middle? We might find that we have a high
priority queue in here and we're going to use that assured forwarding for. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
priority queue in here and we're going to use that assured forwarding for.
And let's say we map all of the fours in here. So for one, for two, for three,
we'll just say for X here.
So this means, actually, let's just draw those out because now we can see that
we've got AF41, AF42 and AF43.
These are three different priority levels that are all going into the same
queue.
So now what can we do? What does this mean for us? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So now what can we do? What does this mean for us?
Well, now if we have a situation where one of these packets shows up and it's,
we'll just say four packet here assured forwarding for its 4, 1, 4, 2, 4, 3,
and it's supposed to go into this queue.
If this queue is now completely filled up, we try to put it in there, it's
going to get dropped.
And if all of these were just the same priority value, that wouldn't be a
problem.
But what if we are ordering it in order of importance like this, where AF41 is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But what if we are ordering it in order of importance like this, where AF41 is
the number one most important traffic inside of that queue.
And now this is a AF41 packet that just arrived and we have a ton of 43s in
here. We're filled up with 43s.
Now we see the problem that I have this relatively, this is relative in this
case,
relative to the three different tags that could go into that queue.
This is the most important of those three, and yet I'm still going to have to
drop it because the queue is full. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
drop it because the queue is full.
If the queue is full, even if it's filled with lower priority packets, I'm
still going to have to drop this relatively high priority packet that just
arrived.
This is the problem that we want to try to avoid.
So now we see an intersection here of what we're trying to accomplish, which is
we want to maintain the choice of our drops, and yet we have a situation here
where if it's full, this means that we automatically are going to drop the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
where if it's full, this means that we automatically are going to drop the
packet.
So more or less we're saying that this situation is the problem, and therefore
we can draw a conclusion.
And our conclusion is simply that we want to make sure that a queue is never
full.
This is what we're going to try to accomplish.
And even though that seems like a lofty goal, there is a way to make it happen.
Now, unfortunately, it's not going to be just make it so the queue has an WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now, unfortunately, it's not going to be just make it so the queue has an
infinite size.
We don't want to just fill up the queue with more and more packets. In fact, if
the packet or if the queue is so full of low priority traffic, that doesn't
help our higher priority traffic anyways, and not to mention the fact that we
do have system resources involved.
So we can't just increase the size of the queue.
That's not necessarily an option, nor would it be necessarily a desirable one.
So we want to talk about the queue never being full, but before we do, there's WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we want to talk about the queue never being full, but before we do, there's
another problem that we have to address in order to see really how the solution
is going to come together.
So problem number one here, problem one, is that a full queue equals no choice.
A packets are just going to drop when they show up. But we do have another
problem in all of this.
And this has to do with TCP behavior. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And this has to do with TCP behavior.
So think about TCP, the transmission control protocol, one of the most common
layer for protocols on the Internet and in all of our networks.
TCP is a wonderful protocol because TCP adjusts itself based on congestion.
The fact that it adjusts itself means that if congestion is high, for high
congestion, we're going to throttle down our transmissions. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
congestion, we're going to throttle down our transmissions.
Where you accomplish this in a number of different ways with TCP, but
ultimately what we're saying here is if I have a computer and I'm setting a
bunch of TCP information and a couple of these packets don't make it through,
TCP says, "Ah, the packets didn't make it through, therefore there must be
congestion."
So I'm actually going to slow down my transmissions in order to make sure that
I'm not contributing to the problem of congestion. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I'm not contributing to the problem of congestion.
So that sounds good. It really is a neat aspect to using TCP on our networks.
Here's the problem. What if I have thousands of hosts?
And these hosts are all sending traffic out onto the network and a lot of them
converge through maybe a single network device, not a terribly uncommon
situation.
And so we've got this connection upstream to the Internet maybe or elsewhere in
the network and there's congestion on this link so that we're constantly having WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the network and there's congestion on this link so that we're constantly having
drops on this link because of congestion.
Well, what do these 1000 hosts do? Assuming a random distribution of dropped
packets, there's a possibility that all of them sense the congestion and so
they all throttle down their transmissions.
Well, guess what happens to the throttle down of transmissions? It means that
this congestion goes away, which is the goal, except usually we throttle down
so much that not only do we get rid of the congestion, it's now very clear link WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
so much that not only do we get rid of the congestion, it's now very clear link
.
Well, what happens at that point is all of the hosts ramp back up and now we
start to see drops again and we end up in this infinite cycle.
So what happens is our hosts ramp up, ramp up, ramp up their transmission and
because of congestion, they all of a sudden drop the amount of packets that
they're transmitting.
And then we see all of these hosts ramp up, ramp up, ramp up and we hit a
congestion point and it all drops again. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
congestion point and it all drops again.
And so if the link bandwidth is roughly here, let's say, where we kind of spike
to the max and we start having all kinds of network drops, we see that this is
not a very efficient way to send traffic in our environment.
We have a lot of wasted bandwidth in here and we'd really rather somehow smooth
this curve.
There's a word for this phenomenon. It is known as TCP global synchronization. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
There's a word for this phenomenon. It is known as TCP global synchronization.
And TCP global synchronization is caused by this problem that we're talking
about, which is that if a queue is full, then we are going to just start
dropping packets.
That's no good for anybody. If we are just dropping packets when the queues are
full and we're not dropping any packets when the queues are not full.
So what are we going to do about it? Well, let's get back to talking about our
solution.
We want the queue to make sure we want to make sure the queue is never full. So WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We want the queue to make sure we want to make sure the queue is never full. So
that number one, we have a choice over which packets are getting dropped in
number two.
We want to avoid this TCP global synchronization. The solution to both of these
problems is congestion avoidance.
Say, all right, well, let's just avoid the congestion or congestion. All right,
well, that's great. How do we go about doing it? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
well, that's great. How do we go about doing it?
Okay, well, that's an interesting question and certainly one we're going to be
talking about. But here's the answer. Here's what we're going to do.
We are going to preemptively drop packets.
We want to actually choose to drop certain packets as they come in. So as the
queue starts to fill up, I'm just going to start dropping packets.
Namely, here's my queue. It starts to fill up. And around this time, if a
packet shows up, especially if it's a lower priority, there's a percent chance WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
packet shows up, especially if it's a lower priority, there's a percent chance
that I'm going to say, you know what, there's a lot of space here in the queue.
I could easily slot this into the queue. But remember, we want to avoid a full
queue. So I'm going to drop that packet.
Now, hopefully, I'm paying attention to my relative priorities. And I'm saying
that you're a lower priority level. And so I'm going to go ahead and drop you.
I would never drop an AF-41, for example, but I might drop an AF-43 when it
comes in. And so as the queue starts to fill up more and more, now let's say WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
comes in. And so as the queue starts to fill up more and more, now let's say
that we're getting closer to being a full packet.
This percentage of drop is going to go up. And we might even get to a point
where we're dropping fully all AF-42s and AF-43s, because the limited amount of
space that's left, we really want to reserve this for the best priority, which
is AF-41 in our example.
And so if a 42 shows up, we drop it. If a 43 shows up, we drop it. The queue is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so if a 42 shows up, we drop it. If a 43 shows up, we drop it. The queue is
not full. But what we're trying to prevent is this queue filling up and making
it so we have no choice over which packets get dropped.
By doing this slowly over time, we actually find that we ramp up this TCP
transmission rate, and it makes it so it doesn't constantly sharply bounce off,
because it's no longer situation where here's where the queue is.
Here's where the queue is empty the whole time. And then the moment the queue WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Here's where the queue is empty the whole time. And then the moment the queue
gets full, we drop down. Instead, because we control the dropping of packets,
it smooths out the curve and makes it a much more efficient means of consuming
that interface bandwidth.
So from here, we're going to talk about the different techniques that allow us
to perform this congestion avoidance conversation. But we needed to start with
understanding the problem. We have two problems here. They essentially both rev
olve around the concept of a queue being full. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
olve around the concept of a queue being full.
It creates these bad situations. It creates the situation of us having no
choice. It creates this TCP global synchronization problem. And as a result, we
need to ensure that the queue is never full.
So that we can maintain our choice and smooth out TCP behavior.