Describe Quality Problems

0:05Welcome to domain 5 of the collaboration core blueprint.

0:08We're going to be talking about 5.1

0:10in this skill, which is, specifically,

0:12describe quality problems.

0:14This entire domain is all about quality of service.

0:16And quality of service is an interesting concept

0:18from the perspective of, yeah, we really

0:20need it to deploy our voice and our video and collaboration

0:23technologies.

0:24And yet most of the configuration

0:26for quality of service is on routers and switches.

0:29So we're crossed between it being a collaboration

0:33technology and a routing and switching technology.

0:35In fact, if you were to switch tracks and go

0:37on to the ENCOR, the Enterprise Networking Core exam,

0:41we'd have to learn quality of service

0:42there as well because Cisco expects not only the route

0:45switch engineers, but, of course, also

0:47the collaboration engineers to understand how exactly quality

0:50of service works.

0:50So throughout the course of this domain,

0:52we're going to be taking a look at QoS

0:54and understanding how exactly it functions on these routers

0:57and on these switches.

0:58And by the end of it, we're going

0:59to look at the configuration because, again, Cisco

1:01expects us to know that.

1:02Now, in this skill, specifically,

1:04describe quality problems, we're going

1:05to be taking a look at the problems

1:07that we have with our quality, why exactly

1:10we want to deploy quality of service.

1:11So we're going to look at the need for quality of service,

1:14different ways that we have deployed in the past,

1:16and how exactly we deploy it now in modern networks.

1:19And then we're going to wrap up with how

1:22we measure whether our network is doing well.

1:24So is quality of service working?

1:26These metrics of delay and jitter and such,

1:29we need to understand what they are

1:30and how we measure them to know whether our QoS mechanisms are

1:33being successful.

1:34So come along with me and have a lot of fun as we explore,

1:37basically, the foundation of QoS--

1:39why we need it, and how we're going to deploy it.

1:41And with that, I will see you in the next video.

0:05Let's be real.

0:06Do we need quality of service in the modern network?

0:09And now if Cisco were to ask us this on an exam, of course,

0:12we'd all check the yes box because we

0:13know that's what Cisco wants to hear

0:15and that's what's considered best practice by the industry,

0:18but we're talking about the modern networking era.

0:20We have 10 gig links.

0:22We have 40 and 100 gig links that are starting to go in.

0:25We've got WAN links now that are not a Meg and a half,

0:28but they're 15, 20, 50 Meg circuits

0:30that we have between our sites.

0:32So if we're being honest, do we really

0:35believe that we need quality of service?

0:37Now, the answer to all of this is

0:39yes, we do still need quality of service

0:41in the modern networking era and we're

0:43going to be exploring that in this video.

0:45But if we don't believe in our hearts that QoS is necessary,

0:49then what's the point of learning any of this when

0:51we're never going to deploy it?

0:52So let's start with the basics.

0:53Let's start with the foundation that yes, we

0:55do need quality of service today,

0:57and we're going to explore why throughout the course

0:59of this video.

1:00Let's take a look.

1:01As with a lot of our conversations,

1:03we're going to start with a couple of network devices.

1:05We're going to connect those devices together.

1:07We're going to consider the fact that we

1:09have a lot of traffic coming into,

1:11maybe, one of these switches or one of these routers, whatever

1:13it is, and all that traffic has to be sent across this wire.

1:17And so it's all sharing the bandwidth of this one link.

1:20And so all this traffic is being generated

1:21from a lot of different applications in most cases,

1:24but what are these applications?

1:26Well, two applications we're certainly

1:27going to consider a lot throughout the entirety

1:29of this course are going to be voice and video.

1:33Voice and video are very important mission

1:35critical applications that ride on our networks

1:38and certainly any QoS conversation

1:40is going to be focused primarily on these two applications.

1:43And the reason for that is because these applications

1:45are considered time-sensitive.

1:48And what we mean by that is that voice and video traffic

1:51has to be delivered as quickly as possible

1:53to the other end of our network.

1:55But it's not just that they're time sensitive,

1:57it's also that they're drop sensitive.

1:59We do not want to drop packets from these two application

2:02types if we can avoid it in any way.

2:05But as we know, voice and video are not the only applications

2:08on our networks.

2:09We often have to deal with the applications that

2:11keep our business afloat.

2:13Applications such as customer resource management tools, CRM,

2:16or enterprise resource planning or ERP systems.

2:20We might also be dealing with point of sale systems

2:22and applications like email that we have to deal with.

2:25And of course, then there's internet surfing.

2:27Our users are often on the internet,

2:28and maybe, that's a good thing, maybe, that's a bad thing.

2:31But either way, we have to deal with that traffic.

2:33Now, when we look at these applications,

2:35these are not considered time-sensitive,

2:37from the perspective that if my email shows up

2:40now or maybe in 10 seconds from now, it's not a big deal.

2:43Compare that to voice and video.

2:44If my voice packets show up 10 seconds later,

2:47that's kind of a big deal.

2:48And so they're not time-sensitive.

2:50In a lot of cases, these are TCP applications,

2:53and TCP has reliability mechanisms,

2:55so they're not technically speaking drop-sensitive either.

2:58But at the same time, these are considered

3:00critical applications.

3:01Meaning if they go down, my business is impacted.

3:05And so these types of applications

3:07are still considered very important

3:08relative to potentially internet traffic down here.

3:12And yes, these days the internet is very useful.

3:15My employees might be logging on to the internet,

3:17maybe, even going to something like YouTube.

3:19YouTube is very educational these days,

3:21and so maybe they're trying to make their jobs more efficient

3:24or make themselves more productive in some way

3:26by going to YouTube, but that doesn't translate

3:28into business criticality.

3:30And so oftentimes, we place this type of traffic

3:33into a noncritical category.

3:35Now, I've given just five examples here

3:37of non-voice non-video traffic, but in a typical network,

3:41we're going to be talking about dozens

3:42of different applications.

3:44And we're going to have to classify those into these

3:46categories-- critical, noncritical,

3:48and maybe even drop further categories where--

3:51somewhere in between, between critical and noncritical,

3:54for example.

3:55So again, all of these applications

3:57are sharing the bandwidth of this link,

3:58and as we've mentioned before here,

4:01we've got a lot of bandwidth these days.

4:03We're typically deploying 1 gig links

4:05at a minimum between our switches and our environments.

4:08In a lot of cases, we're going to be seeing 10 gig,

4:10or possibly even 40, or 50, or 100 gig.

4:14I mean, even at the time of this video,

4:16we are deploying 400 gig connections usually

4:18into data centers and dark fiber connections and such.

4:21But at the same time, the reality

4:23is that we've got a lot more bandwidth these days

4:25than we did 15, 20 years ago when voice over IP

4:28was first arriving on networks.

4:31And so is still needed in the modern network.

4:34And the answer, as you can imagine, is going to be yes,

4:37but we need to understand why.

4:39Why exactly do we need to worry about quality of service

4:41when we have so much bandwidth available to us?

4:44Well, the first reason we want to consider

4:45is going to be contention.

4:47It sounds great to say that I have a 10 gig connection,

4:50but is that really enough?

4:52Because at some point during the day,

4:54especially, as network traffic ramps

4:56up, we might find ourselves pushing the limits of 10 gig.

5:00And furthermore, as we're going to explore later

5:02on in this skill, we don't need to hit 9.99 gig of throughput

5:07before we start dropping packets.

5:09We might start dropping packets as soon

5:10as we get up to 7 or 8 gig.

5:12Even if we have 10 gig available to us,

5:15our network traffic likes to spike,

5:17and these spikes, right here, might get cut off, especially,

5:20during periods of contention, periods of busyness--

5:23maybe, right in the middle of the day when

5:24everybody is working and all things are

5:27happening all at once, everything is converging.

5:30Yeah, this results in network spikes pretty regularly.

5:32And so we can throw as much bandwidth at it as we want,

5:34but it doesn't mean that we will never have network spikes that

5:37exceed our allotted bandwidth.

