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

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

Hi

Thank you for your quick response. I hope to clarify the ideas here and justify the use of push.

> I agree in general, but would want to avoid getting to tied up in the 
> detailed characteristics of the underlying network.

I agree that it is not necessary or desirable to get tied up in link details. It is sufficient that the IMG specifications take account of the general environments in which they are used and I expect the three kinds of links described (unidirectional, bi-directional and hybrid) are sufficient at this level of abstraction. Is there a need for any more detail at this stage?

> 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.

This is true. The sender would know what kinds of subscribes it has (for notify_quiz, notify_push and push; and for p-t-p and p-t-m), and may be configured (manually?) to send certain items to certain p-t-m channels be default. This should be sufficient to handle each of the link cases. Can you see any situations where additional sender knowledge would be needed to abstract away the link-layer?

> 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.

It's great to hear that using these kinds of IMG transport services classifications to define the work of multicast/unidirectional and unicast/bi-directional transport seems to make sense. As stated, there are cases where the distinction between notify and push is fuzzy - the piggy-backing of notify and push is certainly useful. Indeed, some implementations may only provide a subset of the transport services such that notify and/or push or not considered useful. 

The important distinction between notify and push is that notify is essentially providing "a notification message to the receiver" [from the pguide_requirements] which may reference the metadata where as push delivers the IMG metadata. Push alone (without notify) is especially important for unidirectional transfer - possibly based on data carousels where transfer is continuous not event driven. Notify alone is especially important where there is an active bi-directional connection to the "fetch server" and the system need not be massively scalable.

> After all, both can contain references, rather than the actual 
> media guide content.

My use of img_PUSH is to send IMG metadata. The metadata itself can contain references to further metadata but this does not effect the use of img_PUSH. My use of img_NOTIFY is to inform of events in the IMG - i.e. new items, modifications, deletions. The notify may just identify the effected part of the IMG, or may also reference the IMG metadata which has changed (e.g. 9pmFootball, or 9pmFootball_destinationIPaddress). The notify may also include the change (i.e. be piggy-backed with a push), but this only makes sense for small changes that are not frequent (otherwise bandwidth and scalability could be baddly effected).

The 3 services mentioned (fetch, subscribe, notify_quiz) correlate well with the pguide_requirements protocol components (Program guide request, Notification request, Update notification). The push service is applicable for multicast IMG metadata delivery. Whether we need to specify notify_push in addition to notify_quiz depends on whether there is any additional value for a separate notify from push. In one hybrid case where a receiver has an intermittent uplink (not always on) but the downlink is continuous (e.g. broadcast), the notify_push can be used to allow receivers to fetch at some later time when they have an active uplink - and without spending extra downlink bandwidth on pushing the IMG metadata with every notify_push. In the unidirectional case, the notify_push can be sent to warn of a changed part so that receivers with no interest in the that part of the IMG can then sleep instead of being forced to filter and parse the uninteresting metadata (which would be on!
 a separate push - possibly a few seconds later).

The unidirectional push case is very distinct from the request/response notify case (as described in the pguide_requirements) so I believe there is a strong case for img_PUSH. So there is a reason to send parts of the IMG without the notify (especially for carouselled repeats of the IMG in a unidirectional-only environment).

On the other hand, the usefulness of img_NOTIFY_push is very dependant on the deployment. I can see 4 potentially advantageous cases:
* If the sender wants to decide between multicast and multiple unicast transport for a large IMG change (or the existing IMG) a multicast notify without IMG metadata can go out a little time before the transport (especially if the multicast bandwidth is limited, and the unicast channel is intermittent this can be a serious optimisation issue). IMG should provide the toolbox to deal with this optimisation even though IMG does not need to be aware of the details of L2.
* If multicast is only used for notifying of updates and unicast fetch is always used to get the data (e.g. the multicast downlink bandwidth is limited) then notify should be optimised just for these update notifications.
* if receivers are "sleeping" and only wake up occasionally, it makes sense to repeat the notify several times so that all of a large group probably get it. If the metadata is also to be pushed, it takes less bandwidth to do this after the notify repeats (when receivers are awake and waiting) than with every single notify repeat. Also, the data rate and total size of the notifies will be smaller without the metadata so the "sleeping" processing of notifies will be smaller (and take less battery power).
* if the IMG sender-receiver link is unidirectional-only, then it may be desirable to save bandwidth by only using this link for the basic IMG metadata. Other IMG metadata, which is not essential to receiving the session or enabling a user's decision to select that content, may be updateable out-of-band, but only the notifies of changes would be sent by IMG multicast transport. This may be useful where a receiver has cached "metadata not essential to receiving the session/content" - such as a rock band's touring dates and pictures of the venues related to the actual "IMG content" of a single piece of music.

