Subject: Re: MMUSIC at the LA IETF

From: Eve Schooler <[email-masked]>
Date: Mon, 16 Mar 1998 14:27:42 -0800 (PST)

There will be one session (two one hour session combined)
for MMUSIC at the upcoming LA IETF.

>    Tuesday, March 31 at 1300-1515 
>    (opposite oncrpc, ngtrans, ip1394, sieve, urlreg spki)

We would like to take this opportunity to solicit input 
for agenda items.  Presently, we expect the agenda to focus
on SIP, SIP profiles, and possibly issues with SAP as well.  
All are more or less follow-ons from the last IETF.  
With your input, we hope to create a more formal agenda in 
the next week or so.

Thanks,
Joerg, Ruth, Mark, and Eve

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 18 Mar 98 14:21:15 JST

> With your input, we hope to create a more formal agenda in 

I'd like to discuss SIP/SAP related issues to announce sessions
statically through web and RTP URLs, as described in

	Title		: Static Multicast
	Author(s)	: J. Crowcroft, M. Ohta
	Filename	: draft-ohta-static-multicast-00.txt
	Pages		: 10
	Date		: 13-Mar-98

							Masataka Ohta

---

From: Mark Handley <[email-masked]>
Date: Wed, 18 Mar 1998 12:10:23 -0500

>	Filename	: draft-ohta-static-multicast-00.txt

Having read your draft, I don't believe it relates to SIP at all.  It
relates to SAP in that you propose not using SAP.  SDP can already be
carried by HTTP as you suggest, thus I don't see that there is any
need to discuss this draft in MMUSIC.

You should probably discuss this draft in IDMR or Mboned.  If you
manage to convince people there that the current model for IP
multicast must be replaced, then clearly SAP will not be useful, but
until then I think we should continue the standardisation of SAP.

Cheers,
	Mark

---

From: Jon Crowcroft <[email-masked]>
Date: Wed, 18 Mar 1998 18:45:06 +0000

>>need to discuss this draft in MMUSIC.
 
um, you mean a group is defined by the protocols it defined in the past
only?

i think not (he said wearing his IAB hat...)

 >>until then I think we should continue the standardisation of SAP.
 
who said it was a replacement - its a shorter term practical solution for
some services while you figure out how to make the ones you are working on
scale.....

mboned is a possibility, i dont see why its IDMR, since its not routing.

 cheers

   jon

---

From: Mark Handley <[email-masked]>
Date: Wed, 18 Mar 1998 14:31:59 -0500

>um, you mean a group is defined by the protocols it defined in the past

Actually we're under strong presure from the IESG to finish our
current protocols and close the working group.

>mboned is a possibility, i dont see why its IDMR, since its not routing.

I disagree with you here - the way a router discovers the Core/RP to
send a join message to is definitely part of a routing architecture.
A very similar proposal was discussed at the last IETF in IDMR, and we
had a lively discussion of the problems of this approach.

Cheers,
	Mark

---

From: Jon Crowcroft <[email-masked]>
Date: Wed, 18 Mar 1998 23:48:25 +0000

>>> >>need to discuss this draft in MMUSIC.
 
ok......so its related to sessions, but....

 >>current protocols and close the working group.

yes......though things move along from time to time....

 >>send a join message to is definitely part of a routing architecture.

you mean the way i find the MX record to find an IP adddress to send
the IP pcaket containin a SYN for my SMTP msg is part of unicast
routing?

i dont think so...

 >>had a lively discussion of the problems of this approach.

lively? um......

only the RP bit, and i think dino was at least 25% right but we had a
bootstrapping problem with his approach...but thats an old IDMR
discussion, whereas this is meant to be a more architectural
discussion

we aren't getting far placing it, and thats a shame, coz actulally
lots of service providers want something ,a n d too many of us in the
IETF in the multicast, session and conf world are too interested in the
difficult (viz researchish)
problems to be good ietf citizens and solve the obvious
problems first - mea culpa too here....

 cheers
mboned doesnt have the charter. iesg aside (:-), i think mmusic is a
good fit......but if the shoe is too small, where to tread?
   jon

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 19 Mar 98 13:18:13 JST

Mark;

> until then I think we should continue the standardisation of SAP.

Thank you for your opinion.

Are there anyone in the WG who disagree with Mark?

	> multicast must be replaced, then clearly SAP will not be useful, but

so clear that it is the consensus of MMUSIC WG, without having
any discussion in face-to-face meeting?

> until then I think we should continue the standardisation of SAP.

Is the discussion on standardization of another way of session
announcement outside the scope of the WG?

I want some forum discuss detailed syntax of session announcement
with RTP/SDP URLs.

If MMUSIC is inappropriate, I should request a new one.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 19 Mar 98 19:10:11 JST

Jon;

> the IP pcaket containin a SYN for my SMTP msg is part of unicast

I'm afraid Mark is missing the point here.

Three proposals in the ID are somewhat interrelated but somewhat
separate.

