All right, let's go ahead and talk through the solution here.
A lot of this is just making sure that we understand the basic concepts of what
we've
been talking about to look at a problem and recognize what exactly is the
solution or
potentially to look at a situation to understand what QOS mechanism is being
used.
So first up, our knock has noticed TCP traffic is stuck in this pattern of
going up and down.
So remember, number one here.
If we see TCP traffic doing this kind of shark fin or triangular type of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
If we see TCP traffic doing this kind of shark fin or triangular type of
approach, this is
known as that TCP global synchronization.
And we say we have two different techniques that can help with this.
They're both roughly using the same underlying process to randomly drop packets
as they come
in.
But one, random early detect is not going to look at the packet tags.
It's just going to drop whatever packets are coming in regardless of the tags
and try to
do so randomly. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
do so randomly.
And then we have weighted random early detect red with a W and that means that
we are going
to look at the tag.
So remember, both of these techniques are going to help us solve TCP global
synchronization.
Even though in the modern network, our focus is on red with a W here, we are
primarily
still going to be able to solve this problem with either one.
Now this leads us to point number two here, challenge number two, where the
organization
is mapping these three different packet tags to a single queue. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
is mapping these three different packet tags to a single queue.
So AF for X essentially, so 41, 42 and 43.
And remember, the higher priority actually exists up here with 41, meaning that
we don't
want to drop those packets.
That's typically what we're talking about with those DSCP per hot behaviors.
So what technique can be applied to ensure that we are not dropping 41 very
often?
Well, that's again, red with a W. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Well, that's again, red with a W.
The weighted nature allows us to look at it and set individual thresholds.
So now we're dropping 43 packets before we drop 42 packets and 42 before 41.
Number three, and internet circuits being upgraded.
So we have this situation, classic situation.
We've got maybe our network core, and then we're connecting up to an internet
circuit.
Maybe it's going through some firewalls, hopefully it's going through some fire
walls,
or a couple of internet routers.
But either way, we have an ISP device here. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But either way, we have an ISP device here.
We are handing off via one gigabit per second, but we have a policy that we
have to meet,
which is 250 megabits per second.
Well, if the speed is one gigabit per second, from an ISP perspective, we know
that the downstream
client could be sending us the full one gig.
And we do not want to allow that.
We want to drop anything in excess of our policy.
So this challenge question is just basically asking us from a basic perspective WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So this challenge question is just basically asking us from a basic perspective
I met,
is asking us what mechanism is being used here, what technique, and it is using
policing.
Now we don't have to go any deeper than that, but understand that we're
probably deploying
that token bucket policy, or that token bucket type of mechanism.
And we probably have the concept of conforming traffic, as well as exceeding WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And we probably have the concept of conforming traffic, as well as exceeding
traffic, where
the conform action would be to allow the traffic and the exceed action would be
probably in
this case to drop the traffic.
Now, number four, I guess I didn't write the word number three there, there we
go.
So number four, what policy can the organization use to ensure that the ISP
never drops a packet?
Well the answer here would be shaping.
So we might be getting a whole lot of traffic, I'll draw it down here again, a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we might be getting a whole lot of traffic, I'll draw it down here again, a
bunch of traffic
coming in, and maybe we want to try to send 300 meg out this link.
Well, if we can shape this, so take our 300 and shape it down to that 250, well
now this
router is never going to drop a single packet, it's just going to approve the
250 megabits
per second that's coming in, especially if we exactly match the token bucket
policy that's
being used on both sides.
Now keep in mind that this means that we have to stop, or maybe the right word WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now keep in mind that this means that we have to stop, or maybe the right word
in this
case is pause, we have to make sure we're not sending packets even though we've
got packets
ready at various times, which means on the back end here we might end up
filling up our
queues and dropping traffic.
So if the queues are filling up, this is where we rely on our random early
detects techniques
in order to make sure that hopefully we're dropping the lower priority packets
in those
queues.
So a lot of this comes together around this concept of dropping packets, just WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So a lot of this comes together around this concept of dropping packets, just
keep in
mind the very start of this whole conversation, we set our goal is to make sure
that we stay
in control of the packet drops, we want to make sure that nobody else is
dropping packets
and we are very intentionally dropping the lowest priority packets that we can,
and along
the way we manage to solve TCP global synchronization.
I hope this has been informative for you and I'd like to thank you for viewing.