Questions we need to answer are: 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? 

The last question relates directly to congestion control in the downlink as congested channels would be able to notify receivers of a change and allow the metadata transfer (push or fetch) to occur at a less congested time in the future (or on a less congested link if multiple links exist between sender and receiver). Thus I think the 4 service cases are all valid, and the two notify subcases are also valid, although any implementation need only implement those which it needs.

> These are logical operations, so SAP would be 
> notification... 

My current thinking is that we need a SAP-like protocol which deals with some of the outstanding problems we have identified with SAPv2 - see below.

> ...where the subscription is done at layer 3 (joining the 
> multicast group).

The use of img_SUBSCRIBE for multicast services (img_PUSH and img_NOTIFY_push) has some advantages over layer 3 joins (i.e. IGMP and MLD). IGMP does not give the server information about multicast participants where as an img_SUBSCRIBE would. This information could be used to customise the img_PUSH and img_NOTIFY so that only relevant multicasts are sent and/or they are spread over logical channels to enable more efficient network routing. (note, spreading over channels also enables less processing overhead in the IP stack of receivers and possibly longer sleep times for battery powered receivers). Additionally, low frequency multicast transmissions to some groups and receiver mobility will cause additional layer 3 signalling which should not be related to the IMG services - i.e. IMG services should not incur congestion control issues which belong to a different layer.

> Depending on whether multicast is available, we then have several 
> protocol choices, with SAP requiring multicast.

Agreed, with SIP requiring unicast :)

Some receivers may have connection to multicast only or more than unicast, so the connectivity (uni/multi-cast and bi/uni-directional) puts the requirement on the protocol. So perhaps "multicast requires something like SAP and unicast requires something like SIP" is the perspective I start from.

