New MAE-EAST

Thu Nov 6 01:33:07 UTC 1997

  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