5:39Now, second, we are going to still have links in our network

5:42that don't have quite as much bandwidth as our LAN links.

5:45And I know, I said in the intro that we've got these large WAN

5:48circuits available to us, but when

5:50we think about a 15 meg WAN circuit, yeah,

5:52that's 10 times what a T1 used to be

5:55or what a T1 still is today, but either

5:57way that's still not a gig.

5:59It's not even a hundred meg.

6:01And so we have to deal with the fact that our WAN links,

6:03especially, and possibly other links on our network

6:06aren't quite going to be what our max bandwidth

6:08throughputs can be on our local area networks.

6:11When we think about MPLS circuits,

6:13we think about wireless connections--

6:14if we're in a metro area, we might

6:16be sending a wireless signal across the city,

6:18and we're not necessarily going to get as much throughput out

6:21of those technologies as we would with a dark fiber

6:24connection.

6:24And lastly, it comes back to this concept

6:26of time-sensitivity.

6:28And let's explore this in a little bit more detail.

6:30And the way I want to do that is by exploring,

6:32specifically, this connection right here.

6:35As we already described, we have a lot of different traffic

6:38from all these applications showing up on the switch.

6:40So what exactly is happening on that interface?

6:43Let's say our first packet shows up,

6:44and it's a big packet, 1,500 bytes, and the switch decides,

6:49OK, I know where I'm sending that.

6:50I'm going to start processing that and sending

6:52that across the link.

6:53But then another packet shows up,

6:55another big 1,500 byte packet, and then maybe

6:58another 1,500 byte packet.

7:00And then wouldn't you know it, even while we're still

7:02trying to send that first packet, a voice over IP packet

7:05shows up.

7:06And we know voice over IP packets

7:08are a little bit smaller than the rest.

7:09In fact, they're quite a bit smaller than the rest.

7:11And again, this voice over IP packet

7:13is a time-sensitive packet.

7:15We need to transmit that as quickly

7:17as we can so we can ensure that it gets across the network

7:19as efficiently as possible.

7:21So is it possible for us to move this voice over IP packet

7:24to the front of the line?

7:25Take it right behind the packet that's currently being sent

7:28so that it can be the next one.

7:30Well, without QoS mechanism, that's impossible.

7:32The voice over IP packet is simply

7:33going to have to wait its turn.

7:35So we have to send the first packet, and then

7:37the second packet, and then the third packet,

7:39and OK, maybe, it's only three packets.

7:41It's not a big deal.

7:42But what if there's 30 packets in front of it or 300?

7:45And again, a lot of these large packets

7:47might be for something like email.

7:48So does it really make sense for us

7:51to prioritize the email packets being delivered

7:53over the voice over IP packets?

7:55And according to our list over here, we would say no.

7:57No, we would want to transmit that voice over IP packet

8:00first.

8:00But again, without QoS that's simply impossible.

8:03A queue on a router on a switch is serial.

8:06We're only able to send our packets in the order

8:08in which they showed up.

8:09But that's not our only problem.

8:11What happens if we get a bunch of other packets in here,

8:14and then wouldn't you know it, we're full.

8:16Routers and switches, they only have so much space

8:18in their queues for so many packets.

8:20And so next, of course, it's the voice over IP packet

8:24that shows up.

8:25The voice over IP packet, when the queue is full,

8:27is going to have to be dropped.

8:29We simply drop that packet when the reality is, again, we've

8:32got so many other packets in here

8:33that belong to applications that fall

8:35into a nondrop-sensitive category.

8:38They're running TCP.

8:39They're not time-sensitive.

8:41We could drop those packets.

8:42The applications would handle it just fine.

8:44Meanwhile, our voice over IP packets

8:46that are sensitive are going to get

8:48dropped, and our voice quality is going to be impacted.

8:51But there's even a third problem we need to consider.

8:53What happens if, let's say, this switch up here,

8:56the second switch, is connected upstream to a WAN service

8:59provider?

9:00Now, this WAN service provider, maybe,

9:02provided us with a 20 meg circuit.

9:04And so they give us an ethernet handoff,

9:05and I don't know about you, but I've never

9:07heard of a 20 meg ethernet connection.

9:10I've heard of a 10 meg ethernet connection.

9:12I've heard of a hundred meg ethernet port.

9:14I've never heard of 20 meg.

9:16And so, really, what they're going to do

9:18is they're going to hand us an ethernet port that's either

9:20100 meg or maybe even a gig.

9:22And so this switch right here-- again, switch 2, let's call it.

9:25Switch 2 thinks that it's got this huge pipe,

9:28this gigabit circuit that I'm handing off to this WAN device.

9:32Maybe it's a router.

9:33And so it's sending traffic.

9:35It's sending traffic.

9:35It's so happy.

9:36It's never having to drop a packet because we've

9:38got so much bandwidth.

9:40Except that WAN service provider isn't

9:41going to be super happy if we all of a sudden try

9:43to send 30 meg.

9:44And so what's the WAN service provider

9:46going to do other than to start dropping some of that traffic?

9:49Now, we're going to be talking about this mechanism later

9:51on in this course.

9:52It's called policing.

9:53But policing is not going to play favorites.

9:56It's simply going to take a packet in as it arrives,

9:59and it's going to drop it.

10:01Now, if we're lucky, that packet is going to be an email packet.

10:04But if we're not so lucky, it's going

10:06to be a voice over IP packet that gets dropped.

10:08And so wouldn't we rather be in control of the packages

10:10that get dropped?

10:12And this is a fundamental concept of QoS

10:14that we need to understand.

10:15QoS is generally not focused on preventing us

10:18from dropping packets.

10:19When we're out of bandwidth, we're out of bandwidth.

10:22And we're out of Q space, we're of Q space.

10:24And so we are going to have to drop traffic no matter what.

10:27So instead, QoS is about giving us a choice.

10:30What kind of traffic do we want to drop?

10:33I would far rather drop this email packet

10:35right here than choose to drop the voice over IP packet.

10:38That would be my choice, and this

10:40is what is so important for us to understand.

10:43QoS is mostly about giving us control and choice over what

10:47traffic gets dropped as opposed to putting that control

10:49into somebody else's hands.

10:51Whether it's a full queue or whether it's a policing policy,

10:54either way that's outside of our control.

10:56We can use QoS to deliver that control back to us,

10:59then we're in good shape.

11:00So hopefully, it's clear that yes, we

11:02do still need quality of service even in our modern networks.

11:05And that's not just giving lip service to Cisco,

11:07the reality is that not all applications are created equal.

11:10And yes, we like to focus on voice and video,

11:13but it's not just about voice and video.

11:14It's about all these other applications,

11:16and categorizing them, and giving

11:18some of them priority over the other as well.

11:20Now, QoS is needed not just for periods of contention,

11:23but also on the low bandwidth links that

11:25still exist in our network.

11:26And so we're going to see scenarios here

11:28that we can overcome the amount of bandwidth,

11:30even if we throw a bunch of bandwidth at it.

11:33At some point we're still going to see contention

11:35because network traffic is just increasing over time,

11:37and even if we're throwing bandwidth links

11:39at-- or high bandwidth links at something

11:41that looks great today it's not going to necessarily help us

11:44in the future.

11:45That said, we need mechanisms for controlling.

11:49Remember that concept of choice or control.

11:51We're going to need to know which packets

11:53to send in what order, but also when it comes time

11:56to dropping a packet--

11:57and remember, that's the key point--

11:58QoS doesn't stop packets from getting dropped,

12:01it simply gives us the control over which packets get dropped.

12:03And so when those-- it comes time to drop that packet,

12:06if we have control over that, then life

12:08is good because we can prioritize the applications

12:11that need priority.

12:12I hope this has been informative for you,

12:13and I'd like to thank you for viewing.

0:05Well, based on that last video, it

0:06seems clear that we need some control mechanisms in place

0:09in order to give us the control that we

0:11desire to make sure that we can drop

0:12the right packets and such.

0:14Now, when the industry first started

