North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: New MAE-EAST

  • From: Paul D. Robertson
  • Date: Thu Nov 06 10:21:33 1997

On Wed, 5 Nov 1997, Al Roethlisberger wrote:

> >  Paul,
> >
> >  I have not spoken with you before, so I do not know if your
> >  posting below is meant in a literal, nonfacetious manner.

It was, however not having spoken to me would have given you a better chance
of getting that right ;)  

> >
> >> > 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.
> >

I'm sure that's a part of it, I initially saw a lot of dropped packets 
through a couple of ATM clouds.  I'm seeing some improvements in 
some of the providers, however, given the trumpeting of ATM (magic bullet 
syndrome), it seems that it's just not something which happens correctly 
by default.  Before we go off on the 'nothing happens correctly by 
default' tangent, it's just been my general observation that whenever 
my packets have been transited over ATM, my latency has been less than 
ideal.  I would have figured that oversubscription would result more in 
lost packets and timed out connections (which were also seen, but more 
easily screamed about) than latency, but I guess that's a factor of how 
oversubscribed the line is.

> 
> 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?
> 
> 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.

This was my preliminary guess.  I expect that it'll be mid next year 
before we start playing with ATM internally, if that soon.  Once I get it on a 
testbed, I'll know for sure where the issues lie.  Is there a good place 
to dig up this stuff, or am I doomed to sniffers and diagnostic code?  

It'll be a couple of months until I start gathering latency stats again.      

Paul
-------------------------------------------------------------------------
Paul D. Robertson
[email protected]