Subject: RE: Use of SAP in a PIM SSM Network

From: [email-masked] (Kevin C. Almeroth)
Date: Wed, 22 Nov 2000 07:41:10 -0800 (PST)

>>Ericsson has very little problem with multicast in Campus environmnets & LAN's...It is the WAN that "generates" all the problems (link speed, load on existing links, business critical traffic "at risk", and redundancy).  Add to this that My division is responsible, but doesn't have control over different "islands" it also becomes a political mess.

I hate to bring up an oft repeated argument:  "How do you deal with
this for unicast?"

When peering between domains, every single issue you mention is
both an issue for unicast and multicast.

>>I have been kicking away for 2 years to try and motivate folks / organisations to open their eyes to the necessity of multicast.  Until September there was very little interest.  NOW everyone & their brother wants everything to work 6 months ago.  Perhaps it is the globality of organisations that the Ericsson Global IT Services Provides for...Am I the only one with this dilemma??

Nope...  and everyone is struggling.  The solution seems to be to
get these folks thinking the right way about multicast.  

>>SSM would be wonderful if we can get it up & running with support for different applications.  

Do you have content and applications lined up?

>>I have an organisational question but it can easily be SSM / PIM-SM related.  Is there anyone out there that has an application (Platform & Application independant) for the dynamic assignment of multicast addresses GGG.GGG.GGG.GGG:port where folks can book a randomized multicast group in the same way as one would book a conference room??  A bonus feature would be that this application could handle & mediate conflicts (someone "keeping" an assignment, or making their own assignments).

Again, this is perception.  Tell your folks if they feel like they
are likely to see a conflict, they should go buy a lottery ticket.
Same odds.

-Kevin

---

From: "Mike Luby" <[email-masked]>
Date: Wed, 22 Nov 2000 09:56:09 -0800

Actually, I don't fully understand the last question about choosing SSM
multicast addresses uniquely.  Since with SSM the address (channel) that the
client sends an IGMPv3 join to is a (S,G) pair, where S is the origin server
IP address and G is easily chosen to be unique among all G's that S is
sourcing, it would seem that the problem of finding a globally unique
address is not a problem.  However, there is still the issue of how the
(S,G) address is mapped to a shorter address by some hardware environments
like Ethernet, and maybe the question is how to make sure that this is
unique with high probability?  It would be good to clarify this question so
that there aren't misunderstandings and so that the weakness of the current
solutions can be potentially fixed in the future.
-Mike

-----Original Message-----
From: Kevin C. Almeroth [mailto:[email-masked]]
Sent: Wednesday, November 22, 2000 7:41 AM
To: [email-masked]; [email-masked]
Subject: RE: Use of SAP in a PIM SSM Network

>>Ericsson has very little problem with multicast in Campus environmnets &
LAN's...It is the WAN that "generates" all the problems (link speed, load on
existing links, business critical traffic "at risk", and redundancy).  Add
to this that My division is responsible, but doesn't have control over
different "islands" it also becomes a political mess.

>>I have been kicking away for 2 years to try and motivate folks /
organisations to open their eyes to the necessity of multicast.  Until
September there was very little interest.  NOW everyone & their brother
wants everything to work 6 months ago.  Perhaps it is the globality of
organisations that the Ericsson Global IT Services Provides for...Am I the
only one with this dilemma??

>>I have an organisational question but it can easily be SSM / PIM-SM
related.  Is there anyone out there that has an application (Platform &
Application independant) for the dynamic assignment of multicast addresses
GGG.GGG.GGG.GGG:port where folks can book a randomized multicast group in
the same way as one would book a conference room??  A bonus feature would be
that this application could handle & mediate conflicts (someone "keeping" an
assignment, or making their own assignments).

-Kevin

---

From: "Wilbert de Graaf" <[email-masked]>
Date: Wed, 22 Nov 2000 12:29:41 -0800

Next week there is a multicast seminar at the London Internet Exchange
(LINX): http://www.linx.net/multicast/programme.html

I was wondering if anybody knows it's safe to send my manager, before he
comes back with a new set of cons.

- Wilbert

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 22 Nov 2000 19:41:54 -0500

> solutions can be potentially fixed in the future.

Dear Mike;

   I think that the biggest issue here is MAC address collision at layer
2. 
I think that it is a good idea to avoid this if possible. What we plan 
to do with our SSM broadcasts (starting next month) is to map our GLOP space
from  233/8  into the 232/8 SSM address range, and use that. If everyone does
this, then it is pretty straight-forward to avoid MAC collisions. Of course,
then, if you have more than 256 multicast groups, you have to worry about
collisions, but at least you can manage that yourself (or acquire access
to another ASN).

   The basic thing here is that broadcasters are going to want static
Class D addresses. (We, for example, have been up (doing ISM) since
early 
October with about 30 seconds of down time, and certainly want constant
addresses.) 
SSM will not change that. Whether these addresses are assigned by GLOP
type mechanisms or by other means such as MALLOC/ MADCAP doesn't really
matter that much, as long
as collisions can be avoided. It would be nice, however, if a Global SSM
allocation mechanism could be set up in the near future, before too many
people's choices get set in stone.

                                  Marshall

-- 

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

---

