So when we're talking about weighted random early detect or W-red, red with a W
, everyone
is saying this, we know that as a queue gets filled up, so the queue fills, and
we want
to start randomly performing drops.
Now the random drops on its own, this helps prevent that global TCP
synchronization issue.
So we want to prevent global sync, and we can do that without the waiting. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we want to prevent global sync, and we can do that without the waiting.
We can do that without paying attention to the DSCP tags.
But naturally the W in weighted random early detect means that we're going to
pay attention
to the tags.
The tags are going to matter, and as a result if we have multiple tags within a
single
queue, those random drops, the odds of dropping a packet, will be dependent on
the tag.
And we're especially going to be paying attention to the per-hot behaviors WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And we're especially going to be paying attention to the per-hot behaviors
within assured forwarding.
Because that second number, technically here, so AF, if we have XY, this Y is
meant to represent
the drop likelihood, where one equals a low percent chance, two equals a mid
percent chance,
one three is a higher, or maybe just at least the highest percent chance, that
a packet
gets dropped.
And this is up to us to configure. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And this is up to us to configure.
This isn't something that just automatically happens on a Cisco device, we have
to configure
it.
And so now's the time for us to start to explore how red configuration, or W-
red configuration,
comes together.
Now there's going to be a few important aspects to this.
First and foremost, we're going to need to configure thresholds.
And we're going to be configuring two different thresholds, we're going to be
configuring a
minimum threshold, and a maximum threshold. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
minimum threshold, and a maximum threshold.
Up until the minimum threshold, we're going to have a zero percent packet drop.
And from the maximum on, we're going to have a 100 percent packet drop.
So these thresholds are very important.
Now what happens in the middle is a little bit of a conversation we're going to
have.
It's a linear increase in percent chance of getting dropped as a packet comes
in.
And that percentage is going to be based on a couple of factors. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And that percentage is going to be based on a couple of factors.
And we'll get into exactly how that works here momentarily.
The other thing we need to consider is the queue size.
Because we might say that, okay, I want my minimum threshold to be when the
queue is,
let's say, 60 percent full.
Unfortunately for us, this is not how Cisco allows us to configure the minimum
threshold.
The minimum and the maximum thresholds, these are configured as a packet count. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
The minimum and the maximum thresholds, these are configured as a packet count.
And so the size of the queue is going to matter.
For example, a lot of Cisco devices have a default queue length of 40 packets.
So if I do want the minimum to start at, let's say, 60 percent full, well 60
percent full
on 40 is going to be 24 packets in size.
10 percent of 40 is four. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
10 percent of 40 is four.
So four times six would give us a 24.
So that's our math there.
That's 60 percent full when there's 24 packets in the queue.
And let's say we want the maximum here to be at 80 percent.
Well using that same math four times eight, that would be 32 packets.
So our thresholds would be established as a number of packets in the queue.
And so we'd say maybe 24 and 32 as the minimum and maximum thresholds. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so we'd say maybe 24 and 32 as the minimum and maximum thresholds.
So it's zero percent drop until we get to 24 packets in the queue.
And then while there's between 24 and 32 packets, we're going to be increasing
with every packet
that's in there.
You know, if there's 25 packets in there, it's a lower percent chance.
But if there's 30 packets in the queue, it's a pretty high percent chance
because it's
linearly increasing during that middle stretch.
And then once we hit 32 packets and above, we're just going to drop every
single packet
that comes in for this specific tag. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that comes in for this specific tag.
Again these thresholds are based on the tags because that is the entire purpose
of weighted
random early detect.
Now one other important aspect to this threshold concept.
When we're talking about packets in the queue, it's easy to think, okay, the
queue has exactly
25 packets in there and therefore we're in the middle of that range, something
along
those lines.
Well, we need to understand that Cisco's calculation is actually not going to
look at WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
look at
the number of packets in the queue, but it's actually going to look at the
average number
of packets that have been in the queue.
And so that is just a little bit of extra information for us to recognize that
we might
be, if we're really zeroing in and looking at debug and such, we might not
quite see
that things are lining up exactly how we want.
Well, that's because Cisco is taking an average of the packet count over time
and matching
our thresholds up with the average, not the raw number of packets that are in WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
our thresholds up with the average, not the raw number of packets that are in
the queue
at any moment in time.
And this allows the system to sort of absorb burstiness.
If the queue spikes up to 33, 34 packets and then immediately gets cleared out,
well,
we don't necessarily want to drop packets that are coming in, we're going to
hope that
that clears up.
And the average gives us a little bit more of the ability to absorb those types
of sharp
increases.
So now let's zoom in a little bit on this linear increase. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So now let's zoom in a little bit on this linear increase.
So we're going to have a chart here.
We're going to say we've got a 0% chance of dropping and 100% chance of
dropping.
And let's say this is for a particular tag, AF 23.
So the three here means it should have a high drop percentage.
And so down here, we're going to chart this out over the course of the packets
in the
queue.
And let's just use this 24 and 32. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And let's just use this 24 and 32.
So somewhere over here, we've got 24 packets and then we've got 32 with the max
being 40.
Down here is zero packets.
So we know that as we chart this out, that we're going to be at 0% until we get
to that
minimum threshold.
And then once we get to the maximum threshold, we're at 100% drop.
So our inclination might be to think that, okay, over the course of time, we're
actually
going to increase this linearly until it gets to 100%. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
going to increase this linearly until it gets to 100%.
Well, believe it or not, that's not actually how it works.
There is going to be a slope concept here where, yeah, that was a very sharp
slope.
But we actually have control over the slope.
So we might actually do something like this, where we have a very shallow slope
.
And then once we get to that 32, all the way up to 100% at that point, which
means maybe
we only actually had a 10% chance of dropping packets leading up to that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we only actually had a 10% chance of dropping packets leading up to that
maximum threshold.
Why would we go about doing this?
Why wouldn't we just linearly increase it to 100%?
Well, the reason we might do this is because if we think about sharply
increasing it up
to 100% over the course of just what are we at?
Eight packets from 24 to 32?
Well as every packet lands in the queue, we're jumping up to 10, 20, 30%
chances of dropping
packets, which means we are guaranteed to be dropping packets more or less. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
packets, which means we are guaranteed to be dropping packets more or less.
Statistically speaking, if I'm at 50% packets and I get three packets in, I'm
probably dropping
at least one of those.
So what we're trying to do here is prevent dropping packets during those burst
iness.
Again, we're doing some things here to prevent a burst of packets that doesn't
ultimately
cause tail drop, doesn't shoot us up to 40.
It just shoots us up into that range, that higher range, and we want to try to
absorb
that a little bit.
So we have average packets in the queue that's going to absorb that a little WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we have average packets in the queue that's going to absorb that a little
bit.
And now we have a more shallow slope, so we're not as likely to be dropping
packets.
But eventually we do need to start dropping those en masse.
And so again, it's AF 23, it's a high prior or high possibility of dropping
those packets
relative to the other tags in that queue, assuming the AF 22 and AF 21.
But so we are going to eventually drop those packets, but we don't necessarily
need to
scale this up at a very sharp rate. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
scale this up at a very sharp rate.
So the question is, how exactly do we define this slope?
Well, the slope is going to be determined by a concept known as the mark
probability.
And this mark probability essentially defines the slope for us.
Now it's not, if we get into our algebraic math, it's not actually literally
the slope,
but it does define this number.
What is the maximum percent chance that we're going to drop a packet, which if WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
What is the maximum percent chance that we're going to drop a packet, which if
I say 10%,
okay, well, that's a pretty shallow amount.
If I were to say, I want to go to 50%, well, that's going to be a sharper
amount, but still
not quite up to 100%.
And so the slope of the line is going to be dependent on this mark probability
concept.
So how do we define the mark probability?
So we're going to use the configuration of the mark probability denominator. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we're going to use the configuration of the mark probability denominator.
So let's look at a little bit of math here.
Let's say I wanted to do 10% at the maximum drop, or as the maximum drop
percentage for
this particular situation, basically exactly what we had drawn out up here.
How would we do this?
Well 10% is 0.1, it's just decimal math, says it's 0.1, and another way of
expressing that
is 1/10. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
is 1/10.
So this is the mark probability.
So what's the mark probability denominator?
Well, if we think about math terms, the denominator is the bottom of the
fraction there, and so
the MPD is 10 in this case.
Well what if we wanted a 25% chance of dropping it?
Well 25 is 1/4, which means that the MPD is 4.
And we could go up to 50%, and that's 1/2, and that's an MPD of 2. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And we could go up to 50%, and that's 1/2, and that's an MPD of 2.
And if we really wanted to get that super sharp increase to go to 100%, well
that's
1/1, which means our MPD is 1.
So the way that we configure this slope is by configuring the MPD.
And we'll see that here coming up with our configuration.
In the end, when we configure our weighted random early detect, we have to do a
few things.
First of all, we have to enable it, and we'll see how we do that coming up. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
First of all, we have to enable it, and we'll see how we do that coming up.
Second of all, we have to define the minimum and maximum thresholds, and that's
in terms
of packet count, not in terms of Q percentage, but the number of packets based
on the average
here.
And then we also have to specify the mark probability denominator.
In a lot of cases, we might choose something like 10 or 4 or 3 would be a 33%
chance, those
kinds of things.
We've got a lot of options in here, but we do need to understand what that map WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We've got a lot of options in here, but we do need to understand what that map
means.
So I can't just say MPD of 10, and I'd have no idea what that means.
No, that means 10%, whereas a 4 would mean 25%.
But we do have to specify the mark probability denominator when we are config
uring weighted
random early detect.