Paolo, you are right, but the client is always more right :-) Accounting for the ATM cell header overhead in the alleged supplied data rate gives a false sense to the client about the amount of data that can be transferred when the estimated by the client required data rates have been calculated in some other media with less overhead (e.g. frame-relay, ethernet). A better approximation of what can be expected by the client occurs when excluding the cell header. Still, even in this case, there can be even more overhead not accounted for, such as cell padding (which can result in an entire cell being almost wasted for every small voice packet sent). I suppose AAL5 style of overheads can be considered somewhat equivalent to other L2 overheads. Of course, you are right in the sense that the provider has to actually support a higher data rate than the one it reports to the client for everything to work.
p.s. In case you are interested:
http://www.cisco.com/en/US/tech/tk648/tk362/technologies_tech_note09186a0080093c9a.shtml#pervc_stats
"While ATM switches think in terms of cells, and do provide per-VC cell counts, routers with an ATM interface think in terms of packets (specifically, AAL5 PDUs)."... "Note that bytes, counted for each AAL5 PDU in IOS, include only layer 3 packet bytes plus 8-byte LLC/SNAP header. These bytes do not include variable length padding, AAL5 trailer and ATM cell header. "
The consequence of this was voice quality issues that we could not determine the cause. It looked like we had enough bandwidth, but we didn't. If client can see similar counters, instead of the cells typically reported in an ATM switch, client can get very puzzled. When cell counters are also reported, as is the case here by supplier, then we can assume the actual required data rate is supported.
