WEBVTT 1 00:00.000 --> 00:04.640 Now we know what the goal of Quality of Service is, and we'll find that we 2 00:04.640 --> 00:07.000 actually have several different ways that we can accomplish that. 3 00:07.000 --> 00:10.860 In fact, we've had different models throughout the years that have shown us 4 00:10.860 --> 00:13.000 that we can do it one way, we can do it another way, 5 00:13.000 --> 00:17.480 and in the modern network we'll find that there is one model that we've really 6 00:17.480 --> 00:19.000 kind of seen embraced. 7 00:19.000 --> 00:23.520 Now, there might be a situation where we consider a different model, but the 8 00:23.520 --> 00:29.000 focus of this course and this exam is to really be looking at what we call the 9 00:29.000 --> 00:29.000 diff-serve model. 10 00:29.000 --> 00:33.540 But let's go and walk through these real quick. The first model we need to talk WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 10 00:29.000 --> 00:33.540 But let's go and walk through these real quick. The first model we need to talk 11 00:33.540 --> 00:39.620 about, which is basically saying we don't have a model, is known as best effort 12 00:39.620 --> 00:40.000 . 13 00:40.000 --> 00:44.920 I know that if I'm going to sit down and play basketball, can you play 14 00:44.920 --> 00:47.000 basketball sitting down? 15 00:47.000 --> 00:52.110 If I'm going to go and get invited to play basketball, I'm going to give it my 16 00:52.110 --> 00:53.000 best effort. 17 00:53.000 --> 00:57.910 I definitely will always give it my best effort because I don't want to 18 00:57.910 --> 01:00.000 disappoint my teammates. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 19 01:00.000 --> 01:04.390 Unfortunately, I'll probably still end up disappointing my teammates because I 20 01:04.390 --> 01:06.000 'm not very good at basketball. 21 01:06.000 --> 01:11.440 And so it'll just bounce off the rim or maybe even not even hit the rim either 22 01:11.440 --> 01:12.000 way. 23 01:12.000 --> 01:18.000 I am still giving it my best effort, which is great, but best effort does not 24 01:18.000 --> 01:20.000 necessarily give us results. 25 01:20.000 --> 01:27.370 The default behavior for our network switches is to present this concept of 26 01:27.370 --> 01:29.000 best effort. 27 01:29.000 --> 01:34.220 And so when we're looking at it from a QOS perspective, best effort is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 27 01:29.000 --> 01:34.220 And so when we're looking at it from a QOS perspective, best effort is 28 01:34.220 --> 01:36.000 basically saying this. 29 01:36.000 --> 01:41.000 All apps are going to be treated the same. 30 01:41.000 --> 01:46.290 So that's everything from my voice over IP to my bulk transfer of information 31 01:46.290 --> 01:51.000 and data to my internet, web surfing, internet streaming traffic. 32 01:51.000 --> 01:57.090 All of these will be treated the same. And as we can imagine, that's exactly 33 01:57.090 --> 02:00.000 what we don't want to be doing on a network. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 34 02:00.000 --> 02:03.330 Because if I have to drop one of these packets because I've got a network 35 02:03.330 --> 02:08.130 device here and we're getting so much traffic in that our buffers are 36 02:08.130 --> 02:10.000 completely maxed out, they're full, 37 02:10.000 --> 02:15.000 I'm going to have to start dropping frames. So what frames do I drop? 38 02:15.000 --> 02:20.000 In a quality of service world, I would say, well, definitely drop the internet 39 02:20.000 --> 02:24.000 and maybe drop the bulk file transfer type of packets. 40 02:24.000 --> 02:29.070 But again, we're treating everybody the same here. And so it's called indiscrim 41 02:29.070 --> 02:33.000 inate dropping of packets, meaning I'll drop anybody. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 41 02:29.070 --> 02:33.000 inate dropping of packets, meaning I'll drop anybody. 42 02:33.000 --> 02:38.470 It doesn't matter who I'm going to end up dropping. To me, all apps and all 43 02:38.470 --> 02:41.000 network packets are the same. 44 02:41.000 --> 02:46.020 And that's going to result in a very bad quality of experience for our voice 45 02:46.020 --> 02:51.100 over IP users, while our bulk traffic and our internet users, they're not going 46 02:51.100 --> 02:56.000 to even notice that they have any kind of issues on the link. 47 02:56.000 --> 03:01.000 If the application can absorb that dropped packet for them. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 47 02:56.000 --> 03:01.000 If the application can absorb that dropped packet for them. 48 03:01.000 --> 03:05.650 So we would like to talk about better model. And we have two different models 49 03:05.650 --> 03:11.160 to talk about, the first of which is known as integrated services, otherwise 50 03:11.160 --> 03:13.000 known as int serve. 51 03:13.000 --> 03:20.260 It takes us back in time a little bit from a methodology perspective. When I 52 03:20.260 --> 03:23.630 was first sitting down to learn about networking, I was learning about the 53 03:23.630 --> 03:27.000 concept of circuit switched versus packet switched networks. 54 03:27.000 --> 03:33.000 And there was a theory early on that our network should be based on circuits, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 54 03:27.000 --> 03:33.000 And there was a theory early on that our network should be based on circuits, 55 03:33.000 --> 03:37.000 just like our phone lines at the time were built on circuits. 56 03:37.000 --> 03:42.030 The idea here was that if I'm going to pick up the phone and talk to somebody, 57 03:42.030 --> 03:47.640 and yes, this is me in like the 1990s talking to my friend with my long arms 58 03:47.640 --> 03:50.000 and banana phone there I guess. 59 03:50.000 --> 03:55.000 But either way, talking to my friend on the phone, we had a dedicated circuit, 60 03:55.000 --> 04:00.350 meaning that there wasn't anything that anybody else had to do to try to get WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 60 03:55.000 --> 04:00.350 meaning that there wasn't anything that anybody else had to do to try to get 61 04:00.350 --> 04:04.000 some of that bandwidth because they couldn't. 62 04:04.000 --> 04:08.470 They couldn't get any of that bandwidth. This is a dedicated link between the 63 04:08.470 --> 04:13.520 two. And as long as I was talking to my friend on this line, then that 64 04:13.520 --> 04:19.000 bandwidth, if we want to call it that was completely reserved for us. 65 04:19.000 --> 04:23.950 And once we hung up, then somebody else could use the circuit. And so this is 66 04:23.950 --> 04:28.000 great other than it's also completely inefficient. 67 04:28.000 --> 04:33.440 It's inefficient because for all we know, for all the come telecom company WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 67 04:28.000 --> 04:33.440 It's inefficient because for all we know, for all the come telecom company 68 04:33.440 --> 04:38.930 knows, my friend and I could both set our phones down and walk away and just 69 04:38.930 --> 04:41.000 leave that hanging there. 70 04:41.000 --> 04:45.480 And yeah, that again in the 90s that meant that we couldn't actually get 71 04:45.480 --> 04:50.350 another phone call because they'd be busy and that was our only phone line, but 72 04:50.350 --> 04:53.000 it was wasting the bandwidth. 73 04:53.000 --> 04:57.150 And even if we didn't want to create this scenario where we could both set the 74 04:57.150 --> 05:01.190 phones down, what about the time periods where we were maybe not talking to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 74 04:57.150 --> 05:01.190 phones down, what about the time periods where we were maybe not talking to 75 05:01.190 --> 05:02.000 each other? 76 05:02.000 --> 05:07.760 Even just sitting here using words and talking to words, there's all these gaps 77 05:07.760 --> 05:13.000 in the words and that's a bunch of bandwidth that's reserved for silence. 78 05:13.000 --> 05:17.240 For really going to break this down and look at it from a millisecond 79 05:17.240 --> 05:22.240 perspective, there's a whole lot of silence on the line that we are guaranteed 80 05:22.240 --> 05:24.000 and dedicated to have. 81 05:24.000 --> 05:30.170 But the natural upside here is that I don't need to worry about any lack of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 81 05:24.000 --> 05:30.170 But the natural upside here is that I don't need to worry about any lack of 82 05:30.170 --> 05:33.000 quality on this connection. 83 05:33.000 --> 05:39.370 So, InServe wants to replicate this and say that we're going to do this now for 84 05:39.370 --> 05:41.000 quality of service. 85 05:41.000 --> 05:47.800 To say that I've got a set of routers here and what I want to do is still 86 05:47.800 --> 05:52.440 leverage the fact that this is a packet switch network, we're still in our TCP/ 87 05:52.440 --> 05:53.000 IP world. 88 05:53.000 --> 05:59.970 And so we've got packets flowing among all of these routers, but if I wanted to 89 05:59.970 --> 06:09.010 have a phone call from one end to the other, then I could still get a dedicated WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 89 05:59.970 --> 06:09.010 have a phone call from one end to the other, then I could still get a dedicated 90 06:09.010 --> 06:11.000 reservation. 91 06:11.000 --> 06:15.320 And we're talking about a reservation at this point, we're not talking about a 92 06:15.320 --> 06:19.380 true circuit, but we're talking about creating sort of a virtual circuit 93 06:19.380 --> 06:22.000 because it's a reservation of bandwidth. 94 06:22.000 --> 06:27.670 So the idea here is now I'm going to reserve, let's just say I'm going to 95 06:27.670 --> 06:34.000 reserve 100 kilobits per second from end to end. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 95 06:27.670 --> 06:34.000 reserve 100 kilobits per second from end to end. 96 06:34.000 --> 06:40.590 This requires an entire request set of, maybe a set of requests where I request 97 06:40.590 --> 06:47.000 all the way down to the other side and then I get responses all the way back. 98 06:47.000 --> 06:54.000 And this transaction was managed by a protocol known as RSVP. 99 06:54.000 --> 07:00.100 And it really just stands for the resource reservation protocol, and yeah, it WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 99 06:54.000 --> 07:00.100 And it really just stands for the resource reservation protocol, and yeah, it 100 07:00.100 --> 07:05.730 doesn't quite line up with RSVP, but as we maybe know from if we speak French 101 07:05.730 --> 07:12.710 or otherwise in even American culture, we use this word RSVP to say that I want 102 07:12.710 --> 07:16.000 to reserve my spot at a party or something along those lines. 103 07:16.000 --> 07:21.670 So I can reserve something using an RSVP, which again going back to the French 104 07:21.670 --> 07:27.000 stands for race bond a see who play, we're saying, please respond. 105 07:27.000 --> 07:33.300 Ultimately RSVP as a protocol is going to manage these transactions for us and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 105 07:27.000 --> 07:33.300 Ultimately RSVP as a protocol is going to manage these transactions for us and 106 07:33.300 --> 07:38.000 ideally reserve a dedicated set of bandwidth and end. 107 07:38.000 --> 07:42.610 Now, in the same way that these circuit switch networks were inefficient, this 108 07:42.610 --> 07:47.050 is not super efficient, because what if I don't actually need even half of that 109 07:47.050 --> 07:50.000 100 kilobits per second reservation? 110 07:50.000 --> 07:55.000 Well, it's dedicated, it's reserved, nobody else can have it. 111 07:55.000 --> 07:59.260 And so there are upsides and downsides to both in serve and the alternative, 112 07:59.260 --> 08:03.000 the diff serve model here that we're going to be talking about. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 112 07:59.260 --> 08:03.000 the diff serve model here that we're going to be talking about. 113 08:03.000 --> 08:08.840 There's upsides and downsides to understand, and ultimately, in service sort of 114 08:08.840 --> 08:12.000 seen as maybe having too many downsides. 115 08:12.000 --> 08:17.660 So our upside, absolutely, it doesn't get better than having a true reservation 116 08:17.660 --> 08:18.000 . 117 08:18.000 --> 08:23.000 Even diff serve, our modern mechanisms can't do this. 118 08:23.000 --> 08:30.000 But on the downside here, we're going to find that we have scaling issues. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 119 08:30.000 --> 08:36.690 And specifically what happens when we run out of resources, because we're 120 08:36.690 --> 08:42.000 inefficient, we might find that we do run out of resources. 121 08:42.000 --> 08:48.000 And so since we're out of resources, I guess we'll abbreviate it that way. 122 08:48.000 --> 08:53.000 Once we're out of resources, this leads to RSVP rejections. 123 08:53.000 --> 08:58.000 I can no longer get resources because all the resources have been reserved. 124 08:58.000 --> 09:03.000 And I need to leave some amount of resources for non RSVP related traffic. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 124 08:58.000 --> 09:03.000 And I need to leave some amount of resources for non RSVP related traffic. 125 09:03.000 --> 09:08.550 And so we see quite a few downsides to in serve, which is again, why we don't 126 09:08.550 --> 09:11.000 typically see it deployed onto modern networks, 127 09:11.000 --> 09:15.000 although it is still something that is supported and we could deploy. 128 09:15.000 --> 09:21.000 So onto the model that we've been teasing, which is differentiated services, 129 09:21.000 --> 09:24.000 otherwise known as diff serve. 130 09:24.000 --> 09:28.000 diff serve embraces the packet switch nature of modern networking. 131 09:28.000 --> 09:31.000 So there's no reservation. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 131 09:28.000 --> 09:31.000 So there's no reservation. 132 09:31.000 --> 09:39.000 We're not trying to replicate the concept of circuits. 133 09:39.000 --> 09:43.000 We don't have these virtual circuits that we're trying to establish. 134 09:43.000 --> 09:49.000 And instead, what we're going to do is we're going to rely on what we call per 135 09:49.000 --> 09:53.000 pop behaviors. 136 09:53.000 --> 10:02.000 Otherwise known as, if I can spell it, there we go, P H B's. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 136 09:53.000 --> 10:02.000 Otherwise known as, if I can spell it, there we go, P H B's. 137 10:02.000 --> 10:08.240 So these per hot behaviors essentially break it down once again into a bunch of 138 10:08.240 --> 10:11.000 devices that are communicating with each other. 139 10:11.000 --> 10:15.000 But there is no end to end reservation. 140 10:15.000 --> 10:17.780 And so when we're talking about reservations, we're really talking about end to 141 10:17.780 --> 10:20.000 end because within serve, that's what we do. 142 10:20.000 --> 10:25.300 We add this 100 kilobit per second reservation end to end from one side to the 143 10:25.300 --> 10:26.000 other. 144 10:26.000 --> 10:30.820 But instead, we're going to say there are no reservations from an end to end WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 144 10:26.000 --> 10:30.820 But instead, we're going to say there are no reservations from an end to end 145 10:30.820 --> 10:32.000 perspective. 146 10:32.000 --> 10:37.790 Instead, what we're going to do is we're going to rely on each one of these 147 10:37.790 --> 10:42.000 devices as having the proper behavior. 148 10:42.000 --> 10:46.210 But the problem, if we want to call it that, is that each one of these has its 149 10:46.210 --> 10:48.000 own set of behaviors defined. 150 10:48.000 --> 10:54.510 And so we need to make sure that we synchronize these behaviors via RQOS 151 10:54.510 --> 10:58.000 configuration. 152 10:58.000 --> 11:01.430 So just like in a packet switched world, and we think about our layer three WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 152 10:58.000 --> 11:01.430 So just like in a packet switched world, and we think about our layer three 153 11:01.430 --> 11:06.560 routing, so often we bring a packet in and we look at the behavior that I have 154 11:06.560 --> 11:07.000 defined. 155 11:07.000 --> 11:12.050 And so I send it on hoping that the next device also has the proper behavior 156 11:12.050 --> 11:13.000 defined. 157 11:13.000 --> 11:18.020 And so that's exactly what the diff-serve model is built on, is saying that 158 11:18.020 --> 11:23.180 each device is going to be responsible for executing the behavior that we 159 11:23.180 --> 11:24.000 desire. 160 11:24.000 --> 11:30.000 Importantly, in all of this, there are no guarantees. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 161 11:30.000 --> 11:33.000 With in serve, we had guarantees. 162 11:33.000 --> 11:34.000 That was the upside here. 163 11:34.000 --> 11:37.000 We had a reservation guaranteed from end to end. 164 11:37.000 --> 11:39.000 With diff-serve, we just don't have that. 165 11:39.000 --> 11:43.230 Packets might make it three quarters of the way there and then end up getting 166 11:43.230 --> 11:44.000 dropped. 167 11:44.000 --> 11:47.000 That could absolutely happen in the diff-serve model. 168 11:47.000 --> 11:51.690 Whereas with in serve, that shouldn't happen short of a packet being malformed 169 11:51.690 --> 11:53.000 on transmission. 170 11:53.000 --> 11:56.160 As long as we have the reservation, that bandwidth should be available and 171 11:56.160 --> 12:00.000 there's really not going to be a way that it gets dropped due to a full buffer. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 172 12:00.000 --> 12:08.130 But we might actually have buffer issues on the network that cause diff-serve 173 12:08.130 --> 12:11.000 packets to get dropped. 174 12:11.000 --> 12:14.760 Now, if we're not doing reservation, then how do we synchronize these behaviors 175 12:14.760 --> 12:15.000 ? 176 12:15.000 --> 12:20.000 How do I know when a packet comes in that it's voice over IP? 177 12:20.000 --> 12:23.000 Well, the way we do that is with a tag. 178 12:23.000 --> 12:28.000 And these tags can be rather famous or maybe infamous among network engineers. 179 12:28.000 --> 12:33.500 It's tags such as class of service, DSCP, the differentiated services code WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 179 12:28.000 --> 12:33.500 It's tags such as class of service, DSCP, the differentiated services code 180 12:33.500 --> 12:34.000 point. 181 12:34.000 --> 12:38.150 As fancy as that sounds, you might notice differentiated services, 182 12:38.150 --> 12:40.000 differentiated services. 183 12:40.000 --> 12:42.000 So clearly the concepts are tied together. 184 12:42.000 --> 12:46.790 There's also a more legacy IP precedence that we'll cover, but we pretty much 185 12:46.790 --> 12:48.000 don't use that anymore. 186 12:48.000 --> 12:52.760 It's always class of service or DSCP being layer two and layer three tags 187 12:52.760 --> 12:54.000 respectively. 188 12:54.000 --> 13:00.000 So the biggest upside that we see to diff-serve is just how efficient it is. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 189 13:00.000 --> 13:04.530 We don't have to worry about accidentally reserving too much bandwidth because 190 13:04.530 --> 13:09.520 if we do put too much of a bandwidth prioritization on, let's say our voice 191 13:09.520 --> 13:10.000 over IP, 192 13:10.000 --> 13:16.000 well, if we're not using that, then it'll get used by other traffic flows. 193 13:16.000 --> 13:20.460 We don't have to stress about maybe running out of bandwidth that we can 194 13:20.460 --> 13:26.000 reserve, which is a big problem down here with RSVP and the Inserve model. 195 13:26.000 --> 13:28.000 So it's highly, highly efficient. 196 13:28.000 --> 13:33.510 One of the biggest downsides to quality of service, that again is probably WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 196 13:28.000 --> 13:33.510 One of the biggest downsides to quality of service, that again is probably 197 13:33.510 --> 13:37.000 famous or infamous among network engineers, 198 13:37.000 --> 13:40.000 is that it is extremely complex at times. 199 13:40.000 --> 13:44.200 We have a bunch of different mechanisms that we're going to be learning and 200 13:44.200 --> 13:45.000 covering. 201 13:45.000 --> 13:49.310 We also have to worry about the fact that switches and routers handle quality 202 13:49.310 --> 13:50.000 of service, 203 13:50.000 --> 13:53.000 queuing and prioritization different from one another. 204 13:53.000 --> 13:58.000 And so unfortunately it does create a little bit more for us to have to learn. 205 13:58.000 --> 14:02.840 But when we compare that to the downsides of the Inserve model, by far diff-ser WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 205 13:58.000 --> 14:02.840 But when we compare that to the downsides of the Inserve model, by far diff-ser 206 14:02.840 --> 14:05.000 ve is the superior way to do things, 207 14:05.000 --> 14:09.680 again embracing that packet-switched implementation that networking has been 208 14:09.680 --> 14:11.000 built on for so long. 209 14:11.000 --> 14:15.810 So as we move forward, we're going to leave Inserve behind and focus on our 210 14:15.810 --> 14:17.000 diff-serve mechanisms 211 14:17.000 --> 14:21.930 and see how we can take advantage of them to deliver, again, that positive 212 14:21.930 --> 14:26.000 quality of experience for our mission critical applications.