Subject: RE: [MMUSIC] Experiences with Media Discovery (for IMG)

From: [email-masked]
Date: Fri, 9 May 2003 16:28:21 +0300

Hi Hitoshi

Thanks for your link, your article is very interesting. There are many issues you cover which are easy to formulate into the requirements and use cases for IMG. So it will be great to collaborate on this issue.

I see you have made some broad conclusions along the same lines of my thinking:
* SAP is not sufficient and often not suitable, especially due to scalability and reliability issues
* XML is a good basis for content descriptions
* SSM is a particularly important use case
* HTTP is sufficient for fetching metadata

And, your general requirements (scalability, easy deployment, flexible policy and scope controls, conformance to SSM-only network) are important for IMG. Could you paraphrase you requirements and use cases so I can practically "cut & paste" into an ID? (Or you could submit an ID on requirements, for later aggregation to IMG, as DVB-IPI did for their considerations).

Also, you in depth analysis on SSM requirements would be of great benefit to IMG, so please contribute!

Some exclusions which IMG needs to cover "system-wide" in addition are:
* It is also desirable to support ASM "media description" and metadata delivery
* Some of our use cases mandate the use of unidirectional multicast delivery (IP broadcast including broadcast radio access)

I very much like your categorization of multicast session discovery approaches: "invitation model", "announcement model" and "session directory model". After working with a few methods, I came to the conclusion that "one-size-fits-all" is close to fitting square pegs in small hexagonal holes (you get the idea), so our aim is to limit the baseline IMG specification to the minimum number of methods for all general sizes (hence a p-t-m and a p-t-p ID). I guess the only obstacle to including the invitation and session directory models in the same p-t-p ID is the choice of protocols. We should discuss this further - any ideas?

I am not quite sure how you partition your metadata to allow a host to get specific entries from a CR (or indeed the CR to select the entries to send and how to group those entries) - can you explain (apologies if I missed this in the text).

There is still a great need to delimit and scope IMG so it is not possible to make too many certain conclusions on what IMG will be until specific items are accepted to the MMUSIC charter. In particular, we have use cases where metadata MUST be delivered by unidirectional multicast and others where it must be delivered over unicast, and there should be individually submitted IDs on both p-t-m (MUPPET+1) and p-t-p (00) available for discussion by IETF-57. These currently represent our best effort and it is highly desirable to get more contribution on these, identify if others are needed and deal with making IMG extensible for application beyond IETF transport area.

In this sense I understand the error in your paper...
"
Internet Media Guides (IMGs) [8] has been recently proposed in IETF MMUSIC WG.
IMGs allow users to initiate streaming media sessions, schedule delivery of downloadable
or multicast content or listen to live multicast sessions. The fact that it relies on WWW
collaboration schemes and that it creates a media directory system for the Internet is very
interesting. Unfortunately, however, there is no concrete architecture yet and it does not
provide any eective scoping technique or policy management whereas we consider these
aspect as central to our own needs. Furthermore, since there is no realistic protocol design,
it seems that SAP will be used continuously.
"
...I very much doubt that we could justify using SAP continuously (and have little desire to do so). Also, I would appreciate it if you could give requirements on the architectures. Our current view is along the lines of "generic enough to handle most IP-based architectures, and including proxies, etc. is wanted". And, any improvements you can contribute to the evolving MUPPET (etc) to make it a more realist protocol design would be much appreciated :)

Of course you are right that the current IMG contributes are not sufficient for all the current requirements, but I hope you are encouraged to help out in this work-in-progress. Certainly, your ideas on policy control and scope control could be very useful for a "better-than-SAP" announcement protocol implementation - as in MUPPET (in addition to the p-t-p case).

Cheers (and have a great weekend), Rod.

> -----Original Message-----
> From: ext Hitoshi Asaeda [mailto:[email-masked]]
> Sent: Friday, May 02, 2003 6:39 PM
> To: Walsh Rod (NRC/Tampere)
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; Luoma
> Juha-Pekka (NRC/Tampere); [email-masked]; Paila Toni
> (NVO/Helsinki); [email-masked]
> Subject: Re: [MMUSIC] Experiences with Media Discovery (for IMG)
> 
> 
> Hi Rod.
> 
> > I really need to find out about YOUR experience in media
> > announcements and descriptor delivery. SDP and SAP love and hate
> > knowledge as well as moving the metadata point-to-point (FTP, HTTP
> > are pretty well used) and new work (SIP, SDPng, etc.) are very
> > important so we can put together a picture of what a really needed
> > by our IP world. Ultimately, our purpose is to be able to specify
> > really useful protocols, etc. as IDs -> RFCs. But first we have a
> > basic goal to compile:
> 
> I've put a draft version of my paper related to this discussion before
> the last IETF.
> Our new "channel announcement mechamism" is called "Channel 
> Reflector".
> The purpose of this proposal is to provide a feasible channel
> announcement mechanism for SSM environment without using SAP
> advertisement. By using Channel Reflector, we can eliminate source
> discovery procedure from multicast service model.
> Some parts of the idea can be overwrapped to IMG, therefore we may be
> able to collaborate.
> 
> If you are interested in, you'd be able to get it from;
> <http://www.inria.fr/rrrt/rr-4762.html>.
> 
> Any comment would be appreciate.
> 
> Thanks.
> --
> Hitoshi Asaeda
> 
_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Hitoshi Asaeda <[email-masked]>
Date: Mon, 12 May 2003 16:34:46 +0200 (MEST)

Rod,

> Thanks for your link, your article is very interesting. There are
> many issues you cover which are easy to formulate into the
> requirements and use cases for IMG. So it will be great to
> collaborate on this issue.

Thanks for your faborable reply.

> And, your general requirements (scalability, easy deployment,
> flexible policy and scope controls, conformance to SSM-only network)
> are important for IMG. Could you paraphrase you requirements and use
> cases so I can practically "cut & paste" into an ID? (Or you could
> submit an ID on requirements, for later aggregation to IMG, as
> DVB-IPI did for their considerations).

At the beginning, I'd like to ask you about the current situation
about IMG.
To be honest, I have a feeling IMG's draft doesn't give us the
concreat architecture. I know this is because the current I-D is a
framework draft, but it would not be sufficient for the point of the
implementation and deployment.

> benefit to IMG, so please contribute!

Fine.
I'll consider that Channel Reflector (CR) should be included in the
IMG's draft or mentioned in a new one. At this moment, I think
separate draft may be better, in order to categorize each draft as a
"framework" draft and a "architectural" draft (like MUPPET?).

> I am not quite sure how you partition your metadata to allow a host
> to get specific entries from a CR (or indeed the CR to select the
> entries to send and how to group those entries) - can you explain
> (apologies if I missed this in the text).

Are you talking about the method to validate or classify data
sender/receiver? If so, it's not mentioned in my paper, since I think
it depends on the implementation and there are several possibilities.
But such information (that I mentioned in Sect. 5.2 and 5.3)
maintained by CR can include the key word to handle it as its basic
components.
If this is not your answer, please tell me.

Thanks.