Re: ANL/NREN Test Beacon (fwd)

Robert Olson (olson@mcs.anl.gov)
Thu, 30 Jul 1998 13:32:40 -0500

I think it would be worth it to push the test back a day. Otherwise it may
not mean anything.

--bob

At 11:14 AM 7/30/98 -0700, Shelly Deixler wrote:
>Joe:
>
>I was hoping to be able to discuss prliminary results of the test on a
>weekly conference call held at 1:00 Central Time every Tuesday. Slipping a
>day could have the potential of setting us back as much as one week. Is
>there any way to accomodate us on this. If we must I could probably push
>back to early Tuesday morning but that squeezes us on coordination between
>several groups and still doesn't leave you folks too much time to fix much
>if the conversion doesn't go very well.
>
>Shelly
>
>At 5:54 PM -0000 7/30/1998, Joe Burrescia wrote:
>>Shelly,
>>
>>As a matter of fact... we in the process of bringing ANL into our
>>PIM cloud. This should satisfy both your short and long term
>>goals. I was hoping to configure this on Monday 8/3 (subject
>>to ANL's approval). Any way to slip your test back a day or so
>>that we can insure that this will work before then?
>>
>>--Joe
>>
>>FYI- I switched the cc line to : routing@es.net. This catches all the
>>folks in the routing group, and is used for discussing routing issues
>>of this sort.
>>
>>> Joe:
>>>
>>> As you have already seen, we would like to conduct a test of our
>>> multicasting network. In the comming weeks and months we will probably
>>> start stressing the networking with ever higher bitrates being multicast
>>> out of Argonne National Labs. 1 Mb/s was chosen for this test simply
>>> because it is a convient logical next step for the rest of us in this
>>> experiment. Can you sugest a way to accomplish both the short term
goal to
>>> enable the test that I would hope could run from about noon on Monday,
>>> 8/3/98, untill Wednesday 8/5/98 noon (Times are Central time) and provide
>>> the long term soultion of letting us place a signal of this or even
greater
>>> magnitude on the network without disrupting your other customers and
>>> without having to coordinate every multicast we do.
>>>
>>> Thank You
>>>
>>> Shelly Deixler
>>>
>>> ___________________________________________________
>>>
>>> >Date: Thu, 30 Jul 1998 09:43:44 -0700 (PDT)
>>> >From: Hugh LaMaster <lamaster@george.arc.nasa.gov>
>>> >
>>> >
>>> >Well, I stand corrected on one point. Although ESnet can handle
>>> >multicast streams as large or larger than 1 Mbps, because it is
>>> >used heavily operationally, ESnet would rather *not* have us do
>>> >ad hoc testing of 1 Mbps streams. They would like us to notify
>>> >them in advance, and, in general, 1 Mbps is considered "antisocial"
>>> >within ESnet. The reason for this, which doesn't surprise me,
>>> >is that although they have the bandwidth, their mrouted-based
>>> >mrouter infrastructure can't handle loads much larger than that,
>>> >and they have lots of operational users.
>>> >
>>> >
>>> >In short, they would rather work with us to enable a PIM-only path
>>> >from ANL to NREN.
>>> >
>>> >------------------------------------------------------------------
>>> >
>>> >Joe Burrescia <joeb@es.net> writes:
>>> >
>>> >> [...] sourcing an unbounded megabit multicast stream is
>>> >> pretty anti-social. We do have users that make daily production use of
>>> >> multicast (both on and off ESnet) and this would be disruptive to them.
>>> >:
>>> >> We (ESnet) has been pushing PIM out into our production network, but we
>>> >> are not totally there yet. In the ANL path, we have PIM running from
>>> >> AMES to LBL but then dvmrp to llnl, lanl and finally ANL. We
>>> >:
>>> >> We have run internal high bandwidth multicast streams in the past, but
>>> >> we used administrative scope to contain them. You are right, most of
>>> >> our links can handle this traffic without a problem, but the fanout
>>> >> of the mrouters is the limiting factors. Over running these mrouters
>>> >> will adversely effect the folks who are using the service in a
>>> >> production manner.
>>> >>
>>> >> If you want to run some high bandwith rate tests please let us know
>>> >> before hand so we can monitor what's going on (trouble@es.net is a
>>> >> good place to send this type of mail in case I'm out).
>>> >
>>> >------------------------------------------------------------------
>>> >
>>> >
>>> >Therefore, before turning up the bandwidth from ANL, we need to
>>> >notify Joe Burrescia <joeb@es.net> and <trouble@es.net>.
>>> >
>>> >And, we need to pursue the PIM-only path anyway; ESnet is willing
>>> >to work with us to enable that.
>>> >
>>> >
>>> >Further additions, corrections, and comments welcome!
>>> >
>>> >
>>> >Regards,
>>> >Hugh LaMaster
>>> >
>>>
>>> ************************************************************
>>> Shelly Deixler
>>> Senior Engineer - NREN Applications
>>> NASA Ames Research Center
>>> Mail Stop 233-10
>>> Moffett Field, CA 94035-1000
>>> USA
>>>
>>> mailto:mdeixler@mail.arc.nasa.gov
>>> http://www.nren.nasa.gov
>>>
>>> 650-604-1329 (voice)
>>> 650-604-3080 (fax)
>>> ************************************************************
>>>
>>>
>