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

Tue Dec 17 08:52:47 UTC 1996

   * ICMP packets are dropped by busy routers

   Many routers drop ICMP packets (ping, traceroute) when busy, or alternate
   dropping ICMP packets.  I know that this behavior occurs when the packets
   are directed to the specific router, I am not sure if this every occurs
   for packets passing through.  The standby tool ping needs a more reliable
   replacement for testing end to end packet loss.

There seems to be a great deal of (understandable) confusion on this
issue.  Let's set it straight:

Packets which are _successfully_ forwarded through a (high end) cisco
router are not (by default) prioritized by protocol type.  Packets which
are not forwarded require more work and are effectively rate limited (and
consume large amounts of CPU time).  Some effects:

- Pinging a cisco is not a valid measure of packet loss.  It's closer to a
CPU load measure than anything else.

- Pinging _thru_ a cisco is reasonable.

- Traceroute to a cisco is rate limited to one reply per second, so will
almost always miss the middle reply.

- Traceroute _thru_ a cisco may show many drops which would NOT be seen by
normal "thru" traffic.  Replies generated by the cisco when the TTL expires
are again thru the CPU.  So you may well traceroute thru a cisco which does
not reply at all.  However, you can clearly see the route after that router.

   * 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 ...

If this is incorrect, I would greatly appreciate pointers to the truth.

Tony