So how do we perform this congestion avoidance?
Well we have a few mechanisms available including the default of tail drop.
Now this tail drop conversation is going to echo the conversation we had
earlier about
the idea that FIFO is a queuing mechanism.
Technically first in first out is a queuing mechanism but it's the default and
it's terrible
and it's why we are trying to solve the problems that we create or solve the
problems using WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
problems using
techniques such as CBWFQ and our LLQ.
So tail drop is going to be the same way.
It's our default operation and it's also terrible.
It presents to us all the problems that we're trying to resolve.
So for example, tail drop allows for a full queue.
The reason why it's called tail drop is because we're going to fill up our
queue all the way
and then the packet that we're dropping is the last packet to arrive. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and then the packet that we're dropping is the last packet to arrive.
This packet might be a very high priority packet, it might be a very low
priority packet but
we understand that this is going to be a problem if we allow it to be used and
keep something
in mind in all of this.
The tail drop can be applied to a FIFO queue and it can be applied to
individual queues
within class based weighted fair queuing.
In fact we specifically said that with class based weighted fair queuing we're
going to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
going to
have multiple queues and each one of these is going to run its own tail drop
mechanism
because it has its own FIFO queue.
So keep that in mind that these concepts sort of stack.
So each one of these is running FIFO.
Now we did say that the best effort queue might run WFQ, weighted fair queuing
but each one
of those flows is going to be in a tail drop type of queue.
So just saying that the default doesn't mean that once we enable CBWFQ that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So just saying that the default doesn't mean that once we enable CBWFQ that
tail drop goes
away, it actually is going to be applied to each of our individual queues
within that
policy and yes that does include the low latency queue if we build one on top
of all
of this.
It's still FIFO and the default is tail drop.
Now the method for each individual queue is, well I should say these are locked
in.
The FIFO is locked in, weighted fair queuing we can actually change this WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
The FIFO is locked in, weighted fair queuing we can actually change this
between that or
FIFO for best effort.
So we do have a choice there but by and large they're locked in.
These here are going to allow us to select options and we are absolutely going
to want
to explore these options because keep in mind we have the two issues that we're
trying to
address.
One we have the issue of choice and two we have the issue of TCP
synchronization.
So both of these continue to apply with tail drop, in fact tail drop is the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So both of these continue to apply with tail drop, in fact tail drop is the
cause of both
of these issues.
So solution number one.
We have a congestion avoidance technique known as random early detect which is
abbreviated
as red, R-E-D.
Random early detects function is right there in the name.
We are going to perform a random evaluation and early detect the packets that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We are going to perform a random evaluation and early detect the packets that
are arriving
and decide whether or not to drop those.
Again, based on the random chance.
So the idea here is sort of what we said earlier in the last video.
I'm going to have a queue and this queue is going to be running first in, first
out within
the queue.
It can be one of these individual queues for example.
And then we're going to set a threshold here for when we are going to start to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then we're going to set a threshold here for when we are going to start to
randomly
drop traffic.
So let's just say that at 50% full we're going to start to randomly drop
traffic.
As the queue gets higher and higher or fuller and fuller, more full, we're
going to start
at a 0% chance of dropping traffic and we're going to ramp up to more or less a
100% chance
of dropping traffic.
I mean eventually we do still have to perform tail drop because packets can
show up if the
queue is full. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
queue is full.
Those are getting dropped and it's not ideal but if the queue is full we don't
have a choice.
So we're going to ramp this up over time.
So as packets are showing up, they're just going to get slotted right into the
queue without
any kind of evaluation.
But now a packet has arrived and we have reached our threshold.
The queue is 50% full.
What are we going to do?
Well, we're going to roll the dice.
We're going to perform a little bit of a probability game.
So we're going to say that, you know, let's give it a 2% chance of getting WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we're going to say that, you know, let's give it a 2% chance of getting
dropped.
We look at this spot right here on our chart.
We're going to say that's a 2% chance of getting dropped.
Probably it's going to make it into the queue.
Well what happens when the next packet arrives?
Well the next packet is going to have to go here and we see that the chance of
dropping
this packet is increased.
Maybe it's up to 10% by the time we get here.
So now we're going to run a 10% chance to drop it. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So now we're going to run a 10% chance to drop it.
Roll the dice, see if the packet makes it in.
Maybe this one makes it in as well.
Well now we start to get a little more serious.
Now there's a 20% chance or a 50% chance or a 75% chance of dropping this
packet.
Eventually we're throwing packets into this queue and we're dropping every
other one.
We drop this one, we allow this one in, we drop this one and so on and so forth
.
We might even be only allowing one in every 5, 6 or 7 packets.
Only one of those makes it in. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Only one of those makes it in.
And so what's going to happen here is as fast as we fill this up, we're going
to start
to slow down as we add packets here.
So I finally make a lot of packet in.
Then I drop another packet.
I drop another packet, I drop another packet.
Ooh now I'm going to add a packet.
And so we do continue to increase the amount of packets here inside of this
queue.
However, we're doing it much more slowly because we are randomly dropping
packets as
they arrive on that interface. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
they arrive on that interface.
So that's the concept of random early detect.
Do we see a problem though with random early detect?
What's something, an important mechanism that we have yet to bring up as part
of this design?
Well we haven't considered the tag.
These tags over here, we've got this probability increase, is completely
ignoring the tag.
So this packet that was allowed could be an AF41, actually that could be an AF
43 which
is actually a lower priority than AF41 which is a higher priority. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
is actually a lower priority than AF41 which is a higher priority.
So the AF43 could have been allowed, AF41 could have been dropped using random
early detect.
So we need a little bit better of a solution.
However, before we move on to the next solution, do notice one thing here that
random early
detect is absolutely going to help with TCP global synchronization.
Because what we've done here is we have smoothed out the drop rate. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Because what we've done here is we have smoothed out the drop rate.
So it's not just 100% transmissions, the whole way and then all of a sudden it
drops
to zero.
Essentially, the graph for that would look like this.
Zero percent for the entire time the queue is building up and then all of a
sudden it's
100%.
Instead we are ramping this up such that our drop rate isn't going to fall into
the trap
of being all or nothing. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
of being all or nothing.
So global synchronization, hey we've got a solution for that, it's random early
detect.
And so this problem is solved.
But our choice in the matter is not actually solved.
We're not choosing whether or not to drop specific packets.
So now let's move on to the next solution which is known as weighted random
early detect.
Otherwise known as red with a W I guess. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Otherwise known as red with a W I guess.
I don't know, it's kind of interesting.
We have red here, we have red here, the W is silent in the English language.
Yeah, we don't do ourselves any favors with these acronyms.
So be careful with what we're talking about.
I will say in the modern network we almost never deploy legacy random early
detect the
special ancestor devices.
We're almost always deploying the weighted random early detect.
So now what we're going to do is we're going to have our queue length here. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So now what we're going to do is we're going to have our queue length here.
And instead of creating this graph for all packets, we're going to do it on a
weighted
basis.
This is going to be per tag.
So let's once again look at our AF 41 AF 42 AF 43.
Now recall what we said.
This first number is supposed to be the priority level four is a very high
priority.
The second number is a drop per probability or drop percentage type of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
The second number is a drop per probability or drop percentage type of
conversation.
And what's interesting here is that a 41 is actually the most important one
because we
actually increase the drop percentage or the drop probability as we increase
that second
number.
So even though a 41 is better than a 31 because four is greater than three.
Unfortunately 41 is a better priority than 43 because one is less than three. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Unfortunately 41 is a better priority than 43 because one is less than three.
Yeah, I know it gets a little bit backwards in there, which is unfortunate.
But keep in mind that the priority value increases like this.
We want to think of it truly in terms of number one, number two and number
three that
that's the consideration we should make here.
So in most situations, we have three different types of traffic entering into
the single
queue.
And so a packet could be arriving from all of these at any given time. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so a packet could be arriving from all of these at any given time.
A 41, 42 or 43 in our example.
So what we're going to do is we're going to again create a per tag chart for
drop probability.
So let's just start with let's say AF 43, which is the most likely to drop.
So let's say that we make it to about that 50% mark again.
And then we ramp it up to 100% there at the very end of the queue. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then we ramp it up to 100% there at the very end of the queue.
So if a pack if our queue, let's say is completely full.
Well not completely full, but it's filled up to 50%.
And a packet arrives for AF 43.
Maybe we'll even throw another packet in here.
Well now if it's going to consume this slot, we're going to see that we have a
percentage
of maybe 10% that this packet gets dropped.
Kind of interesting.
So that would be for one of our tags. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So that would be for one of our tags.
Now the next tag is going to be for AF 42.
And AF 42 is going to come to about 75% let's say, and then ramp up a little
bit sharper.
Both of these end up at 100% because once we get to a full queue size, then we
don't
have much of a choice anyways.
But notice that if a 42 packet shows up and it's going to go here now in that
same spot, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
same spot,
we said that maybe it was a 10% chance of getting dropped at that point for the
AF 43
packet.
But notice this is still at 0%.
We haven't started increasing the drop probability for AF 42.
So now AF 42 is not going to start dropping unless the queue is 75% full.
And lastly, as we might imagine, AF 41 has the best deal of all.
And we are not going to drop this almost never or will probably still do some WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And we are not going to drop this almost never or will probably still do some
amount of random
dropping there at the end, let's say 90%.
And there's still value there because we're still trying to prevent TCP global
synchronization,
even though we are talking about the most important packets that could show up
in that
queue.
So there might still be a ramp up at 90%.
But for the most part, if a packet that is marked with AF 41 is arriving, it's
almost
always going to go in because no matter where in this queue we are, unless it's WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
always going to go in because no matter where in this queue we are, unless it's
very, very
full, we're going to find that we have a very low drop probability.
Most often it's going to be a 0%.
So that's the idea of weighted red.
We create a per tag drop probability, typically using our pH B's, our per hot
behaviors for
DSCP over here, understanding that the higher the number in here, the greater
the increase
in drop probability.
So we need to focus on that. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we need to focus on that.
But by creating these three different drop probabilities for our three
different values
that show up within one of our queues, now we are no longer using tail drop.
But instead we are solving global or TCP global synchronization by smoothing
our drops.
And because we're considering this on a per tag basis, we are maintaining our
choice and
we are trying to make sure that we are never sliding in a low priority packet
instead of
a high priority packet.
We always want to drop the lower priority ones in favor of the higher priority WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We always want to drop the lower priority ones in favor of the higher priority
packets.