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

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 10 Jun 2005 14:21:51 -0400

Mickael,

I think that the security considerations and inter-domain multicast routing realities are what drive these applications to the client-server model instead of multicasting. However, leaving that aside, what is wrong with using the standard approaches already mentioned (e.g. SAP/SDP or HTTP) as a good approach to discovering valid sources for an SSM, as well as the appropriate IP multicast group?

In short, why are we looking for another protocol to do this job?

Bert

> -----Original Message-----
> From: Hoerdt Mickael [mailto:[email-masked]] 
> Sent: Friday, June 10, 2005 4:42 AM
> To: David Meyer
> Cc: Stig Venaas; [email-masked]; 
> [email-masked]
> Subject: mboned: draft-lehtonen-mboned-dynssm-req
> 
> Hello,
> 
> With Stig and Rami, a draft has been presented to the mboned at the
> last 62th IETF in Minneapolis. This draft discuss about the 
> requirements
> needed
> for a general source specific multicast service and the application
> range scope where
> it could be used.
> 
> During the session, it seems that good comments where raised 
> about this
> work, but there where no reaction on the mailing list, so I start a
> thread on it. The draft can
> be read on line at :
> 
> http://ietfreport.isoc.org/idref/draft-lehtonen-mboned-dynssm-req/
> 
> What do you think of this work ? Do you think that a general 
> SSM source
> discovery
> layer have to be studied or it is better for developpers to 
> write their
> own ?
> 
> Another question :
> 
> Last experiments on the IPv6 multicast enabled showed that the time to
> construct a multicast branch is very high (about 900ms-1s for the
> PIM-JOIN message to reach hop
> by hop some source, traversing 8 hops). Experiments on the mbone IPv4
> network showed similar results, do someone have an idea why 
> it takes to
> much time (thats
> about 100ms per hop, which is a geologic time in current networks), is
> there something
> in the PIM specification or is it implementation related ?
> 
> Cheers,
> 
> Hoerdt Mickaël

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

---

From: Hoerdt Mickael <[email-masked]>
Date: Fri, 10 Jun 2005 21:19:11 +0200

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