Algorithm Design

798
Epilogue: Algorithms That Run Forever
buffers to output buffers, then all their input buffers and all their output buffers
g} must
form a bipartite matching. Thus we can model a single time step as follows.
One step under input/output queueing:
Packets arrive on input links and are placed in input buffers
A set of packets whose types form a matching are moved to their
associated output buffers
At most one packet departs from each output buffer
The choice of which matching to move is left unspecified for now; this is a
point that will become crucial later.
So under input/output queueing, the switch introduces some "friction" on
the movement of packets, and this is an observable phenomenon: if we view
the switch as a black box, and simply watch the sequence of departures on the
output links, then we can see the difference between pure output queueing
and input/output queueing. Consider an example whose first step is just like
Figure E.1, and in whose second step a single packet s of type (I4, 04) arrives.
Under pure output queueing, p and q would depart in the first step, and r and
s would depart in the second step. Under input/output queueing, however,
the sequence of events depicted in Figure E.2 occurs: At the end of the first
step, r is still sitting in the input buffer 14, and so, at the end of the second
step, one of r or s is still in the input buffer 14 and has not yet departed. This
conflict between r and s is called head-of-line blockir~, and it causes a switch
with input/output queueing to exhibit inferior delay characteristics compared
with pure output queueing.
Simulating a Switch with Pure Output Queueing While pure output queueing
would be nice to have, the arguments above indicate why it’s not feasible
to design a switch with this behavior: In a single time step (lasting only tens of
nanoseconds), it would not generally be possible to move packets from each
of n input links to a common output buffer.
But what if we were to take a switch that used input/output queueing and
ran it somewhat faster, moving several matchings in a single time step instead
of just one? Would it be possible to simulate a switch that used pure output
queueing? By this we mean that the sequence of departures on the output links
(viewing the switch as a black box) should be the same under the behavior of
pure output queueing and the behavior of our sped-up input/output queueing
algorithm.
It is not hard to see that a speed-up of n would suffice: If we could move
n matchings in each time step, then even if every arriving packet needed to
reach the same output buffer, we could move them a~ in the course of one
(b)
Epilogue: Algorithms That Run Forever
~ 02
~ 0 3
J O1
____.------- 0 2
~Packets q and r can’Q
both move through
the switch in one
~me step.
Iin
As a result of r having ~
to wait, one of packets|
r and s will be blocked|
this step.
J
Figure E.2 Parts (a) and (b) depict a two-step example in which head-of-line bloc!ring
OCCURS.
step. But a speed-up of n is completely infeasible; and if we think about this
worst-case example, we begin to worry that we might need a speed-up of n to
make this work--after all, what if all the arriving packets really did need to
go to the same output buffer?
The crux of this section is to show that a much more modest speed-up
is sufficient. We’ll describe a striking result of Chuang, Goe!, McKeown, and
Prabhakar (1999), showing that a switch using input/output queueing with a
speed-up of 2 can simulate a switch that uses pure output queueing. Intuitively,
the result exploits the fact that the behavior of the switch at an internal level
need not resemble the behavior under pure output queueing, provided that
the sequence of output link departures is the same. (Hence, to continue the
799