Let's look at some of the congestion management queuing mechanisms.
There are many queuing mechanisms.
Some of these are older and or inefficient for modern rich media networks.
In other words they were good in the past but are not good for voice over IP and video running across
a data network.
So let's start with a FIFO First In First Out queue.
This consists of a single queue with packets that are sent in the exact order that they arrived.
We've probably all experienced this queuing mechanism in the real world.
In this example we have people wanting to pay for their purchases.
There's only one cashier that they can pay at.
People are serviced in first come first serve order.
In other words First In First Out.
This lady arrived first.
So she served first.
This gentleman arrived second so he served a second and so forth and so on.
This is the front of the queue.
This is the back of the queue and people are served in that order.
In the same way in a FIFO queuing algorithm on a rota packets are served in the order that they arrived.
This is the front of the queue.
This is the back of the queue new packets are in queued at the back packets at the front of the queue
or D queued and forwarded for transmission.
The problem with this queuing mechanism is voice packets can be delayed by larger data packets.
Everyone is served in the same way which may work well in some cases in the real world but that wouldn't
work as an example if there was a emergency and an ambulance.
As an example needed to go to the front of the queue and a truck carrying cement or dry goods as an
example should wait for the ambulance.
You don't want a slow moving truck or lorry in front of a ambulance.
You want an ambulance to go to the front of the queue in the same way you want to voice packets to be
able to go to the front of the queue.
So FIFO is not good for voice and video another older queuing mechanism is a pretty key.
This consists of full queues that are served in a strict priority order and this queuing algorithm we
had for cues a high medium.
Normal and low key by enforcing a strict property the lower priority queues are served only when the
higher protein cues are empty so when traffic arrives.
If it's classified as important it's put into the high priority key classification could be done on
protocol or source interface or some other criteria.
Traffic in the high priority queue is always serviced first only when the high and medium queues are
empty is the normal queue processed.
The low priority queue is only processed when the high medium and normal queues are empty.
So this is the problem.
The low priority queue could starve if there is constant traffic in the high medium or normal queues
so low priority queues could be starved by higher priority queues.
It was an older mechanism which was fine in the past but doesn't serve well for modern networks.
A gain in a party queue we have full queues high medium normal and low High Priority Queues are always
serviced before low priority queues.
The problem here is it could result in starvation of lower priority queues.
A third queuing algorithm is custom queuing.
This consists of up to 16 queues serviced in a round robin fashion in order to prevent starvation.
It provides traffic guarantees.
The problem with this method however is that it doesn't provide strict priority for real time traffic.
So as an example we've got incoming packets they are classified into various queues that can be up to
16 of them can be of different sizes.
So you could provide more bandwidth to some queues compared to other queues.
The problem with custom queuing however is that if you have important voice traffic arriving it will
only be serviced in its round or in its turn so as an example of voice is processed now and then it's
the turn of the second queue and a new voice packet arrives.
That new voice packet is not going to be processed until Q3 Q4 queue five and all the way up to queue
16 is serviced and then it comes round back to voice customer queuing users a round robin queuing scheduler.
So once voice is processed it becomes the turn of the second key the scheduler doesn't come back to
the first queue or The Voice queue until it's processed all the other queues.
So the problem with this method is it introduces delay.
There's no priority for voice so voice traffic often gets delayed which introduces delay and Jetta and
affects voice quality.
So neither FIFO party queuing or custom queuing are ideal for a modern network a fourth algorithm is
weighted for queuing.
This is an algorithm that divides the Internet bandwidth by the number of flows thus trying to ensure
proper distribution of the bandwidth for all applications.
It provides generally a good service for real time traffic but they are no bandwidth guarantees for
particular flows and some flows can actually stop other flows.