ATM overhead

Sat Apr 6 02:18:21 UTC 1996

At 05:12 PM 4/5/96 -0800, Kent W. England wrote:

>
>I have been doing some more arithmetic on the "ATM cell tax" to see if I can
>find out how folks get from 10% (which is the 5/53 overhead) to 35%
>overhead. I would really really like to see some backup for those sort of
>numbers -- I can't make the arithmetic work out to anything near 35% for
>what I think are useful assumptions.  Of course, if you want to posit 100%
>of IP traffic with 49 bytes, but that doesn't seem realistic and you
>shouldn't forget that 40 of those are TCP/IP overhead. :-)
>
>What traffic mix do you use to calculate ATM overhead and what results do
>you get?
>

Trying to avoid reinventing the arithmetic wheel here, I've taken the
liberty of cutting-and-pasting a couple of snippets from earlier
discussions on this topic.

[snip]

Date: Tue, 19 Mar 1996 19:51:33 -0800
From: Jim Forster <forster at cisco.com>
Sender: owner-nanog at merit.edu

He's talking about the overhead due to carrying variable length IP packets
in fixed length ATM cells.  Consequently the last cell of an AAL5 frame
will contain 0 - 39(?) bytes of padding, which is wasted bandwidth.
Assuming random length distributions (which they're not), the average waste
is about 20 bytes per packet.

My rough estimate, based on an average packet size of 200 bytes (used to be
correct, not sure anymore), is that the waste due to cell padding is about
10%.  Due to the highly skewed packet size distribution the actual overhead
might vary substantially.  Note that this 10% is on top of the ~10%
overhead due to the 5 byte ATM cell headers (5/53 ~= 10%), and various
other overheads (some of which are also present in frame over Sonet
schemes).

There's beginning to be some expectation that there will be a transmission
capacity crunch in the carrier's Sonet nets, and this ~25% ATM cell tax may
be looked at carefully as packet over Sonet solutions emerge.

[snip]

From: Wolfgang Henke <wolfgang at whnet.com>
Date: Tue, 19 Mar 1996 20:34:05 -0800 (PST)
Sender: owner-nanog at merit.edu

Great. Let's estimate the ATM bandwidth available on an OC-3. With
STS-3c SONET at 155.520 Mbps it gets reduced to 149.760 Mbps due to 
section, line and path SONET overhead. 

Next we reduce 10% due to 20 bytes lost on average 200 byte long
packets due to incomplete ATM cell fills resulting in 134.784 Mbps.

Then we need to subtract 9.43% due to ATM headers of 5 bytes in 53 byte
packets.

Thus we end up with a 122.069 Mbps true information rate which is about
78.5% of the nominal OC-3 capacity.

And we still have not raised the issues of wasted reserved bandwidth
and routing ease which were recently addressed very eloquently by
Vadim Antonov when comparing connection based with packet based
transport.

[snip]

Me again.

Finally, these are the various overheads mentioned in Jim's message
above:

                        ATM                    

AAL5                    8 bytes                 
LLC snap encap          8 bytes                
unused part of cell     0-40 bytes (avg. 20)
                        ---                  
                        36 bytes (avg.)          

- paul