Well, that basic policeor that we just described there, that is known as a
single rate two-color
policeor, which sounds a little bit fancy.
But what we're saying here is that single rate that we talked about is the
committed
information rate or CIR.
It's the only rate that we configured in our policeor policy map.
The two colors are going to be the two different statuses, which involve con
forming traffic, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
forming traffic,
as well as exceeding traffic.
Well what if we wanted a third category of traffic?
What if we said, you know, we want to transmit the conforming traffic, but we
really want
to do something in the middle besides dropping.
So we've got transmit on this side, we've got dropping on this side, but maybe
we want
something here in the middle.
Again, that idea that I could remark traffic and send it on. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Again, that idea that I could remark traffic and send it on.
Well at that point, we're going to need a third color or a third status.
And so that would be the goal here is for us to create that.
So typically what we're looking at here is creating a third class known as
violating traffic
or violated traffic either way, but this concept here is going to give us the
third color,
which typically allows us to perform our dropping traffic on the most, the
traffic that's way
outside the bounds of our configuration that would be violating traffic and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
outside the bounds of our configuration that would be violating traffic and
allow us to
deploy a remark policy here in the middle.
So again, we've got now three different statuses as well as three different
actions and so
we tend to match those up.
But how exactly do we get this third color?
Well, that's going to involve one of two options.
The first option is going to be a single rate, but now it is a three color
policeer. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
policeer.
Now both of these options, so this is the first option, we'll talk about a
second one,
both of them are going to involve a second bucket.
We're going to require a second bucket because now we're going to have to have
two different
sets of tokens.
So here's our BC bucket, our committed burst, and now we're going to have
another bucket
here known as BE, which stands for excess burst.
So in this case, we still have a single rate, we have our CIR, and that is the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So in this case, we still have a single rate, we have our CIR, and that is the
rate at which
we fill up the BC bucket.
Now in a, up here with our basic policeer, if we have the bucket and our CIR
here and
tokens are flowing into the bucket and this bucket is full, well the next token
to try
to come in here is just going to get dropped.
We don't get to keep additional tokens.
We defined the size of the bucket and we can't store more bites than what is
sitting inside
of that bucket.
So that's the downside to the single rate two color policeer or one of the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So that's the downside to the single rate two color policeer or one of the
downsides.
So our BE, what we're going to find is when the bucket is full, we're actually
going to
overload or take those tokens and put them into the BE bucket and be able to
fill up a
second bucket.
So now we have two different bucket types.
And so now we have to think about what happens in different scenarios.
First scenario is a packet comes in and there's enough tokens in the BC bucket. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
First scenario is a packet comes in and there's enough tokens in the BC bucket.
So we use the BC token or sets of tokens if they're there, the BE is sort of
like a backup.
So we're not going to use that if we don't have to.
And this means that we are a conforming packet.
What if however, BC is empty.
So there is no BE token.
And so we take a BE token instead that excess burst.
From now we're going to classify this as an exceeding traffic. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
From now we're going to classify this as an exceeding traffic.
And lastly, there's no or at least not enough tokens in the BC bucket.
There's not enough tokens in the BE bucket.
Remember each token actually equals one bite.
So it depends on the size of the packet of course.
And so in this case, it becomes a violating packet.
So what actions do we take?
Well we get to configure the actions ourselves.
I as the admin decide on the actions. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I as the admin decide on the actions.
But typically what we're going to do is what we said up at the top.
I'm going to transmit.
For conforming, I'm going to remark for exceeding and I'm going to drop for
violating.
Now could I remark harsher on violating?
Absolutely.
I could do that.
I'm going to drop exceeding and violating then why am I running a three color
beleaser.
So chances are this is probably what we're looking at in the real world. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So chances are this is probably what we're looking at in the real world.
So this has an advantage.
It allows me to burst additionally.
So before with the two color, it's sort of like this.
If I am transmitting up to the CIR amount, then that's great.
Everything is fine.
But everything over here, this is conforming and this is exceeding.
And now we sort of have this CIR and everything is conforming up into this.
But then we have this little bit of burst amount here that is exceeding before
we get WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we get
into the violating section.
And this exceeding is based on the number of bits or bytes that can store up
here.
Now if we think about this overflow mechanism like this, there is a flaw to
this strategy
which is that if the BE tokens are completely used up, then the CIR is first
filling this
bucket.
And so for a time, potentially an extended time, we might not have anything in
the BE
bucket. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
bucket.
Because we have to wait for this bucket to completely fill up and then overflow
into
the second bucket.
So if we have that CIR of 600 megabits per second and we might need this to
truly back
down to a very low amount, like 400, 300 megabits per second for a very
extended time, or we're
never going to see the BE bucket fill back up.
So that is the downside to the single rate CIR, single rate three color WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So that is the downside to the single rate CIR, single rate three color
solution.
Well we do have another option here.
And that would be option number two, which is the dual rate three color police.
Well, we know what the three color means.
We're going to get our three different statuses for the packets potentially.
But now we have two different buckets still, BC and BE.
But there's no overflow concept.
Instead, I'm going to take my CIR and I'm going to fill this bucket with tokens WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Instead, I'm going to take my CIR and I'm going to fill this bucket with tokens
at a
particular rate.
And then I'm going to take a different type of rate, the PIR.
This is the peak information rate.
And I'm going to fill this bucket at the PIR.
So for example, I can say that, hey, you know, we're trying to still keep
everything WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
everything
within 80 kilobits per second here.
But I'm going to set a PIR of 100 kilobits per second.
And now all of a sudden when we think about this type of diagram, now we have a
CIR here
and a PIR up here.
So it's no longer based on the bytes.
This concept here was more of a byte concept for how much data I can consume.
Well now we actually have two different rates, this 80K limit and this 100K WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Well now we actually have two different rates, this 80K limit and this 100K
limit, at which
point we have conforming traffic, exceeding traffic and violating traffic.
We're trying to lock it down to a rate rather than so many bytes that again
might take
a long time for me to recover from.
Now here's what's interesting about this.
We noticed that we're filling this bucket at 80K, this bucket at 100K.
So do I get 180 kilobits per second of throughput?
Well that doesn't really match what I'm doing here.
I'm trying to hit 80K and then it's exceeding up to 100K and then it's WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I'm trying to hit 80K and then it's exceeding up to 100K and then it's
violating past 100K.
So no that's not the case but how do I recognize that I'm filling this bucket
up at 80 and
this bucket up at 100 and not add them up?
Well that has to do with how we consume our packets.
So once again we have our packets coming in and if a packet comes in it's going
to attempt
to consume both bucket types at once.
In other words I have to have enough tokens in BC and BE in order for this to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
In other words I have to have enough tokens in BC and BE in order for this to
be a conforming
packet and I will consume tokens from each as a result.
Meanwhile if I don't have BC but I do have BE tokens, well now that falls into
the exceeding
category and naturally if I have neither of these BC and BE.
So no BC and no BE this would be violating traffic.
So likely we're going to take the same actions and apply them here. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So likely we're going to take the same actions and apply them here.
Again we are in full control of those actions we can configure those but in the
real world
that's typically what we're going to end up matching with.
But do recognize in this dual rate three color policeor that one packet is
going to consume
both of these tokens at the same time whereas with our other model over here we
're really
only consuming either BC or we're consuming BE. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
only consuming either BC or we're consuming BE.
We're not consuming both at the same time.
So this allows us to ultimately establish this.
I mean our takeaway from this conversation is really what is the goal of these
policeors.
The goal of the policeors are to allow us to burst above a certain amount.
In this case with the dual rate it allows me to define that rate as sort of a
sliding
scale to say that again everything up to 80k is treated one way and then
everything up
to 100k is treated another way and then everything over 100k is probably WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to 100k is treated another way and then everything over 100k is probably
dropped at that point.
That's what we're trying to accomplish here.
Whereas again CIR, single rate options, yeah we store up some amount of bytes
here in the
middle but that can be tricky for us to recover from although it doesn't and
again it doesn't
make it clear what we can burst up to just however many bytes we can kind of
store up
for a rainy day.
And of course the basic one up here there is no such conversation.
It really is just this conversation. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It really is just this conversation.
The left of that line is what this is here.
So we got lots of options.
just go ahead and jump to the CLI and see how we can configure these.