0:15developing QoS mechanisms, as you can imagine,

0:18there were some different options that were explored.

0:20And as a result of that, we have two different QoS models

0:23that we need to understand, the first of which

0:25is called integrated services or IntServ.

0:28IntServ heralds back to the circuit switching days

0:30and tries to replicate that inside of the packet switch

0:32network.

0:33Now, IntServ is not really what I'd say we deploy

0:37in modern networks today.

0:38It's generally considered legacy.

0:39However, a couple of things about IntServ.

0:41First of all, it does still have a place inside of service

0:44provider networks, this concept of traffic engineering and MPLS

0:47circuits.

0:47So we do still have a place for it in modern networks.

0:50But at the same time, Cisco also expects

0:52us to understand IntServ, especially when it

0:54comes to exams and such.

0:56So it is important that we understand it,

0:58and that's why we're going to start with this.

0:59It's always great from a history perspective

1:01to understand maybe where we started to fully understand

1:04why we are where we are.

1:05And that would be with the second model, the DiffServ

1:07model.

1:08But first let's start with IntServ, and in the next video,

1:10we'll explore DiffServ.

1:11Let's dive in.

1:12Once upon a time, our phone calls

1:14happened across what we'd call a circuit switched network.

1:16I think about when I was growing up

1:18and the phone was hanging on the wall

1:19and we had the cord that would go to the earpiece.

1:22I'd hold it up to my head.

1:24And calling my friend across the line,

1:26we didn't need to worry about QoS on the circuit.

1:28And the reason for that is because it was truly

1:30a circuit, a circuit being a dedicated connection

1:33between our two phones.

1:35It didn't matter how much we were talking.

1:36In fact, I could totally prank my friend and be like, hey,

1:39can you just wait just a few seconds?

1:41I'll be back.

1:42And I'd set my phone down on the counter maybe,

1:45and I just run off and play a video game.

1:47And my friend's sitting there just waiting, like, all right,

1:49is he coming back?

1:50[LAUGHS]

1:51And the fact that we're not talking at all

1:54means nothing for this circuit.

1:55The entire bandwidth, so to speak, of that circuit

1:58was being consumed even though no words were being said.

2:01And this lack of efficiency is one

2:04of the reasons why we migrated from circuit switch networks

2:06to packet switch networks.

2:08Now if nobody is speaking on a voice over IP connection,

2:11we're not sending any packets at all.

2:13And therefore, the efficiency is maximized.

2:15However, it causes a different problem,

2:17which is what we saw in the last video, which

2:19is that, in a packet switch network,

2:20we are sending lots of different packets

2:22from lots of different sources, usually onto a single wire.

2:26And so this contention has caused additional problems.

2:28In order for us to maximize the efficiency of our links

2:31by taking advantage of packet switch networks,

2:33well, now we need these QoS mechanisms.

2:35Well, one of the early models that

2:37was developed in order to solve this problem

2:39would be the IntServ model.

2:40And the IntServ model is trying to replicate the circuit switch

2:43nature of what we used to have.

2:46And really, when we to talk about circuits, what we're

2:48talking about is a guarantee.

2:50We want to guarantee that a particular traffic flow has

2:53the bandwidth and the priority that it

2:55needs to get across the network in a timely fashion.

2:58In other words, if I have a switch here,

2:59on one end of my network, and a switch on the other end

3:02of the network, it doesn't really

3:03matter how many routers and switches I have in the path.

3:06If all of these devices can guarantee

3:08that I can build sort of a circuit between these two

3:12devices, this circuit essentially

3:14equates to, again, bandwidth and maybe a priority

3:17level that's going to make sure that the packets get

3:19across the network.

3:20And we're going to rely on a specific protocol

3:22in order to accomplish this, and that would be the resource

3:25reservation protocol, or RSVP.

3:27Now, if you maybe aren't a native English speaker,

3:30you might be saying, well, wait a second, Jeff,

3:32the resource reservation protocol should be RRP, not

3:35RSVP.

3:36What's going on here?

3:37And the reality is that RSVP is actually a French word.

3:41I know I just said English speaking,

3:43but there's a reason for that.

3:44RSVP is based on a French phrase,

3:46and I'm going to ask my French-speaking friends

3:49to forgive me for this.

3:50I'm going to attempt to pronounce it.

3:52It is [SPEAKING FRENCH].

3:54And in English, that means please respond.

3:57And in English-speaking cultures,

3:58even though this is a French phrase,

4:00we like to use RSVP on party invitations.

4:03So I might send out a wedding invitation or a birthday party

4:06reservation.

4:07I send these invitations out, and I say RSVP on it.

4:11RSVP means literally, again, please respond.

4:14Tell me if you're coming.

4:15And so the person who receives the invite

4:17is going to send back an RSVP that says,

4:20OK, I'm coming and so is my spouse,

4:22and so there are two of us coming.

4:24And so now the party host knows that they

4:26need to prepare food and prepare whatever

4:28is happening for those two people who are coming.

4:31So anyways, that's a little aside,

4:33but that's why we call the resource reservation protocol

4:36RSVP.

4:37Either way, RSVP is going to be a protocol that

4:39runs on all of these devices in the network.

4:42And so when a device comes onto the network and wants to send

4:45a particular traffic flow-- let's say it's a voice over IP

4:48stream--

4:49then we can send a reservation request upstream.

4:52And that reservation request is going

4:54to be propagated throughout the network in order

4:57to figure out if it can accommodate that reservation

4:59request.

5:00If so, the bandwidth that's being requested

5:02will be carved out, really truly reserved for that traffic flow,

5:06again, essentially establishing a circuit

5:08of guaranteed bandwidth between two different networking

5:11devices.

5:12Now, there are two different message types in RSVP

5:14that we need to be aware of.

5:15First of all is the path message type.

5:17The path message is sent originally

5:19as part of that request.

5:20So I called it a reservation request.

5:22Let's call it what it really is, and that

5:23would be a path message.

5:25The path message is going to be propagated

5:27throughout the network in order to make

5:28sure that we have the bandwidth that the requesting device

5:32wants to guarantee for itself.

5:33Assuming that we do, we send a different type of message back.

5:37And that would be the RESV, or the reservation message,

5:40that's going to be propagating back,

5:41locking in that bandwidth for the requesting device.

5:44We start with a path message, we end with a reserve message,

5:47and that is what carves out our bandwidth guarantee.

5:50So let's say this device wanted to curve out 100 kilobits

5:52per second of bandwidth.

5:54And we send the path message.

5:55The reserve comes back.

5:56Everything is good.

5:57We are locked in at 100 kilobits per second.

6:00But now, all of a sudden, I send 200 kilobits per second.

6:03Well, what exactly is going to happen in this scenario?

6:05Because this would be like me saying,

6:07hey, I'm just bringing my spouse.

6:09But then I show up with my three kids,

6:10and so there's really five of us.

6:12And we're all hungry, and we're all going to eat a lot of food.

6:14I mean, that's kind of rude, right?

6:15I shouldn't have shown up with more people

6:17than I reserved at that party.

6:19In the same way, I can't necessarily

6:21guarantee that you're going to get

6:23200 kilobits per second of throughput

6:25when you only requested 100k.

6:27We have two different options in RSVP.

6:29First of all, we can't actually police that traffic.

6:32So remember, we used this phrase in the last video.

6:34Policing is the concept of dropping traffic

6:36that is exceeding a particular service level agreement

6:39that we've established.

6:40In our case, we've established 100k,

6:43but 200k is what you're actually trying to send.

6:45However, RSVP can also be configured

6:47to allow that traffic.

6:49If, for example, I'm sitting on unreserved bandwidth,

6:51maybe only 50% of my bandwidth has

6:53been reserved but I still have hundreds of kilobits

6:55and maybe even mega or gigabits per second of bandwidth

6:58available, well, then, by all means,

7:00allow the extra 100k to go through because there's

7:03no reason to drop it.

7:04Now, eventually, every good party must come to an end.

7:07And at some point, that phone call is going to hang up

