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

From: [email-masked]
Date: Tue, 3 Dec 2002 12:13:49 +0200

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 03 Dec 2002 09:12:44 -0500

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]:
>  4) "Reference specification defining what description formats the 
> contents of Internet Media Guide could use"
>
> 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.
>
> 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).
>

---

From: "Yuji Nomura" <[email-masked]>
Date: Wed, 4 Dec 2002 21:13:02 +0900

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