Cogent service

David Diaz davediaz at smoton.net
Fri Sep 20 22:50:44 UTC 2002


At 22:38 +0300 9/20/02, Petri Helenius wrote:
>>  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
>cases.
>>
>>  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
>backbone,
>you´ll figure out that 99.9% of the time, there aren´t any. If you burst
>your
>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
>get
>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.

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.


>
>Pete




-- 

David Diaz
dave at smoton.net [Email]
pagedave at smoton.net [Pager]
Smotons (Smart Photons) trump dumb photons





More information about the NANOG mailing list