7:09or that traffic stream is going to end.

7:11And so once that traffic has stopped for a particular amount

7:13of time, well, we're going to go ahead and cancel

7:15the reservation, freeing up that bandwidth

7:17to be reserved by a different traffic flow.

7:19Now, let's think through some of the benefits of the IntServ

7:22model, because it truly does have benefits even

7:24over the modern DiffServ model.

7:26There are reasons why it existed and why

7:28it was a benefit to networks, the first of which

7:31is this concept of guaranteeing.

7:33This guarantee is unique to the IntServ model.

7:36We don't see this showing up in the DiffServ model.

7:39If you need 100 kilobits per second,

7:41I guarantee that you can have 100 kilobits per second.

7:45That is fantastic.

7:46And furthermore, the control that we

7:48have in allowing applications to reserve traffic,

7:51I might allow voice over IP traffic flows

7:53to reserve bandwidth.

7:54But I don't want to give email or internet traffic the ability

7:58to guarantee itself bandwidth.

8:00However, as you can imagine, if this

8:02is more of a legacy protocol, then there

8:03must be some downsides to this.

8:05And there certainly are downsides

8:07that keep us from deploying this into the modern networks.

8:09The biggest downside is going to be

8:11the efficiency of our design.

8:13Remember, we had a problem with efficiency

8:15with circuit switch networks.

8:17There was a problem up here.

8:18If I pranked my friend and we aren't even talking at all,

8:21we are still reserving all of that circuit, the entirety

8:24of that circuit for ourselves.

8:26And this is why we went to packet switch networks.

8:28And so you can imagine, if we're trying

8:29to replicate circuit-switching on top of packet-switching,

8:33well, that's going to have some of the efficiency problems

8:35that circuit switch networks had.

8:37The same concept, right?

8:38I have requested 100k, but I'm only

8:40using 10 kilobits per second of that bandwidth.

8:43I was guaranteed that bandwidth.

8:45So I can't simply allow a different application

8:48to use the 90k that I'm not using.

8:50That's not a benefit or that's not

8:51a feature of the IntServ model.

8:54Furthermore, it's all or nothing.

8:56If I need 500 kilobits per second of throughput

8:58on this link and there isn't that much available,

9:01then I get no guarantee.

9:03That path message isn't going to complete.

9:05I don't get the reserve message in response.

9:07And so I'll end up with nothing.

9:09So even though I needed some level of network guarantee,

9:12I'm not getting anything whatsoever.

9:14And lastly would be the scaling challenges

9:16that are going to come along with this.

9:17Imagine trying to put these network guarantees

9:21across a very large enterprise network.

9:23Imagine a network as large as Cisco, for example, trying

9:26to guarantee a particular amount of bandwidth

9:29across the entire infrastructure.

9:31And so because of these downsides,

9:32this is why we looked into a new way of doing things.

9:36And that would be the DiffServ model

9:37that we're going to be talking about in the next video.

9:40So in review, the IntServ model is

9:41going to work by guaranteeing bandwidth.

9:44We guarantee bandwidth to traffic flows.

9:45And the way we do that is with that resource reservation

9:48protocol, otherwise known as RSVP.

9:50Now, the benefits of IntServ are pretty great.

9:52We can guarantee bandwidth to a traffic flow.

9:54It gives us absolute control over which applications

9:57can even make those requests, or at least

9:59which of those requests we'll actually abide by.

10:01But the downsides are pretty great.

10:03It's not the most efficient use of our network bandwidth.

10:06And furthermore, it causes a lot of efficiency problems

10:09and scaling issues that we're just not

10:11sure exactly how we can accomplish

10:14that, some of those things, with the IntServ model.

10:16And that's why we created a new model.

10:18We have the DiffServ model.

10:19And in the next video, we're going

10:20to be exploring exactly how the DiffServ

10:22model solves all of the problems that we have with IntServ.

10:24I hope this has been informative for you.

10:26And I'd like to thank you for viewing.

0:00[CBT NUGGETS JINGLE]

0:05All right, enough with the history lesson.

0:06It is time to jump into the DiffServ model.

0:09The DiffServ model is what we deploy into modern networks.

0:11It's concepts such as IP precedence and DHCP

0:15and per-hop behavior.

0:16Some of these acronyms that you've probably heard,

0:18especially if you've already been

0:19swimming in the collaboration space for some time.

0:21Now in this video, we're going to explore

0:23how exactly the DiffServ model differs from the IntServ

0:25model and some of the terms and concepts

0:27that we need to understand moving forward

0:29as we continue to explore this.

0:30Let's dive in.

0:31The DiffServ model is going to fully embrace

0:33this nature of a packet switch network.

0:36Again, we moved to packet switch networks for a reason.

0:39It's to gain efficiency.

0:40But at the same time, the packet switch

0:42networks are why we have these problems of contention

0:44and why we need quality of service.

0:46But the reality is that if we can embrace packet switch

0:48networking when it comes to our problem solving mechanisms,

0:51then we probably accomplish what we're

0:53trying to accomplish in a better fashion.

0:55Or at least that's the theory of the DiffServ model.

0:57The DiffServ model is going to differ from the IntServ

1:00model in that there is no such thing as a resource

1:03reservation.

1:05Again, this is one of the perks of the IntServ model.

1:07It's one of the best things about it.

1:09But at the same time, we don't necessarily

1:10need to reserve bandwidth across an entire network for a traffic

1:14stream.

1:14It's not the most efficient use of resources, as we discussed,

1:17and so let's not reserve bandwidth.

1:20But instead, let's classify our network, first of all.

1:24And second of all, we're going to apply policy

1:26against that classification.

1:29Let's see this in action.

1:30Let's say we have three routers in the path here.

1:33And so what we have is we have some links between them,

1:35maybe with some limited bandwidth that play.

1:37And so we have network traffic showing up here

1:39on the ingress router that's destined

1:41for some host outside the egress router.

1:43So we'll call this ingress, and we'll call this one the egress.

1:46And so what's going to happen here

1:47is we're going to classify this traffic as it

1:49arrives on our network.

1:50And when we talk about classification,

1:52what we're really saying is that we're

1:53going to tag this traffic.

1:55We often talk about tags in the QoS and networking space.

1:57We're going to go into more detail on these tags

1:59here in a little bit.

2:00But again, we're not guaranteeing anything

2:02with this packet.

2:03When it shows up, we simply classify it,

2:05and we forward it on.

2:06Now this router here, in the middle,

2:09it's going to receive that traffic.

2:10It's going to check the classification,

2:12and it's going to apply policy against that classification.

2:16That policy is defined on that router.

2:18That router might say, hey, prioritize that traffic.

2:21It might say, make sure that it's

2:23guaranteed at least 60 kilobits per seconds.

2:25Whatever that policy is is specific to this router.

2:29And this router is going to send it on in hopes

2:32that this router here, on the other end,

2:34is going to have a similar policy.

2:36But the reality is that these two policies might

2:38be different from one another.

2:40And this is why we call this a per-hop behavior, or PHB,

2:43within the DiffServ world.

2:45The way we define per-hop behavior is sort of how it

2:47sounds--

2:48per-hop.

2:49And every networking hop, we're going to define the behavior--

2:52or in other words, the policy--

2:53for that traffic.

2:54And so with the IntServ model, we recall,

2:56IntServ is going to guarantee policy

2:59stretched from one end of the network to the other.

3:02But the DiffServ model relies on these per-hop behaviors.

3:05And yes, ideally, our policies are in alignment,

3:07but that's not necessarily the case.

3:09In fact, that can be one of the challenges of the DiffServ

3:11model is to make sure that our policy is network-wide

3:14consistent.

3:15All right, so we talked about this classification concept--

3:18in other words, network tags.

3:19So what does this actually look like?

3:21We have three primary ways of tagging packets.

3:24The first of which is going to be called class of service,

3:26or COS.

3:27Class of service exists within the Ethernet frame.

3:30And not just within the Ethernet frame, but specifically

3:33within the VLAN tag inside the Ethernet header.

