headers
Rod.Walsh | 3 Dec 2002 11:13
Picon

Transport of Internet Media Guides - Work/Service Split

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
(Continue reading)

Permalink | Reply | 2 comments |
headers
Henning Schulzrinne | 3 Dec 2002 15:12

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.

Rod.Walsh <at> nokia.com 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
(Continue reading)

Permalink | Reply | 1 comment |
headers
Magnus Westerlund | 3 Dec 2002 15:46
Picon
Picon

RTSP Teleconference 11 December

Hi,

It is time to resume the RTSP teleconferences. We have not had one since 
12th of June. But now a significantly updated version of draft exist we 
can continue to make progress. All RTSP interested are welcome to 
participate. If you want to participate please send me a mail and I will 
send you the contact information.

The teleconference will be the December 11, 2002 at 18.00 CET, equal to 
9.00 AM PST. It will last 90 minutes.

Participants are assumed to be knowledgeable about the the latest draft 
version:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc2326bis-02.txt

Also the currently reported bugs are available at:
http://rtspspec.sourceforge.net

Proposed Meeting Agenda
-----------------------
1. Opening of meeting
2. Way forward
   2.1 Intention of work: Get RTSP to draft standard
   2.2 Method: Divide and conquer. Write a base spec for basic playback 
and anything not basic shall be written as extensions.
   2.3 Extensions?
   2.4 Review of the draft
   2.5 Interoperability tests
3. Issues (As many as we have time for):
   3.1 - RTSP URL is case sensitive: http://rtsp.org/bug644626
(Continue reading)

Permalink | Reply | 0 comments |
headers
rtspspec-bugs-request | 3 Dec 2002 21:13
Picon

Rtspspec-bugs digest, Vol 1 #67 - 1 msg


This is an automatic digest of bugs submitted and changed on the RTSP bug tracker.  To see a list of bugs, visit:

http://sf.net/projects/rtspspec

When replying, please make your Subject line more specific than "Re: Rtspspec-bugs digest"

Today's Topics:

   1. [ rtspspec-Bugs-647838 ] Warning header (noreply <at> sourceforge.net)

--__--__--

Message: 1
To: noreply <at> sourceforge.net
From: noreply <at> sourceforge.net
Date: Tue, 03 Dec 2002 06:27:40 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-647838 ] Warning header

Bugs item #647838, was opened at 2002-12-03 15:27
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=647838&group_id=23194

Category: General
Group: Fix for DS - Need WG Input
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Rob Lanphier (robla)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Yuji Nomura | 4 Dec 2002 13:13
Picon

Re: 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" <hgs <at> cs.columbia.edu>
To: <Rod.Walsh <at> nokia.com>
Cc: <mmusic <at> ietf.org>; <csp <at> isi.edu>; <jo <at> tzi.uni-bremen.de>; <nom <at> flab.fujitsu.co.jp>; <schulzrinne <at> cs.columbia.edu>;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Teodora Guenkova-Luy | 4 Dec 2002 14:14
Picon

Contunuing the discussion on QoS within SDPng

Dear MMUSIC Folks,

For quite some time we published the draft 
"draft-guenkova-mmusic-e2enp-sdpng-00" with requirements about quality 
of service (QoS) negotiation protocol as an SDPng enhancement.
Alas, up to now we did not manage to come up with a specification draft 
for the End-to-End Negotiation Protocol (E2ENP) for QoS. Nevertheless, 
we already produced some detailed results in this direction within the 
scope of the IST-MIND Project. These results consider the current state 
of the MMUSIC discussion on QoS for SDPng. The major idea behind these 
results is the consideration of both transport level and application 
level QoS and the possibility to appropriately associate them and 
formally describe them in a form of an SDPng extension.

The documentation (IST-MIND Deliverable 1.2) is available under:

http://www.ist-mind.org/deliverables.htm

(the Adobe Icon under "Deliverable 1.2 Top-level architecture for 
providing seamless QoS, security, accounting and mobility to 
applications and services")

or under:

http://www.dit.upm.es/~ist-mind/deliverables/MIND_D12.pdf 
<http://www.dit.upm.es/%7Eist-mind/deliverables/MIND_D12.pdf>

The mentioned results are the Annex A of this deliverable.

We would like to encourage all the interested parties to take a look at
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gonzalo Camarillo | 4 Dec 2002 16:26
Picon
Picon

Streaming media

Hi,

I kind of remember that some time ago there was a proposal about an SDP
attribute to indicate that the receiver could use long buffers to
receive the media. I believe it dealt with tones, mainly.

I was thinking that if we establish a session using SIP that will carry
streaming media, we may want to tell the other end that it can buffer
this stream.

What is the status of that work? was there any interest in the group?

Thanks,

Gonzalo
Permalink | Reply | 6 comments |
headers
Flemming Andreasen | 8 Dec 2002 00:44
Picon
Favicon

Re: Streaming media


Gonzalo Camarillo wrote:

> Hi,
>
> I kind of remember that some time ago there was a proposal about an SDP
> attribute to indicate that the receiver could use long buffers to
> receive the media. I believe it dealt with tones, mainly.
>

Right (sort of). The basic discussion was support of fax and modem calls
and we've had a couple of different drafts on this topic (starting in
London 2001), with the latest one being
<draft-rajeshkumar-mmusic-gpmd-01.txt>. The approach taken has been to
associate optional attributes with a particular payload type in order to
indicate certain characeteristics about the media that the receiver may
benefit from knowing. For example, the gpmd draft defines a "voice band
data" attribute to indicate that the media is voice-band data. However, we
would not try and specify implementation specific ways of dealing with
"voice-band data" such as use of long buffers or other.

>
> I was thinking that if we establish a session using SIP that will carry
> streaming media, we may want to tell the other end that it can buffer
> this stream.
>

I believe the gpmd framework could be used for this, but in a slightly
different way. Rather than specifying that "media can be buffered" we would
have a more generic attribute that defines the media as "streaming" and
(Continue reading)

Permalink | Reply | 5 comments |
headers
Rod.Walsh | 9 Dec 2002 13:55
Picon

RE: Transport of Internet Media Guides - Work/Service Split

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
(Continue reading)

Permalink | Reply | 1 comment |
headers
Rod.Walsh | 9 Dec 2002 14:14
Picon

RE: Re: Transport of Internet Media Guides - Work/Service Split

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].
(Continue reading)

Permalink | Reply | 0 comments |

Gmane