1 1 00:00:00,250 --> 00:00:01,760 As I mentioned before, 2 2 00:00:01,760 --> 00:00:04,640 we have different ways of categorizing our traffic. 3 3 00:00:04,640 --> 00:00:07,250 We can do it through classification, marking, 4 4 00:00:07,250 --> 00:00:10,280 utilizing congestion management, congestion avoidance, 5 5 00:00:10,280 --> 00:00:13,460 policing and shaping, and link efficiency. 6 6 00:00:13,460 --> 00:00:15,710 All of these ways, are ways for us to help implement 7 7 00:00:15,710 --> 00:00:19,470 our quality of service and take us from this to this. 8 8 00:00:19,470 --> 00:00:20,450 Now, as you can see, 9 9 00:00:20,450 --> 00:00:22,730 we want to start shaping out those peaks and valleys 10 10 00:00:22,730 --> 00:00:24,270 using these different mechanisms 11 11 00:00:24,270 --> 00:00:26,310 to give us a better quality of service. 12 12 00:00:26,310 --> 00:00:28,326 Now, when we look at the classification of traffic, 13 13 00:00:28,326 --> 00:00:29,860 traffic is going to be placed 14 14 00:00:29,860 --> 00:00:31,690 into these different categories. 15 15 00:00:31,690 --> 00:00:32,660 Now, this is going to be done 16 16 00:00:32,660 --> 00:00:34,580 based on the type of traffic that it is. 17 17 00:00:34,580 --> 00:00:36,740 There's email, but even inside of email, 18 18 00:00:36,740 --> 00:00:37,990 we have many different classes 19 19 00:00:37,990 --> 00:00:39,900 of information inside of an email. 20 20 00:00:39,900 --> 00:00:40,990 If you think about email, 21 21 00:00:40,990 --> 00:00:43,023 we have POP3 traffic, we have IMAP traffic. 22 22 00:00:43,023 --> 00:00:46,240 We have SMTP traffic. We have Exchange traffic. 23 23 00:00:46,240 --> 00:00:47,870 Those are four different types right there. 24 24 00:00:47,870 --> 00:00:49,210 And so we can look at the headers 25 25 00:00:49,210 --> 00:00:50,979 and we can look at the packet type of information 26 26 00:00:50,979 --> 00:00:53,440 and we can even use the ports that are being used. 27 27 00:00:53,440 --> 00:00:55,540 And then we can determine what services 28 28 00:00:55,540 --> 00:00:57,229 need higher or less priority. 29 29 00:00:57,229 --> 00:00:59,620 We can then do this, not just across email, 30 30 00:00:59,620 --> 00:01:01,270 but across all of our traffic. 31 31 00:01:01,270 --> 00:01:03,420 And by doing this, this classification 32 32 00:01:03,420 --> 00:01:06,660 doesn't alter any bits in the frame itself or the packet. 33 33 00:01:06,660 --> 00:01:08,940 Instead, there is no marking inside of there. 34 34 00:01:08,940 --> 00:01:11,830 It's all based on the analysis of the packet itself, 35 35 00:01:11,830 --> 00:01:13,490 the ports and the protocols used, 36 36 00:01:13,490 --> 00:01:16,160 and our switches and routers are going to implement QoS 37 37 00:01:16,160 --> 00:01:17,970 based on that information. 38 38 00:01:17,970 --> 00:01:20,827 Now, another way to do this, is by marking that traffic. 39 39 00:01:20,827 --> 00:01:24,070 With this, we're going to alter the bits within the frame. 40 40 00:01:24,070 --> 00:01:26,470 Now we can do this inside frames, cells, or packets, 41 41 00:01:26,470 --> 00:01:28,000 depending on what networks we're using. 42 42 00:01:28,000 --> 00:01:30,688 And this will indicate how we handle this piece of traffic. 43 43 00:01:30,688 --> 00:01:32,890 Our network tools are going to make decisions 44 44 00:01:32,890 --> 00:01:33,840 based on those markings. 45 45 00:01:33,840 --> 00:01:35,568 If you look at the type of service header, 46 46 00:01:35,568 --> 00:01:38,309 it's going to have a byte of information or eight bits. 47 47 00:01:38,309 --> 00:01:41,349 The first three of that eight bits is the IP Precedence. 48 48 00:01:41,349 --> 00:01:43,750 The next six of that is going to be 49 49 00:01:43,750 --> 00:01:46,168 the differential control protocol or DSP. 50 50 00:01:46,168 --> 00:01:47,810 Now you don't need to memorize 51 51 00:01:47,810 --> 00:01:49,880 how this type of service is done inside the header. 52 52 00:01:49,880 --> 00:01:52,330 But I do want you to remember one of the ways 53 53 00:01:52,330 --> 00:01:54,010 that we can do this quality service 54 54 00:01:54,010 --> 00:01:55,699 is by marking and altering that traffic. 55 55 00:01:55,699 --> 00:01:58,408 Next, we have congestion management. 56 56 00:01:58,408 --> 00:02:00,120 And when a device receives traffic 57 57 00:02:00,120 --> 00:02:01,339 faster than it can be transmitted, 58 58 00:02:01,339 --> 00:02:03,377 it's going to end up buffering that extra traffic 59 59 00:02:03,377 --> 00:02:05,453 until bandwidth becomes available. 60 60 00:02:05,453 --> 00:02:07,600 This is known as queuing. 61 61 00:02:07,600 --> 00:02:09,670 The queuing algorithm is going to empty the packets 62 62 00:02:09,670 --> 00:02:11,629 in a specified sequence and ML. 63 63 00:02:11,629 --> 00:02:14,680 These algorithms are going to use one of three mechanisms. 64 64 00:02:14,680 --> 00:02:16,279 There is a weighted fair queuing. 65 65 00:02:16,279 --> 00:02:18,170 There's a low-latency queuing, 66 66 00:02:18,170 --> 00:02:19,680 or there is a weighted round-robin. 67 67 00:02:19,680 --> 00:02:22,179 Now let's look at this example I have here. 68 68 00:02:22,179 --> 00:02:24,048 I have four categories of traffic: 69 69 00:02:24,048 --> 00:02:26,159 Traffic 1, 2, 3, and 4. 70 70 00:02:26,159 --> 00:02:28,248 It really doesn't matter what kind of traffic it is, 71 71 00:02:28,248 --> 00:02:30,040 for our example right now, 72 72 00:02:30,040 --> 00:02:32,210 we just need to know that there's four categories. 73 73 00:02:32,210 --> 00:02:34,610 Now, if we're going to be using a weighted fair queuing, 74 74 00:02:34,610 --> 00:02:36,989 how are we going to start emptying these piles of traffic? 75 75 00:02:36,989 --> 00:02:39,900 Well, I'm going to take one from 1, one from 2, 76 76 00:02:39,900 --> 00:02:41,730 one from 3, and one from 4. 77 77 00:02:41,730 --> 00:02:44,420 Then I'm going to go back to 1 and 2 and 3 and 4. 78 78 00:02:44,420 --> 00:02:45,736 And we'll just keep taking turns. 79 79 00:02:45,736 --> 00:02:47,338 Now, is that a good mechanism? 80 80 00:02:47,338 --> 00:02:50,930 Well, maybe. It depends on what your traffic is. 81 81 00:02:50,930 --> 00:02:53,690 If column 1, for example, was representing VoIP traffic, 82 82 00:02:53,690 --> 00:02:55,288 this actually, isn't a very good mechanism, 83 83 00:02:55,288 --> 00:02:57,658 because it has us to keep waiting for our turn. 84 84 00:02:57,658 --> 00:03:00,949 So instead, let's look at this low-latency queuing instead. 85 85 00:03:00,949 --> 00:03:03,358 Based on our categories of 1, 2, 3, and 4, 86 86 00:03:03,358 --> 00:03:05,840 we're going to assign priorities to them. 87 87 00:03:05,840 --> 00:03:07,448 If 1 was a higher priority than 2, 88 88 00:03:07,448 --> 00:03:09,390 then all of 1 would get emptied, 89 89 00:03:09,390 --> 00:03:10,850 then all of 2 would get emptied, 90 90 00:03:10,850 --> 00:03:12,789 and then all 3 and then all of 4. 91 91 00:03:12,789 --> 00:03:14,980 Now this works well to prioritize things like 92 92 00:03:14,980 --> 00:03:16,020 voice and video. 93 93 00:03:16,020 --> 00:03:17,539 But if you're sitting in category 3 or 4, 94 94 00:03:17,539 --> 00:03:19,170 you might start really receiving 95 95 00:03:19,170 --> 00:03:20,939 a lot of timeouts and drop packets 96 96 00:03:20,939 --> 00:03:22,810 because it's never going to be your turn. 97 97 00:03:22,810 --> 00:03:24,539 And you're just going to wait and wait and wait. 98 98 00:03:24,539 --> 00:03:27,930 Now the next one we have is called the weighted round-robin. 99 99 00:03:27,930 --> 00:03:29,297 And this is actually one of my favorites. 100 100 00:03:29,297 --> 00:03:31,629 This is kind of a hybrid between the other two. 101 101 00:03:31,629 --> 00:03:33,280 Now with a weighted round-robin, 102 102 00:03:33,280 --> 00:03:35,330 we might say that category 1 is VoIP, 103 103 00:03:35,330 --> 00:03:37,860 and category 2 is video, category 3 is web, 104 104 00:03:37,860 --> 00:03:39,280 and category 4 is email. 105 105 00:03:39,280 --> 00:03:41,800 And so we might say that in the priority order, 106 106 00:03:41,800 --> 00:03:43,280 1 is going to be highest 107 107 00:03:43,280 --> 00:03:44,647 and we're going to use a weighted round-robin, 108 108 00:03:44,647 --> 00:03:46,610 and we might say, we're going to take three 109 109 00:03:46,610 --> 00:03:49,130 out of category 1, two out of category 2, 110 110 00:03:49,130 --> 00:03:51,500 and then one out of 3 and one out of 4. 111 111 00:03:51,500 --> 00:03:53,010 And we'll keep going around that way. 112 112 00:03:53,010 --> 00:03:56,860 We'll take three, two, one, one, three, two, one, one. 113 113 00:03:56,860 --> 00:03:58,090 And we keep going. 114 114 00:03:58,090 --> 00:04:01,020 That way, VoIP traffic is getting a lot of priority. 115 115 00:04:01,020 --> 00:04:03,190 Video is getting the second highest priority. 116 116 00:04:03,190 --> 00:04:04,770 And then we start looking at web and email 117 117 00:04:04,770 --> 00:04:05,960 at the bottom of the barrel, 118 118 00:04:05,960 --> 00:04:06,878 but they're still getting a turn 119 119 00:04:06,878 --> 00:04:08,547 every couple of rounds here. 120 120 00:04:08,547 --> 00:04:10,929 And so that way it becomes a weighted round-robin. 121 121 00:04:10,929 --> 00:04:13,287 As I said, this is the quality of service mechanism 122 122 00:04:13,287 --> 00:04:15,912 that I really like to implement inside my own networks. 123 123 00:04:15,912 --> 00:04:18,887 Next, we have the idea of congestion avoidance. 124 124 00:04:18,887 --> 00:04:21,940 As new packets keep arriving, they can be discarded 125 125 00:04:21,940 --> 00:04:23,975 if the output queue is already filled up. 126 126 00:04:23,975 --> 00:04:26,318 Now, I like to think about this as a bucket. 127 127 00:04:26,318 --> 00:04:28,417 As you can see here, I have a cylinder on the bottom 128 128 00:04:28,417 --> 00:04:30,870 and it has a minimum and a maximum. 129 129 00:04:30,870 --> 00:04:32,500 Now, if it's already at maximum and you try 130 130 00:04:32,500 --> 00:04:33,870 to put more into the bucket, 131 131 00:04:33,870 --> 00:04:35,307 it just overflows over the top. 132 132 00:04:35,307 --> 00:04:37,169 Now to help prevent this, we have what's called 133 133 00:04:37,169 --> 00:04:39,787 the RED or random early detection. 134 134 00:04:39,787 --> 00:04:43,010 This is used to prevent this overflow from happening for us. 135 135 00:04:43,010 --> 00:04:45,270 As the queue starts approaching that maximum, 136 136 00:04:45,270 --> 00:04:46,350 we have this possibility 137 137 00:04:46,350 --> 00:04:48,120 that discard is going to happen. 138 138 00:04:48,120 --> 00:04:50,750 And so we start doing is we start dropping traffic. 139 139 00:04:50,750 --> 00:04:52,467 Instead of just dropping traffic randomly, 140 140 00:04:52,467 --> 00:04:54,530 we're going to drop it based on priority, 141 141 00:04:54,530 --> 00:04:57,257 with the lowest traffic priority getting dropped first. 142 142 00:04:57,257 --> 00:05:00,280 RED is going to drop packets from the selected queues 143 143 00:05:00,280 --> 00:05:01,848 based on their defined limits. 144 144 00:05:01,848 --> 00:05:04,520 Now I might start dropping TCP traffic first 145 145 00:05:04,520 --> 00:05:06,740 because I know it'll retransmit itself. 146 146 00:05:06,740 --> 00:05:09,017 Where UDP, if you drop it, it's gone forever. 147 147 00:05:09,017 --> 00:05:11,410 And so I might keep that in my queue a little bit longer, 148 148 00:05:11,410 --> 00:05:12,870 so it doesn't get dropped. 149 149 00:05:12,870 --> 00:05:15,067 Now, that's the idea here with TCP traffic, 150 150 00:05:15,067 --> 00:05:17,730 even if I drop it, we're going to get that retransmission 151 151 00:05:17,730 --> 00:05:18,563 and we'll try again. 152 152 00:05:18,563 --> 00:05:20,169 But with UDP, if it dropped, 153 153 00:05:20,169 --> 00:05:21,610 you're never going to know about it, 154 154 00:05:21,610 --> 00:05:23,137 and you're going to have loss of service. 155 155 00:05:23,137 --> 00:05:25,650 Now, when you're dealing with congestion avoidance, 156 156 00:05:25,650 --> 00:05:26,980 we're going to try to use the buffer 157 157 00:05:26,980 --> 00:05:29,470 to our advantage, and be able to use it to help us 158 158 00:05:29,470 --> 00:05:30,489 get more bandwidth through. 159 159 00:05:30,489 --> 00:05:32,706 Now, when we start putting all these things together, 160 160 00:05:32,706 --> 00:05:35,130 we start getting into these two concepts, 161 161 00:05:35,130 --> 00:05:36,928 known as policing and shaping. 162 162 00:05:36,928 --> 00:05:39,110 Policing is going to discard packets 163 163 00:05:39,110 --> 00:05:41,110 that exceed the configured rate limit, 164 164 00:05:41,110 --> 00:05:43,187 which we like to refer to as our speed limit. 165 165 00:05:43,187 --> 00:05:45,460 Just like if you're driving down the highway too fast, 166 166 00:05:45,460 --> 00:05:47,050 you're going to get pulled over by a cop 167 167 00:05:47,050 --> 00:05:47,883 and you're going to get a ticket. 168 168 00:05:47,883 --> 00:05:49,796 That's what policing is going to do for us. 169 169 00:05:49,796 --> 00:05:52,040 Now, we're just going to go and drop you off the network 170 170 00:05:52,040 --> 00:05:53,660 anytime you're going too fast. 171 171 00:05:53,660 --> 00:05:56,358 So, drop packets are going to result in retransmissions, 172 172 00:05:56,358 --> 00:05:58,654 which then creates more bandwidth. 173 173 00:05:58,654 --> 00:06:00,940 Therefore, policing is only good 174 174 00:06:00,940 --> 00:06:03,020 for very high-speed interfaces. 175 175 00:06:03,020 --> 00:06:05,430 If you're using a dial up modem or an ISDN connection, 176 176 00:06:05,430 --> 00:06:08,206 or even a T1, you probably don't want to use policing. 177 177 00:06:08,206 --> 00:06:10,740 You're much better off using our second method, 178 178 00:06:10,740 --> 00:06:11,918 which is known as shaping. 179 179 00:06:11,918 --> 00:06:14,670 Now, what shaping is going to do for us 180 180 00:06:14,670 --> 00:06:15,860 is it's going to allow the buffer 181 181 00:06:15,860 --> 00:06:18,690 to delay traffic from exceeding the configured rate. 182 182 00:06:18,690 --> 00:06:21,137 Instead of dropping those packets like we did in policing, 183 183 00:06:21,137 --> 00:06:22,867 we're just going to hold them in our buffer. 184 184 00:06:22,867 --> 00:06:25,597 Then when it's empty and there's space available, 185 185 00:06:25,597 --> 00:06:27,100 we're going to start pushing it 186 186 00:06:27,100 --> 00:06:30,067 over that empty space and start shaping out the packets. 187 187 00:06:30,067 --> 00:06:33,238 This is why we call it shaping or packet shaping. 188 188 00:06:33,238 --> 00:06:35,900 Now you can see what this looks like here on the screen. 189 189 00:06:35,900 --> 00:06:36,929 I have traffic at the top, 190 190 00:06:36,929 --> 00:06:39,750 and you'll see all those jagged lines going down. 191 191 00:06:39,750 --> 00:06:41,710 Now, what really happens here in your network 192 192 00:06:41,710 --> 00:06:43,350 is there's this high period of time, 193 193 00:06:43,350 --> 00:06:44,740 and there's low periods of time, 194 194 00:06:44,740 --> 00:06:46,320 because not everything is happening 195 195 00:06:46,320 --> 00:06:48,710 all the time in an equal amount. 196 196 00:06:48,710 --> 00:06:51,364 If we do policing, all we did was chop off the tops, 197 197 00:06:51,364 --> 00:06:54,470 which gave us more retransmissions and was shaping. 198 198 00:06:54,470 --> 00:06:55,810 Instead, we're going to start filling 199 199 00:06:55,810 --> 00:06:57,580 in from the bottom, from our queue. 200 200 00:06:57,580 --> 00:06:59,770 So it keeps up there right towards the speed limit 201 201 00:06:59,770 --> 00:07:00,906 without going over it. 202 202 00:07:00,906 --> 00:07:02,900 Again, shaping does a better job 203 203 00:07:02,900 --> 00:07:04,540 of maximizing your bandwidth, 204 204 00:07:04,540 --> 00:07:06,350 especially on slow speed interfaces, 205 205 00:07:06,350 --> 00:07:07,996 like a T1 connection, a dial up, 206 206 00:07:07,996 --> 00:07:10,280 satellite connections, or ISDN. 207 207 00:07:10,280 --> 00:07:12,740 Then the last thing we need to talk about here 208 208 00:07:12,740 --> 00:07:13,916 is link efficiency. 209 209 00:07:13,916 --> 00:07:15,990 Now there's a couple of things we need to mention 210 210 00:07:15,990 --> 00:07:17,880 in regard to link efficiency. 211 211 00:07:17,880 --> 00:07:19,900 The first of which is compression. 212 212 00:07:19,900 --> 00:07:21,460 To get the most out of your link, 213 213 00:07:21,460 --> 00:07:23,700 you want to make it the most efficient possible. 214 214 00:07:23,700 --> 00:07:25,994 And so to do that, we can compress our packets. 215 215 00:07:25,994 --> 00:07:28,156 If we take our payloads and we compress it down, 216 216 00:07:28,156 --> 00:07:29,684 that's going to conserve bandwidth 217 217 00:07:29,684 --> 00:07:31,550 because it's less ones and zeros 218 218 00:07:31,550 --> 00:07:32,826 that need to go across the wire. 219 219 00:07:32,826 --> 00:07:35,044 VoIP is a great thing that you can compress 220 220 00:07:35,044 --> 00:07:37,204 because there's so much extra space 221 221 00:07:37,204 --> 00:07:39,596 that's wasted inside of voice traffic. 222 222 00:07:39,596 --> 00:07:41,274 VoIP payloads can actually be reduced 223 223 00:07:41,274 --> 00:07:43,864 by up to 50% of their original space. 224 224 00:07:43,864 --> 00:07:46,330 We could take it down from 40 bytes 225 225 00:07:46,330 --> 00:07:48,386 down to 20 bytes by using compression. 226 226 00:07:48,386 --> 00:07:51,131 If you think that's good, look at the VoIP header. 227 227 00:07:51,131 --> 00:07:52,796 I can compress the VoIP header down 228 228 00:07:52,796 --> 00:07:56,082 from 90 or 95% of its original value. 229 229 00:07:56,082 --> 00:08:00,236 I can take it from 40 bites down to just two to four bytes. 230 230 00:08:00,236 --> 00:08:04,844 To do this, we use something called compressed RTP or cRTP. 231 231 00:08:04,844 --> 00:08:07,186 Now, when I have the original VoIP payload, 232 232 00:08:07,186 --> 00:08:09,575 as you can see here, I have an IP address, 233 233 00:08:09,575 --> 00:08:12,060 I have UDP as my packet type, 234 234 00:08:12,060 --> 00:08:13,670 and I have RTP for its header. 235 235 00:08:13,670 --> 00:08:15,610 And then I have my voice payload. 236 236 00:08:15,610 --> 00:08:19,095 I can compress all of that down into just a cRTP, 237 237 00:08:19,095 --> 00:08:21,560 which consolidates the IP, the UDP, 238 238 00:08:21,560 --> 00:08:23,950 and the RTP altogether into one. 239 239 00:08:23,950 --> 00:08:26,120 The voice payload can also be squeezed down 240 240 00:08:26,120 --> 00:08:27,415 to about half of its size. 241 241 00:08:27,415 --> 00:08:29,470 Now you're not going to notice a big difference 242 242 00:08:29,470 --> 00:08:31,236 in your audio quality either by doing this, 243 243 00:08:31,236 --> 00:08:33,407 this can be utilized on slower speed links 244 244 00:08:33,407 --> 00:08:35,590 to make the most of your limited bandwidth. 245 245 00:08:35,590 --> 00:08:36,727 And it's not just for VoIP. 246 246 00:08:36,727 --> 00:08:38,687 You can do this with other types of data too. 247 247 00:08:38,687 --> 00:08:40,946 Compression is a great thing to use. 248 248 00:08:40,946 --> 00:08:43,770 They have devices out there called WAN accelerators. 249 249 00:08:43,770 --> 00:08:45,715 That focus specifically on compressing your data 250 250 00:08:45,715 --> 00:08:47,906 before sending it out your WAN link. 251 251 00:08:47,906 --> 00:08:49,727 The last thing I want to talk about here 252 252 00:08:49,727 --> 00:08:52,487 is what we call LFI, which is another method 253 253 00:08:52,487 --> 00:08:55,007 to make more efficient use of your links. 254 254 00:08:55,007 --> 00:08:58,087 This is known as link fragmentation and interleaving. 255 255 00:08:58,087 --> 00:09:01,226 Now what this does is if you have a really big packet, 256 256 00:09:01,226 --> 00:09:02,676 it'll start chopping those up 257 257 00:09:02,676 --> 00:09:05,610 and take those big packets and fragment them, 258 258 00:09:05,610 --> 00:09:07,946 and then interleave smaller packets in between them. 259 259 00:09:07,946 --> 00:09:10,440 This way, it's going to allow you to utilize 260 260 00:09:10,440 --> 00:09:12,510 those slower speed links to make the most 261 261 00:09:12,510 --> 00:09:13,607 of your limited bandwidth. 262 262 00:09:13,607 --> 00:09:15,840 Notice here I have three voice packets, 263 263 00:09:15,840 --> 00:09:17,074 and one big chunk of data. 264 264 00:09:17,074 --> 00:09:20,220 Now what the router would do, is it's going to chop up 265 265 00:09:20,220 --> 00:09:21,854 and put that one small voice piece 266 266 00:09:21,854 --> 00:09:23,740 and then one small data piece, 267 267 00:09:23,740 --> 00:09:25,200 and then one small voice piece, 268 268 00:09:25,200 --> 00:09:26,640 and one small data piece. 269 269 00:09:26,640 --> 00:09:28,250 That way, the voice doesn't suffer 270 270 00:09:28,250 --> 00:09:30,670 from huge latency by waiting for that big piece 271 271 00:09:30,670 --> 00:09:31,807 of data to go through first. 272 272 00:09:31,807 --> 00:09:34,470 By doing this fragmentation and interleaving, 273 273 00:09:34,470 --> 00:09:36,687 it allows you to get some of that high priority traffic out 274 274 00:09:36,687 --> 00:09:39,403 in between those larger data structures as well.