All things related to multicast

["Richard Mavrogeanes" <>]

Hi Dan,
 
More likely *I'm* the confused one :) 
 
Our appliances are both clients and servers (encoders and decoders). We are
ISO-9001 certified and take our product reliability very seriously, hence even
a "tweek" requires months of testing, at the very least to make sure nothing 
else
is broken.  Like I said, in many ways SSM is easy to implement. But our 
client cannot
"rely on on the OS".  Same with our Set Top Box product. There is a big 
multicast
world out there outside of the Internet2, in campus networks and in 
residential
dsl and cable networks. These industries require commercial products and the
Internet2 benefits from this momentum.
 
A desktop client might be able to use the OS, but that is only part of the 
story and 
our experience is that such reliance typically does not meet commerical 
reliablilty 
and stability goals. Heck, we could not even use Microsoft's rtsp because of 
their
implementation.
 
-- SSM comments --
 
Your point about SSM making arbritary address assignment a non-issue because 
the source
address is considered is well taken. But we need migration and should not
expect revolution. Can you tell me today what is the deployment of SSM-capable
routers and switches?  I don't have a clue and would really like to know 
where we 
stand. I do know that one one will upgrade all of their L2 switches just for 
SSM, hence it 
may be 10 years before SSM becomes pervasive as switches are natually 
upgraded. 
In my arguments with switch vendors about IGMPv2 five years ago, I learned 
that many 
had silicon implementations and could therefore not provide upgrades that 
deal with 
L2 issues (e.g. Nortel).
 
--Directory Comments --
 
We've implemented what we call "rtsp announce" in our latest products. This 
simply
allows you to enter an address to which a SAP message (SDP) is sent 
periodically. In
use, it sends a unicast message to a server that builds an automatic program 
guide on
a public server: click on the program guide and you view the multicast -- if 
multicast fails 
you can still get the content via unicast.  
 
This is because each source appliance creates its SDP on the fly and makes it 
available to 
requesters via http.  No need to create, manage, store, or post a SDP file 
which can be 
very confusing in my experience (e.g. is this one current?). The SDP file may 
describe a 
multicast or it may describe a unicast.  As a result, you need only post a 
link to the 
source appliance/SDP address. The downside is that the source must be on an 
outside address.
For appliances that are NAT'd, I simply use a server to automatically do a 
standard form "post" 
to place the SDP file on a web server.  This works well too, as it is not 
uncommon for multicast 
sources to exit a network yet the appliance is inside the firewall and/or is 
running DHCP.
 
In our case with MPEG-4, we a) transmit multicast with SAP, b) transmit 
unicast to a reflector which
provides unicast bandwidth scale, and c) accept standard rtsp requests 
directly, all at the same
time.  The directory lists both the multicast and unicast source to the same 
content from the same
source.  This turns out to be VERY useful because when you attempt to view 
some multicast
content, you can never be really sure if a failure is the result of a 
multicast issue, content format issue, 
player issue, an expired link, etc.  With this approach you can verify there 
really is a source (view it via unicast) 
and then attempt to view the multicast.  As I mentioned in an eariler post, 
the multicast typically fails because 
it does not really extend into the host's LAN. The directory is, by its 
nature, always current. Flick off the power
on the source and the link goes away in the directory. Move the source 
someone else, change it's name, and
it reappears.  I don't find the standard SAP to be particularlly useful for 
limited-duration multicasts (the SAP
could show up too late or stay too long) or for and obviously does not reach 
non-multicast enabled users. 
 
rich
 

        -----Original Message----- 
        From: Dan Pritts 
[mailto:]
 
        Sent: Sun 5/23/2004 11:41 AM 
        To: Richard Mavrogeanes 
        Cc: John Zwiebel; Alan Crosswell; wg-multicast 
        Subject: Re: I rest my case
        
        

        On Sat, May 22, 2004 at 06:07:08PM -0400, Richard Mavrogeanes wrote: 
        > SSM is certainly on our map. In many ways, it's easy to implement. 
You 
        > are right, VBrick is a vendor and must be driven by business.  
There is 
        > only so much "if you build it they will come" a company can 
undertake, 
        > and I doubt my company will sell more stuff any time soon by having 
        > IGMPv3 support, as much as we can all agree it is "better".  With 
that 
        > said, it *is* coming. 

        I'm a bit confused - what work does vbrick need to do to support 
        SSM/IGMPv3? 

        I'd think that your server software would not need to change at all, 
        and any client side changes would be handled by the IGMP stack in the 
        OS, not in your software? 

        You're certainly right about the switch issue.  If a switch doesn't 
support 
        IGMP at all, well, it won't work any better with IGMPv3.  

        However, there is still a benefit to using SSM - no MSDP needed in 
the 
        router infrastructure.  

        danno 
        -- 
        dan pritts                                       

 
        systems administrator                            734/352-4953 office 
        internet2                                        734/834-7224 mobile