At 06:17 PM 11/5/97 -0800, Al Roethlisberger wrote:
Perhaps he is referring to latencies that some beleive is incurred as ATM 'packet shredding' when applied to typical data distributions encountered on the Internet that fall between the 53byte ATM cell size and any even multiple thereof?
I'm going to rant a little. Sorry Al, but it was you repeating something allegedly BAD about ATM that once ATM promoters used to say was GOOD, well it's just too funny and too ironic to pass up. One of the advantages of ATM as touted by ATM bigots in the early days was the advantage of "cell interleaving". When two "packets" meet at an intermediate ATM node, their cells interleave as they are switched through. This reduces the per-hop latency of an ATM network over a frame network on the order of microseconds for large packets. An idiotic marketing-initiated "advantage" that I used to make fun of when ATM marketers would trot it out. Now you tell me that ATM segmentation probably increases latency because the modulo 48 byte payload causes the extra padding bytes on some packets to "take a long time" to be forwarded? On the order of picoseconds. An idiotic "what else can we think of that's wrong with ATM" engineering-initiated disadvantage. And if we could remember what we were actually talking about -- an ATM switch for an exchange point and not an ATM network -- we can see that none of this matters, except to show how we know that ATM is Just Bad and we would never do that.
Some reports that I have seen show a direct disavantage for data where a large portion of 64byte TCP ACKS, etc. are inefficiently split among two 53byte ATM cells, wasting a considerable amount of 'available' bandwidth. i.e. one 64byte packet is SARd into two 53byte ATM cells, wasting 42bytes of space. If a large portion of Internet traffic followed this model, ATM may not be a good solution.
The TCP ACKs are 40 bytes long and if you aren't trying to solve too many problems at once, you can use an encapsulation that will fit a 40 byte TCP ACK in a single cell. There isn't a way to stuff a 64 byte packet into a 48 byte payload. Is that a problem!? Only if you have a lot of 64 byte datagrams, which you don't, because the ACKs are 40 bytes long. I have actually looked at some Internet traffic distributions to see how big a problem this isn't. There is no point agreeing with the Big Backbone Network Engineers that the MAEs suck. It is in their best interest that the MAEs suck, the CIX is crippled, you aren't bugging them to plug into a high perf exchange, and that you, the little ISP, go out of business soon. THEY have private interconnects which you can't join. Find a co-lo where you can cross-connect without being robbed or build your own NAP, just don't use DEC-designed Gigaswitches and FDDI. Use full duplex 100 Mbps Ethernet switch or find an old Fore switch cheap. --Kent Kent W. England President and CEO Six Sigma Networks Experienced Internet Consulting 1655 Landquist Drive, Suite 100 Voice/Fax: 760.632.8400 Encinitas, CA 92024 mailto:kwe@6SigmaNets.com PGP Key-> http://keys.pgp.com:11371/pks/lookup?op=get&search=0x6C0CDE69