3:36This means that's a Layer 2 concept,

3:38and we dedicate 3 bits to it.

3:40Now if we do our binary math right,

3:423 bits means that we have 8 different values

3:44available to us in the class of service.

3:46Next, we have the concept of IP precedence.

3:48IP precedence is essentially the Layer 3 equivalent

3:51of class of service.

3:53And we occasionally might see the spelled out as IPP,

3:56or otherwise abbreviated as precedence.

3:58Unfortunately, it's part of the native IP header.

4:00So with Ethernet, if we don't have a VLAN header,

4:03it's kind of hard to contain a class of service tag.

4:05That's a concern in the Ethernet world.

4:07But with IP, it's just part of the header.

4:09Now, this exists at Layer 3, meaning

4:11it's not going to change from hop to hop, which is good.

4:14But furthermore, we still dedicate 3 bits

4:16to it, which again means that we have different values of IP

4:18precedence.

4:19Now the last one might be the one

4:20that we've heard the most about, especially in terms

4:23of modern networking tagging.

4:24And it is called, and I'm going to spell

4:26this all out, differentiated services code point.

4:29And if we were to write this out as an acronym,

4:31it would be DSCP.

4:33Now, DSCP is interesting because it actually also exists

4:36within the IP header.

4:37And furthermore, it actually exists on top of IP precedence.

4:41See, when IP precedence was developed,

4:42we actually took 3 bits out of 8 that were reserved.

4:45And so we had all of these extra bits that were just

4:47sitting there being unused, and so those

4:50who were making the decisions at that point decided,

4:52you know what?

4:52Let's take 3 more of those bits.

4:54And so now we have 3 bits for IP precedence, another 3

4:57bits for DSCP for a 6 total.

4:59And then another 2 that are reserved.

5:01And in fact, they're actually now used

5:02for other QoS mechanisms.

5:05So in that sense, yes, it's IP, and yes, it's Layer 3.

5:07But we actually have all 6 bits available to us--

5:09the 3 from IP precedence and the 3 from DSCP.

5:12And so again, let's do our binary math correctly here.

5:152 to the 6th power, this would be 64 different values

5:18that we have available to us in the DSCP space.

5:21So let's see this in action.

5:22When we have a packet arriving on this ingress router,

5:25now we're truly talking about inserting a tag into it.

5:27So let's say we choose an IP precedence value of 5.

5:31We're going to place 5 in there.

5:33That would be binary 101 inside of those 3 bits

5:36that have been reserved for IP precedence tags.

5:39But now we have this tag of 5 inside the IP header.

5:42We send it on to the next router, that middle router,

5:45and it's going to check its policy against a IP precedence

5:49value of 5.

5:51But we might say hey, an IP precedence value of 5

5:54means that we reserve 100 kilobits

5:56per second of throughput for packets that have that value.

5:59And we might prioritize how quickly

6:00we get that packet out using mechanisms

6:02that we're going to be discussing later

6:04on in this course.

6:05But here is what's key about the DiffServ model.

6:07We're going to apply our policy and send it out

6:09to the egress router.

6:10And as we indicated earlier, this egress router

6:13might have a completely different policy.

6:15Maybe this router was configured, correctly

6:17or incorrectly, to only guarantee

6:1950 kilobits per second to that particular tag.

6:22And so this is where we need to make sure

6:24our policy is in alignment everywhere.

6:25But at the same time, this is the important concept

6:28of per-hop behavior.

6:29So let's make sure that we understand that when

6:30it comes to the DiffServ model.

6:32So when it comes to the benefits of why we are deploying

6:35the DiffServ model into our modern networks today,

6:37the primary one is the efficiency.

6:39In fact, we could almost flip this conversation on its head.

6:42We recall that one of the downsides to IntServ

6:44was efficiency, but also scaling.

6:46And scaling at this level is pretty

6:48simple from the perspective of we're not actually

6:52agreeing with other routers how we're going to handle traffic.

6:54We simply deploy policy everywhere.

6:56It doesn't matter how many routers and network devices

6:59we have at that point.

7:00But then we do still need to consider the downsides

7:02to this model.

7:03And one of which we just talked about.

7:05Even though scaling is great, and we can deploy this

7:07across hundreds of routers, making sure

7:09that our policy stays consistent everywhere

7:11is going to be one of the biggest challenges

7:13that there is to deploying the DiffServ model.

7:15And I wish I could say that it's just

7:17a matter of making sure we copy and paste everything correctly,

7:20but the reality is that we have different QoS

7:22mechanisms in different domains or different parts

7:24of our networks.

7:25If we think about data centers, for example,

7:27and the way QoS is deployed on data center switches,

7:29is different than how we deploy it in campus switches.

7:32Not to mention the WAN space.

7:33In the WAN space, we've got different amounts of bandwidth

7:36available to us in the WAN environment.

7:38And so we can't simply copy a policy.

7:41Let's say we've got this policy here,

7:43and we want to copy this into a WAN router that maybe

7:46is connected this way, well, this WAN router

7:48has a whole lot less bandwidth that it needs to consider.

7:51So we can't simply take one policy

7:52and copy and paste it onto another device.

7:54First of all, that device might have different QoS commands.

7:57But second of all, we might not want exactly the same policy

8:00on every one of these routers.

8:02They need to be consistent and in alignment,

8:04but that doesn't mean identical.

8:06Furthermore, changes in this environment can be a challenge.

8:09It's one of the reasons why we've

8:11delved into the world of network automation.

8:12In fact, I remember going to Cisco Live back

8:15in the early 2010s.

8:16And one of the biggest problems that was trying to be solved

8:20was this idea of changing QoS.

8:23Again, imagine that I've got this policy all established.

8:25I've deployed all of these policies.

8:27And I've decided that 10% of my network bandwidth

8:30is going to be reserved for voice over IP.

8:32And that sounds great, and we deploy the policy and life

8:35is good for a couple of years.

8:37But then we find that we've injected so much new traffic

8:39onto our network that we'd actually

8:41need to tweak this value.

8:43We need to make it, let's say, 12% of our bandwidth or 15%.

8:48Well, how exactly are we going to make that change?

8:50Well, in the DiffServ model, we don't have a choice.

8:52We're going to have to go to every single device

8:54and change the way that their policy is configured.

8:57And that, as you can imagine, is no small task,

8:59which is why when I was at Cisco Live,

9:01I saw several vendors touting their ability

9:03to go out and automate the deployment and the changing

9:07of QoS policies.

9:08They'll simply go into a GUI and say, hey, instead of 10%,

9:11make it 12%.

9:12And it would still manually go out

9:13to all of these different routers and switches

9:15and make the changes.

9:16And that was using early concepts of automation.

9:18Fortunately, today, we have much more advanced forms

9:20of automation.

9:21But this is one of the reasons why

9:23we want to deploy and at least consider

9:25deploying automation to our network

9:26is so that we don't have to deal with this particular downside

9:29of the DiffServ model.

9:31And as we see, there's no perfect way of deploying QoS.

9:33However, DiffServ does things differently

9:35and in a much better way for our modern networks.

9:37And the way it does that, first of all,

9:39is by offering no guarantees or reservations at all.

9:42Instead, we use this per-hop behavior methodology,

9:44which involves configuring classification

9:46and policy deployed against that classification.

9:48Now, the way we do classification

9:50is by tagging packets.

9:51And we saw we have three different ways

9:52of tagging packets.

9:53We have class of service, IP precedence,

9:56and usually what we use in, again, more modern networks,

9:58DSCP.

10:00Now, the benefits of DiffServ are pretty

10:02clear from the beginning.

10:03Again, we're embracing packet switch networking.

10:05So efficiency and scaling, these are huge.

10:08As our networks get very, very large,

10:09we need to make sure that we're using the bandwidth as

10:11efficiently as possible.

10:13But again, we don't want to base the size of our network

10:15on our QoS mechanisms.

10:17We want to be able to grow as large as we need in order

10:19to meet the needs of the business.

10:22And so, that said, again, we know that there

