From: Tom Christiansen (tomchr@ee.washington.edu)
Date: Fri Oct 22 2004 - 19:16:31 PDT
This article points out a fundamental flaw in previous, packet based,
fairness control schemes. In previous schemes, packages were sent in a
round robin fashion. This meant a fair allocation of the number of sent
packages per source, but as package sizes differ, this will not always be a
fair allocation of bandwidth. The proposed method, Fair Queuing, corrects
this by assigning a bid number to each packet entering the queue. By making
the bid number dependant on packet size, a more fair allocation of
bandwidth is ensured. The proposed method was simulated in a number of
different scenarios and compared against other algorithms. It was concluded
that the FQ method was superior with respect to fairness and immunity
against ill-behaved sources.
The strongest part of the paper is the description of motivation, proposed
new algorithm, flow control, and the discussion sections. These parts of
the paper are reasonably well written and provide enough scientific
background to make the case for using the FQ algorithm.
The paper falls apart in the Simulations section. This section is a mix of
descriptions of simulation setups, arguments for why these setups are
relevant, notes, figures, tables, etc. The whole section could use a
re-write making it easier to read and more concise and to the point. Let
the data speak for itself.
The paper does bring out one interesting point: Different services should
have different priorities. This paper uses Telnet vs. FTP as such an
example. The Telnet users should have higher priority than FTP users as
they send smaller amounts of data and are more intolerant to large
round-trip delays. The authors, provide a few suggestions on how to solve
this problem, but arrive at the conclusion that implementation of these
suggestions is not feasible as there are no measures to ensure that
low-priority applications can't cheat the system by faking to be an
application with higher priority.
This archive was generated by hypermail 2.1.6 : Fri Oct 22 2004 - 19:16:39 PDT