RTP/SDP URL is meaningful as long as multicast addresses are
represented by DNS A records, which is mostly independent of
the rest of the proposals.

It suggests (but does not require) that, because of the global
nature of DNS, multicast address is globally unique.

DNS inverse lookup of multicast addresses is directly related to
the global uniqueness, so that it is weakly related to RTP/SDP
URL.

PIM/CBT RP/Core proposal is unrelated to the validity of the
RTP/SDP URL.

> discussion, whereas this is meant to be a more architectural

Where can I see Dino's full proposal? I saw only a piece of his
example, with which I can certainly say it is 25% correct at
most.

> good fit......but if the shoe is too small, where to tread?

Mboned is chartered to be related to multicast protocols and
(operational) procedures and is seemingly unrelated to
application layer issues.

							Masataka Ohta

---

From: Mark Handley <[email-masked]>
Date: Thu, 19 Mar 1998 12:56:57 -0500

>the rest of the proposals

Yes, but multicast addresses are not represented by DNS A records in
the current multicast service model.  You need to get acceptance of
your service model before we should spend the working group's time on
something that depends on it.

BTW, you should note that multicast sessions contain multiple media,
using multiple multicast addresses (particularly for layered codecs),
not all of which are RTP.

>application layer issues.

And application layer issues are critically dependent on our
assumptions about the IP multicast service model.

You want to change that service model - you need to change all hosts
to do a DNS lookup and pass the resulting address to the local router
before you can send or receive.  Without this change to the service
model, there is no point in representing multicast addresses in DNS in
the way you suggest.

  [Note: you're actually changing the IP service model too, as the
  current IP multicast service model follows the IP service model in
  that senders can send to an IP address without any prior host->router
  communication.]

If we don't assume a particular service model, we can't design
suitable applications.  You're asking us to discuss application-level
issues for a service model that is not even properly written down yet,
and has absolutely no concensus behind it.

What you need is a BOF, so that you can discuss the different parts of
your proposal in one place and get feedback as to whether anyone
considers your ideas worthwhile.  But discussing the application level
stuff alone seems somewhat pointless to me.

Mark

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 20 Mar 98 9:13:37 JST

Mark;

> something that depends on it.

Which WG, do you think, define the application layer service model
of multicast MMUSIC must follow?

> not all of which are RTP.

An interesting point. So, the URL might better be SDP URL containing
session descriptions of, including but not limited to, RTP.

Or, I may say my service model support RTP only. :-)

> model, there is no point in representing multicast addresses in DNS in

???

When an application on a host choose a session, with the current
multicast model, it must tell the local router the selected session
before you can send or receive.

Or, are you saying that SAP do not need such a thing?

Or, are you saying about the issue specific to core/RP of PIM/CBT,
which is not related to applications.

>   that senders can send to an IP address without any prior host->router

I think you are talking about core/RP addresses.

That is an inellegance of the current IP multicast service model
to break the e2e priciple.

It's end host or an application on it, which knows varous
requirements to RPs best. So, the end host, not the first hop router
nor the flooding protocol in the network, should control session
related things.

If hosts themselves directly speak PIM or CBT, prior communication
is not necessary.

> stuff alone seems somewhat pointless to me.

Thank you for your advices.

But you are wrong that discussion with you has been quite
useful even in an application specific issues.

							Masataka Ohta

---

From: Christian Huitema <[email-masked]>
Date: Fri, 20 Mar 1998 15:01:05 -0500 (EST)

Just my two cents.  When Mark mentions that:
	Actually we're under strong presure from the IESG to finish our
	current protocols and close the working group.
he should really not believe that the pressure only comes from
the IESG.  There are already many applications that use SDP, and
they have been interoperating for several years.  There are many more
that could use SDP, SAP and SIP.  The glacial pace of progress of
MMUSIC is going to condemn those protocols to irrelevance.

Sure, we will be able to do a better job in 3 months.  And an even
better one in 3 years.  But please, freeze the damn spec and publish it,
so we can get a minimum of experience from independent implementations..

-- 
Christian Huitema
----------
See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/

---

From: Mark Handley <[email-masked]>
Date: Fri, 20 Mar 1998 15:14:08 -0500

>so we can get a minimum of experience from independent
implementations..

I understand and agree with your sentiment.  Here is the current
status of the MMUSIC protocols.

The SDP spec is frozen, except for trying to accomodate comments from
the IESG.  I'm not accepting changes from the WG.

The SIP and SAP specs are essentially frozen now, except for
addressing security issues.  

As you know, we can't get these through the IESG without a thorough
consideration of security, and this does take some time.

In the case of SIP we've also been discovering occasional errors and
things that needed clarification as we implement.  This would
obviously go faster with more technical feedback from the group.  It's
not a question of doing a better job, but of producing a spec that
others can implement from, that isn't full of security holes.  None of
the authors have a great amount of time to work on this, so it's
progressed slowly. If you feel as strongly about it as you imply,
please contribute effort (preferably in the form of constructive
feedback).

Cheers,
	Mark