10:24are challenges with DiffServ.

10:25And so some of these challenges are deploying

10:27a consistent end-to-end policy, making sure all of our policies

10:30are in alignment, and life is good.

10:32But again, making sure that we can deploy our policies

10:36across different domains and even different types of devices

10:39that have different QoS commands, and as we saw,

10:41making changes.

10:42So we've got ways of getting around some of these

10:44and dealing with these.

10:45I mean, everyone in the networking world

10:47wants to solve pain points.

10:48And so network automation might be one of those.

10:50But again, from the beginning, let's just

10:52recognize that there are some challenges with DiffServ,

10:54and we need to keep those in mind

10:55when we're doing our network designs.

10:57I hope this has been informative for you,

10:59and I'd like to thank you for viewing.

0:05I know, I know.

0:06The skill is called Describe Quality Problems

0:08and here we are on the fifth video

0:10ready to talk about quality problems.

0:12But it made sense to establish a baseline for our QoS mechanisms

0:15so that now, we can actually talk

0:16about what some of these challenges

0:18are that we're going to face in our networks.

0:20So in this video, we're going to look at some of the things

0:23that Cisco specifically calls out on their blueprint.

0:25We're thinking about latency and jitter and such.

0:28And these are concepts that we talk about a lot in our network

0:31designs and just supporting troubleshooting networks.

0:34But do we actually understand what exactly jitter is

0:36and how we calculate jitter?

0:38Because I know for most of my network career,

0:40I didn't actually know how to calculate jitter.

0:42But I can promise you that Cisco expects

0:44us to understand that if we want to pass the collaboration core

0:47exam.

0:48So in this video, we're going to explore some of these concepts.

0:50We're also going to take a look at bandwidth, which

0:52is interesting because Cisco calls out

0:54our need to understand bandwidth as part of this blueprint item.

0:57And bandwidth might not work the way you think it does.

1:00And so we're going to explore exactly how bandwidth is

1:02calculated and how that affects our QoS

1:04mechanisms in this video.

1:06Let's dive in.

1:07Let's start off with the concept of latency.

1:09Latency can sometimes be referred to as delay.

1:12Latency is usually measured as around trip time or RTT.

1:15What that means is when I'm going

1:17to send a ping, maybe from one end to the other or one device

1:20to another, we're going to measure

1:22the latency of not only the packet getting there,

1:24but then we add in the time that it takes for the ping response

1:27to come back.

1:27And that's simply because without some pretty fancy

1:30coordination, which does exist in the networking

1:32world, for the most part what we're doing is

1:33we're recording the time that we send the packet,

1:36and we compare that to the time that we receive the response.

1:39And that tells us the total trip time, the round trip time,

1:42as we again call it.

1:43Now, delay inside of a LAN space,

1:45we should expect to see this far below 10 milliseconds.

1:48In fact, in a lot of cases, we might even

1:49see it below 1 millisecond.

1:51And ideally, that's the case.

1:53However, when we step into the land space,

1:55we might see this in the tens of milliseconds.

1:57So maybe 10 plus milliseconds 20, 30, 40.

2:00We could also get into the hundreds of milliseconds,

2:03especially for winds that cover great distances

2:05or maybe use an inconsistent technology like wireless.

2:08Now, the ITU specification of G-114 114

2:11specifies that for voice over IP packets, ideally

2:15we have less than 150 milliseconds

2:16of latency between our two endpoints.

2:18However, what's important about this value is that this is

2:21a one way value, meaning that if we have 150 milliseconds--

2:25let's look at our diagram up here--

2:26150 milliseconds to the other endpoint, then that's OK.

2:30Which means that from a round trip time perspective,

2:32we could actually achieve 300 milliseconds.

2:35If we were to send a ping, for example, we

2:37wait for the ping response and our computer

2:39says that was a 300 millisecond response.

2:42In theory, that's OK, keeping in mind

2:44that just because it's 300 milliseconds doesn't mean it

2:46was 151 way and 150 back.

2:49It could have been 100 one way and 200 back, and that

2:52would end up causing problems.

2:53Next up is the concept of jitter.

2:55There is a fun one because I think we all

2:57have an idea of what jitter is.

2:58Meaning that if nothing else, I might actually

3:02know what jitter sounds like when I'm having a phone call.

3:04It sounds like my voice speeds up really fast

3:06and then it gets sketchy, and I can't really hear,

3:08and then speeds up real fast.

3:10That would be jitter.

3:11How exactly do we measure jitter,

3:13and what's it measured in?

3:14Well, here's how we do jitter?

3:16Let's say we run a bunch of ping tests,

3:18and our ping tests come back and we get something

3:20like 90 milliseconds back, and then

3:23we get 105 milliseconds, and then 90 milliseconds again,

3:28and then 85 milliseconds.

3:31So with four different latency measurements,

3:33now let's take a look at what the jitter looks like.

3:35And the way we look at jitter is by taking the difference

3:38in delay between two consecutive measurements.

3:41And so when we look at this, this

3:42is a 15 millisecond difference between the 90 and 105.

3:46And then from 105 to 90, we see another 15 milliseconds.

3:50And then from 90 to 85, we see 5 milliseconds.

3:53So once we've completed our measurement

3:55and we have our differences, what we're going to do

3:57is we're going to average these out.

3:59In other words, we would take 15, plus 15, plus 5.

4:02We would divide that by 3 to average it

4:04across to three differences that we've calculated.

4:07And so 35 divided by 3, that's going to be roughly 11.67

4:12milliseconds.

4:13So 11.67 milliseconds is our jitter measurement,

4:16which means, yes, we do measure jitter in milliseconds just

4:19like we do latency.

4:20However, it's looking at something very different.

4:22It's looking at the idea that the latency varies over time.

4:26As we can see, maybe the latency is longer in some cases

4:28and shorter in others.

4:29That might mean we have a great connection at times,

4:32and then the connection doesn't get so great.

4:34And in the world of voice over IP,

4:36I would rather have a longer latency that

4:38is more consistent than have occasionally--

4:41if I'm going from 30 up to 150, this is really bad.

4:44This is a lot of jitter.

4:46If however, I get several measurements of, let's say,

4:48about 120--

4:49maybe 120, 121, 119.

4:52Yeah, it's longer latency, but the jitter

4:54is phenomenal in this case.

4:56I'm going to have a consistent experience

4:57throughout the entirety of my phone call if my jitter is low.

5:00So now you may say, OK, so what is a recommended

5:03amount of jitter on a network?

5:05And Cisco recommends less than 30 milliseconds

5:07of jitter when it comes to voice over IP.

5:09This is ideal if we see much more than 30 milliseconds

5:12of jitter, then we are going to start seeing

5:14an impact on our voice quality.

5:16Next, let's talk about packet loss.

5:18In the world of networking, we can drop packets

5:20for a whole lot of reasons.

5:22Let's think about that.

5:23Why would I drop a packet?

5:25Well, the primary reason is going to be network congestion.

5:28When I'm playing video games online and all of a sudden I

5:31get a lot of lag, usually that's because a router somewhere

5:34in the internet is overloaded and it's dropping my packets.

5:37However, there could be another reason.

5:39Maybe I have a bad connection.

5:41What if I'm on wireless, and my Wi-Fi connection

5:43all of a sudden drops?

5:45Or maybe I decide to go to a cafe and play there.

5:49[LAUGHING] Play my video games in a coffee shop,

5:52and their Wi-Fi connection is just not great

5:54because there's 50 people there all

5:55trying to compete in the wireless space.

5:57And so there's dropped packets everywhere.

6:00Now, while I would consider these the primary reasons why

6:02we drop packets, there are certainly other reasons.

6:05For one, we might have malformed packets.

6:08My networking hardware my NIC on my PC might simply mess up.

6:12It happens.

6:13It's hardware.

6:14It's not perfect.

6:15So it forms the packet improperly,

6:16and that packet eventually gets dropped by a networking device

6:19that realizes it's malformed.

6:21And simply, hardware failures.

