|
0:00:14
|
The next section we'll take a look at is a quality of service primer.
|
|
0:00:19
|
So, as we mentioned before, packet-switched networks can potentially suffer form a number of issues.
|
|
0:00:25
|
So, the ITU recommends as specifically part of the G.114 specification or recommendation
|
|
0:00:36
|
that for voice over IP, that you have a delay or latancy of less than or at maximum equal to a 150 ms one-way so for each direction.
|
|
0:00:50
|
Now, just to clarify well briefly, this is not the same as a simple ping test with a round trip.
|
|
0:00:59
|
So, both ways, the packet going all the way one way there and then returning of 300 ms or less.
|
|
0:01:06
|
More is needed to be tested in order to truly get the understanding of what a voice packet
|
|
0:01:15
|
or potentially video packet would go through in terms of one-way or even round trip delay.
|
|
0:01:20
|
So, a ping test is much too small, does not have many of the characteristics such as compression and decompression.
|
|
0:01:28
|
It doesn't have the same level of serialization or possibly even packetization delay as a voice or video packet would.
|
|
0:01:38
|
So, ultimately, our one way delay of 150 ms or round trip of 300 ms will be in terms of a ping time much less than 300 ms.
|
|
0:01:54
|
In terms of jitter, so the difference again between latencies from hop-to-hop.
|
|
0:01:59
|
The ITU recommends less than or at a maximum equal to of 30 ms.
|
|
0:02:05
|
And for packet loss, less than or equal to 1% packet loss.
|
|
0:02:11
|
And really, unless we're using something like the iLBC or iSAC protocols, we really want to have no packet loss at all,
|
|
0:02:20
|
but some of those can deal with a little bit of packet loss.
|
|
0:02:25
|
Now, actually, I should note that these recommendations for 1% or less, preferably less,
|
|
0:02:34
|
were around before the iSAC and iLBC protocols but the same governance skill applies.
|
|
0:02:44
|
Bandwidth for voice and video RTP packets is subject to Codec, Sampling, L3 and L2 Overhead.
|
|
0:02:46
|
So the bandwidth for the signaling, depends on the protocol.
|
|
0:03:03
|
So, in terms of the bandwidth for the signaling, this is going to be anywhere from around a 150 bits per second.
|
|
0:03:08
|
So we're talking about the skinny signaling or other VOIP signaling
|
|
0:03:15
|
but for skinny, you know, we could be as low as 150 bits per second
|
|
0:03:20
|
and depending on H323 Resip or also a number of other factors involved in the signaling.
|
|
0:03:29
|
It could be as high as 1 kbps, but this is for the signaling stream.
|
|
0:03:34
|
The bandwidth for the voice and video is going to be subject to all those other things.
|
|
0:03:39
|
What is the Codec? What is the sampling rate? How faster we're sampling?
|
|
0:03:43
|
How many packets per second are we transmitting? Layer 3, Layer 2 overhead?
|
|
0:03:47
|
All things that we look at in Advanced Certificiation Quality of Service Modules.
|
|
0:04:01
|
Bandwidth for Video should always have an additonal 20% overhead to deal with things like keyframes.
|
|
0:04:04
|
So, without getting too involved in video, specifically the H.264 or actually as it is better known as the ABC Advanced Video Codec
|
|
0:04:13
|
which is really a combination of the ITU's H.264 recommendation along with the motion picture group of pictures (mpeg4) recommendation
|
|
0:04:31
|
Those two together bring together the ADC, but things like these can dealt with things known as B frames and P frames, predictive frames,
|
|
0:04:41
|
and essentially not all of the information on a screen, not all the pixels on a screen are transmitted in any one time,
|
|
0:04:50
|
a lot of times depending on what Codec is used.
|
|
0:04:53
|
Differing pixels are transmitted and the picture is updated or figured out in the case of H.264 predicted and figured out
|
|
0:05:06
|
what it looks like or what it should look like.
|
|
0:05:08
|
However, every once in a while almost regardless what Codec is used,
|
|
0:05:11
|
there is almost always a keyframe that's sent.
|
|
0:05:16
|
Whenever there's a keyframe that's sent, thta means an enitre redraw of the screen is performed and then sent
|
|
0:05:25
|
which obvioulsy has a lot higher overhead associated with in terms of bandwidth.
|
|
0:05:30
|
So, there is always a recommendation for at least 20% overhead, you know.
|
|
0:05:36
|
So, if you have a 384 kbps call, on average, you would have 384 x 1.20
|
|
0:05:46
|
or the entirity of your 384 plus the 20% overhead.
|
|
0:05:53
|
So, there are three types of Quality of Service Models or QoS Models.
|
|
0:05:58
|
We have Best Effort which is effectively No Quality of Service at all, basically (FIFO) First-In, First-Out
|
|
0:06:07
|
And then we have Integrated Services, also known as IntServ.
|
|
0:06:13
|
This is guaranteed bandwidth for voice and signaling and it uses the ReSerVation Protocol (RSVP).
|
|
0:06:20
|
However, RSVP must be enabled and properly configurd on every router in the Layer 3 path of the VOAP call.
|
|
0:06:28
|
So, this is where this makes this form of QoS modelling or deployment much less readily available or likely to be used
|
|
0:06:41
|
because there are many times when we simply can't configure a given protocol on a router
|
|
0:06:47
|
especially for dealing with things like MPLS and Layer 3 providers for our data
|
|
0:06:54
|
that are not probably not going to turn on the exact type of mechanism that we want to regardless of what it is such as RSVP.
|
|
0:07:05
|
Then we have Differentiated Services also known as DiffServ.
|
|
0:07:10
|
Here he have guaranteed bandwidth for voice and signaling as well,
|
|
0:07:13
|
but we classify different types for traffic such as Media or Signaling or ICCS which is the Intercluster Communciation Signaling
|
|
0:07:24
|
for Cisco Unified Communication Manager Networks or bulk data, you know, E-mail, etc.
|
|
0:07:31
|
We might even have may others. We might have SAP traffic or Oracel traffic or whatever types of traffic we want to classify
|
|
0:07:39
|
We can do so with Differentiated Services or Diff Serv.
|
|
0:07:44
|
And we use policies to ensure that differentiated levels or priority and service are applied.
|
|
0:07:51
|
This is most commonly used in enterprise networks.
|
|
0:07:55
|
Carriers typically use MPLS-TE, although they can do that based on DSCP or DiffServ, if they like.
|
|
0:08:07
|
And this just not have to be enabled on every router in the Layer 3 path of the VOIP call.
|
|
0:08:12
|
Let's not just say that it's not recommended, but for instance, such as MPLS,
|
|
0:08:17
|
we may have a carrier that is guaranteeing that if we mark things with certain DSCP,
|
|
0:08:23
|
or Differentiated Services Code Point, with different DSCP bits, or with specific bits that they will then in turn honor a guaranteed service level agreement
|
|
0:08:39
|
for the Differentiated Services, Diffirentiated Services Code Point, or DSCP bits, the different DSCP bits that we set,
|
|
0:08:48
|
they offered different levels of service and they guarantee those whether they are using DSCP queueing
|
|
0:08:54
|
like we would in an enterprise or whether they're just looking at those DSCP bits
|
|
0:08:58
|
and then mapping them to their MPLS Traffic Engineering.
|
|
0:09:00
|
The point is that we're honoring a common system which is DiffServ or DSCP.
|
|
0:09:06
|
But the point is that we don't have to have it enabled every step, we can actually guarantee from end-to-end,
|
|
0:09:15
|
although we could not guarantee on the one particular router.
|
|
0:09:18
|
Let's just say we're not dealing with MPLS, we're dealing with our own enterprise network.
|
|
0:09:23
|
We've got 6 Routers and one of them in the middle, we cannot for whatever reason, enable Differentiated Services' Quality of Service.
|
|
0:09:31
|
We can still guarantee that at the other five, they will get priority treatment,
|
|
0:09:38
|
our voice will and we will be guaranteed quality on those.
|
|
0:09:43
|
May not be guaranteed on that one, but at least it is still be guaranteed on the others.
|
|
0:09:47
|
Whereas, with IntServ of Integrated Services, if we don't turn on RSVP on even one of the routers,
|
|
0:09:57
|
then we are not going to have any sort of a guarantee on any of the routers
|
|
0:09:57
|
because it really does rely on every single router being configured properly for RSVP.
|
|
0:10:13
|
Now, later in your study, it is not necessary for CCNA level Voice,
|
|
0:10:19
|
but later on the study, when we look at quality of service, you will see that we used a hybrid approach
|
|
0:10:25
|
where we use or utilize the RSVP protocol, but we do it with DiffServ.
|
|
0:10:33
|
We're not getting in to that right now, but i just want to clarify something upfront so that
|
|
0:10:39
|
if you do see this in later videos that you're watching from INE,
|
|
0:10:45
|
that you don't kind of say, "Wait a minute, I thought we're using DSCP or Differentiated Services Code Point,
|
|
0:10:54
|
but I thought RSVP is a part of IntServ, and it does have to be enabled on every single router in the path
|
|
0:11:05
|
if you're using the Integrated Services model, but there is a hybrid approach where we can use the benefits of RSVP
|
|
0:11:14
|
without having to have it enabled on every single router because we're using DSCP or Differentiated Services
|
|
0:11:21
|
for the Actual Queuing Mechanism, but that comes much later.
|
|
0:11:27
|
So, the Different QoS Mechanisms.
|
|
0:11:31
|
We'll take a look here. To begin with, at Classification and Marking where we identify and prioritize.
|
|
0:11:41
|
And we'll look at Queueing and Dropping or Manage and Sort
|
|
0:11:45
|
and then Link Specific Mechanisms or Process and Send.
|
|
0:11:48
|
So, the first element with QoS Policy is the need really to classify or identify the traffic that is ultimately to be treated differently.
|
|
0:11:58
|
So following Classification, once we've identified that traffic, we use a set of tools that mark the traffic.
|
|
0:12:06
|
They set an attribute something called a DSCP, a DiffServ Code Point of a Layer 2 frame.
|
|
0:12:14
|
Actually, if in Layer 2, it would be a class of service.
|
|
0:12:21
|
In Layer 3, it would be a DSCP or Differentiated Services Code Point, to a specific value
|
|
0:12:28
|
in order to signal to the downstream or upstream neighbors that this traffic has already been classified and is a particular type.
|
|
0:12:42
|
Next, comes Policing. So this is typically done on the ingress of a device.
|
|
0:12:48
|
We'll talk a little more about this, but this determines whether packets are conforming
|
|
0:12:53
|
to some sort of administrator-defined rate and then we take action accordingly.
|
|
0:13:02
|
So, such actions could include things like remarking the traffic if it doesn't conform,
|
|
0:13:09
|
or possibly even dropping the packet and one of the actions is certainly transmitting a packet
|
|
0:13:14
|
if it fits within or conforms to the profile you've identified.
|
|
0:13:18
|
Next comes Scheduling, with two different portions here, Congestion Management and Congestion Avoidance
|
|
0:13:29
|
Congestion Management typically deals with Queueing and Congestion Avoidance typically deals with some form of Dropping.
|
|
0:13:37
|
Yes, thta's right. Sometimes, in quality of service we want to preemptively or proactively drop less important traffic
|
|
0:13:46
|
in order to prevent a congestion point in the network.
|
|
0:13:51
|
And then when we do have any sort of congestion points in the network, we manage that with Queueing.
|
|
0:13:58
|
Scheduling tools determine how a frame exits a device.
|
|
0:14:02
|
So, queueing algorithms are only activated when a device is actually experiencing congestion
|
|
0:14:08
|
and then they're deactivated once the congestion clears
|
|
0:14:11
|
This is actually all except for the priority queue where any packets entering the priority queue will always be sent on to the wire
|
|
0:14:21
|
or transmitter under the wire ahead of every class is traffic, whether there's congestion or not.
|
|
0:14:29
|
And then we have Link Specific Mechanisms.
|
|
0:14:32
|
So this deals with things like shaping, fragmentation, compression and even transmit ring.
|
|
0:14:40
|
And this offers Network Administrators, the tools to be able to optimize the overall and total link utilization better.
|
|
0:14:51
|
So, where do we apply these different QoS Mechanisms?
|
|
0:14:56
|
Well, for Classification and Marking, they should always be performed as close to the source as possible.
|
|
0:15:03
|
So the question you have to ask yourself, is do you have administrative control over the device that nodes connect to?
|
|
0:15:11
|
If not, then you should apply it to the closest device.
|
|
0:15:15
|
So, in other words, nodes on your network typically apply to some sort of an access layer switch.
|
|
0:15:21
|
If possible, this is the best place to perform Classification and Marking, possibly even Mapping.
|
|
0:15:32
|
So that is Mapping Layer 2 to Layer 3. QoS markings and possibly even Layer 3 back to Layer 2 QoS markings.
|
|
0:15:45
|
Just to say one more thing about that. So if you don't have administrative control over an acces layer switch
|
|
0:15:53
|
where the phones and/or computers woud connect to, then what's the next closest device,
|
|
0:16:01
|
is it an upstream switch, is it a router of the closest place that you have accessed to or administrative control all over,
|
|
0:16:08
|
that is where you should apply your classification and marking.
|
|
0:16:13
|
Next, with Policing, this should always be applied at the Ingress of a device
|
|
0:16:18
|
So, for talking about a Layer 2 switch, Layer 2 frame, this would be at the switch level.
|
|
0:16:24
|
Talking about a Layer 3 packet, this would be at the Ingress of a Router.
|
|
0:16:31
|
And of course, because any port on a switch or a router can be both an Ingress or Egress point,
|
|
0:16:39
|
then we want to make sure we apply the policing on the Ingress direction and we take careful note
|
|
0:16:45
|
as to if the particular port at the Ingress direction is in fact where we want to apply it or not per the flow of traffic
|
|
0:16:55
|
Next is Scheduling. So, Queueing for Congestion Management, Dropping or Weighted Dropping,
|
|
0:17:02
|
RED and Weighted RED, RED for Random Early Detect. I call it Random Early Discard. That's really what it does, or WRED for Weighted Random Early Discard
|
|
0:17:16
|
So, randomly discard traffic early to avoid congestion but do it based on a given weight and we weigh packets or frames differently.
|
|
0:17:24
|
These are usually applied at the Egress before we actually transmit the Layer 2 frame or the Layer 3 packet on to a device.
|
|
0:17:39
|
Before the LSM where the Link Specific Mechanism is involved
|
|
0:17:43
|
The exception for LAN switches were Ingress Queueing and Dropping can be applied.
|
|
0:17:50
|
But on a router, we would almost do the set to Egress.
|
|
0:17:53
|
And on a switch, we also do, in fact, do at the Egress, however, we can potentially queue Ingress traffic as well.
|
|
0:18:06
|
Then we have our link specific mechanisms such as Traffic Shaping, something called LFI or Link Fragmentation and Interleavinga and Compression.
|
|
0:18:15
|
These are always applied as the very last thing to occur before frame or packet leaves the Egress of a device.
|
|
0:18:26
|
So, taking a look at Queueing Types.
|
|
0:18:28
|
We've got FIFO. So the First In is the First Out.
|
|
0:18:33
|
We have Priority Queueing which essentially states transmit all frames or packets in the given priority queue
|
|
0:18:42
|
and then pull, traffic, pull frames or packets from other queues.
|
|
0:18:48
|
We also have weighted fair queueing which is that we scheduled to be transmitted based on types of flows of traffic.
|
|
0:18:59
|
Then we have a further advancement of Weighted Fair Queueing called Class-Based Weighted Fair Queueing.
|
|
0:19:14
|
So, this is Weighted Fair Queueing but with specific administrator-defined classes to allow us to define specifically
|
|
0:19:16
|
which types of traffic get how much of the available bandwidth versus just with Weighted Fair Queue
|
|
0:19:23
|
where they're all weighted and treated equally based on the individual flows.
|
|
0:19:29
|
And then we have something called Low Latency Queueing.
|
|
0:19:31
|
This was basically the combination of Priority Queueing and Class-based Weighted Fair Queueing together
|
|
0:19:38
|
sometimes referred to as PQ-CBWFQ or Priority Queueing with Class-based Weighted Fair Queueing.
|
|
0:19:45
|
But these together are what we use today and are known as Low Latency Queueing
|
|
0:19:49
|
and really this have been what have been using since the early 2000's.
|
|
0:19:56
|
So taking a look at Link Specific Mechanisms, and to begin with Header Compression.
|
|
0:20:01
|
Header compression reduces the size of Layer 3/ Layer 4 IP, UDP and RTP headers
|
|
0:20:10
|
from a fixed 4D-byte link down to 2 bytes and this is actually 4 bytes if UDP check summing is enabled or used.
|
|
0:20:22
|
So, the average G.729 call, for instance, reduces the overall transmission rate
|
|
0:20:30
|
from approximately 28 kbps depending on the Layer 2 type link down to about 14 kbps.
|
|
0:20:38
|
Now this is only used for low-speed links that is 768 kbps and below and this is performed hop-by-hop.
|
|
0:20:50
|
But you can see here, we've got the Voice Payload which with G.729 Codec
|
|
0:20:58
|
and depending on the sampling rate we're using but actually either one is a fairly small portion of the overall packet itself.
|
|
0:21:13
|
And so when we see a large header that's fixed, we really can't do anything about it
|
|
0:21:21
|
All IP headers are 20 bytes, UDPs are 8 bytes and RTPs are 12 bytes.
|
|
0:21:27
|
The Voice Payload begins to look really small and its like we've got this, you know,
|
|
0:21:31
|
Government bureaucracy for just a tiny little bit of work that's being done.
|
|
0:21:36
|
So this is the idea behind Header Compression.
|
|
0:21:38
|
And it's one of the things that can seem very lucrative to perform all the time
|
|
0:21:47
|
because of the amazing amount of bandwidth savings but its one of the more CPU intensive
|
|
0:21:55
|
and specifically when we get to Payload Compression, extremely CPU intesive operations
|
|
0:22:01
|
and the amount of processing time actually outweighs and begins to degrade the overall delay and latency
|
|
0:22:12
|
as we get to bandwidth links connected to routers that are higher than 768 kbps.
|
|
0:22:20
|
So, looking at Payload Compression, we not only compress the RTP header but also the RTP Payload itself.
|
|
0:22:26
|
So, Cisco routers have hardware-assisted compression ASICs or Application Assisted Integrated Circuits
|
|
0:22:33
|
that deal and can help off-load some of this but still CPU intensive and again it's still under 768 kbps
|
|
0:22:41
|
or I should say equal to or less than 768kbps links.
|
|
0:22:44
|
Looking at a Link Specific Mechanism called Link Fragmentation and Interleaving or LFI
|
|
0:22:55
|
So the Serialization Delay which is the finite amount of time that it takes to actually put frames
|
|
0:23:03
|
not to packetize then put them inside, they're given headers and packets
|
|
0:23:09
|
but actually to transmit this into the electrical impulses that need to go on to the Layer 1 wire
|
|
0:23:19
|
for links that are less than or equal to 768 kbps, it can be a major factor in affecting latency and more specifically jitter.
|
|
0:23:30
|
And so for links that are slow such as these large data packets really should be fragmented
|
|
0:23:39
|
and then interwoven with smaller, more urgent voice packets, but we never want to fragment voice packets
|
|
0:24:00
|
So the idea is, if we have a large data packet and small voice packets, it's really hard for this smaller packets to get through very quickly.
|
|
0:24:11
|
I typically try to equate it to, let's say we've got a major motor way or free way and we've got a lot of really large trucks,
|
|
0:24:23
|
semi-trucks or lorries, whatever you refer to them as, and they're loaded down with goods and they're really, really slow taking up all the lanes of traffic.
|
|
0:24:31
|
Now, one of the ways to deal with this is simply to add more lanes of traffic, so to go above 768 kilobits per second as a link speed
|
|
0:24:37
|
and then the small, you know Bugatti Veyrons and Porches and Ferraris can zoom around them.
|
|
0:24:47
|
But if we can't add more bandwidth, we can't add more lanes of traffic, then the idea is to cut them up to equal sizes as the voice packets,
|
|
0:24:49
|
we never want to cut up the voice packets.
|
|
0:24:52
|
That way they all basically share the same speed footprint or at least that's the general idea.
|
|
0:25:01
|
Now, when we perform Fragmentation and Interleave those with the voice packets and the other data packets,
|
|
0:25:10
|
there is a penalty imposed in a sense that it takes time to cut up the data packets and there's time that it takes to refragment or reassemble
|
|
0:25:23
|
so it takes time to fragment and then also put the number of, you know, of fragment that this particular packet is inside of that header
|
|
0:25:35
|
additional header information for the fragmentation and then on the other side,
|
|
0:25:41
|
wait until we get all of the proper fragment bits and reassemble them into proper order
|
|
0:25:49
|
so that, obviously causes quite a bit of penalization or penalty to these data packets and it's one of the reasons we never want to cut off voice packets any smaller.
|
|
0:26:00
|
and so it is also one of the reasons why we can't get larger bandwidth or higher speed links, we won't penalize this data traffic by fragmenting it.
|
|
0:26:13
|
And then we'll take a look at a link specific mechanism known as Traffic Shaping.
|
|
0:26:19
|
So, Policers typically drop traffic although they do rate limit.
|
|
0:26:25
|
Shapers also rate limite like Policers except they typically delay or queue excess traffic rather than dropping it.
|
|
0:26:33
|
And the idea of this is to smooth out bursts and prevent unnecessary drops.
|
|
0:26:39
|
So, typically, when we look at Data Traffic is very bursty, specially TCP traffic can be very bursty.
|
|
0:26:51
|
and as we reach the top of the actual line rate, what we typically do is there's some sort of dropping
|
|
0:27:02
|
you know, some sort of tail dropping, some sort of we've reached the top of the buffer we can't take anymore
|
|
0:27:08
|
we signal that we can't take anymore and traffic spikes then back down and it tries to build up slowly again
|
|
0:27:15
|
and finally it gets up to the top again and it hits the top of the buffer and then it spikes back down
|
|
0:27:21
|
and what we end up with is in between here, a lot of unused bandwidth or underused bandwidth.
|
|
0:27:30
|
So with Traffic Shaping and what we typically try to do is sort of aggregate this data all together by providing sort of a soft ceiling.
|
|
0:27:39
|
Now this soft ceiling might be almost the same as the hard ceiling, the actual line rate
|
|
0:27:44
|
it will never be the exact amount of the line rate or else we'll still deal with this same hard drops.
|
|
0:27:51
|
But it might be, you know just slightly below and in fact Traffic Shaping we typicall recommend 95% of the overall bandwidth is what we shape to
|
|
0:28:01
|
Here this looks a lot more like 60% of the bandwidth but the idea is the same regardless of how much of the bandwidth we shape to
|
|
0:28:11
|
is that we provide the soft ceiling and we queue or delay the excess traffic and therefore we can transmit on to the line
|
|
0:28:19
|
first of all in a more even fashion spread out over an equal amount of time
|
|
0:28:24
|
and then we also have the ability to therefore not allow this large, not only spikes up but then it spikes back down
|
|
0:28:36
|
and drops in traffic where they have to begin re-transmitting again but we smooth it out and end up utilizing a lot more of the overall available bandwidth.
|
