Subject: [MMUSIC] Re: [MBONED] WG action for draft-savola-mboned-mcast-rpaddr-03.txt

From: [email-masked]
Date: Tue, 22 Jul 2003 08:39:28 +0200 (CEST)

Yes, I am very curious of how to achieve ASM at the end hosts using
SIP and sdp. Maybe some people from mmusic could give us some hints ?

Hoerdt Mickaël

> IMO, you'll never get a consensus on depricating ASM until all of the
> pieces are in place for SSM to accomplish the same thing.  I think that
> what you will get a consensus on is a document that identifies the missing
> pieces and provides recommendations on how these pieces could be provided
> both at the protocol level, hardware level (MLDv2 Snooping??) and most
> importantly, at the application or session level to achieve the same
> many-to-many ASM behavior.
>
> Respectfully,
>
> Beau Williamson
>
>

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: [email-masked]
Date: Tue, 22 Jul 2003 09:28:34 +0200 (CEST)

On Tue, 22 Jul 2003, Colin Perkins wrote:

> The question "how to achieve ASM at the end hosts" is pretty vague, given
> that the end hosts already support ASM natively.

And that ASM for IPv4 is not supported in the network at large scale
today.

>
> If you mean, how to use SSM in applications, then the SDP source filter
> extensions <draft-ietf-mmusic-sdp-srcfilter-05.txt> allow you to signal
> SSM sessions in SDP (and hence in SIP). This draft is in AD review for
> Proposed Standard.

As far as I know This is a grammar to describe SSM channel and do not
gives any protocol to announce them.

>
> If the aim is to emulate many-to-many multicast with multiple SSM channels,
> then an application that knows its peers could, for example, signal a full

In my hypothesis, an application do not always knows its peers. You
signal a full mesh of SSM channels, OK but how ? which transport
protocol ? http over tcp / udp / multicast SSM/ ASM / soft state/hard
state ? how do you resolve the prob of high source dynamics ? I mean If I
only want to announce IP channels, what is the minimal protocol requirement to achieve it ? If
this is SIP, I would be glad to have to pointer to documents describing
it, and it should exist as you mention it in the last mboned session.

Thanks,

Hoerdt Mickaël

> mesh of SSM channels using SIP. I'm not aware of any applications that do
> this, since a central server architecture is easier and scales to the sizes
> most people are considering, but it doesn't seem outside the realm of what
> is possible. The question is better suited for the SIPPING working group,
> though.
>
> Colin
>
>
> --> [email-masked] writes:
> > > what you will get a consensus on is a document that identifies the
> > > missing pieces and provides recommendations on how these pieces could
> > > be provided both at the protocol level, hardware level (MLDv2
> > > Snooping??) and most importantly, at the application or session level
> > > to achieve the same many-to-many ASM behavior.
> > >
> > > Respectfully,
> > >
> > > Beau Williamson
> > >
> > >
> >
> --
> Colin Perkins
> [email-masked]

---

From: Colin Perkins <[email-masked]>
Date: Tue, 22 Jul 2003 16:51:55 +0200

> gives any protocol to announce them.

Correct. SDP is used by other protocols, such as RTSP, SIP or SAP, which
do the actual setup.

> > If the aim is to emulate many-to-many multicast with multiple SSM
> > channels, then an application that knows its peers could, for example,
> > signal a full
> 
> only want to announce IP channels, what is the minimal protocol
> requirement to achieve it ? If this is SIP, I would be glad to have to
> pointer to documents describing it, and it should exist as you mention it
> in the last mboned session.

If you know the peers, I would expect standard SIP signalling to work with
minimal - if any - extensions. This would let you build a conferencing app
above a mesh of SSM channels, for example. The SIPPING working group would
be the correct place to discuss this. 

I suspect, however, that you wish to fully emulate an ASM service over SSM,
including the rendezvous and discovery aspects of ASM, rather than building
an application that uses the SSM service in a novel way to provide many-to-
many multicast. I question what problem you are trying to solve by doing
this.

-- 
Colin Perkins
[email-masked]

---

From: [email-masked]
Date: Tue, 22 Jul 2003 17:24:44 +0200 (CEST)

<snip>
...
</snip>

> many multicast. I question what problem you are trying to solve by doing

You didn't answered my question but you answered your own: to
fully emulated an ASM service over SSM. Many applications do not know the
peers before the application start and may require a lightweight mechanism
to do source discovery and Group managment at IP level instead of have
the full machinery of SIP. Is there a working group for that ?

Read : I don't want to do an HTTP GET on some overloaded web server only
to know that there are no new sources in my highly dynamic session. I
prefer to open an SSM control channel on my Host, and to manage my Group
on with my application requirement at IP level. If some higher session
level requirement are required by the application, then I will use
SIP/RTSCP/RTP etc...

Then you may ask : why emulate ASM over SSM as we already have ASM ?
Answer : At this moment, ASM for IPv4 is not scalable in interdomain but
SSM is, and if you want to have something else than TV on
the large-scale Internet it would be good to have some IP level mechanism
to still have an ASM behaviour at the interdomain scale.

Hoerdt Mickaël

---

From: Colin Perkins <[email-masked]>
Date: Tue, 22 Jul 2003 08:59:03 +0200

Colin

-- 
Colin Perkins
[email-masked]