6:22What happens if a router happens to have a bunch of my packets

6:26all queued up ready to send, and that router just dies?

6:28It loses power.

6:29Whatever happens, all of my packets

6:31have now been lost that that router was storing.

6:34And so even though these aren't as likely to occur,

6:37it certainly can cause packet loss.

6:39Now, we're looking at packet loss across the network,

6:41we're going to measure this as a percentage.

6:43When it comes to voice over IP, typically, we want less than 1%

6:47of packet loss on the network.

6:48Otherwise, we're going to start seeing an impact on our voice

6:51calls.

6:52Now, latency jitter and packet loss

6:53are going to be three parameters that our network is

6:55able to evaluate and measure.

6:57And what we like to do is combine all three of these.

7:01So latency, jitter, and packet loss

7:04are going to combine these into this concept of mean opinion

7:07score, MOS.

7:09Mean opinion score is going to be a value between 0 and 5,

7:11and yes, it can be fractional.

7:13So we could have a MOS value, for example, of 1.3.

7:16That would be a really bad MOS score, by the way.

7:19Now, essentially, what we're doing is

7:20we're trying to relate this back to as if we were asking people.

7:23If we were to take the opinions of several users

7:26who just got done with a phone call-- we said, hey,

7:28how good was this phone call?

7:30Rate it from 0 to 5.

7:31What would those users respond with?

7:33Then maybe we take those opinions,

7:34and we find out based on the quality

7:36of that voice call that our mean opinion score is 4.4.

7:40Well, that's pretty good.

7:41That's not too bad.

7:42Now, compare that to 1.3.

7:44If somebody truly said 1.3, then that

7:46would be pretty bad overall.

7:48Now, unless you want to go out and actually poll

7:51the opinions of all of your users,

7:53we're not going to calculate MOS by tracking how

7:57people felt about phone calls.

7:58Instead, we're going to take these parameters-- latency,

8:01jitter, and packet loss are going to automatically

8:04calculate out what the MOS is.

8:06Furthermore, certain codecs that we

8:08might use for our voice over IP and for our video

8:11are going to have different expectations for a mean opinion

8:13score.

8:14For example, the more compressed that our voice traffic is, then

8:18the lower MOS score we can expect.

8:20There's not just about maximizing the MOS score,

8:22it's more just understanding that we can use the MOS scores

8:26in order to figure out whether our call quality is

8:28at an acceptable level.

8:29Now, I promised a bandwidth conversation.

8:32So let's go ahead and unpack what

8:33exactly Cisco might want us to understand about bandwidth.

8:36And before we talk about bandwidth,

8:38I want to use a kind of a real world example.

8:41Let's say you're at a car, and you're

8:42driving down the highway.

8:44And you look at your speedometer,

8:46and it says that you're going 50 miles per hour.

8:49Now, I don't want to get too deep into the physics world,

8:52but there is no such thing as saying

8:55that I'm going at a particular speed at a particular moment

8:58in time.

8:59And here's the reason for this.

9:00If I take a car, and I want to know how fast it's going,

9:04I need to look at how far the car travels

9:07in a particular moment of time.

9:08It looks something like this.

9:10I might travel, let's say, half of a mile,

9:13and that occurs in 0.01 hours.

9:160.01 hours should be roughly 36 seconds.

9:19Now, I'm going to take that, I'm going to say, OK, 0.5 miles,

9:23I'm going to divide that by 0.01 hours.

9:26And guess what, that calculation equals

9:2850 miles per hour, which is really just saying

9:32miles divided by hours.

9:34Why in the world am I bringing up

9:35a physics lesson as part of bandwidth conversations?

9:38Well, here's the key point.

9:39When I'm going to calculate out my speed,

9:42I want to figure out how fast I'm going,

9:43look what I had to do.

9:45I had to calculate that out over time.

9:48To say that I'm going 50 miles an hour here,

9:50or that I'm going 50 miles an hour here is erroneous.

9:53It's not correct.

9:54I'm not actually going any particular speed

9:57at that moment.

9:58I'm simply in a location.

10:00If I want to know how fast I'm going, I have to figure out,

10:02OK, I was here at this time, I was here at this time,

10:05and now I can figure out how fast

10:07I was going as an average across that time period.

10:10And guess what?

10:11Bandwidth is the same concept.

10:12Replace my cars with bits, and we're

10:14going to see that we have the exact same idea of calculating

10:18out a number of packets or really, a number of bits

10:20that I've sent across a particular time interval.

10:23And just like with our car scenario, that means

10:25I can never look at a specific moment in time

10:28and say that I am sending 10 kilobits per second

10:31that's impossible.

10:32I can only say that if I average that out over a time period.

10:36Let's investigate this concept a little bit further.

10:38In fact, I like to think of bandwidth

10:40as this concept of a conveyor belt. When I think of conveyor

10:43belts, I think about factories, where these wheels are spinning

10:46at a particular speed and the treads

10:48are moving in a particular direction.

10:51So now, I can place a part on this part of the conveyor belt,

10:54and as it moves, a machine can add something to it.

10:57So maybe now it looks like this.

10:59And then I add something to that.

11:01And so now, it looks a little bit more like this.

11:03And so in the factory process, that piece

11:06moves at a particular speed regardless of anything

11:09else that's happening to it.

11:10And then when it gets to the other side,

11:12it can be processed and sent out.

11:14However, in our factory example, let's say

11:16we have a worker over here who's assembling these devices that

11:19need to be placed onto the conveyor belt.

11:21And let's say this worker is superefficient,

11:23and he or she is creating these things faster

11:26than what the conveyor belt can keep up with.

11:28What's going to happen here right before the conveyor belt?

11:31What's going to happen is we're going

11:32to have a stack of these devices that are all waiting

11:35to be placed on the conveyor belt

11:36because again, the conveyor belt is only

11:38moving at a particular speed.

11:40And whether I have lots of devices to put on the conveyor

11:42belt or whether I have zero devices

11:44to put on the conveyor belt, the speed of the conveyor belt

11:46is the same.

11:47All right, now let's bring this back to networking.

11:50When it comes to bandwidth, it's like a conveyor belt.

11:52If I have a 100 meg ethernet connection that

11:56is going to operate at hundred megabits per second, period,

11:59end of story.

12:00It is a conveyor belt that has been

12:01tuned to a particular speed.

12:03And now, from a networking perspective,

12:05these individual parts or these packages

12:07or whatever we're putting onto the conveyor belt,

12:09these are actually bits, 0s and 1s

12:12that we need to propagate on this link.

12:14Because remember, we're talking about a hundreds

12:16megabits per second, and that's how we measure our bandwidth.

12:19And so yes, we might actually have

12:20a packet that shows up that consists of a bunch of bits.

12:24But either way, we need to make sure

12:25that we're thinking about things correctly.

12:27And so these individual bits keep stacking up,

12:30and in our factory example, what happens if we run out of space?

12:33What happens if we truly run out of floor space?

12:36We might be able to tell this worker, hey,

12:37just go take a break.

12:38Go take a long walk.

12:40We're going to wait for the conveyor belt

12:41to catch up, basically, to all of the production that you've

12:44created.

12:46But on a networking example, we don't have

12:47a person that's creating these.

12:50Instead, we have all kinds of network devices

12:52that are sending bits and packets to this device,

12:55and they're stacking up.

12:56But we can't tell those devices to, hey,

12:58stop sending us traffic.

12:59So instead, what we're going to do

13:00is we're going to start dropping packets.

13:03These packets that come in that have more bits than we can

13:06store are going to get dropped.

13:08Now, this brings up two important concepts when

13:10it comes to network bandwidth.

13:11First of all, if I'm going to look

13:13at the utilization of a link.

13:15For example, on this connection, maybe, I'm

13:16using 85 megabits per second.

13:19Where is my network device getting that value?

13:22Well, based on this whole conversation up here,

13:24it's taking that as an average over time.

13:26In other words, I can never look at a link

13:28and say, hey, I am at 85 megabits per second exactly.

