Interesting numbers. After a few weeks of bad performance on an Internet feed I look after I was drawn back to an issue I thought was long buried. This circuit was dropping 4-5% of its traffic at well below advertised capacity. The delivery method was ethernet over ATM/AAL5 (RFC1483). The usual suspects were rounded up and shot (duplex and error counters, purple switches, the cleaning lady). The next question was overhead for cell tax and encapsulation. 12% seems to be the allowance by our supplier. IIRC this is the same as was used 10 years ago for ATM VCs delivered directly to routers (no ethernet involved); nanog has a few dusty posts about this number. It seems this is no longer enough. Perhaps average packet sizes have changed since then if 12% was ever a reasonable number. In the end our supplier ramped overhead to about 20% and the pipe has performed nicely since. For an ethernet service, I don't understand why they don't simply provision the VC (VBR) as large as the customer bearer can handle and let the end devices do the shaping. Michael's numbers including AAL5 padding give this new figure some context: Upstream: cell tax = 14.84% (18.09% AAL5) Downstream: cell tax = 18.35% (23.43% AAL5) Is anyone aware of a recent study of packet size distribution on Internet traffic? CAIDA have some information from the AIX in 1999, NLANR from '97, and Sprint do a semi-regular dump from their ipmon project. http://www.caida.org/analysis/AIX/plen_hist http://www.nlanr.net/NA/Learn/packetsizes.html http://ipmon.sprint.com/packstat/packetoverview.php
From netflow stats on this link, I see a similar story with 64, 576 and 1536B being the points of most interest. The percentage of 1536B packets (~25) I think is larger now than previously.
Has anyone had similar frustrations with PVC dimensioning? Does anyone else still use ATM? :) Mark. On 5/23/06, Michael Newbery < Michael.Newbery(a)team.telstraclear.co.nz> wrote:
Prompted by Mark Seward, we have had a look at the cell tax incurred for our customers, in those cases where we are unfortunate enough to have to transit an ATM pipe. Which has not been the usual case on our network but becomes interesting for things like UBS.
This enables us to answer the question: for a pipe of x bps sufficient to carry pure IP, how much bigger must the ATM PVC be to carry the same load?
IP_bw = x ATM_bw = ceiling(x/48)*53 Diff = ATM_bw - IP_bw Cell_tax = Diff/IP_bw
For a sample SAMP, we calculate the mean cell tax as (sum(ceiling( SAMP/48)*53) - sum(SAMP))/sum(SAMP)
Looking at a 24 hour sample, we get: Upstream: cell tax = 14.84% Downstream: cell tax = 18.35%
I understand that this is somewhat at variance with the standard provisioning rules applied by another provider. -- Michael Newbery IP Architect TelstraClear Limited Tel: +64-4-920 3102 Mobile: +64-29-920 3102 Fax: +64-4-920 3361
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
On 24/5/06 11:13 AM, "Mark Seward"
Interesting numbers. After a few weeks of bad performance on an Internet feed I look after I was drawn back to an issue I thought was long buried. This circuit was dropping 4-5% of its traffic at well below advertised capacity. The delivery method was ethernet over ATM/AAL5 (RFC1483). The usual suspects were rounded up and shot (duplex and error counters, purple switches, the cleaning lady).
The next question was overhead for cell tax and encapsulation. 12% seems to be the allowance by our supplier. IIRC this is the same as was used 10 years ago for ATM VCs delivered directly to routers (no ethernet involved); nanog has a few dusty posts about this number. It seems this is no longer enough. Perhaps average packet sizes have changed since then if 12% was ever a reasonable number.
In the end our supplier ramped overhead to about 20% and the pipe has performed nicely since. For an ethernet service, I don't understand why they don't simply provision the VC (VBR) as large as the customer bearer can handle and let the end devices do the shaping.
OK, I've tried out the effects of the various encapsulations, and get ATM Cell Tax Upstream: 18.35% (23.43% AAL5, 29.28% rfc1483/2225, 30.01% PPPoA, 29.68% UBS) Downstream: 14.84% (18.09% AAL5, 20.70% rfc1483/2225, 21.13% PPPoA, 20.55% UBS) The raw upstream is not terribly useful---it's just the ATM overhead. At a minimum you'll get AAL5 overhead. If you use rfc1483 or rfc2225 encapsulation you'll get some more. PPPoA has a different overhead, and for L2TP as per UBS, you'll have L2TP + PPP + RFC + AAL5. Note that this is just the cell tax. I.e., after you've padded your IP packet with L2TP + PPP + RFC, that's how much extra you need to allow for in your cell budget. I've heard off-list that our distribution matches at least one other organization. 12% seems to be the overhead you'd get for sending 1,500 byte packets in an ATM PVC. Basically, it is the minimum overhead you can ever achieve. -- Michael Newbery IP Architect TelstraClear Limited Tel: +64-4-920 3102 Mobile: +64-29-920 3102 Fax: +64-4-920 3361
participants (2)
-
Mark Seward -
Michael Newbery