All things related to multicast

[Frank Fulchiero <>]

Hi Hitoshi, thanks for the link and info. I have scanned, but not yet  
studied your Internet-draft (on "vacation"), and plan to, but have  
some preliminary comments.

I believe there are several aspects to the SAP announce/discovery issue.

Part of the problem is that RFC2974 was devised on or before 2000,  
when internet television, at the consumer level, was really no more  
than occasional 320x240 QT or Real movies. There was little multicast  
video available for watching. Someone please correct me if I'm wrong,  
I am not that familiar with the "early days", but I do remember  
struggling to get our IBM Videocharger working just on unicast, and  
having to install and configure hardware cards to encode and decode  
MPEG2 streams. Forget about live video, I felt fortunate to get on- 
demand working.

Then slowly, over the years, with CPU power increasing, it became  
possible to live decode just with a computer, hardware encoding  
(especially live) became easier with boxes like VBrick's, and in a  
parallel development more institutions became multicast enabled. It  
seems, however, that RFC2974 has not kept up with current announce/ 
discovery needs.

Looking at RFC2974, it states the purpose of SAPs is "to assist the  
advertisement of multicast multimedia conferences and other multicast  
sessions". I assume this includes video streams.

RFC2974 goes on to say:

" SAP is intended to announce the existence of long-lived wide-area
   multicast sessions.  It is not an especially timely protocol:
   sessions are announced by periodic multicast with a repeat rate on
   the order of tens of minutes, and no enhanced reliability over UDP.
   This leads to a long startup delay before a complete set of
   announcements is heard by a listener.  This delay is clearly
   undesirable for interactive browsing of announced sessions."

The problem is that people's viewing habits have changed from the  
year 2000. We like to "surf the web", have periods of ADD, and need  
instant information. We don't want delay. As I have said before, how  
often before you turn on a TV do you want to know what channels are  
available? I am using a consumer model of discovery, but that is how  
many of us with busy lives expect to receive information in our  
normal workday responsibilities. So, up to this point in the spec,  
the RFC does not really address the current needs most of us have.

However, RFC2974 then does go on to say:

   "In order to reduce the delays inherent in SAP, it is recommended  
that
   proxy caches are deployed.  A SAP proxy cache is expected to listen
   to all SAP groups in its scope, and to maintain an up-to-date  
list of
   all announced sessions along with the time each announcement was  
last
   received.  When a new SAP listeners starts, it should contact its
   local proxy to download this information, which is then sufficient
   for it to process future announcements directly, as if it has been
   continually listening.

   The protocol by which a SAP listener contacts its local proxy cache
   is not specified here."

Above is the RFC2974 solution to the "timeliness" problem. Instead of  
having a listener listen to the actual SAP announcements, it is  
supposed to listen to a "proxy". The SAP listeners I have used: VLC  
and VBrick's StreamPlayer, by default both listen to the actual SAP  
announce and not a proxy.  It seems possible in both to have them  
listen to another multicast address, but not sure anyone is really  
using proxies.

This extra proxy "layer" of complexity makes RFC2974 unwieldy in  
current use of multicast video. It's hard enough to set up a robust  
SAP server, as we have seen from the storms, now we have to worry  
about a proxy!

I know you are working on an alternate solution, and I (and I am sure  
others) will be glad to investigate it. In the meantime, we have  
tried to devise a better SAP server (EasySAPAnnouncer), to bridge us  
over. A parallel approach would be to investigate the possibility of  
updating RFC2974 to meet current use needs, and to overcome some of  
its limitations. I don't know who would have the time or inclination  
to do it, or if it is worth it.

I would also like to point out the repercussions of skipping the  
Proxy and Announcement Interval guidelines of RFC2974, and getting  
into a real-world usability situation.

If each SAP is 1 kilobyte and each video stream is announced every 30  
seconds, it results in a network traffic of 33.3 bytes/sec.
A thousand SAP announcements would result in 33 kilobytes/second.
5,000 SAP announcements would result in a network traffic of 166  
kilobytes/sec.  (hope my math is right!)
This should not be an undue stress on most modern networks.

It seems to me that, while a better system of announce/discovery is  
devised, if SAPs are prudently used there is adequate capacity for  
current and short-term foreseeable requirements.

Looking forward to studying your ID in more detail. Again, I am more  
at the usability end than the network admin end...

Thanks for all your work on this.

Frank Fulchiero
Digital Media Specialist
Connecticut College




On [Jul 25], at 2:34 AM, Hitoshi Asaeda wrote:

> > I think 10s must be the default for VLC.  I see our system on the
> > list and as far as I know we have done nothing to change VLC to send
> > at anything but the default rate.
> >
> > > We've tried to collect some statistics for sources currently  
> > > sending to
> > > the IPv4 SAP group. See attachment if you like.
> > >
> > > Right now (when we checked), there was one source (193.10.29.5)  
> > > sending
> > > 10 pps to SAP, which is rather high.
> > >
> > > Next up there are a handful of sources sending announcement 1pps  
> > > which
> > > also is rather high. Many others at about one packet every 10s which
> > > still is rather high.
>
> Either 10pps or 1pps is rather high. 10s SAP interval is also too
> short.
>
> According to RFC 2974 (SAP specification), the next SAP message
> transmission time for an announcement should be longer than 200 sec.
>
> And in my calculation based on rfc2974, when we assume the average
> message size of a single multicast session information is about 300
> bytes, an interval time of each session announcement becomes greater
> than 300 seconds. And if the total number of active multicast sessions
> is more than 500 the average announcement interval increases
> proportionally.
>
> BTW, as I promised, I submitted an individual I-D whose title is
> "Requirements for IP Multicast Session Announcement in the Internet"
> on July 6.
> http://www.ietf.org/internet-drafts/draft-asaeda-mboned-session- 
> announcement-req-00.txt
> If you are interested in it, please read it.
> I'd appreciate your comment.
>
> Regards,
> --
> Hitoshi Asaeda