1 00:00:00,530 --> 00:00:04,520 Now let's look at some of the congestion management queuing mechanisms. 2 00:00:04,730 --> 00:00:06,890 There are many queuing mechanisms. 3 00:00:06,950 --> 00:00:12,790 Some of these are older and are inefficient for modern, rich media networks. 4 00:00:12,800 --> 00:00:19,310 In other words, they were good in the past but are not good for voice over IP and video running across 5 00:00:19,310 --> 00:00:20,600 a data network. 6 00:00:21,020 --> 00:00:25,190 So let's start with a FIFO or first in first out queue. 7 00:00:25,220 --> 00:00:31,850 This consists of a single queue with packets that are sent in the exact order that they arrived. 8 00:00:31,880 --> 00:00:36,410 We've probably all experienced this queuing mechanism in the real world. 9 00:00:36,680 --> 00:00:41,070 In this example, we have people wanting to pay for their purchases. 10 00:00:41,090 --> 00:00:47,840 There's only one cashier that they can pay at people of service to in first come, first serve order. 11 00:00:47,960 --> 00:00:49,880 In other words, first in, first out. 12 00:00:49,880 --> 00:00:53,060 This lady arrived first, so she served first. 13 00:00:53,420 --> 00:00:55,190 This gentleman arrived second. 14 00:00:55,190 --> 00:00:57,950 So he served a second and so forth and so on. 15 00:00:58,580 --> 00:00:59,990 This is the front of the queue. 16 00:01:00,020 --> 00:01:01,550 This is the back of the queue. 17 00:01:01,550 --> 00:01:03,980 And people are served in that order. 18 00:01:05,030 --> 00:01:12,170 In the same way in a FIFO queuing algorithm on a router, packets are served in the order that they 19 00:01:12,170 --> 00:01:13,010 arrived. 20 00:01:13,040 --> 00:01:14,270 This is the front of the queue. 21 00:01:14,300 --> 00:01:15,790 This is the back of the queue. 22 00:01:15,830 --> 00:01:22,790 New packets are in queued to the back packets at the front of the queue or D queued and forwarded for 23 00:01:22,790 --> 00:01:23,690 transmission. 24 00:01:23,840 --> 00:01:30,630 The problem with this queuing mechanism is voice packets can be delayed by large data packets. 25 00:01:30,650 --> 00:01:35,960 Everyone is served in the same way, which may work well in some cases in the real world. 26 00:01:35,960 --> 00:01:37,220 But that wouldn't work. 27 00:01:37,220 --> 00:01:43,760 As an example, if there was an emergency and an ambulance as an example, needed to go to the front 28 00:01:43,760 --> 00:01:44,570 of the queue. 29 00:01:44,570 --> 00:01:50,690 And a truck carrying cement or dry goods, as an example, should wait for the ambulance. 30 00:01:50,990 --> 00:01:56,540 You don't want a slow moving truck or lorry in front of a ambulance. 31 00:01:56,540 --> 00:01:58,970 You want an ambulance to go to the front of the queue. 32 00:01:59,660 --> 00:02:03,320 In the same way you want a voice packets to be able to go to the front of the queue. 33 00:02:03,350 --> 00:02:06,350 So FIFO is not good for voice and video. 34 00:02:07,190 --> 00:02:10,430 Another older queuing mechanism is a priority queue. 35 00:02:10,580 --> 00:02:14,930 This consists of four queues that are served in a strict priority order. 36 00:02:15,910 --> 00:02:21,610 In this queuing algorithm, we had four queues a high medium, normal and low queue. 37 00:02:22,150 --> 00:02:28,360 By enforcing a strict priority, the lower priority queues are served only when the higher priority 38 00:02:28,360 --> 00:02:29,590 queues are empty. 39 00:02:30,370 --> 00:02:36,010 So when traffic arrives, if it's classified as important, it's put into the high priority queue. 40 00:02:36,460 --> 00:02:42,400 Classification could be done on protocol or source interface or some other criteria. 41 00:02:42,880 --> 00:02:49,060 Traffic in the high priority queue is always serviced first only when the high and medium queues are 42 00:02:49,060 --> 00:02:49,720 empty. 43 00:02:49,750 --> 00:02:51,820 Is the normal queue processed? 44 00:02:52,030 --> 00:02:58,570 The low priority queue is only processed when the high, medium and normal queues are empty. 45 00:02:59,050 --> 00:03:00,520 So this is the problem. 46 00:03:00,520 --> 00:03:08,170 The low priority queue could starve if there is constant traffic in the high, medium or normal queues, 47 00:03:08,650 --> 00:03:13,120 so low priority queues could be starved by higher priority queues. 48 00:03:13,390 --> 00:03:19,360 It was an older mechanism which is fine in the past but doesn't serve well for modern networks. 49 00:03:19,480 --> 00:03:24,580 Again, in a priority queue we have four queues high, medium, normal and low. 50 00:03:24,610 --> 00:03:29,140 High priority queues are always serviced before low priority queues. 51 00:03:29,440 --> 00:03:34,600 The problem here is it could result in starvation of lower priority queues. 52 00:03:35,140 --> 00:03:37,930 A third queuing algorithm is custom queuing. 53 00:03:37,960 --> 00:03:42,340 This consists of up to six queues serviced in a round robin fashion. 54 00:03:42,340 --> 00:03:46,750 In order to prevent starvation, it provides traffic guarantees. 55 00:03:46,780 --> 00:03:53,380 The problem with this method, however, is that it doesn't provide strict priority for real time traffic. 56 00:03:53,890 --> 00:03:59,050 So as an example, we've got incoming packets, they are classified into various queues. 57 00:03:59,050 --> 00:04:03,340 There can be up to 16 of them can be of different sizes. 58 00:04:03,340 --> 00:04:08,470 So you could provide more bandwidth to some queues compared to other queues. 59 00:04:08,680 --> 00:04:14,530 The problem with custom queuing, however, is that if you have important voice traffic arriving, it 60 00:04:14,530 --> 00:04:18,310 will only be serviced in its round or in its turn. 61 00:04:18,700 --> 00:04:21,610 So as an example, your voice is processed now and then. 62 00:04:21,610 --> 00:04:28,570 It's the turn of the second queue and a new voice packet arrives that a new voice packet is not going 63 00:04:28,570 --> 00:04:36,430 to be processed until Q3, Q4, Q5 and all the way up to queue 16 is serviced and then it comes round 64 00:04:36,430 --> 00:04:41,830 back to voice custom queuing uses a round robin queuing scheduler. 65 00:04:42,460 --> 00:04:46,950 So once voice is processed, it becomes the turn of the second queue. 66 00:04:47,020 --> 00:04:53,410 The scheduler doesn't come back to the first cue or the voice cue until it's processed all the other 67 00:04:53,410 --> 00:04:54,160 cues. 68 00:04:54,430 --> 00:04:57,640 So the problem with this method is it introduces delay. 69 00:04:57,670 --> 00:04:59,940 There's no priority for voice. 70 00:04:59,950 --> 00:05:06,700 So voice traffic often gets delayed, which introduces delay and jitter and affects voice quality. 71 00:05:06,970 --> 00:05:13,630 So neither FIFO priority queuing or custom queuing are ideal for a modern network. 72 00:05:14,890 --> 00:05:17,440 A fourth algorithm is weighted for queuing. 73 00:05:17,470 --> 00:05:25,030 This is an algorithm that divides the internet bandwidth by the number of flows, thus trying to ensure 74 00:05:25,030 --> 00:05:28,960 proper distribution of the bandwidth for all applications. 75 00:05:29,260 --> 00:05:36,940 It provides generally a good service for real time traffic, but there are no bandwidth guarantees for 76 00:05:36,940 --> 00:05:41,170 particular flows and some flows can actually starve other flows.