Re: nv - CU-SeeMe interoperation

Richard Cogger (R.Cogger@cornell.edu)
Thu, 3 Nov 1994 13:22:14 -0500


At 4:22 AM 11/3/94, Jon Crowcroft wrote:
>
> > First issue: We're worried about releasing something that will
> >allow folks to unknowingly invoke link-melting bitblasts across the
> >Internet. The problem is that nv, designed for a primarily multicast
> >environment, does not provide any information the reflector could use to
> >know which video streams a participant is actually viewing (has a window
> >open for). So the reflector just sends them all. (Or it could send none
>
>but...
>the problem you have is that recipient interest maps to mcast prunes
>in the mbone environment, while in a unicast sender based system like
>yours (and the uni bitfield codec based stuff) you explicity se things
>up....

Ummm... As I understand it, the current state of the art is that mbone
conference participants all send to the same mcast group-address and that
(some) mbone routers prune everything for such a group when there are no
downstream receivers joined. I'm told that a future version of mcast
strategy intends source-specific pruning, but nowhere is it implemented
today. It would of course be possible for each sender to use a different
group-address for AV streams and everyone use a common group for control.
And then, each sender could use a *set* of group-addresses to send the
various layers...
>
>now, iff everyone runs pruining code (actually PIM, but...) i don't
>see your problem, but until they do, i heartily agtree - you would
>envisage 100s of small, sparse unicast/reflector based school
>conferences, and everyone of these would traverse every link in the
>mbone where there wasn't a pruner (or in fact where there was until
>the prune relaibley got back....)

Does PIM include source-specific pruning?
>
> > We're exploring with Ron Frederick how we might best be able to add
> >somehow a means for a unix system to send the info the reflector needs to
> >be able to prune (or not unprune) unwanted streams. Unfortunately, none of
> >the CU-SeeMe team knows UI programming for X. If anyone wants to help...
>
>i guess you need 'negative eyeball' detection the way that vat does silence
>detection...

Yes, that would be good. Failing availability of that technology, we can
consider not showing a window as a fair clue.
>
> > Second issue: nv sending via reflector to CU-SeeMe only works if nv
> >uses its CU-SeeMe encoder. So you can't in general use this new version to
> >watch an mbone conference with a Mac or PC. We plan to move nv's set of
> >decoders and the CU-SeeMe encoder into the reflector for general
> >transcoding, but that's proving a little tougher in practice than it sounds
> >just to say it. But there's no real obstacle to getting this done beyond
> >the time to do it.
>
>so what is the most fruitful architectural approach: to consider the
>world as made up of MCU/reflector style confeences, and build an
>mbone tool so mbone people can explicitly join/leave, or to consider
>the mbone as the base case model, and engineer it right (PIM) so we can
>stand the prune etc traffic from implict joins? [good test
>case....looks like reflectors as members of mbone conferences will be
>classic sparse mode...]

I would say: short term the former, longer term, the latter and also plan
on continuing need/use of hybrid setups.
>
>this, approximately, is the topic of mark handley's thesis work....

Look forward to it.

Cheers, -Dick