Now let's look at some of the congestion management queuing mechanisms.
There are many queuing mechanisms.
Some of these are older and are 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 or 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 of service to 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 router, 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 to 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 large 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 an 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 a 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 priority queue.
This consists of four queues that are served in a strict priority order.
In this queuing algorithm, we had four queues a high medium, normal and low queue.
By enforcing a strict priority, the lower priority queues are served only when the higher priority
queues are empty.
So when traffic arrives, if it's classified as important, it's put into the high priority queue.
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 is fine in the past but doesn't serve well for modern networks.
Again, in a priority queue we have four 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 six 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.
There 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, your voice is processed now and then.
It's the turn of the second queue and a new voice packet arrives that a new voice packet is not going
to be processed until Q3, Q4, Q5 and all the way up to queue 16 is serviced and then it comes round
back to voice custom queuing uses a round robin queuing scheduler.
So once voice is processed, it becomes the turn of the second queue.
The scheduler doesn't come back to the first cue or the voice cue until it's processed all the other
cues.
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 jitter and affects voice quality.
So neither FIFO priority 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 there are no bandwidth guarantees for
particular flows and some flows can actually starve other flows.