Subject: Re: mbone feed and bandwith

From: Joe Spagnolo <[email-masked]>
Date: Fri, 31 May 1996 15:41:34 -0400 (EDT)

Yves,

I moved this over to the mbone list instead of rem-conf.

> If however, the session has all  of its medias in the
> same mcast group, using this method will not be possible. There's a trick that might
> provide you with the same effect though. If you have a router or a firewall between your provider
> and you, you might be able to use it to filter port ranges out.
> 
> Because ports for each medias are assigned in a certain range:
> 
>        [0, 16384) - lowest priority, unclassified
>        [16384, 32768) - highest priority, i.e. audio
>        [32768, 49152) - medium priority, i.e. whiteboard
>        [49152, 65536) - low priority, i.e. video
> 
> You could let only the highest priority ports go through.
> 

We looked at doing similar things to compensate for mrouted's
habit of losing prune requests. If you're connected via a slow-speed
link and the upstream router drops a few of your prune requests
on the floor - you're toast.

The problem with what you are proposing is that traffic from low-priority
sessions will no longer be pruned and therefore will always be delivered to
the system doing the filtering. Upstream links will be forced to always
carry all video streams. Your provider may have a problem with doing this
for you.

Threshold based forwarding causes similar effects. It prevents low TTL
packets from being forwarded, but it also prevents their sessions
from being pruned.

As far as I know, scoped (boundary) addresses is the only mechanism
that works in conjunction with pruning.

Cheers.

--

Joe Spagnolo

---

From: Yves Lepage <[email-masked]>
Date: Fri, 31 May 96 15:53:10 -0400

Hello Joe,

> carry all video streams. Your provider may have a problem with doing this

Hmm, I figured it wouldn't break things assuming that statements made in this scenario
were true:

- I use a router to only let udp ports 16384 to 32768 go through it
- Of course, I also let prune information/requests go through
- and I let sd/sdr announcements go through too
- I let IGMP go through as well
- I then join a session for which audio and video are in the same group
- My upstream will begin sending me both audio and video but for that group only
- my router filters the video out and only let audio pass
- since it is all udp, the filtering produces the same effect a network problem
  (or a very high loss percentage) would do and my upstream doesn't care much
- I get the audio  fine

I fail to see how this would disrupt pruning since only one group is involved in that process.

If something is wrong is my reasoning, could you show me where?

Thanks, and regards,
Yves Lepage

PS: they have Mbone connectivity in Ontario? where do you get you feed from?

---

From: Joe Spagnolo <[email-masked]>
Date: Fri, 31 May 1996 17:43:42 -0400 (EDT)

Hi Yves,

> If something is wrong is my reasoning, could you show me where?

First of all, we are talking about native multicast here. Since,
we are filtering based on UDP numbers, we need to be able to see
them in the header.

What you proposed achieves what you want - it separates the two streams
(audio/video) from the session you want to receive and filters out
the video. I guess I'm talking about video sessions that you don't want to
receive and that use a separate multicast addresses for the audio (if
present).  There may be a number of them floating around on the
MBONE at any given time above port 49152.

Let's say that your provider's firewall or router filters out a video session
that you don't care about on your behalf. Because the video traffic is not
sent downstream, it is not pruned by your downstream leaf-router (prunes are
originated at leaf routers). If your provider's router does not receive
a prune request for the video session, it keeps transmitting (it thinks
anyway) the video traffic because it can't differentiate between 1) It sent
the video traffic downstream but did not receive a prune so somebody
downstream must want the traffic 2) the video traffic got filtered. Either
way, your provider's router does not send a prune upstream and therefore
receives the video traffic unnecessarily. Pruning is a negative response
mechanism. "If you don't want it, let me know, otherwise I'll assume
you want it. But if you don't know it's there, you can't tell me you don't
want it".

If all conferences use the same multicast address for all media, then
you may have something. The audio traffic will cause all traffic from
the unwanted conferences to get pruned. I don't believe conferences are
always set up that way. 

This is my reasoning anyway!

-- 

Joe Spagnolo

---

From: Petri Helenius <[email-masked]>
Date: Sat, 1 Jun 1996 11:27:45 +0300 (EET DST)

-----BEGIN PGP SIGNED MESSAGE-----

 > on the floor - you're toast.
I think it's worth mentioning that not retransmitting prunes is a flaw
in the implementation not actually a protocol design shortcoming.

 > that works in conjunction with pruning.
Yes. Unfortunately not enough focus and effort has been made to
actually implement 'standard' scoping for different traffic classes.

Pete