Really? Then I guess Juniper made a mistake chopping every packet
into 64 byte packets ;-) . From a hardware standpoint, it speeds up
the process significantly. Think of a factory with a cleaver
machine, it knows exactly where to chop the pieces because there is a
rhythm. It takes no "figuring out." By chopping up everything into
set sizes you dont need to "search" for headers or different parts of
the packet. It's always at a "set" byte number. Well Ive done a
poor job of explaining it, but it does speed things up.
Under the best possible circumstances, most of the extra delay is due to
the fact that routers do "store and forward" forwarding, so you have to
wait for the last bit of the packet to come in before you can start
sending the first bit over the next link. This delay is directly
proportional to the bandwidth and the packet size. Since ATM uses very
small "packets" this isn't as much an issue there.
But doing SAR at the ends of the PVC youīll end up suffering the same
latency anyway and since most people run their ATM PVCīs at a rate
smaller than the attached linerate, this delay is actually larger in many
However, the real problem with many hops comes when there is congestion.
Then the packet suffers a queuing delay at each hop. Now everyone is going
to say "but our network isn't congested" and it probably isn't when you
look at the 5 minute average, but short term (a few ms - several seconds)
congestion happens all the time because IP is so bursty. This adds to the
If you either do the math at OC48 or above or just look at how many places
are able to generate severe, even subsecond bursts on any significant
youīll figure out that 99.9% of the time, there arenīt any. If you burst
access link, then itīs a not a backbone hopcount issue.
jitter. It doesn't matter whether those extra hops are layer 2 or layer 3,
though: this can happen just as easily in an ethernet switch as in a
router. Because ATM generally doesn't buffer cells but discards them, this
also isn't much of an issue for ATM.
Most ATM switches have thousands of cell buffers for an interface or tens of
thousands to a few million shared for all interfaces. There is one legendary
piece of hardware with buffer space for 32 cells. Fortunately they didnīt
too many out there.
However, when an ATM network gets in trouble it's much, much worse than
some jitter or even full-blown congestion, so I'll take as many hops as I
must to avoid ATM (but preferably no more than that) any day.
Depends on your ATM hardware, most of the vendors fixed their ATM to make
decisions based on packets. Which kind of defeats the idea of having 53 byte
shredded packets in the first place.