Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

2.2.-FIFO Queuing Discipline: Previous Content Next

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 3

Previous Content 

  Next

2.2.- FIFO queuing discipline

32-bit, 32-elements FIFO queue performing  


insert, delete, replace, shuffle*, get and put
operations (* in multiple of 4's)

FIFO is absolutely explained by Chuck Sumeria [11] in a few sentences and a figure; let's see
how:
First in, first out (FIFO) queuing is the most basic queue scheduling discipline. In FIFO
queuing, all packets are treated equally by placing them into a single queue, and then servicing
them in the same order that they were placed into the queue. FIFO queuing is also referred to as
First come, first served (FCFS) queuing. (See Figure 2.2.1)
 

  

 
Easy. Isn't it? By the way, FIFO is the default queuing discipline used by Linux and most of
the routers around the world. In case you don't specifiy any specific qdisc Linux assembles its
interfaces with this type of queue. Let's see now how we can setup a FIFO queue on ethernet
interface eth0 using tc; at the Linux command prompt just write:
 
 
The command is self-explanatory. 'tc' is the utility; 'qdisc' for telling tc we are configuring a
queue discipline (it could be 'class' or 'filter' if we are configuring a class or a filter
respectively); 'add' because we are adding a new qdisc; 'dev eth0' for adding the qdisc to the
device or interface Ethernet eth0; 'root' because it is a root qdisc (it doesn't apply to pfifo that is  
classless - only a root qdisc exists - but required to normalize the command utilization); 'pfifo'
because our queue is a pfifo (packet-fifo) queue. Finally pfifo requires only one parameter: just
'limit' to indicate the length of the queue (number of packets that the queue can hold). Our
pfifo queue is a 10 packets queue.
 
After creating our queueing discipline we can ask tc what we have configured; the following
command:

will respond with:

The command just says: show us what qdisc we have on device eth0. tc responds by telling us
that we have a pfifo qdisc numbered as 8001: (this really means 8001:0) with a limit capacity of
10 packets. Qdiscs and components are numbered, or better yet identified by a 32 bits handler
formed by a 16 bits major number and a 16 bits minor number. The minor number is always zero
for queues. When we added our pfifo queue we didn't assign it any handler and then tc created
one for it (8001:0).
FIFO has spread as the grass but it has benefits and limitations. Chuck [11] exposes about this in
a magisterial approach:
FIFO queuing offers the following benefits:
 For software based routers, FIFO queuing places an extremely  
low computational load on the system when compared with more
elaborate queue scheduling disciplines.
  The behavior of a FIFO queue is very predictable---packets are
not reordered and the maximum delay is determined by the
maximum depth of the queue.
 As long as the queue depth remains short, FIFO queuing provides
simple contention resolution for network resources without
adding significantly to the queuing delay experienced at each hop.

FIFO queuing also poses the following limitations:


 
 A single FIFO queue does not allow routers to organize buffered
packets, and then service one class of traffic differently from other
classes of traffic.
 A single FIFO queue impacts all flows equally, because the mean
queuing delay for all flows increases as congestion increases. As
a result, FIFO queuing can result in increased delay, jitter, and
loss for real time applications traversing a FIFO queue.
 During periods of congestion, FIFO queuing benefits UDP flows
over TCP flows. When experiencing packet loss due to
congestion, TCP based applications reduce their transmission
rate, but UDP based applications remain oblivious to packet loss
and continue transmitting packets at their usual rate. Because
TCP based applications slow their transmission rate to adapt to
changing network conditions, FIFO queuing can result in
increased delay, jitter, and a reduction in the amount of output
bandwidth consumed byTCP applications traversing the queue.  
 A bursty flow can consume the entire buffer space of a FIFO
queue, and that causes all other flows to be denied service until
after the burst is serviced. This can result in increased delay,
jitter, and loss for the other well behaved TCP and UDP flows
traversing the queue.

More clearly, impossible. Well, with all these problems let's delete the
pfifo queue from our device eth0:
 

 
That brought to the english just means: delete from device eth0 the root
queue discipline. Okay. We are over with FIFO. Now let's try with PRIO.

   

Previous Content   Next

You might also like