Skip to Content.
Sympa Menu

wg-multicast - Re: Report from the Miami I2/NLANR meeting

Subject: All things related to multicast

List archive

Re: Report from the Miami I2/NLANR meeting


Chronological Thread 
  • From: Jan Novak <>
  • To: David Meyer <>
  • Cc: ,
  • Subject: Re: Report from the Miami I2/NLANR meeting
  • Date: Fri, 07 Jan 2000 16:33:07 +0000

>
> > > Or is it something else?
> > >
> >
> > I think, I understand very well, what Kevin means/wants.
> > We have at least two SM connected countries with quite
> > careful and knowledgeable people in charge of the mcast
> > network and they also need "protection" from high speed
> > streems - for 99% they don`t have any users, wanting the data
> > - once we kill the rest of DVMRp, I think we will come back to cisco -).
>
> So the problem is that there are dense mode regions with
> "high bandwidth" streams, implying that flood and prune
> is the problem?

The most recent problem was purely SM domain sending about 1 Mbit/s
of data. Some of our "research customers" have DM domains
behind the SM connections - in my only feeling the border
SM-DM is problem.

>
> I still don't understand. If it's flood&prune, then data
> goes where it is not wanted every three (or so) minutes.
> That might be a problem. If not, then it seems that we're
> trying to stop these streams from going over commodity
> links. Well why would they? I can think of a few reasons:
>
> (i). There are receivers for the group in the commodity
> internet that do not have I2 connectivity (why do they
> see the session, if using sdr?). In this case we're
> just trying to trying to protect ourselves from users
> (see Bill's note).
>
> (ii). If there are receivers that have both commodity
> and I2 connectivity. In this case it would appear
> that there is a routing problem (why don't join/prunes
> follow the I2 routes?).
>
> (iii). Flood and prune regions
>
> (iv). Implementation, design or configuration bugs


I am end user only and I would need the time to debug more deeply
what I feel it is happening:

The SM domain mentioned above sends data.
The other pure SM domains connected elsewhere behave as you say - join when
they have users etc. When there is a small DM cloud inside of somebodies
network and somebody ordinarily joins the group, he gets the data
which is still OK -). The problem is, that the data flow to the DM domain
never stops, even when there are no more any group members. The only
thing, which helps is to disconnect the network for 20-30 mins, all
times out and then it behaves for some time again - this helps sometimes, when
the SM-DM border is your direct neighbour, if it is more far away, there is
simply
steady stream of data all the time.

We would like to debug this, we have at least three such networks. The problem
is, when this happens totally outside your management domain (e.g. "comodity
Internet") you can`t do anything about it and just watch your "SM" connection
being totally useless as it was with DVMRP tunnels. Then the only solution is
the Kevin`s
one - admin scoping to simply restrict these data being forwarded.



>
> BTW, what is a high bandwidth flow?

For us still 1 Mbit/s and more -).
>


Jan




Archive powered by MHonArc 2.6.16.

Top of Page