RE: Use of SAP in a PIM SSM Network

["Michael Luby" <luby@digitalfountain.com>]

> SSM in intended for (or, is at least, ideal for) BROADCASTING.
> In the real world, broadcasters
> stay up for years at a time. They don't like down time, even for seconds.
> They will NEVER want to renumber their class D addresses - these will
> get embedded in too many places (including .pls type files at the
receivers)
> to make any such transition smooth.
> If there is a MAC layer collision, for any reason, they will want a fast
> means of resolving it. Now, I am sorry,
> but this sounds awful much like a static address to me.

> SSM is very attractive for broadcasters. Please do not hinder it by
insisting
> on some theoretical purity that does not fit their business model.
>
>
>                                    Marshall

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
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
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
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.

Mike