Subject: RE: mboned: draft-lehtonen-mboned-dynssm-req

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 10 Jun 2005 15:52:57 -0400

Okay, I'm not disputing whether another protocol might be useful or not for this purpose. I'm just having trouble with understanding why use SSM in a case where ASM seems the obvious choice.

From what you describe, the huge dynamic multicast environment, it seems to me that the natural solution would be ASM and either SDP or some mirrored web sites to get the group's specifics out. In this case, the SDP or web sites would not have to change in real time, because the group membership doesn't matter, so the only scaling issue is how fast the multicast tree will adapt.

Where SSM must be used, that's where I don't see this approach scaling well. Not for this enormous example of sources coming and going. (For static sources, no problem.) Seems to me that millions of sources joining and leaving, where this will impact millions more in how they formulate their IGMPv3/MLDv3 "reports" in real time, and routers reacting to these to build or tear down multicast trees, is what will be a scaling challenge. No?

Bert

> -----Original Message-----
> From: Hoerdt Mickael [mailto:[email-masked]] 
> Sent: Friday, June 10, 2005 2:19 PM
> To: Manfredi, Albert E
> Cc: [email-masked]
> Subject: Re: mboned: draft-lehtonen-mboned-dynssm-req
> 
> Hi Albert,
> 
> SAP has been designed over ASM/IP model, using a well known group to
> discover
> all the running session over the network. This flat model 
> doesn't scale over
> the Internet, so something else have to be invented to publish the SDP
> information.
> 
> The client-server based on HTTP is well designed to discover 
> simple SSM
> sessions,that
> is static regarding the SSM channel set: you have a set of  sources
> transmitting toward a set of fixed channels and this 
> information is put
> on a  SDP file published on the web server and with all 
> clients getting
> the information about it.
> 
> But what If the session is dynamic, what is source are coming and
> leaving over time,
> as ASM/IP allowed to do ? We could argue that one only have to update
> the SDP file
> published on the web server and that clients could get this 
> information
> by RSS feeds, but does it make sense and will it scale when 
> millions of
> receivers have to have this
> information ?
> 
> Having a standardized source discovery protocol provide 
> interoperability
> between
> various multicast applications which require the same powerful
> properties of the
> ASM/IP model. Simple applications doesn't require this and can rely on
> existing solutions to get an SDP file, but I think that complex
> applications require something
> that scale better than a simple client-server model.
> 
> You may argue by "which applications ?", but then I would answer that
> ASM multicasting needs more than waiting for applications to come to
> leverage it's power.
> It needs a clear view about what a multicast session is from the
> IP-multicast community and to provide this clear view to the 
> app-folks,
> maybe with the Mdoc initiative.
> 
> Documenting the requirements for a channel discovery service fits in
> this effort and may eventually helps to fill the gap between 
> MMUSIC and
> SSM IETF working groups. Even if multiple solutions exists today, I
> think that there is a lack of good documentation about the 
> usability of
> these solutions in various scenarios, does
> the mboned charter fits in this, or is it too much high over the IP
> layer and too
> much below the application layer ?
> 
> Mickaël

_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: "Marshall Eubanks" <[email-masked]>
Date: Fri, 10 Jun 2005 16:22:26 -0400

On Fri, 10 Jun 2005 15:52:57 -0400
 "Manfredi, Albert E" <[email-masked]> wrote:
> Okay, I'm not disputing whether another protocol might be useful or not for this purpose. I'm
> just having trouble with understanding why use SSM in a case where ASM seems the obvious choice.
> 
> >From what you describe, the huge dynamic multicast environment, it seems to me that the natural
> solution would be ASM and either SDP or some mirrored web sites to get the group's specifics out.
> In this case, the SDP or web sites would not have to change in real time, because the group
> membership doesn't matter, so the only scaling issue is how fast the multicast tree will adapt.
> 
> Where SSM must be used, that's where I don't see this approach scaling well. Not for this
> enormous example of sources coming and going. (For static sources, no problem.) Seems to me that
> millions of sources joining and leaving, where this will impact millions more in how they
> formulate their IGMPv3/MLDv3 "reports" in real time, and routers reacting to these to build or
> tear down multicast trees, is what will be a scaling challenge. No?
> 

My feeling is that the IPv6 situation fits about right (SSM for broadcasts, embedded RP's for
highly dynamic ASM scenarios, with trees going to the ERP). That suggests that serious thought
be given to ERP for IPv4, which Dave Thaler suggested, with a less than resounding response.

> Bert

Marshall

---

From: Hoerdt Mickael <[email-masked]>
Date: Mon, 13 Jun 2005 10:30:12 +0200

Right, I don't really want to re-enter in the debate of ASM architecture
versus SSM
architecture but....

ASM/IPv6 have Embedded-RP (ERP) to provide a scalable interdomain
in-band multicast source discovery inside the same group  but  is ERP
enough for the public
IPv6 Internet  that we will have tomorow ?

One still have to define the rules to access an RP and if these rules
are compatible with both the application and the  security policy of the
domain. If a domain is offering a
public RP, this means that every hosts in every domains can use this RP.
You have
the same situation with an application layer RP, but at least ISP and
its clients can
be separated and this allow easier policy rules like :

