Re: ANL/NREN Test Beacon (fwd)

Hugh LaMaster (lamaster@george.arc.nasa.gov)
Thu, 30 Jul 1998 09:43:44 -0700 (PDT)

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