|
0:00:13
|
Okay, so let's take a look now at quality of service primer.
|
|
0:00:18
|
And as I mentioned before, we're not gonna go very deep in the quality of service at the CCNA voice level.
|
|
0:00:24
|
We certainly will go very deep in the quality of service at the CCNP voice level.
|
|
0:00:29
|
But we do need to be familiar with some of the basic topics
|
|
0:00:33
|
and some of the basic concepts of quality of service for the CCNA voice exam.
|
|
0:00:40
|
So, to begin with, as we just previously mentioned,
|
|
0:00:43
|
packets switch networks have a few inherent problems.
|
|
0:00:47
|
And we mentioned the disadvantages for those could be solved with quality of service.
|
|
0:00:52
|
So, the ITU recommends in the G.114 specification,
|
|
0:00:58
|
hopefully you won't have to remember that possibly but I doubt it.
|
|
0:01:03
|
It's not like one of the codecs or signaling protocols that you'll need to remember the acronym for.
|
|
0:01:08
|
But they specify delay or latency should be less than or maximum equal to 150 ms
|
|
0:01:17
|
one way or in each direction.
|
|
0:01:20
|
So, a total of 300 ms roundtrip.
|
|
0:01:23
|
And delay for voice is really calculated in single direction.
|
|
0:01:29
|
Now, this is not the same as a simple ping test with the roundtrip
|
|
0:01:33
|
of greater than or equal to, I'm sorry, less than or equal to 300 ms.
|
|
0:01:38
|
Because there are a number of other things that take place in a voice network that don't take place in a simple ping.
|
|
0:01:45
|
So, if you can ping and you have 120 ms roundtrip, you think you're great,
|
|
0:01:51
|
it doesn't necessarily mean that voice will have the same quality or the same allowance in terms of delay.
|
|
0:02:00
|
We already mentioned that jitter was the difference between the delays or latencies
|
|
0:02:06
|
as it varies from hop-to-hop.
|
|
0:02:08
|
And jitter needs to be less than or equal to 30 ms.
|
|
0:02:14
|
So, in other words, I can't have one router hop that from me to let's say router 5 is 20 ms
|
|
0:02:22
|
and for me to router 6, the very next router is 80 ms, that's gonna be a big jitter difference.
|
|
0:02:31
|
And normally, that doesn't happen but it needs not to.
|
|
0:02:35
|
G.114 spec also specifies that packet loss be less than or equal to at max 1%.
|
|
0:02:44
|
And so the bandwidth for the voice and video for the real time protocol is subject to a number of things,
|
|
0:02:51
|
like I said more than just ping.
|
|
0:02:52
|
So, codec, the sampling involved in that, the quantization, all the PVDM and DSP,
|
|
0:03:04
|
compression, the Layer 3 and Layer 2 overhead have to be accounted for.
|
|
0:03:09
|
The bandwidth or the signaling really depends on the protocol.
|
|
0:03:15
|
And for the given protocol, most signaling protocol are somewhere between 150 bits per second and 1 kbps.
|
|
0:03:23
|
So, very, very low bandwidth for signaling compared to the actual voice or video RTP.
|
|
0:03:32
|
When we're talking about bandwidth for video, we should always have about 20% additional overhead
|
|
0:03:38
|
or various things like key frames where the entire picture is sent rather than just a portion of the picture,
|
|
0:03:45
|
such as H.264 has B and P frames
|
|
0:03:49
|
and basically deal with predictive frames and pixel differentiation from the last frame.
|
|
0:03:54
|
But every once in a while, there needs to be entire frame, every pixel in the frame sent, that's known as the key frame
|
|
0:04:01
|
and another various factors we should always have about 20% overhead.
|
|
0:04:06
|
Now, there are three basic types of quality of service models.
|
|
0:04:11
|
The first is basically no quality of service at all.
|
|
0:04:14
|
Okay? It's best effort.
|
|
0:04:16
|
So, basically, first in-first out or FIFO.
|
|
0:04:20
|
The next and this was used a lot more earlier on
|
|
0:04:25
|
was known as IntServ or Integrated Services.
|
|
0:04:29
|
And this definitely gave guarantee bandwidth for voice and signaling
|
|
0:04:32
|
using something called RSVP, the Reservation Protocol.
|
|
0:04:36
|
Now, we'll look more at this as I mentioned in the CCNP Voice and we'll look at RSVP and actually even use it,
|
|
0:04:46
|
but it won't be used with something called IntServ, Integrated Services.
|
|
0:04:50
|
And the reason was in order for Integrated Services to work as a quality of service model,
|
|
0:04:56
|
it really had to be enabled and properly configured on every Layer 3 device,
|
|
0:05:02
|
so every router in the path of a Voice over IP call.
|
|
0:05:05
|
And this is really isn't practical especially with today’s modern MPLS Layer 3 networks.
|
|
0:05:11
|
We can't and shouldn't count on the carrier, running RSVP that's gonna honor our QoS markings.
|
|
0:05:20
|
Now, they may in a sense but it's gonna be handing off to MPLS marketing, which is quite a bit different.
|
|
0:05:26
|
So, we will look again in the next class at RSVP
|
|
0:05:32
|
but we'll look at it decoupled with IntServ.
|
|
0:05:35
|
So then came along Differentiated Services or DiffServ.
|
|
0:05:40
|
This gave guaranteed bandwidth for voice and signaling,
|
|
0:05:43
|
and we classify different types of traffic such as media signaling traffic, inter-cluster communication,
|
|
0:05:51
|
and even just regular bulk data or other types of data.
|
|
0:05:56
|
Be it oracle or SQL or some other important e-mail or something on your network into these different classes.
|
|
0:06:06
|
And then, we use policies to ensure that these differentiated classes
|
|
0:06:10
|
received their various levels of priority and bandwidth servicing as required.
|
|
0:06:19
|
Now, these are what are most, or Differentiated Services is what's most commonly used in enterprise networks.
|
|
0:06:25
|
And it does not have to be enabled on every router.
|
|
0:06:27
|
I'm not saying it shouldn't be. It should be but
|
|
0:06:30
|
it doesn't to be in order for the protocol, or in order for
|
|
0:06:35
|
the Quality of Service mechanism as a whole to work like it did have to be with Integrated Services.
|
|
0:06:42
|
So, looking at DiffServ QoS mechanisms,
|
|
0:06:45
|
first of all, we need to classify and mark our traffic.
|
|
0:06:50
|
Now, depending on what we're looking at, maybe the phones do that for us automatically,
|
|
0:06:55
|
maybe the service do that for us automatically,
|
|
0:06:57
|
but we need to classify the traffic and we need to have it marked appropriately.
|
|
0:07:02
|
And so, we also, after that, we're gonna deal with various queuing and dropping mechanisms.
|
|
0:07:10
|
So, it's important to queue less prioritized traffic behind more prioritized traffic,
|
|
0:07:18
|
and get the more prioritized traffic out the door first.
|
|
0:07:21
|
So, things like voice and video,
|
|
0:07:23
|
we need to make sure that we get those and schedule those out the door first.
|
|
0:07:29
|
And in terms of dropping,
|
|
0:07:32
|
so, we're gonna queue less prioritized traffic but we may actually want to drop certain types of traffic.
|
|
0:07:37
|
There might be traffic that is what's known as scavenger.
|
|
0:07:40
|
It's traffic that we classify however we want, any type of traffic that we don't want out network
|
|
0:07:47
|
whether it's peer to peer traffic, whether it's obviously virus or worm type traffic.
|
|
0:07:54
|
Anything that we classify that we don't want, or possibly that we don't just want as much as of.
|
|
0:07:59
|
So, it might be necessary to drop certain types o traffic in times of congestion
|
|
0:08:05
|
in order to favor other types of traffic getting through smoothly.
|
|
0:08:10
|
And then, we finally have link specific mechanisms.
|
|
0:08:13
|
So, we're going to process our information and send it out accordingly.
|
|
0:08:17
|
And we do things like traffic shaping here,
|
|
0:08:20
|
we may do things depending on our link type, like fragmentation,
|
|
0:08:24
|
we may actually compress headers or even the entire payload,
|
|
0:08:30
|
and then, we have our final hardware queue, something known as the transmit ring.
|
|
0:08:38
|
So, Quality of Service mechanisms, where do we apply these various mechanisms?
|
|
0:08:43
|
Classification and marking should always be performed as close to the source as possible.
|
|
0:08:48
|
So, the question you need to ask is what device that first astute at the edge
|
|
0:08:54
|
that you have administrative control over?
|
|
0:08:56
|
And if you don't have administrative control say, over the switch that the phones are connected to,
|
|
0:09:03
|
maybe not even faster router, but somewhere down the line, at some point, you have administrative control.
|
|
0:09:10
|
Obviously, hopefully, we have full administrative control of our networks,
|
|
0:09:13
|
and we can do the classification out at the edge, at the actual access layer or switches.
|
|
0:09:20
|
But if we don't, then, we need to decide where do we have administrative control,
|
|
0:09:27
|
and there, we will draw what's called a trust boundary.
|
|
0:09:29
|
So, basically saying, anything before I have control over,
|
|
0:09:34
|
I'm not going to trust. And on that ingress,
|
|
0:09:37
|
on the incoming port of wherever I do begin to have administrative control,
|
|
0:09:42
|
that's where I'm going to re-classify everything.
|
|
0:09:45
|
And even if it's marked with DSCP or type of service markings,
|
|
0:09:51
|
I'm going to remark it based on how I classify it.
|
|
0:09:56
|
So, that's our trust boundary.
|
|
0:09:57
|
But again, hopefully you have access or administrative control all the way out to the access switch layer,
|
|
0:10:03
|
and in most cases, it is safe to do a conditional trust
|
|
0:10:07
|
where we trust the device if it's a Cisco IP phone, and we trust its marking.
|
|
0:10:12
|
Whatever the phone has already marked the packet as.
|
|
0:10:16
|
Policing.
|
|
0:10:18
|
If we need to do any sort of policing,
|
|
0:10:21
|
which is basically, we are going to have traffic that's coming in to our network,
|
|
0:10:26
|
and sometimes, it's going to come in at a rate that exceeds,
|
|
0:10:31
|
something that we've set at a maximum rate or a certain type of traffic.
|
|
0:10:36
|
And that traffic we may want to police. That is, we may want to drop it.
|
|
0:10:41
|
Not all of the traffic, but only that which exceeds the rate which we've defined as the maximum.
|
|
0:10:46
|
Policing is almost always applied at the ingress. In fact, I...
|
|
0:10:50
|
I think I could safely say that always applied at the ingress.
|
|
0:10:55
|
If you're going to drop traffic beyond the certain rate, there's no reason to allow it to go through a router,
|
|
0:11:01
|
and out the egress or output side of the router
|
|
0:11:04
|
before you begin to drop the traffic that is excessive of your specified rate.
|
|
0:11:09
|
You would always do that at the incoming at the ingress.
|
|
0:11:16
|
Next, we deal with scheduling, which comprise, as I mentioned, outgoing queuing,
|
|
0:11:21
|
various congestion management and congestion avoidance mechanisms,
|
|
0:11:26
|
and we usually do this at the egress before the link specific mechanisms.
|
|
0:11:32
|
So, the exception is for LAN switches where we actually,
|
|
0:11:36
|
and so, that was more for later three devices routers,
|
|
0:11:38
|
the exception is for LAN switches where we have actually ingress queuing as well as ingress policing.
|
|
0:11:46
|
So, we can actually queue packets on the ingress
|
|
0:11:50
|
to allow more prioritized packets to come into the switch first.
|
|
0:11:55
|
And then, we have our link specific mechanism which is traffic shaping,
|
|
0:12:00
|
LFI, which is link fragmentation interleaving and optional compression.
|
|
0:12:06
|
We're gonna talk about each of these just a little bit more.
|
|
0:12:09
|
Because it's always the last thing to occur as the frame or packet egress as the device.
|
|
0:12:17
|
So, looking at basic queuing types,
|
|
0:12:20
|
we have the default, de facto standard FIFO - First In First Out.
|
|
0:12:28
|
We also have something called Last In First Out, but we're really not gonna talk too much about that.
|
|
0:12:33
|
Next, we have something called priority queuing.
|
|
0:12:36
|
The idea of priority queuing is that I have a...
|
|
0:12:41
|
software mechanism that says, if you are in a certain class or in a certain queue,
|
|
0:12:47
|
then, if you're deemed to priority queue, we are gonna transmit all packets or frames,
|
|
0:12:54
|
I hope that you know what device we're talking about
|
|
0:12:56
|
in that priority queue before any traffic, any other of the queues are sent.
|
|
0:13:02
|
So, we're gonna empty that queue.
|
|
0:13:05
|
Now, maybe we empty all the voice RTP packets, all the UDP packets
|
|
0:13:12
|
out of a router software priority queue,
|
|
0:13:17
|
and then, we begin servicing some of the other queues.
|
|
0:13:21
|
Our signaling queue, our bulk data such as e-mail or oracle traffic or something like that,
|
|
0:13:29
|
and then, all of a sudden, voice traffic comes back.
|
|
0:13:31
|
Well, we're gonna halt servicing those other queues and empty the voice queue.
|
|
0:13:36
|
So, the ideas that voice always gets out the door first.
|
|
0:13:39
|
And depending on what kind of video we're working with, and it really depends.
|
|
0:13:43
|
There's a lot of different types of video.
|
|
0:13:45
|
Some is non-real time such as video and demand. Some is like you're watching now, a live stream.
|
|
0:13:53
|
So, it's a lot more critical that it gets out of the door first.
|
|
0:13:57
|
Some if streaming IP tv, we really don't care if there's a little bit of an interruption
|
|
0:14:03
|
to someone watching CCN news, maybe if they're watching CNBC or something like that,
|
|
0:14:10
|
a stoctic or maybe you need to see it more quickly if it's a trading,
|
|
0:14:14
|
or it just depends what type of video it is.
|
|
0:14:16
|
Whether were going to priority queue it or not.
|
|
0:14:19
|
Telepresence would almost always be priority queued.
|
|
0:14:23
|
But the ideas that it always gets out the door first, then, we service the other queues.
|
|
0:14:27
|
The other's up to us to make sure that we engineer the Quality of Service properly
|
|
0:14:31
|
so that we don't starve the other queues, because that is the other potential.
|
|
0:14:34
|
It is possible that we put so much voice or video traffic in the priority queues
|
|
0:14:40
|
that it starves all of the other queues from ever getting service.
|
|
0:14:47
|
Next, we're gonna look at weighted fair queuing.
|
|
0:14:50
|
So, we're gonna schedule traffic in various classes or queues that we've set up
|
|
0:14:56
|
based on their flow, based on the type of data that they have based on DSCP markings,
|
|
0:15:06
|
I'm sorry, with weighted fair queuing, strictly based on flow.
|
|
0:15:09
|
Then, we get into class-based weighted fair queuing, which is weighted fair queuing, but
|
|
0:15:14
|
we get into, as I was mentioning, the specific administrative defined classes
|
|
0:15:20
|
that we had previously set up. So maybe based on DSCP value,
|
|
0:15:24
|
we already classified. We're saying, now, we don't necessarily look at the traffic
|
|
0:15:30
|
in terms of type of traffic although we may call the class based on the type of traffic,
|
|
0:15:36
|
we look at it based on DSCP value, and if we have this certain DSCP value
|
|
0:15:42
|
of let's say AF31 or something like that, maybe signaling,
|
|
0:15:51
|
or CS3, something like that. We're going to put you into various class.
|
|
0:15:56
|
And we're gonna put you into a various queue.
|
|
0:15:58
|
Basically, we're going to apply weighted fair queuing based on flow, but, or the individual classes.
|
|
0:16:04
|
And then, we have low latency queuing.
|
|
0:16:05
|
This was basically, we took class based weighted fair queuing,
|
|
0:16:08
|
we added a priority queue, and some people call it, PQ with CB,
|
|
0:16:15
|
WFQ or priority queuing with class based weighted fair queuing,
|
|
0:16:18
|
but it's... You'll see a couple documents like that still on Cisco.com.
|
|
0:16:22
|
But by in large, you see people referring to it as Low Latency Queuing or LLQ.
|
|
0:16:30
|
This is the best of both worlds.
|
|
0:16:34
|
Looking at some link specific fragmenting and interleaving.
|
|
0:16:38
|
So, serialization delay is the amount of time, finite amount of time, I should say
|
|
0:16:45
|
that is required to serialize and put the frames on to the actual wire.
|
|
0:16:51
|
To actually turn them into an electrical signal.
|
|
0:16:54
|
For links that are lower them, or equal to 768K, it could be argued at 768K
|
|
0:17:00
|
although there's minimal benefit in doing so.
|
|
0:17:02
|
But certainly for any that are less than 768K,
|
|
0:17:06
|
serialization delay can be a major factor that affects both the delay and the variants of the delay, the jitter.
|
|
0:17:14
|
So, for such slow links, it's important to take the larger data packets and break them up.
|
|
0:17:22
|
And I tried to draw the analogy, let's say I have a high-way, or a motor way,
|
|
0:17:28
|
and I've got really large semi-trucks.
|
|
0:17:31
|
And the bandwidth is how many lanes wide my freeway is.
|
|
0:17:38
|
But it doesn't really matter how many lanes wide my freeway is whether it's 2, 4, or 16 lanes wide
|
|
0:17:46
|
if I happen to have heavy traffic. So, I have congestion at that moment.
|
|
0:17:51
|
And all of the lanes are being taken up by all of these semi-trucks.
|
|
0:17:56
|
Fully loaded, slow semi-trucks.
|
|
0:18:00
|
And you've got a Bugatti Veyron or you've got a Tesla, Roadster, something like that.
|
|
0:18:07
|
Something incredibly fast. You'd like to get around these big trucks,
|
|
0:18:10
|
but you really can't, just because they're blocking so many of the lanes.
|
|
0:18:14
|
So, it really doesn't matter how many lanes we have if we have this sort of congestion.
|
|
0:18:19
|
So, wouldn't it be nice if could just slice up these trucks,
|
|
0:18:23
|
and so, therefore, give each of these slice engines or layer 3, layer 2, IP,
|
|
0:18:31
|
and frame relay, or whatever Ethernet frame headers
|
|
0:18:37
|
being the engines, and then allow them to go individually so that they're lighter loads.
|
|
0:18:42
|
So that they're less than a full load and they can therefore travel a little faster because they're smaller.
|
|
0:18:51
|
And so, that's the idea behind fragmentation,
|
|
0:18:54
|
and then, the interleaving is allowing your fast cars to interleave back and forth between
|
|
0:19:00
|
the now broken up data payloads of these larger semi-trucks.
|
|
0:19:06
|
And it allows these more urgent voice packets to get out of there,
|
|
0:19:13
|
to weave it in a faster out course. If we combine this LFI with priority queuing,
|
|
0:19:19
|
which says strict priority that it we have a priority queue, or in the analogy of the motor way or high way,
|
|
0:19:28
|
we've got an HOV lane, a High Occupancy Vehicle lane.
|
|
0:19:31
|
So, if you happened to be allowed to be in that High Occupancy Vehicle lane,
|
|
0:19:35
|
then, you're in the priority queue,
|
|
0:19:38
|
and you can go at any speed you need. And so, you really get out the door first.
|
|
0:19:43
|
That's really our voice packets, but even fragmenting the large data packets
|
|
0:19:48
|
can be very necessary even if voice packets aren't necessarily being stopped because of the
|
|
0:19:54
|
priority queue getting them out the door first the signaling packets.
|
|
0:19:59
|
Remember our very small, tracking 150 bits to maybe 1 kilobit per second depending on
|
|
0:20:06
|
SIP or H.323 signaling or skinny. Whether it's secure or not. All those make a little bit of a difference,
|
|
0:20:16
|
So those need to be able to certainly interleave back and forth
|
|
0:20:20
|
with the larger data packets now fragmented up.
|
|
0:20:25
|
Now, when you take a look at fragmentation,
|
|
0:20:28
|
and also something that we're gonna look at with header compression here in a moment,
|
|
0:20:31
|
you're gonna see that some of these begin to look really attractive,
|
|
0:20:37
|
but one of the things we wanna keep in mind is that as we go...
|
|
0:20:41
|
above a link speed of 768, so, 1 meg and higher,
|
|
0:20:48
|
the benefits that are obtained from using some of these links specific mechanisms
|
|
0:20:53
|
like link fragmentation and header compression, things like this, compressed RTP, as we'll talk about.
|
|
0:21:02
|
They're really offset, and the end up causing a net negative value.
|
|
0:21:08
|
So, they still look like they could be helpful, especially with compression,
|
|
0:21:12
|
we're gonna look at next in terms of bandwidth savings.
|
|
0:21:14
|
But in terms of the amount of CPU and...
|
|
0:21:21
|
and packetization time that it takes, they end up causing detriment to our networks,
|
|
0:21:26
|
and slowing us down causing more latency than they do end up helping.
|
|
0:21:30
|
So, these are for 768K and slower links.
|
|
0:21:36
|
So, looking at another link specific mechanism being header compression.
|
|
0:21:41
|
And we also have the option of payload compression as well.
|
|
0:21:43
|
If we take a look at this voice payload,
|
|
0:21:46
|
we maybe have a 40 byte voice payload. It depends on what codec we're using, and...
|
|
0:22:00
|
It depends on mainly what codec we're using and then also the sampling rate.
|
|
0:22:03
|
How many samples per second. But...
|
|
0:22:09
|
But the idea is that our voice payload are routers small entity compared to all of the headers that go with it.
|
|
0:22:19
|
So, if we've got a...
|
|
0:22:23
|
I'm sorry, if we have a 20 byte voice payload, and we've got let's say and RTP header of 12 bytes,
|
|
0:22:29
|
we've got another 8 for UDP. So now, we're up at 20.
|
|
0:22:32
|
And then, we've got another 20 fixed bytes for IP,
|
|
0:22:36
|
we've got 40 bytes of header for a 20-byte payload.
|
|
0:22:41
|
So, we've got just way too much overhead, way too much red tape.
|
|
0:22:46
|
Now, this is for WAN traffic, this is for router traffic.
|
|
0:22:50
|
So, that's where we're probably gonna have a little bit smaller voice payload with a G.729
|
|
0:22:56
|
or depends, IOBC codec or ISAC, just depends how big that
|
|
0:23:01
|
payload's gonna be based on the codec.
|
|
0:23:03
|
But we're gonna have a large header to payload ratio.
|
|
0:23:10
|
And the idea is that again, this is first lower speed links,
|
|
0:23:14
|
because this is one of the most intensive CPU operations that you can do with regard to QoS
|
|
0:23:21
|
is compressed RTP headers. But we can basically take and reduce all these down
|
|
0:23:27
|
to a 2-byte or 4-byte header. Basically a hash value.
|
|
0:23:34
|
It's gonna be 2 bytes if we're just using standard UDP,
|
|
0:23:37
|
if we're using UDP with a checksum, then, it's gonna be 4 bytes instead.
|
|
0:23:43
|
Again, only for low speed links, this will generally reduce a G.729 call
|
|
0:23:49
|
down from anywhere from 24 for 28 kilobits, down to about 12-14 kilobits per second.
|
|
0:23:56
|
So, it'll cut your G.729 bandwidth needed traffic in half.
|
|
0:24:03
|
And it sounds really great, but again, the packetization time increases the delay,
|
|
0:24:09
|
and for higher speed links, it is a net loss value.
|
|
0:24:13
|
So, only use that in the lower speed links.
|
|
0:24:18
|
Payload compression is even more CPU intensive.
|
|
0:24:21
|
A lot of Cisco routers, the ISRs and ISR G2s have hardware-assisted ASICs that can help with that.
|
|
0:24:29
|
But this compresses not only the RTP header but also the voice and/or video payload.
|
|
0:24:35
|
So, we talked about fragmentation and interleaving.
|
|
0:24:38
|
Here's just a graphic just to show we've got this large data packets and small voice,
|
|
0:24:43
|
and with fragmentation, we're just basically cutting them up.
|
|
0:24:47
|
Now, we're never gonna fragment voice packets.
|
|
0:24:49
|
We're only gonna fragment data to the size of what we've already calculated our voice packets are going to be at.
|
|
0:24:57
|
We never wanna fragment voice because that's going ton introduce a lot of additional delay.
|
|
0:25:07
|
And so, we're just gonna look at one final link specific mechanism,
|
|
0:25:10
|
and we're not gonna go too far into traffic shaping right now.
|
|
0:25:13
|
We're just gonna talk about the basics of it.
|
|
0:25:16
|
We will in CCNP Voice go into a lot more into policing and traffic shaping,
|
|
0:25:23
|
draw some analogies between then two and then start contrast differences between the two,
|
|
0:25:27
|
and also talk about multi-color and multi-tear policers,
|
|
0:25:33
|
and deal with multiple token bucket for traffic shaping.
|
|
0:25:37
|
But we've already stated that policers typically drop the traffic at a given line rate.
|
|
0:25:42
|
Or whatever given maximum rate we want it to be.
|
|
0:25:46
|
Shapers, traffic shaper seems like a policer, but it really delays or queues up to a certain amount
|
|
0:25:55
|
the excess traffic over that rate.
|
|
0:25:58
|
And the idea is that TCP/IP is very bursty.
|
|
0:26:02
|
And so, without traffic shaping, it's going to,
|
|
0:26:06
|
if it has enough data to transmit, burst up to the maximum rate that it's allowed.
|
|
0:26:12
|
And then, at the maximum rate, whether that just simply be the line rate,
|
|
0:26:16
|
or if we have some sort of policer, it's going to hit that hard limit, and it's gonna be dropped.
|
|
0:26:23
|
TCP is gonna issue a re-transmit, UDP simply dropped. Gone forever.
|
|
0:26:29
|
And the problem is as it goes up spikes to the top and then gets dropped,
|
|
0:26:37
|
and then tries to very quickly increase back up to the maximum flow and then get dropped,
|
|
0:26:44
|
there's a lot of empty space in between. There's a lot of unused bandwidth.
|
|
0:26:50
|
And so, with traffic shaping, what we do by queuing,
|
|
0:26:53
|
and then only releasing certain bits on to the line every given amount of milliseconds
|
|
0:27:00
|
value known as Tc or the time interval. We'll talk about again much more in CCNP Voice.
|
|
0:27:07
|
And specifically, the C Voice course.
|
|
0:27:10
|
This...
|
|
0:27:13
|
What this allows is us to shape the traffic.
|
|
0:27:17
|
So, we're still not allowing the traffic to go beyond a given rate,
|
|
0:27:23
|
and maybe that rate is even the line rate, and in fact, we would talk about in CCNP Voice, it's gonna be
|
|
0:27:29
|
95% of the line rate. But even if it's the maximum line rate,
|
|
0:27:33
|
5% for overhead, we're still going to queue the excess traffic,
|
|
0:27:40
|
and so, because the original router, let's say it's a TCP stream,
|
|
0:27:45
|
the original sending router or host doesn't see a drop, and therefore a re-transmit,
|
|
0:27:51
|
it thinks that everything is fine.
|
|
0:27:52
|
Now, if traffic's being queued up, and then releases slowly unto the line,
|
|
0:27:56
|
and so, it's utilizing a lot more of the bandwidth, available bandwidth much, much more efficiently.
|
|
0:28:05
|
Okay, and then, as the need for that data falls off, so does the stream.
|
|
0:28:11
|
So, this is going to smooth out our traffic. It's gonna allow us to use a lot more available bandwidth,
|
|
0:28:17
|
and it's going to prevent unnecessary drops.
|
|
0:28:21
|
So, these are some of the basic things that you need to understand about Quality of Service
|
|
0:28:25
|
for the CCNA Voice exam. Again, we're gonna go over everything we've seen here in much, much more depth
|
|
0:28:32
|
as well as a lot of demonstration of it in the CCNP Voice course.
|