- How many trees do I allow for each sources to be the root.
- How much upstream multicast bandwith do I allow for each sources.
- How do I prevent a source to not flood the network when there are no
receiver.

Of course, if there are no policy at all, then ERP and a application
layer source discovery relying on SSM are almost equals on the security
level.

ASM/IPv4 provided MSDP as  a transitional solution toward BGMP/MASC but
derived multicast allocation and routing seemed more elegant and simple
to instanciate (both SSM and Embedded-RP use group adress derived from
unicast, this really simplify multicasting and is very elegant but that
imply a fixed root of the multicast tree).

So yes, I think that the IPv4 Internet architecture is missing an
appropriate multicast
source discovery mechanism comparable to what ASM provide at the intradomain
level. For IPv6, questions remains unsolved in my opinion as there is no
BCP documenting :

- How to enforce a ERP multicast group address.
- How to allocate ERP group addresses, and how I'm sure that my ERP
group address
  will not collide with another
- How an ISP offer a public service with ERP.

Several propositions have been made, including enabling ERP on each DR
:  each /64 could have their own RP,  and they can managed at the
network admin discretion depending on the applications running on this
network, but with the same argument
as above, how will an ISP separate services ? If I have my own RP at
home, will my ISP
accept to be my PIM neighbor and if not, how much will I pay for that ?

To sum up :

- MSDP have serious drawbacks when deployed at large scale, as only one
packet
trigger a flooding on all RP in all domains because the receiver and the
sources have
to meet somewhere but there is no signalisation at all for that so
flooding cannot
be avoided.
- ERP is a nice solution, which constraint the flood of new sources at
one RP, but
  management problems remains (see above).
- A majority of the problem that have been encountered comes from source
discovery, taking an historical argument, DVMRP was profiled to allow
the network to discover
the source in a flooding approach.

I think that a general requirement draft on source discovery is needed, 
because it
is a central problem of ASM, doing it at the network layer or at the
application layer,
but what about the mboned community ?

Hoerdt Mickaël

---

From: Marc Manthey <[email-masked]>
Date: Mon, 13 Jun 2005 10:50:28 +0200

> but what about the mboned community ?

Hi  michael experts  all,

IPv6 will be a challenge. No normal human beeing thinks of typing in  
IPv6
addresses. Cut and paste, maybe - but typing, no! IPv6 will break DNS!

There are nameservers behind firewalls that dont allow tpc  
connections to the
namesevers. IPv6 addresses will break packet borders and they will  
finally
break these nameservers.

You dont need IPv6? Ipv4 is good enuf for you?

Joe and me, we have seen IPv9 working. Stay with your old IPv4  
machines and let
governements decide what is good for you. Send your emails to the  
governement
and let them decide what is spam. They are looking forward to reading  
and maybe
forwarding or not your emails. Who needs to run a mailserver anyhow.  
Dont you
think its a good idea of the goverment to close port 25 forwarding?

If you dont think so read on!

Today we have to worlds a host might live in. There are some good  
guys running
servers running important machines with fixed addresses. They make up  
the world
of DNS. Everybody can ask DNS for their addresses and maybe their names.

And then we have hosts like yours and mine connected via NAT-routers  
to dsl- or
cable-modems or to good old pots via good old modems. Whenever I  
connect to the
internet I get a new ip. An ip that somebody else might have used for  
sending
spam the I cannot use it for sending emails. An ip that nobody knows  
not even me.
If I dont disconnect and reconnect my provider will do that for me  
once every
24 hours. That is the world of P2P users and services like no-ip.com .

How do these hosts know eachother? How do they find eachother. How do  
they
connect? How do they identify?

There is live outside DNS. I have met them.

Before we had DNS there was /etc/hosts and there still is NIS. NIS+  
might have
become DNS but SUN has given up. It does not scale up.

Still there is P2P. It is losely connected to DNS by services like no- 
ip.com

Does P2P really need static ip addresses?.

The DSLAM the concentrator and router I am connected to, manages some  
4K addresses.
To find echnaton.serveftp.com just try 4K ip addresses and you have  
got me.

If only 100 hosts of those 4K possible addresses in the voicinity of  
frankfurt on
main, germany had a P2P-nameservice running you would only have to  
ask 40 addresses
to get me.

Have a nice week

marc manthey

www.cuseeme.de

P.S free reflector set up on mac osx with dymamic  ip!!!
cuseeme.dyndns.tv  with your cuseeme client or vchat
multiple video and  audio conferencing for free
********************************************************
opencuseeme /  peer2peer multiparty conferencing
********************************************************

---

From: Hoerdt Mickael <[email-masked]>
Date: Mon, 13 Jun 2005 21:22:17 +0200

Coming again on this scalability problem, It seems to me that PIM-SSM is
not stressing
the multicast architecture more that PIM-SM as the default behavior on most
cisco routers is to switch to the SPT at the first packet from the
source, the network
is stressed in the same way, one difference with PIM-SSM for PIM-SM is
that with PIM-SM, the network have to find wether a source stopped to
send packet or not to
tear down the SPT. I see this at least as difficult as the problem of
source discovery. With PIM-SSM, you tear down the SPT explicitely, and
the network doesn't have to care.

Back on the Joining time, any info on this ? Commercials routers that I
tested takes
about 100ms to process a Join and forward it to the next-hop.

Hoerdt Mickaël