We have also identified some short-comings of SAP that it would be necessary to address for IMG transport:
- no reliability (some kind of FEC building block is needed)
- descriptor size limitation - a descriptor (e.g. SDP) must fit in one SAP packet and will be no larger than the MTU or 4kB
- state information needs to be maintained for the SAP "session" as well as the SDP session (this is quite minor relating to SAP ("session") message identifier (hash), but is only useful for encrypted descriptors/payload)
- IMG descriptors need the insertion, expiry, deletion, replacement policy details - not the announcement transport protocols frames (this seems to require that encrypted descriptors must provide a clear text identifier (and version?) or be discarded by hosts without the keys.
- Sender listening to other senders may not be necessary in all environments for bandwidth control. Sender listening when descriptors are encrypted also forces the need for SAP "session" state maintenance as an expiry mechanism must be used without the session time information in SDP.
- Prioritisation and timeliness of some announcements over others is desirable

It is essential that the IMG unidirectional/multicast transport draft does not repeat any of the known short-comings of SAPv2. So it would be very helpful if any other input on the short-comings is given as soon as possible (so the draft doesn't need to correct these later). Does anyone know of additional problems SAPv2 doesn't solve or creates, or solves but are not used (i.e. unused features)?

In summary, I am expressing that the multicast/unidirectional case is as important as the unicast/bi-directional cases. One is not a small plug-in to the other, and many services can be provided over both. This may implementers have a toolbox of services with which to produce the right application for the use cases that they need and ensure that they are compliant with what the IMG framework and related specifications describe.

What do you think?

Cheers, Rod.

-----Original Message-----
From: ext Henning Schulzrinne [mailto:[email-masked]]
Sent: 03 December, 2002 16:13
To: Walsh Rod (NRC/Tampere)
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; Luoma Juha-Pekka
(NRC/Tampere)
Subject: 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

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 09 Dec 2002 09:48:47 -0500

> I agree that it is not necessary or desirable to get tied up in link
> details. It is sufficient that the IMG specifications take account of
> the general environments in which they are used and I expect the
> three kinds of links described (unidirectional, bi-directional and
> hybrid) are sufficient at this level of abstraction. Is there a need
> for any more detail at this stage?

No. I actually believe that only simplex and duplex (or, if you prefer, 
unidirectional/bidirectional). Hybrid is not meaningful. No connection 
is ever perfectly symmetric, including your plain old modem. In many 
cases, the asymmetry is not visible to the end system in any event.

> 
> 
>> 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.
> 
> 
> This is true. The sender would know what kinds of subscribes it has
> (for notify_quiz, notify_push and push; and for p-t-p and p-t-m), and
> may be configured (manually?) to send certain items to certain p-t-m
> channels be default. This should be sufficient to handle each of the
> link cases. Can you see any situations where additional sender
> knowledge would be needed to abstract away the link-layer?

No. That's why I'm arguing that we should only worry about the one-way 
and two-way cases. Bandwidth constraints are a separate issue.

> My use of img_PUSH is to send IMG metadata. The metadata itself can
> contain references to further metadata but this does not effect the
> use of img_PUSH. My use of img_NOTIFY is to inform of events in the
> IMG - i.e. new items, modifications, deletions. The notify may just
> identify the effected part of the IMG, or may also reference the IMG
> metadata which has changed (e.g. 9pmFootball, or
> 9pmFootball_destinationIPaddress). The notify may also include the
> change (i.e. be piggy-backed with a push), but this only makes sense
> for small changes that are not frequent (otherwise bandwidth and
> scalability could be baddly effected).

Again, I don't see a clear boundary here. Updates and full state are 
content functions, not message type functions. I can see SUBSCRIBEing to 
a certain type of program and then get notified when, say, my favorite 
actor is on. As you say, with SAP, you want something more personalized 
than a small set of multicast groups, so you will need a form of 
"subscription" to convey those preferences.

For robustness, my preference is actually to make each update 
self-contained and complete, i.e., while it may contain update data 
(say, a time-shift) in the body, there should be a reference in the 
notification which allows the receiver to retrieve the whole item. This 
is necessary since the state coupling between sender and receiver is 
going to be very loose. It can easily happen that the receiver "forgot" 
earlier announcements for some reason.

Making notifications and announcements mostly references also has the 
advantage that this works well for small devices and for devices where I 
may want to delay retrieving information until more bandwidth becomes 
available (think of a hybrid 3G/802.11 device or a device that's roaming 
into expensive data territory). There is no way that the sender should 
keep track of receiver bandwidth costs and availability.

> We have also identified some short-comings of SAP that it would be
> necessary to address for IMG transport: - no reliability (some kind
> of FEC building block is needed) - descriptor size limitation - a
> descriptor (e.g. SDP) must fit in one SAP packet and will be no
> larger than the MTU or 4kB - state information needs to be maintained
> for the SAP "session" as well as the SDP session (this is quite minor
> relating to SAP ("session") message identifier (hash), but is only
> useful for encrypted descriptors/payload) - IMG descriptors need the
> insertion, expiry, deletion, replacement policy details - not the
> announcement transport protocols frames (this seems to require that
> encrypted descriptors must provide a clear text identifier (and
> version?) or be discarded by hosts without the keys. - Sender
> listening to other senders may not be necessary in all environments
> for bandwidth control. Sender listening when descriptors are
> encrypted also forces the need for SAP "session" state maintenance as
> an expiry mechanism must be used without the session time information
> in SDP. - Prioritisation and timeliness of some announcements over
> others is desirable

I agree with most of these, except the last one. That's a transport 
issue. The problem with large packet size is that you then have to do 
application-layer fragmentation.