Cogent service

Fri Sep 20 20:20:21 UTC 2002

On Fri, 20 Sep 2002, 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

Yes, but only once. With a layer 3 network (or non-ATM layer 2 network)
you get this at every hop.

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

Ok, if you push your line to 99% utilization your average queue size is
100 packets. Assuming those are 1500 bytes this adds up to 1200000 bits or
some 480 microseconds delay...

Not sure how many people do 99% or more over their 2.4 Gbps lines, though.

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

Well, I don't have an OC48 but I have seen slower lines that aren't
considered congested by any definition still experience tail drops from
time to time, so bursts happen. But that could be just 0.1% of the time,
yes.

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

I'm sure that after seeing jumboframes in gigabit ethernet, someone will
invent jumbocells for ATM to solve those shredding inefficiencies.

The problem with running IP over ATM is that both protocols need/use very
different ways handle congestion and those ways tend to conflict. So then
you have to cripple either one or the other. (Or buy more bandwidth.)