...

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