The IP Over NBMA (ION) Archive

[Dennis Ferguson <dennis@jnx.com>]

> Of course, this sort of comparison is meaningless if one considers why
> one might be using ATM (in a reasonable world). ATM might be use to send
> this stuff over a very fast SONET WAN, shared with other non-IP signals.
> I don't see that getting hung up on overhead bits means much. The faster
> the media are, the more overhead creeps in.

If you don't like comparing IP to ATM, how about comparing frame relay
to ATM?  Frame relay has been used for just about everything that ATM
has been used for, and has the added bonus that if most of the traffic
you are carrying turns out to be IP anyway (a common occurance these days)
you don't have to equip all the routers with big bandwidth reassembly
interfaces which are more complex than the rest of the router and far,
far more expensive than frame interfaces built with the same technology.

And I don't get the comment about overhead at all.  The overhead of HDLC
on the 56 kbps circuits we built networks out of 10 years ago (which was
actually a 64 kbps circuit, except the phone company took 12.5% of it
as overhead) is 1 byte per frame plus about 0.6% for bit stuffing.  The
overhead of HDLC on an OC-48 SONET circuit (which the phone company takes,
what, 6% or 8% of for SONET header gunk) is 1 byte per frame plus about
0.8% for byte stuffing.  That doesn't seem like a lot of overhead creep
for a 4,000,000% bandwidth increase.

But it would be most inconsistent for one to suggest that the 15% or
25% more circuit (see, the percentages get even bigger when you put the
ATM payload bandwidth in the denominator) you could have by carrying
IP frames in HDLC frames (over frame relay or PPP, I care not) rather than
ATM cells is insignificant overhead, while simultaneously lamenting the
waste of "over-engineering" an IP backbone for QOS, when in fact on a
large backbone network aggregating lots of traffic from smaller sources
15% more circuit will actually take you from a state where you are dropping
3% of the packets out of a 50 ms queue at the hottest part of the day
to a state where you are dropping no packets and almost never seeing
queues longer than 3 ms (and this was on a T3 network since that's what
there was when I was in a position to measure.  OC-12 has just got to be
better still).  If you've got a large IP network aggregating traffic from
lots of smaller sources Poisson just isn't all that far off in predicting
its behaviour, self-similarity not withstanding.

Dennis Ferguson