- [Instructor] In this video,
we're going to take a look at some different Quality of service
or QoS mechanisms.
First, let's identify when or if we might need QoS.
One time we might need QoS is in a
situation like this where we have a speed mismatch.
Notice that we're coming into router R1 on a gig link,
but we're going out to the IP WAN on a fast ethernet link.
That's a 10 to one-speed mismatch.
And if traffic is coming in faster than we can send it out,
that could cause some congestion
on the output interface of that router
or maybe we don't have a speed mismatch
instead, we have an aggregation point.
Here we've got an ethernet switch
and all the ports are running at a gig speed,
but maybe we've got a bunch of servers
coming into the switch
and we're all trying to leave this server
firm on a single gig link.
We're coming in with multiple gig links
and leaving on a single gig link
that could cause some oversubscription of the bandwidth
and cause congestion even on a high-speed switch network.
The great news is
we've got some Quality of service mechanisms
that can help us out in situations like this.
However, if we're congested all of the time,
we need more bandwidth.
Quality of service is good for a periodic congestion.
Maybe there are specific times
of the day when we're congested,
maybe everybody is coming in at 8:00 a.m
and they're firing up their computers
and they're synchronizing their Dropbox accounts
and there's a lot of network traffic,
or maybe overnight we're doing a network backup
that might cause some congestion.
If we just have those periodic times of congestion,
yeah, Quality of service might help us out.
But if we're congested all the time,
we need more bandwidth
and Quality of service breaks down
into three different categories.
We have a best effort category that's not strict at all.
In fact, I even hesitate
to call it a Quality of service category
because really it's FIFO,
first-in-first-out.
The first packet that comes into the router
or switch is the first packet to go out.
There's no reordering of packets,
there's no prioritization,
it's just first come first serve.
That's best effort Quality of service.
Another QoS category we have is DiffServ.
That's less strict than our most strict
which is the bottom we'll talk about in a moment,
but DiffServ is short for Differentiated services.
This is typically what
we're going to be using in our enterprise networks.
We're going to mark traffic with a DiffServ marking.
Specifically, it's a DSCP Marking.
A Differentiated Services Code Point Marking
that's going to identify the relative level of priority
and drop probability for a packet.
There is a more strict option for QoS
and that's called IntServ
which is short for Integrated services.
The mechanism I want you to know here is RSVP.
That's the Resource Reservation Protocol
and it can make a hard
and fast reservation for an application
and it can say
that during this application nobody else is allowed
to use this bandwidth.
Even if this application doesn't need it at the moment
it's reserved.
And until that application stops
and gives that reserved
bandwidth back to the bandwidth pool,
nobody else can use it.
That doesn't really share bandwidth,
it doesn't make the most use of available bandwidth.
So typically we go with the less strict option or DiffServ.
Now let's take a look at some specific QoS mechanisms.
And the first one is classification and marking.
And Cisco says that we should classify
and mark our traffic as close to the source as possible.
As an example,
let's say that I'm going to be traveling on an airplane
and currently I've not earned a silver medallion status
or whatever they call it on Delta Air Lines.
I fly Delta a lot.
But imagine the day comes.
Imagine the day comes where I earn
that frequent flyer status
and I get to get on the plane first
and I go up to the gate agent and they say,
''Hello Mr. Wallace before we let you on the plane
can you prove that you're a frequent flyer?
Can you produce the boarding pass
from the time you went to San Jose
and to Orlando and to Austin and to Las Vegas?''
No, that wouldn't be efficient, would it?
If I had to prove myself every time I got on the plane.
So what do they do?
Well, they give me a marking on my boarding pass
that says something like a sky priority
and that tells them that I am a priority passenger.
I get to get on first.
It's the same thing with our network traffic.
Very early on in a packets travel,
we're going to recognize.
We're going to classify it
as being a particular type of traffic
and we're going to mark it.
But classification and marking by itself
who doesn't really alter the behavior of packets.
We need some other mechanism
that's going to look at that marking
and make a decision like a forwarding decision
or dropping decision based on that marking.
An example of a mechanism that can do that is queuing
which is also known as congestion management.
You might see that in the literature,
but queuing is going to influence how a router or switch
forwards packets out of an interface's output queue.
Remember when we talked
about the speed mismatch a moment ago
and we were coming into a router at a gig rate
and we're trying to leave at 100 megabits per second.
Well, what's going to happen to those packets
that we cannot send right now?
Well, that output interface
can reserve some memory called a buffer
or a queue and it can store those packets
that we just don't have bandwidth to send at the moment.
It can store those packets temporarily in that queue
and then when bandwidth becomes available
we can take the packets out of the queue
and send them on their way.
Now if we just did this on a first come first serve basis,
that would be the not strict.
That would be the best effort flavor of QoS.
However, we might want to have a little bit more control
over how packets get forwarded out of the queue.
After all, that queue is of a finite size.
It can only hold so many packets.
Imagine that we had this big data burst on the network
and we're flooding traffic trying to go out to the IP WAN
and that queue is filling up and filling up
and eventually it's going to fill to capacity.
It's going to start to overflow.
We're going to be dropping packets,
high priority packets,
low priority packets.
We're dropping everybody.
But what if we did something very simple?
Let's say that we took that output queue
and we divided it into two queues,
two sub-queues.
Maybe we're going to put Voice over IP traffic in one queue
or one bucket
and we'll put everybody else in the best effort queue
or the best effort bucket.
Now the best effort queue it might fill up,
it might overflow but meanwhile,
the Voice over IP bucket is not overflowing.
We're not dropping voice traffic
because we've done this basic queue separation.
Now in the enterprise network,
Cisco says that we should create no more
than 11 of these sub-queues.
After all if everybody is special then nobody is special.
So what we're going to do is probably create several
of these sub-queues no more than 11
and we're going to put different categories of traffic
into different cues to give us that cue separation
and we can give different bandwidth guarantees
to these different cues.
We can even say that a queue is a priority queue
and traffic in that queue gets to go first.
That's a queuing technology called LLQ
or Low Latency Queuing.
However, if we don't give priority to a queue
but we just set a bandwidth guarantee
for each of the queues,
that's called Class-Based Weighted Fair Queuing.
Those are a couple of the queued mechanisms
I'd want you to know about.
LLQ has a priority queue.
Class-based Weighted Fair Queuing
does not have a priority queue
and while queuing
can give us a minimum bandwidth reservation,
congestion avoidance is going to give us
a mechanism to prevent a queue from filling to capacity.
Bad things can happen when a queue fills to capacity.
Not only does it overflow
and start to drop high priority packets,
low priority packets,
it also causes TCP flows to go into TCP slow-start.
Do you remember how TCP works with the sliding window?
We set up a TCP session with the SYN, SYN-ACK
and the ACK that three-way handshake
and then we start to grow that window size.
I might send a TCP segment to the other side and it says,
''Okay, I got it.
Send me the next segment.''
And I say, ''Wow, that was successful.''
Instead of sending a single segment,
I'll send two segments
and I get the acknowledgment for those two segments
and I say, ''Well, let's double it again.''
Let's go to four segments and then eight,
16, 32, 64, 128, 256, 512,
1,024, 2,048, 4,096, 8,192, 16,384, and 32,768
and that's as high as I can go for memory,
but we double double double double
until there's too much time that elapses
before we get an acknowledgment
or we get an acknowledgment requesting a segment
that we already sent.
That's an indication that we're sending too aggressively
and if either of those two conditions happen,
we go into TCP slow-start
where that window size takes the precipitous drop.
It drops and we start to send traffic
at a much more conservative pace.
We'll send a little bit
and we'll wait for an acknowledgment,
send a little bit and wait for an acknowledgment.
We're not using bandwidth as efficiently.
And that's not a big deal for a single TCP flow,
but think of this.
If a queue fills to capacity
and every single TCP flow
simultaneously starts dropping packets,
you guessed it.
Every single TCP flow
is going to simultaneously go into TCP slow start.
That's a condition sometimes called TCP synchronization
or global synchronization.
What it results in
is an incredibly inefficient use of bandwidth
because everybody is going into slow start at the same time.
We can prevent that using congestion avoidance
and the congestion avoidance mechanism we typically use
on Cisco routers is called Weighted Random Early Detection
or WRED weighted red.
And what it's going to do,
it's going to set different thresholds
for different packet markings
and it's going to say
as long as the queue depth hasn't exceeded this level,
you're welcome to come in.
But if we have exceeded a level for a particular marking,
we introduce the possibility
that we might occasionally throw some of those packets away.
And the deeper the queue gets,
the higher the probability
that we're going to throw away a particular marking
and it's set up such that we'll never fill to capacity.
And the reason I have the Vulcan live long
and prosper symbol on the screen is
congestion avoidance or weighted red.
It reminds me of my favorite ''Star Trek'' movie.
It's ''Star Trek II: The Wrath of Khan.''
Back in the 80s you might remember
where Ricardo Montalban played Khan.
In that scene toward the end,
the enterprise is damaged.
Khan is about to blow them up.
So, Spock, he goes down to fix the warp drive
and he goes into this room
and he gets poisoned by the radiation in the room
and he's blind and Kirk comes down to see him
and Kirk goes up to the glass
and he says, '' Spock.''
And Spock comes to the glass
and he says, ''Ship out of danger.''
Kirk says, ''Yes.''
And they go on to have this discussion he says,
''Why did you do it, Spock?
Why did you give your life to save the enterprise?''
And I paraphrase here,
Spock said, ''Don't grieve, Admiral it's logical.
The needs of the many outweigh the needs of the few''
and then Kirk says,
''Or the one.''
Well, that's what weighted red is doing.
It realizes that the needs of the many TCP flows outweigh
the needs of the one TCP flow
and it will throw away packets from individual flows.
It'll make those flows suffer
so that everybody doesn't have to suffer.
That's what weighted red does for us.
Our next QoS mechanism is policing and shaping.
Now together these are called traffic conditioners
and they will set a speed limit on our traffic.
Unlike queuing which gave us a minimum bandwidth guarantee,
policing and shaping give us a maximum bandwidth limit.
And policing is a bit more harsh than shaping.
If we try to go above a speed limit,
called the CIR the Committed Information Rate
with shaping, shaping says,
''I'm so sorry
I don't have enough bandwidth to send you at the moment,
but don't go anywhere.
Let me temporarily put you in this queue.
And then when the bandwidth with demand dies down,
I'll take you out of the queue
and I'll send you on your way.''
So shaping is delaying traffic
when tries to exceed the speed limit.
Policing by default is much more harsh.
It is going to by default drop any packets trying to exceed
that speed limit that CIR that we've said.
Then the reason I have a bowl of soup on the screen is
it reminds me of that Seinfeld episode
where if you don't order soup correctly,
the guy says, ''No soup for you.
Come back one week.''
That's what policing does.
It says ''No bandwidth for you come back.
Literally, come back.''
Because we're causing TCP segments to be retransmitted.
So policing and shaping or traffic conditioners,
they're setting speed limits on our traffic
so we don't have a particular traffic type
consuming too much bandwidth.
And the final category is link efficiency.
In this, as the name suggests,
is trying to make the most efficient use out
of a relatively limited amount of bandwidth.
Now, to be honest,
this is not nearly as important as it was a few years ago
because now our link speeds are typically higher.
We've got gig links all over the place these days,
but if you do have some slow link speeds
you're dealing with,
then you might want to consider a link efficiency mechanism.
And what do I mean by low speed?
Well, first of all,
take RTP Header Compression.
That's one of the link efficiency mechanisms.
RTP that's the Real-time Transport Protocol.
That's what we use to send voice traffic
and also video traffic.
And if you look at the header of a voice packet,
it could be 40 bytes in size.
If we use a coder-decoder
or a codec of g.729.
That's a common codec for voice.
That's going to save bandwidth.
If you look at the header
and you add up the IP header
and the UDP header and the RTP header,
it's a whopping 40 bytes in size compared
to a payload size of only 20 bites.
That's right the header is twice the size of the payload.
That's not a good ratio.
So what RTP header compression will do
is it will make this observation.
It will say,
''As we send packets as part of the source conversation
between these two routers,
each of the headers have a whole lot in common.''
All of these headers in this flow have the same source
and destination IP addresses.
They all have the same source
and destination UDP port numbers.
They all have the same RTP payload type.
Instead of sending all that redundant information,
what they do instead is cash it.
They make a copy of it
and they put it in memory
in the routers at each end of the link
and they just don't send that information.
We'll strip off that 40-byte header on one router.
Send it over the relatively low-speed WAN link,
and when it gets to the router on the other side,
we put it back on because we've made a copy of it.
Now that we do have about two bites of header
that identifies what voice conversation this is a part of,
we don't want to get confused.
That's going to be two bytes in size
or we could use a UDP checksum
and that would make it four bytes in size.
But typically when we do RTB header compression,
we're going to have a two-byte header
instead of a 40-byte header.
By the way,
Cisco says that this is appropriate when the link speed
is less than two megabits per second.
So fairly slow WAN link speed
less than two megabits per second.
The other link efficiency tool I want you to know about
is called Link Fragmentation and Interleaving or LFI.
That's the reason I've got the tractor-trailer on screen.
Now, this tractor-trailer
it looks like it might have a couple
of trailers behind it,
but there are some tractor-trailers out there
that have three trailers behind them.
The tractor in front
and imagine that you're in your little tiny sports car
and you're behind one of these big triple tractor-trailers
and you're at a traffic light
and the light turns green
and slowly the tractor-trailer start
to go through the intersection.
The first trailer goes through
and the second and then finally the third.
By the time you get to the intersection,
the light's probably red again.
That's a lot like our voice traffic
getting trapped behind a big data packet.
For example, if we had a 1,500-byte data packet
trying to go out of an interface,
just to give you an extreme example.
If we had a really slow WAN link,
let's say 56 kilobits per second.
Just because of easy math,
it would take 214 milliseconds just for
that data packet to get out of the interface
and that would adversely delay the voice traffic
and it would give us poor voice quality
because we've got too much delay.
What we could do instead is
take that big data packet and break it up.
Going back to our tractor-trailer metaphor.
Instead of having one tractor with three trailers behind it,
what if we put a tractor in front of each of the trailers?
Now we've got three separate vehicles on the road.
We've got three separate tractor-trailer combinations
and in our little tiny sports car,
we're nimble, we're agile.
We could probably weave in and out
and get ahead of one or two of those tractor-trailers.
That's what we can do
with link fragmentation and interleaving.
We can take that big data packet
and bust it up into a little tiny fragments.
And then just like we're shuffling a deck of cards,
we could shuffle in the little tiny voice packets
in amongst the narrow fragment of data packets
and as a result our voice packets get
through the interface sooner.
Now, where does Cisco say
that we should use link fragmentation and interleaving?
It's when we have voice
or video traffic on a link speed of 768K or less.
That's pretty slow.
You probably aren't going to run into too many of those,
but if you do and if you're running voice or video,
it might benefit you to consider using
link fragmentation and interleaving.
If you use link fragmentation
and interleaving on higher speeds,
it starts to hurt you more than help you
because if you think about it,
when we fragmented that big data packet,
we had to put a header on each of those fragments.
We now have more headers than we did before.
We're actually using more bandwidth than we did before,
but it's a valuable trade-off if we're on a lower link speed
and we can get voice packets ahead of some of the traffic.
But it starts to hurt us more than help us
if we're above 768 kilobits per second.
And that's a look at some of the common
Quality of service mechanisms we have.