Paul, I have not spoken with you before, so I do not know if your posting below is meant in a literal, nonfacetious manner.
With all of the problems with MAE-EAST.....
Any plans from anyone to create a ATM exchange point in the DC area?
For what it's worth, I do understand that there is a plan to create an ATM exchange point in the DC area, at speeds exceeding those currently available.
Given the latency we've seen over some ATM backbones,
The latency increased in network areas that are switched is generally (by all but the zealots) given to be less than that of comparable layer three data moving topologies. The latency induced by several providers claiming an ATM backbone is generally attributable to an error: they leave off one important word -- shared -- . The latency about which I assume you speak is caused by large amounts of queuing. This queuing is demanded by network oversubscription. The latency introduced by the oversubscription is consistent with any oversold network. Bear in mind, the introduced latency is not something that they directly control. However, by implementing their Internet base level transit upon a shared network, such as ATM or FR, the NSP/OSP is at the mercy of the carrier. And the carrier does so like to squeeze money out of that capital investment of an ATM network. With dedicated circuitry (SONET/SDH) the bandwidth sold is readily available, in fact fixed. With shared networks, the bandwidth is available on a 'best effort' nature, withstanding rare altruistic CIR and SCR implementations. An ATM Exchange Point implemented by a third-party should (and in one case about which I have knowledge, most assuredly WILL) disallow oversubscription within the L2 shared network. This means that the guaranteed BW really is guaranteed, and the latency induced by oversubscribing links will be 0, because the links will not be oversubscribed. (except maybe interswitch trunks [which is part of what DEC offered in Pandora's box])
I certainly hope not. I agree with Paul that MTU sizes in gigabit ethernet make it very attractive as a next step, I'd certainly be interested in seeing anything anyone has on fragmentation related delays going from a large MTU switched environment to a small MTU switched environment though.
Yes, this would be interesting.
Overall, I've been less-than-pleased with latency when I've been transited that way.
I don't understand, the MTU with which I'm most familiar on the ATM SAR Frame is 4470. How does this induce latency as a function of fragmentation? Fragmentation occurs when a PDU is larger than the available PDU space in the MTU of the transit or destination media, no? -a