NAP/ISP Saturation WAS: Re: Exchanges that matter...

   * Head of queue blocking in the Gigaswitch

   Even though the Gigaswitch has input and output queues, your output queue
   will block until the other providers input queue is free.

My (admittedly second hand) understanding is that the Gigaswitch/FDDI
actually has minimal amounts of buffering. During a congestion event, it
simply withholds the token, resulting in buffering in the routers. Queues
there eventually overflow, and ...

This matches my understanding, though I think it understates the problem.
Gigaswitches are essentially input-queued. When their teeny tiny buffers
fill they flow-control everyone to slow them down. What this means is that
a single congested output port will cause all inputs, including packets
to the other `n' uncongested output ports, to be pushed back, so the overall
throughput drops. And there appear to be additional problems caused when
two gigaswitches are connected together, on the link between them, I
assume because flow control sucks even worse when neither of the guys on
the ends of the link has buffers.

In any case, the head-of-line blocking means these switches only work
really well when they're unloaded, something I've always suspected.
Providing suitable buffering in switches is both necessary and sufficient.
The evil that flow control attempts to hide is still evil, you just have
to work harder to see it.

Dennis Ferguson

I'm quite curious how they handle full-duplex FDDI where
witholding the token doesn't seem to be an option. Do they simply drop
packets when traffic gets bursty?

  Ironically, I'd prefer they drop the packet bound for a busy port
rather than stop all incoming traffic from a port until the busy port

  If anyone has experience with NetStar's GigaRouters, especially
in comparison to the GigaSwitches, I'd love to hear about it. You can
reach me at