Re: Use of SAP in a PIM SSM Network

[Marshall Eubanks <tme@21rst-century.com>]

Michael Luby wrote:
> 
<snip>
> 
> I'm still a little confused about why it is such a big deal for collisions
> to be happening.  First off, aren't the collisions only going to occur at
> the edge of the network on some local shared LAN?  Aren't all the router and
> switches in the middle smart enough to understand the channel address (S,G)
> and not the hashed MAC address of this and thus will only care if the pair
> (S,G) is unique?  Aren't clients only going to receive the packets they have
> asked for unless they are on a shared LAN (in which case they should filter
> them out)?  Maybe some networking expert could explain exactly where the
> problem could occur of colliding at the MAC level, and how many end users in
> the Internet today and in the future are likely to be susceptible to such a


Dear Mike;

Sorry for being so wordy about this, but...

You are correct, collisions only will happen at the edge of the network.
Don't forget, though, that ALL of the audience is at the edge of the
network :)

Our surveys indicate that the current audience "passed" by broadband multicasts
is (conservatively) on the order of 1 to 2 million people. Of these,
almost all are on LANs. Most DSL providers have problems with
multicasting, due to under-provisioning between the last-hop router and
the DSLAM; while many ISDN users can get multicasts, this is clearly not
the future of broadband. If there are any reports of Cable Modem
providers supporting multicasting, I would love to hear of it. Pretty
much everyone else with broadband is on a LAN of some sort, generally
some flavor of Ethernet, and  
a subset of these people is the early audience for multicasting.

Even as broadband gets into people's houses, you won't have a separate line
for each computer / device in the house - you'll have one hub / router
that talks to the line, and a LAN (maybe wireless) that hooks everything
else together. Basically everyone I know who has broadband
(DSL/ISDN/Cable Modem, etc.) 
does something like this already. This indicates that collision problems will
not go away.

> problem?  This would be very enlightening to me, as then I would understand
> the full scope of the issue and the pros and cons on both sides.  I'd also
> like to point out that anybody who is deploying commercial grade
> applications will obviously have an application level filter to make sure
> that they are receiving the correct packets and make sure to throw out
> packets that weren't requested, and not just rely on the networking

Of course, layer 3 will filter this. 
However, if you are getting colliding video streams, at the least
your performance will suffer. This may prove to never be a problem -
but if it does, it would be wise to have a mechanism in place to say who
has to change their G address.

> infrastructure to deliver requested packets.  This is certainly something we
> do.  This at least solves the problem of accepting bad packets, but still
> there is the wasted bandwidth issue that this doesn't deal with (wasted by
> pulling in unintended packets).
> 
> On the last point you made Marshall, one of the main attractions of SSM to
> really large commercial broadcasters is that it frees them up from using the
> same multicast address allocation that they have today in the 233 space.  If
> multicast is really successful, large broadcasters won't be using just a
> couple of hundred multicast groups, but thousands and tens of thousands.
> Thus, the old scheme of using AS numbers etc. is exactly one of the things

Sure. And there is plenty of room - we have a /4 for multicasting, after
all, and 23 non-colliding bits of address space (some 8 million choices)...
The trouble is, we (multicast-tech) want to start SSM broadcasts NEXT
MONTH. 
True, they'll be tests, but once they go up, we don't ever plan to take
them down.

So, IMHO, there needs to be two things :

- Some means of picking SSM addresses immediately. "Do what thou wilt" seems
to be whole of the current law - so we will pick from our (translated) "GLOP"
space. If there is something better for the short term, it needs to be
presented (at least) in San Diego.

- Some means of getting non-colliding addresses assigned, whether static or
not. There are plenty of such addresses - and I agree that GLOP is not
an efficient means of doing so.

Maybe the way to go is :

1.) Make some range of Class D addresses 
is available without warranty. You just pick them and use them - if you
suffer collisions, that's your problem. These won't collide with #'s 1
and 2, but
can collide with each other.

2.) Some small "GLOP type" address range is available on a reserved
basis without any paperwork at all.

3.) Once you use this up (or come close), you can then justify getting a 
larger range from a different pool of addresses.

This begins to sound (to me) a lot like what ARIN does.

Maybe I'm just being a worry-wart here, but I worry that once people start
obtaining revenues of a million dollars a minute from an SSM broadcast
(not out of line for a major network, BTW), they will become VERY, VERY
intolerant of anything that might interfere with their stream.

Maybe the REAL long term solution is to buy a shorter MAC prefix
for multicasting, so that collisions do not occur.

> broadcasters (at least the ones we've talked with) have to get away from,
> because they are already out of multicast addresses to use.  This style of
> static allocation restricts them to do no more than what they are doing
> today, and this does not bode well for the commercial deployment of SSM if
> this becomes the model.  Thus, whatever we can do to make it the case that
> SSM means (S,G) packets get delivered to a client based on the full channel
> name is really going to help commercial deployment.
> 
> One last point Marshall, with SSM wouldn't it be the pair (S,G) that the
> broadcasters should be embedding in all those places, not just the group
> address G?  Maybe you can explain this more (about where these multicast
> addresses would be embedded by the commercial broadcasters and why) to have
> a more cogent understanding.

Sure. Most of the Internet broadcasters that I am familiar with use a
file (with the
open source FreeAmp project and some others this has
an extension of .pls) stored on the receiver's computer with various
information required to decode the broadcasts, including a URL to
describe the
source. When you click the "play" button on the web page, this file 
gets put on your hard disk, the player reads it, and gets the stream.
We are already embedding (S,G) in our version, so that it will be 
possible to use the same file type with SSM. (how to best detect
that SSM is in use is another story). In any case, once you have the file,
it's like having a bookmark - you can just push play (or toggle on a 
play list in the player) and get the stream without having to go back to
the original web page. 

If you're trying to scale multicasts to millions of simultaneous
listeners or viewers,
then you are going to need to have this sort of information distributed
somehow, to
avoid packet storms (when the Superbowl starts, say). On a deeper level,
the simple fact is, the (S,G) will not change for YEARS for some
large broadcasters. It would be hard, to put it mildly, to prevent people
from embedding this info, even if you wanted to.

Now - people have talked about having a DNS type distributed database
(or, putting the info into the DNS itself, maybe as "A" records).
In that case foo.multicast.ssm might map into 232.111.111.111 and
be coupled with some IP address for the source. So far, so good -
you could embed domain name type information instead of actual IP addresses.
This would be a VERY useful feature to have, for things like local
advertising insertion. I don't think that it really helps this problem,
though :
changing the G name->address mapping is likely to be as painful as
renumbering your regular IP addresses - yeah, it can be done,
but you don't want to do it very often. (We encountered DNS caches
on the network with 30 day !!! expiration times. Imagine CNN being
unavailable for 
some large chunk of the net for days because the caching hasn't
updated!) This "multicast DNS" would be useful
for a lot of reasons, but IMHO frequent changes in the Class D addresses in
use is not one of them, at least for large broadcasters.

(BTW, I have asked around about multicast DNS, and several people have told
me that something is in the works, and have even sent me drafts. These,
however, have been about using multicasting to distribute DNS
information, not
about using the DNS to distribute multicast information, so I do not
know what the real status is here.)

> 
> Mike

Let's get together at San Diego and discuss this further... maybe at a
bar BOF.

                     Marshall



   Multicast Technologies, Inc.
   10301 Democracy Lane, Suite 201
   Fairfax, Virginia 22030
   Phone : 703-293-9624          Fax     : 703-293-9609     
   e-mail : tme@on-the-i.com     http://www.on-the-i.com