If we end up w/ a few minutes this might be a useful topic of discusssion .. :)

Subject: mbone/NSFnet migration Date: Wed, 19 Oct 94 22:50:18 -0400 From: "Matt Mathis" <mathis@pele.psc.edu> X-Mts: smtp

Hopefully most of you are aware of the pending massive restructuring of the U.S. Internet (see footnote (1) below if not). In a few idle minutes (ha!) I attempted to extrapolate the existing mbone onto (my limited understanding of) the brave new North American Internet topology.

First the good news: When everything is done, the existing mbone will match new topology far better than we deserve to expect, perhaps almost optimal, needing only a few minor tweaks. This was a real surprise!

Naturally during the transition, this will not be the case: unless two regionals connected by a tunnel move to their new National Service Provider at the same time, the tunnel between them will temporarily pass through an interconnect (a Network Access Point) between the NSPs. Since all regionals are going to be making the transition at different paces, the intermediate states are likely to be pretty ugly, with possibly a dozen or more tunnels crossing the NAPs.

It is hard to predict if this will be a problem. The aggregate bandwidth through the NAPs will be quite large - hundreds if not thousands of megabits per second (see 2), so even two dozen copies of the mbone may be ok. I would not do anything drastic, such as shutting down the mbone (even temporarily). However, if there are problems we MUST be prepaired to adjust the mbone's bandwidth rating.

Now the bad news: the the transition schedule is already slipping, and the slippage has widened the spread in expected transition dates. The original cut off date for the existing NSFnet service was October 31th. It is being extended on a month-by-month, peer-by-peer basis. Most connections have already been extended to Nov 30, which is less than a week before the IETF......

The situation is complicated be two other issues: the Internet itself is going to be rather fragile during the transition. Although hundreds (thousands?) of people have been working very hard on it, there is just too much new technology, infrastructure and hardware for the transition to be totally free of glitches. There will be mbone outages that are due to IP failures unrelated to mbone traffic. It may be very difficult to tell if the mbone is contributing any observed instability.

Furthermore, most of the contacts on the mbone provider list are already working overtime on the Internet transition. If some regional is having problems with vanilla IP service, mbone problems will be secondary.

So, what can the research community do to help? I can think of several things:

o Dust off mbone mapping, instrumentation and diagnostic tools - particularly "strip charts" for mbone load and route transitions per hour, so we have a "before" baseline, and can correlate route flaps with load. If data storage is a problem let me know, and I can make some arrangements.

o Be patient when it is broken, and be aware that the the person who needs to fix it may have already been up all night.

o Be gentle with the bandwidth, or it may be discovered that is your bits were the "last straw".

o We need to have some administrative mechanism to come to a consensus about mbone capacity. The scheduling tools are a nice idea, but how do you know how much BW you have to divide under conflicting reports of signal quality.

o Don't start a conversation about the tunneled vs native multicast. We've been there.

I will be posting an updated mbone provider contact list sometime soon.

Sorry about the duplicate posting, but I believe that both the mbone users and providers need to be aware of what is going on.

--MM--

---------------------------------------- Footnotes:

(1) To make a long story short, the existing NSFnet is a service of one provider: Merit, with one prime subcontractor: ANS. NSF is spending a large sum of money to provide "free" T3 connections to the regionals.

After the transition, the NSF money will flow directly to the regionals (with a builtin 5 year sunset), who must purchase connectivity from NSF certified National Service Providers. The primary requirement to be a NSP is that they connect to the NSF awarded NAPs, which are for exchanging traffic between providers. (Much detail omited....). In addition there are some Independent Service Providers, who are selling a la cart connectivity, mostly to businesses, etc. They may also connect to the NAP's but unless they meet the NSP certification, they are ineligible to directly carry NSF funded regionals. Note that no NSF money goes directly to the NSPs, NAPs, or ISPs. They get all of their revenue by charging for their services.

The up-to-date status can be obtained under http://rrdb.merit.edu/home.html. Note that the intended audience is the service providers, who do not need introductory explanations.

(2) The aggregate bandwidth available within the NAPs is surely gigabits/second, but most (all?) NSPs will connect via T3 links to 3 or 4 NAPs for a total usable IP bandwidth of no more than 160 Mbit/s. I am not privy to any of the global traffic models, so I can not comment on the expected load on these links.

-- --bill