From: Tom Pusateri <[email-masked]>
Date: Wed, 22 Nov 2000 19:07:27 -0800

>people's choices get set in stone.

Encouraging the use of static Class D addresses sets a bad precedent
and I don't think we should be encouraging this. The broadcasters
and content providers have static host names which can be
used for rendezvousing and the source address and group address should
be able to float as needed to meet demand. End users will not be
aware of the group address being used under most circumstances
anyway.

Thanks,
Tom

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 24 Nov 2000 09:37:42 -0800 (PST)

> aware of the group address being used under most circumstances

Agreed. What i was thinking of as a possible operational improvement would
be to have some operational SSM document in which to recommend a specific
randomn number generator for selecting the SSM address to use, and have this
generator be seeded by some combination of AS number and source ip address
to be used for the channel, so that we gett less MAC-level ambiguities of
the SSM groups being used. 

Would just need someone with more insight and time to come up with good
recommendaations for this. I think if you could show just by some good
simulation, that you could get collision rate at MAC layer down by a few
factors over completely random assignment, then it would be good enough
to have this for all practical purposes.

Dunno how much one could practically achieve with this though...

Cheers
	Toerless

---

From: Marshall Eubanks <[email-masked]>
Date: Sat, 25 Nov 2000 10:57:59 -0500

> Dunno how much one could practically achieve with this though...

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

---

From: Tom Pusateri <[email-masked]>
Date: Sat, 25 Nov 2000 08:30:44 -0800

>but this sounds awful much like a static address to me.

The whole point is this should be left up to the source
to determine how to allocate group addresses. If your SSM
source wants to assign static addresses, that is a local decision.
But I would make a few points known upfront to your clients:

1. Others SSM sources will likely use the same group addresses
   and they must be prepared to deal with this.

2. Unused group addresses will be reclaimed.

In fact, I would encourage a group address lease which they can
renew at regular intervals.

Thanks,
Tom

---

From: "Michael Luby" <[email-masked]>
Date: Sat, 25 Nov 2000 10:49:54 -0800

> on some theoretical purity that does not fit their business model.

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

---

From: Marshall Eubanks <[email-masked]>
Date: Sun, 26 Nov 2000 12:18:21 -0500

Michael Luby wrote:
<snip>

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.

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

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

> 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

---

From: "Mike Luby" <[email-masked]>
Date: Mon, 27 Nov 2000 11:32:36 -0800

Are agreements and approvals also welcome? ;)

-----Original Message-----
From: Hugh LaMaster [mailto:[email-masked]]
Sent: Monday, November 27, 2000 10:05 AM
To: [email-masked]
Subject: Re: Use of SAP in a PIM SSM Network

> on some theoretical purity that does not fit their business model.

Two points:

1) This isn't a question of "theoretical purity".  Lots of IPv4
multicast addresses are mapped to each Ethernet multicast
address assigned for IPv4 multicast.  That means that layer-2
filtering must be imperfect.  On this mailing list, or, one of
its cousins, there was discussion/complaint a few months ago
about traffic to some multicast address like 225.0.0.1 getting
forwarded to all hosts-- well, it isn't a bug, it is a feature!
SSM effectively eliminates the shortage of IPv4 multicast addresses,
but, it doesn't address the shortage of MAC addresses, which is
really a function of the way IEEE looked at multicast MAC addresses
way back when.

MAC layer collisions are unavoidable by design.  But, they can
be reduced in number through intelligent design.

2) I don't agree that static IPv4 multicast application addresses
should *ever* be hardcoded.  Just the opposite: application
addresses should never, ever be hardcoded.  The possibility
should always exist for moving the address.  Certainly, some
broadcasters using SSM may not want to change the addresses
every day, but, if someone mistakenly chooses an address with
a serious collision problem of some kind, they should be prepared
to change it.  Applications with hardcoded addresses can create
serious problems downstream.

Disagreements and refutations welcome.

--
["I hate to say I told you so, but, I told you so."

 Hugh LaMaster, M/S 233-21,    Email: [email-masked]
 NASA Ames Research Center     Or:    [email-masked]
 Moffett Field, CA 94035-1000  Or:    [email-masked]
 Phone: 650/604-1056           Disc:  Unofficial, personal *opinion*.

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 27 Nov 2000 12:14:30 -0800 (PST)

> be reduced in number through intelligent design.

Well, i don't think that a protocol to solve this issue would be too difficult,
the question really is, how much it would be needed at all!

I would go so far as to say that most MAC layer switched networks will be able 
to sustain the level of MAC mapping ambiquity resulting from normal application
use. Like: there is sufficient bandwidh to sustain that excess receipt traffic,
and typical hosts (PCs, set-top boxes) are of equal - fast - speed.

As soon as you modify these parameter - like what Bill suggested, connecting
a poor lightbulb and a PC to the same MAC switched network, then you are
stretching the simple MAC mapping function of RFC1112 too far, and you
should look for a better solution, like a protocol to dynamically map (S/*,G)
to individual MAC addresses, or better use layer3 switching instead of
layer2 switching.

Cheers
	Toerless

---

From: Hugh LaMaster <[email-masked]>
Date: Mon, 27 Nov 2000 10:05:02 -0800 (PST)

Two points: