North American Network Operators Group

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

Re: New MAE-EAST

  • From: Sean Donelan
  • Date: Wed Nov 05 23:46:35 1997

>> I don't really fault MFS with these problems.  Show me another
>> exchange that is trying to pass as much traffic as MAE-east is and
>> functioning properly.
>> 
>
>  CHI is pretty close. Also, check Pac-Bell. 
>
>   Smooth surf.

Pac-bell is running about 50% of MAE-East's aggregate inbound traffic
level.

AADS's web pages said they were going to get rid of their statistics
pages, and it looks like they did because I can't find them anymore.
But my memory was the Chicago-NAP was also much lower than MAE-East.

The ATM NAPs have had different problems than the FDDI/Ethernet NAPs;
but they've both had their growing pains.  At one point both ATM NAPs
installed FDDI rings as a work-around.  Fortunately the Internet has
had multiple types of NAPs available, and so far all the NAPs haven't
had the same problems at the same time.  However, all the NAPs do suffer
from one common problem, providers who don't upgrade their egress from
the NAPs when it is full.  Even the ATM NAPs are having huge numbers of
cell drops on certain providers' ports.  This goes all the way back to
the CIX router.  Even the private interconnects between some providers
have this problem.

I think the third-party problem is pretty much a red-herring.  Everyone
is getting paid for service by somebody.  The third-party problem seems
to be one of finger-pointing.  If I give all my Internet traffic to
Sprintlink, Sprintlink act as much like a third-party as the Sprint-NAP
acts when there are end-to-end performance problems.  There isn't a
single circuit in the Internet that isn't nominally 'managed' by someone,
so there shouldn't be a single circuit connection problem that can't be
isolated.  No matter what the public may think, Internet circuits don't
grow on trees.

There is a observation problem for an outside observer, which lets the
poorly performing provider shift blame.  I've had an ISP tell me the
reason packets were being dropped was MAE-East was full.  Ok, open a
ticket with MFS and after checking, it turned out the provider's circuit
was running at capacity.  Go back to the original provider, escalate it
to their 'backbone engineering group' and find out they knew the port was
full.  It was just easier for their customer service people to blame it
on "MAE-East," rather than the lack of facilities on the ISPs side.  I
see much of the same behavior from providers when it comes to fiber
cuts.  Mythology says the Internet can survive a atomic bomb, but not
the backhoe.

MFS has a MTTR of 2 hours, and a 99.99% availability target for its
MAE's which is a higher target service-level than I see from most ISPs.
I couldn't find any target performance goals for either of the Bellcore
ATM NAPs, or most other exchange points.  Of course, whether MFS is
meeting their target service-levels is questionable.

I had a question a few weeks ago, what is the best way to interconnect
multiple things? If N providers want to exchange traffic, should each
connect one large pipe to a common exchange point, or should each connect
N smaller pipes with all the other providers?  If I went out today, and
tried to connect individual pipes between all the providers I exchange
traffic, I end up with the same scaling problem as any other NAP.  So
far the solution I've seen from providers doing trying this is simply
not scale past a small number n (3, 4, etc).

Some folks try to limit connections by using unknowable numbers like
the percentage of total Internet traffic a provider carries.  Since no
one knows or can even measure the total amount of Internet traffic, it
is impossible to know any single provider's percentage of the total.
Claims like 3 ISPs account for 90% of the Internet traffic are in the
catagory that 80% of all statistics are made up.

Even measuring just the traffic between end-points on two different
providers is difficult because multi-homing may lead the traffic through
diverse paths.  I didn't know the InterNIC had so many different providers
until I started peering with different providers.  Besides Mark Kosters,
I don't know if anyone on the outside NSI can really be sure they know of
every single path to the InterNIC.  Predicting what adding an additional
path will do to existing traffic levels remains a problem.  Simulating
the Internet on anything smaller than the Internet is one of those
traditional research problems, or a Scientific Wild-A** Guesses.
-- 
Sean Donelan, Data Research Associates, Inc, St. Louis, MO
  Affiliation given for identification not representation