Subject: RE: [MMUSIC] Re: Transport of Internet Media Guides - Work/Service Split

From: [email-masked]
Date: Mon, 9 Dec 2002 15:14:04 +0200

Hi Yuji and everyone,

I'm glad you find these ideas on basic operations very useful. They should make it reasonably easy to communicate the scope each transport draft. 

I also believe the 4 elements you stated are essential, and that the framework should enable extensibility so that alternative (out-of-band) transports and additional IMG metadata semantics and syntax are feasible.

There is a clear need for use cases and requirements as well as framework and usage specification. The target is clearly to take this to RFC and so we should come to a consensus on whether it is beneficial to include requirements and framework in the same RFC at some point. (I like the way RTP has done this, but don't have a strong opinion as long as the IESG and RFC Editor are happy). Usage of unidirectional/multicast and bi-directional/multicast transports seems to belong to the framework scope, although the protocol specification is an entirely different level of abstraction so it might make sense to separate these in a similar way to RMT building blocks + protocol instantiations.

In direct response to your 3 points...

(1) did my mail earlier today clarify this? - can we answer the questions posed: Is the actual img_PUSH sufficient warning of the push itself (unidirectional case), is an img_FETCH at a later time when an uplink will be available unnecessary (hybrid case)? Can we save bandwidth with use of both notify and push instead on always piggy-backing? (and, are any of the 4 potentially advantageous cases listed useful to the Internet community at large?)

(2) The use of fetch for IMG update status allows receivers to check that its current IMG metadata is correct without: subscribing; joining a multicast push; potentially wasting bandwidth by fetching the relevant parts of the IMG just in case they are updated. Any environment where a receiver connection to the sender can go down and then heal could benefit from this. Anonymity and scalability are the two reasons I see for this. [Note HTTP "conditional GET" using the If-Modified-Since header field could give the "fetch only if updated" functionality].

(3) For transport service names I just wanted a brief (mostly) self explanatory term for each transport service. 3 of these services are very similar to the 3 protocol components in pguide_requirements and the additional functionality strongly reflects the multicast case. I didn't use the terms from pguide_requirements because I didn't want to imply only request/response cases (as the protocol requirements current implies) and they wouldn't fit into my ASCII matrix easily :) Any improvements to these names are welcome.

The use of these names should allow "IMG transport protocol instantiations" to easily identify which IMG transport service (protocol components) they provide and so determine what is in and out of scope for that protocol (in terms of fulfilling the framework needs). In that context, how do you feel about the scope as I proposed:
> >     Unidirectional/Multicast Transport of IMGs:
> >         img_PUSH
> >         img_NOTIFY (push)
> >         [SAP-like]
> >     Unicast/Bi-directional Transport of IMGs:
> >         img_SUBSCRIBE
> >         img_NOTIFY (quiz)
> >         img_FETCH
> >         [SIP-like]

If this seems like a good idea, it's time to put my thinking cap on and get some draft text written.

Cheers, Rod.

-----Original Message-----
From: ext Yuji Nomura [mailto:[email-masked]]
Sent: 04 December, 2002 14:13
To: Henning Schulzrinne; Walsh Rod (NRC/Tampere)
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; Luoma Juha-Pekka (NRC/Tampere)
Subject: Re: [MMUSIC] Re: Transport of Internet Media Guides -
Work/Service Split

Toni, Rod,

I agree that we need four parts, that is framework, requirements,
protocol and reference data model, in IMG drafts.

It is very useful to come up with the basic operations
in order to organize content in these drafts.

I'd like to clear three points on your thoughts so far.

(1) I'm not sure the differences between img_NOTIFY and img_PUSH.
As mentioned in "Piggy-backing" part in your mail, we can distinguish
between references and actual media guide data in the same operation
by using message body field.

(2) I think img_FETCH can request and retrieve all or part of IMG as
necessary.  However, is it necessary to request and retrieve update
status about IMG by img_FETCH?

(3) Please give additional information about the idea of
"Service Naming"

Regards,
-----
Yuji Nomura

----- Original Message -----
From: "Henning Schulzrinne" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Tuesday, December 03, 2002 11:12 PM
Subject: [MMUSIC] Re: Transport of Internet Media Guides - Work/Service Split

> I agree in general, but would want to avoid getting to tied up in the
> detailed characteristics of the underlying network. In many cases, the
> sender may not know, for example, whether the receiver is on a hybrid
> link. After all, the Internet model is about abstracting away link-layer
> details.
>
> I agree that it is useful to consider the basic operations we need:
>
> - img_NOTIFY
> - img_FETCH
> - img_SUBSCRIBE
>
> I'm less clear on the need for 'img_PUSH' since the boundary to notify
> is fuzzy. After all, both can contain references, rather than the actual
> media guide content. These are logical operations, so SAP would be
> notification, where the subscription is done at layer 3 (joining the
> multicast group).
>
> Depending on whether multicast is available, we then have several
> protocol choices, with SAP requiring multicast.
>
>
> [email-masked] wrote:
>
> > Hello
> >
> > After some hard thinking about the split of IMG transport instances
> > (Toni Paila's earlier mail), we came up with the notion of using a
> > matrix to analyse the subtle differences between "unicast vs.
> > multicast" and "bi-directional vs. unidirectional". The problem is
> > that the work split between a unicast/bi-directional transport
> > (SIP/HTTP-like) and a multicast/unidirectional transport
> > specification/draft is not as obvious as "unicast is used over
> > bi-directional links" and "multicast is used over unidirectional
> > links". For instance, bi-directional links can still be used for
> > multicast push, and unicast service can be delivered over
> > unidirectional links.
> >
> > One major of the observations of this analysis is that the notion of
> > "IMG Transport Services" is essential. We came up with 4 basic
> > services which would need to be defined in the IMG framework and then
> > "IMG Transport Instantiations" would need to support one or more of
> > these services compliant to the framework. This makes it much easier
> > to describe what is in scope and out of scope for each of the two
> > transport instantiations proposed at IETF-55 [(2) and (3) below]:
> >  1) Internet Media Guide Requirements and Framework
> >  2) Unicast/Bi-directional Transport of Internet Media Guides
> >  3) Unidirectional/Multicast Transport of Internet Media Guides
> >  4) "Reference specification defining what description formats the
> > contents of Internet Media Guide could use"
> >
> > I've tried to explain these ideas below as well as possible in ASCII :)
> >
> > Comments, questions and further ideas are extremely welcome
> >
> > ...
> >
> > _Internet Media Guide Transport Matrix_
> >
> > The purpose of this matrix is to distinguish between the type of
> > delivery each IMG transport service so that the delivery requirements
> > can be fulfilled by the separate "unicast/bi-directional" and
> > "multicast/unidirectional" IMG transport instantiations.
> >
> >           +---------------+---------------+---------------+
> >           |unidirectional |    hybrid     |bi-directional |
> >           |  access/link  |  access/link  |  access/link  |
> >           | (1 x simplex) | (2 x simplex) | (duplex)      |
> > +---------+---------------+---------------+---------------+
> > |         | img_NOTIFY    |  <-depends->  | img_SUBSCRIBE |
> > |  p-t-p  | img_PUSH      |  <-  " "  ->  | img_NOTIFY    |
> > | unicast |               |      " "  ->  | img_FETCH     |
> > |         |               |               |               |
> > +---------+---------------+---------------+---------------+
> > |         | img_NOTIFY    |  <-depends->  | img_SUBSCRIBE |
> > |  p-t-m  | img_PUSH      |  <-  " "  ->  | img_NOTIFY    |
> > |multicast|               |      " "  ->  | img_PUSH      |
> > |         |               |      " "  ->  | img_FETCH     |
> > +---------+---------------+---------------+---------------+
> >
> > * Four IMG transport services (identified so far):
> > 1. img_SUBSCRIBE: Ask for certain notify and/or push services
> > 2. img_NOTIFY:    Send "update available", two transports:
> >                   1. push (unidirectional indication, requiring no (or
> > discretionary delayed) acknowledgement)
> >                   2. quiz (bi-directional request/response)
> > 3. img_FETCH:     Two options:
> >                   1. Request and retrieve all or part of IMG
> >                   2. Request and retrieve update status of all or part
> > of IMG
> > 4. img_PUSH:      Send part or all of IMG (may be redundant resend or
> > new/updated)
> >
> > * Additional notes on applicability of the transport services:
> >     img_NOTIFY
> >         IMG update is available (for subsequent FETCH, or
> > "unbounded-PUSH")
> >         IMG PUSH (probably update) is imminent (wake up and get the PUSH!)
> >         Application alert (event alert service which is
> > application-specific like RTP APP)
> >     img_PUSH and img_FETCH
> >         deliver the whole NEW IMG (for a certain scope - e.g. area, or
> > the whole world)
> >         deliver a new part of the IMG
> >         deliver the whole IMG which has previously been sent
> > (especially for PUSH)
> >         deliver a part of the IMG which has previously been sent
> >
> > * Piggy-backing
> > In some cases it may be desirable to piggy-back notify_push and
> > push_new/replacement_metadata together, so use of the same syntax has
> > advantages.
> >
> > * Service Naming
> > "img_SERVICE" terms are work-in-progress (not yet fixed) and should
> > not be confused with other (e.g. SIP) use of the same words. Actually,
> > better suggestions on any terms are very welcome.
> >
> > * Access/link Types
> > These are the type of "physical" connection the terminal (client, MN,
> > whatever) has to the network. They do not fix the network/transport
> > protocol type (although they clearly influence it). [By
> > network/transport protocol I mean things like "TCP over unicast IP"
> > and "unacknowledged payload over UDP/multicastIP with no return
> > signalling" and so on].
> >
> > There are 2 basic link types: unidirectional; and bi-directional. The
> > former has only downlink connectivity (server->client or
> > network_client->terminal_client), and the latter has connectivity both
> > ways (and clearly uplink implosion issues). A third link type is
> > hybrid (different uplink and downlink paths/routes and probably access
> > networks) - that takes some characteristics of both of the basic
> > types. A hybrid example would be a terminal with access to the
> > Internet through dial-up, and to a unidirectional IP multicast by
> > satellite.
> >
> > * Other multicast cases
> > The m-t-m and m-t-p cases are intentionally omitted. Input on these is
> > welcome if people are interested (and where these are more than just
> > an abstraction of p-t-p + p-t-m).
> >
> > * IMG Transport Instantiation Split
> > So my preliminary view on how to support the IMG transport services in
> > the two proposed instantiations is:
> >     Unidirectional/Multicast Transport of IMGs:
> >         img_PUSH
> >         img_NOTIFY (push)
> >         [SAP-like]
> >     Unicast/Bi-directional Transport of IMGs:
> >         img_SUBSCRIBE
> >         img_NOTIFY (quiz)
> >         img_FETCH
> >         [SIP-like]
> >
> > ...
> >
> > After taking a deep breath, does this make sense to anyone else?
> >
> >
> > >>Rod>>
> >
> >
> > ================================
> >   Rod Walsh
> >   Nokia Research Center
> >   Tampere, Finland.
> >   [email-masked]
> >   +358 50 483 5632
> > ================================
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mmusic
>

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