mbone/NSFnet migration (fwd)

[bmanning () ISI EDU]

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