13:32That's not a thing.

13:33All I'm looking at is I'm averaging out

13:35over a particular set of time, which

13:37is going to vary by device how many bits I have sent

13:40in that particular time frame.

13:42And that brings up a second important concept,

13:44which is that I might all of a sudden spike my network traffic

13:48and start dropping packets before I'm expecting to.

13:51If I were to look at this and say at face value,

13:53I'm 85% network utilization.

13:56This is great because I have 15% of my network bandwidth left.

13:59That's plenty of bandwidth overhead, right?

14:02Well, wrong.

14:03And the reason for that is because, first of all,

14:06this is an average over time, and second of all,

14:08because we understand we're not just dealing

14:09with a particular number.

14:11We're really dealing with this concept of stacking up bits

14:14here on the left.

14:15And so when we speed this operation up,

14:17I might completely clear out all of these bits

14:19and have zero left.

14:20And so I'm not actually sending anything.

14:22My conveyor belt is empty.

14:23But then all of a sudden, I get flooded with network traffic

14:26to the point that I'm actually dropping traffic.

14:28Well, wait a second.

14:29I went from 0 to having more bits than I can handle.

14:33And so yes, averaging this out over time,

14:35I'm at 85% network utilization, but I

14:38know that at various times I was at 0,

14:40and other times I'm dropping traffic.

14:42And so when it comes to this network utilization concept,

14:45if I'm over 70% utilization, I'm probably

14:48in pretty great danger of dropping a lot of packets.

14:51We can't, unfortunately, rely on this number, this hard number,

14:54to tell us whether we're in good shape

14:55or not because even at a lower percentage,

14:57I might be dropping packets if my network traffic is

15:00very inconsistent.

15:01And that's this concept of network bursts

15:03that we're going to have to talk about as part of QoS mechanisms

15:06later on in this scores.

15:07Oh, that was an interesting conversation about bandwidth.

15:10Hopefully it, maybe, sparked a new way

15:11of thinking about things.

15:12But either way, as we summarize all of this together,

15:15we start at the beginning.

15:17Latency, jitter, and packet loss.

15:19These are our primary ways of measuring

15:21the quality of the network.

15:22And so any one of these could be in good shape and some of them

15:25could be in bad shape at a time.

15:26So how do we really know what were the overall statuses?

15:29Well, that would be that mean opinions score concept.

15:32MOS is going to tell us, just from an automatic ability

15:36to calculate out, what the call quality probably

15:39was based on network conditions at the time.

15:41And yes, we don't have to go out, fortunately, and pull

15:44our users.

15:44Instead, we can usually run these based

15:46on those three quality metrics.

15:48And lastly, when it comes to bandwidth,

15:50it helps to think of it like it's a conveyor belt.

15:52But importantly, we need to understand that we are never

15:54consuming a certain amount of bandwidth at a moment in time.

15:58We have to average it out over time

16:00and every device is going to be, maybe, a little different

16:02depending on how exactly it does that calculation,

16:05but that is why we can have network interfaces that

16:07don't appear to be fully utilized that are still

16:09dropping traffic.

16:11So thinking back to the cardinality,

16:12thinking back to the factory analogy,

16:14whatever we need to do to understand

16:16how exactly bandwidth operates in the networking devices

16:19that we deploy.

16:20I hope this has been informative for you.

16:21I'd like to thank you for viewing.

0:00[MUSIC PLAYING]

0:05We have reached the end of a skill, which

0:06means it's time to review what we've learned by taking a quiz.

0:09First up out of four questions-- what

0:11is the primary focus of quality of service?

0:13And by the way, feel free to pause this video in order

0:16to make sure you have enough time to answer these questions.

0:23Let's go through each one of these-- preventing packets

0:25from dropping.

0:26This is one of the biggest misnomers,

0:27I would say, in the industry-- is that we somehow

0:29think that quality of service is going to actually prevent

0:32those packets from dropping.

0:33And in some cases, we might be able to do that

0:35with traffic shaping and such.

0:37But for the most part, we're not preventing packets

0:39from getting dropped.

0:40Instead we are controlling which packets get dropped.

0:43And so B is actually our answer here from the sense

0:46that, yeah, I'd rather drop an email packet than a voice

0:48packet, for example.

0:50Now, compressing network traffic, speeding up WAN

0:52links-- these are good things that we could possibly

0:54do to improve the performance of our network.

0:56But that's not really quality of service.

0:58That's really outside the realm of QoS.

1:00So again, B here is our answer.

1:03Question two-- what two message types

1:04are used by RSVP for establishing a bandwidth

1:07reservation?

1:13When we have a series of routers here--

1:15let's say we've got an ingress router here

1:17on the left and an egress router here on the right.

1:19And remember, RSVP is all about establishing a guarantee that

1:23stretches across the entire network,

1:24essentially emulating those circuit switch networks

1:27that we moved away from.

1:28And we're going to use two different message

1:29types to accomplish this.

1:31First of all, we're going to send up, originally,

1:33a path message.

1:34The PATH message is going to go forth and establish the path.

1:37And assuming that every router and every device in the path

1:40is good to go, well, then we can send back

1:43the reservation or the RESV message type

1:45in order to lock in that bandwidth guarantee.

1:47So our answers here are RESV, B, and PATH,

1:51E. Those would be our answers.

1:53Next up-- what are the two components

1:55of managing Per-Hop Behavior PHB in DiffServ designs?

2:03Let's remember how this works.

2:05So instead of using RSVP, for example, we

2:08are going to bring a packet in.

2:09And we are going to classify that packet.

2:12And another word for classify would be tagging.

2:14We like to talk about tagging our packets as they come in.

2:17And so we classify the packets.

2:18So A would be our first choice here.

2:20And then we are going to enforce the policy not only

2:22on the router here as it sends the packet on, but then also

2:26at the next router.

2:27We're going to have another policy here

2:29that gets enforced, eventually on ingress, but then also

2:32on egress when I send it onto the next hop.

2:34This is why we call this Per-Hop Behavior,

2:36because every hop behaves in the way

2:38that we configure it to behave.

2:40So really this behavior or this policy, this

2:42is going to be the second component of our DiffServ

2:44designs.

2:45So that means A and now D, these are our answers.

2:49OK, last question-- latency measurements

2:51of 102 milliseconds, 110 milliseconds, 93 milliseconds,

2:55and 119 milliseconds are taken in sequential order.

2:58What is the jitter in this time period?

3:00And by the way, as a bonus, would the call quality

3:03be affected?

3:08All right, so let's write out these different latency

3:10measurements.

3:11So we have 102 milliseconds, 110 milliseconds, 93, and 119.

3:16And so the way we calculate our jitter is by, first of all,

3:19figuring out the difference between these sequential

3:21latency measurements.

3:23So the difference between 102 and 110,

3:25this would be 8 milliseconds.

3:27And then the difference between 110 and 93,

3:29that would be 17 milliseconds.

3:31And then our last calculation here, that would be 7 plus 19.

3:34So that's 26 milliseconds.

3:36Now what we can do is we can add these up and take them

3:38as an average.

3:39So we have 8 plus 17 plus 26.

3:43Well, 8 plus 17 would be 25 plus 26.

3:46So that's 51 divided by 3.

3:4851 divided by 3 should be exactly 17 milliseconds.

3:51So if this is what you calculated out,

3:53then congratulations.

3:54You got the jitter right.

3:55Now for the bonus.

3:57Would call quality be affected?

3:58And as we recall, the recommendation for jitter

4:00is to keep it below 30 milliseconds.

4:03In our case, 17 milliseconds falls well

4:04below 30 and as such, no.

4:07The call quality should not be affected by this jitter.

4:10Well, that wraps up this quiz.

4:11If you find yourself missing any of these key pieces

4:13of information, then be sure to go back

4:14and watch the appropriate videos in order

4:16to fill those knowledge gaps.

4:17Otherwise, congratulations on completing Describe Quality

4:19Problems.

4:20I hope this has been informative for you,

4:22and I'd like to thank you for viewing.