1 00:00:00,630 --> 00:00:04,860 Let's look at some of the congestion management queuing mechanisms. 2 00:00:04,860 --> 00:00:06,960 There are many queuing mechanisms. 3 00:00:07,110 --> 00:00:12,990 Some of these are older and or inefficient for modern rich media networks. 4 00:00:12,990 --> 00:00:19,290 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,290 --> 00:00:21,200 a data network. 6 00:00:21,210 --> 00:00:25,410 So let's start with a FIFO First In First Out queue. 7 00:00:25,410 --> 00:00:32,100 This consists of a single queue with packets that are sent in the exact order that they arrived. 8 00:00:32,100 --> 00:00:36,780 We've probably all experienced this queuing mechanism in the real world. 9 00:00:36,840 --> 00:00:41,260 In this example we have people wanting to pay for their purchases. 10 00:00:41,280 --> 00:00:44,460 There's only one cashier that they can pay at. 11 00:00:44,460 --> 00:00:48,120 People are serviced in first come first serve order. 12 00:00:48,150 --> 00:00:49,870 In other words First In First Out. 13 00:00:50,010 --> 00:00:51,450 This lady arrived first. 14 00:00:51,480 --> 00:00:53,490 So she served first. 15 00:00:53,580 --> 00:00:58,690 This gentleman arrived second so he served a second and so forth and so on. 16 00:00:58,710 --> 00:01:00,080 This is the front of the queue. 17 00:01:00,090 --> 00:01:03,810 This is the back of the queue and people are served in that order. 18 00:01:05,200 --> 00:01:13,180 In the same way in a FIFO queuing algorithm on a rota packets are served in the order that they arrived. 19 00:01:13,180 --> 00:01:14,320 This is the front of the queue. 20 00:01:14,320 --> 00:01:20,440 This is the back of the queue new packets are in queued at the back packets at the front of the queue 21 00:01:20,880 --> 00:01:24,000 or D queued and forwarded for transmission. 22 00:01:24,010 --> 00:01:30,820 The problem with this queuing mechanism is voice packets can be delayed by larger data packets. 23 00:01:30,820 --> 00:01:36,910 Everyone is served in the same way which may work well in some cases in the real world but that wouldn't 24 00:01:36,910 --> 00:01:41,530 work as an example if there was a emergency and an ambulance. 25 00:01:41,530 --> 00:01:47,620 As an example needed to go to the front of the queue and a truck carrying cement or dry goods as an 26 00:01:47,620 --> 00:01:51,160 example should wait for the ambulance. 27 00:01:51,160 --> 00:01:56,560 You don't want a slow moving truck or lorry in front of a ambulance. 28 00:01:56,560 --> 00:02:01,690 You want an ambulance to go to the front of the queue in the same way you want to voice packets to be 29 00:02:01,690 --> 00:02:03,430 able to go to the front of the queue. 30 00:02:03,580 --> 00:02:10,810 So FIFO is not good for voice and video another older queuing mechanism is a pretty key. 31 00:02:10,830 --> 00:02:17,330 This consists of full queues that are served in a strict priority order and this queuing algorithm we 32 00:02:17,330 --> 00:02:20,000 had for cues a high medium. 33 00:02:20,030 --> 00:02:27,680 Normal and low key by enforcing a strict property the lower priority queues are served only when the 34 00:02:27,680 --> 00:02:31,740 higher protein cues are empty so when traffic arrives. 35 00:02:31,770 --> 00:02:38,250 If it's classified as important it's put into the high priority key classification could be done on 36 00:02:38,250 --> 00:02:42,830 protocol or source interface or some other criteria. 37 00:02:42,960 --> 00:02:49,020 Traffic in the high priority queue is always serviced first only when the high and medium queues are 38 00:02:49,020 --> 00:02:51,740 empty is the normal queue processed. 39 00:02:52,230 --> 00:02:59,010 The low priority queue is only processed when the high medium and normal queues are empty. 40 00:02:59,250 --> 00:03:00,720 So this is the problem. 41 00:03:00,720 --> 00:03:07,980 The low priority queue could starve if there is constant traffic in the high medium or normal queues 42 00:03:08,790 --> 00:03:13,550 so low priority queues could be starved by higher priority queues. 43 00:03:13,560 --> 00:03:19,450 It was an older mechanism which was fine in the past but doesn't serve well for modern networks. 44 00:03:19,530 --> 00:03:26,550 A gain in a party queue we have full queues high medium normal and low High Priority Queues are always 45 00:03:26,550 --> 00:03:29,610 serviced before low priority queues. 46 00:03:29,610 --> 00:03:34,890 The problem here is it could result in starvation of lower priority queues. 47 00:03:35,190 --> 00:03:38,090 A third queuing algorithm is custom queuing. 48 00:03:38,100 --> 00:03:44,490 This consists of up to 16 queues serviced in a round robin fashion in order to prevent starvation. 49 00:03:44,520 --> 00:03:46,920 It provides traffic guarantees. 50 00:03:46,980 --> 00:03:54,020 The problem with this method however is that it doesn't provide strict priority for real time traffic. 51 00:03:54,020 --> 00:03:59,790 So as an example we've got incoming packets they are classified into various queues that can be up to 52 00:03:59,790 --> 00:04:03,380 16 of them can be of different sizes. 53 00:04:03,420 --> 00:04:08,820 So you could provide more bandwidth to some queues compared to other queues. 54 00:04:08,820 --> 00:04:14,700 The problem with custom queuing however is that if you have important voice traffic arriving it will 55 00:04:14,760 --> 00:04:21,810 only be serviced in its round or in its turn so as an example of voice is processed now and then it's 56 00:04:21,810 --> 00:04:26,760 the turn of the second queue and a new voice packet arrives. 57 00:04:26,760 --> 00:04:34,090 That new voice packet is not going to be processed until Q3 Q4 queue five and all the way up to queue 58 00:04:34,090 --> 00:04:41,840 16 is serviced and then it comes round back to voice customer queuing users a round robin queuing scheduler. 59 00:04:42,620 --> 00:04:48,950 So once voice is processed it becomes the turn of the second key the scheduler doesn't come back to 60 00:04:48,950 --> 00:04:54,490 the first queue or The Voice queue until it's processed all the other queues. 61 00:04:54,620 --> 00:04:57,700 So the problem with this method is it introduces delay. 62 00:04:57,870 --> 00:05:05,180 There's no priority for voice so voice traffic often gets delayed which introduces delay and Jetta and 63 00:05:05,180 --> 00:05:07,130 affects voice quality. 64 00:05:07,130 --> 00:05:16,190 So neither FIFO party queuing or custom queuing are ideal for a modern network a fourth algorithm is 65 00:05:16,190 --> 00:05:17,680 weighted for queuing. 66 00:05:17,690 --> 00:05:25,040 This is an algorithm that divides the Internet bandwidth by the number of flows thus trying to ensure 67 00:05:25,040 --> 00:05:29,280 proper distribution of the bandwidth for all applications. 68 00:05:29,420 --> 00:05:36,830 It provides generally a good service for real time traffic but they are no bandwidth guarantees for 69 00:05:37,010 --> 00:05:40,970 particular flows and some flows can actually stop other flows.