Subject: Re: [AVT] I-D Action:draft-lennox-avt-rtp-layered-encoding-timestamps-00.txt

From: [email-masked]
Date: Tue, 10 Jun 2008 10:57:24 +0200

Hi,

I fully agree to the main goal of this draft. Simplicity is a guarantee
of efficiency, notably for IPTV services.  Allowing
a common
timestamp resolve the very important problem of latency to access a
video. This proposal is consistent with the SVC streams, because all
the layers and all the sessions  come from a
single source. So it makes
sense to have the same SSRC and the same TS for all the layers,
particularly since encoding layers use the same clock. Maybe it could be
accurate to precise this draft does not apply to
encoding schemes from multiple independent sources (I heard about
sensor networks).

About security considerations, in my understanding multiple keys may be
a benefit because it allows several quality to the user depending of
its account.

>From another point of view, I understand it is always possible to
multiplex some layers in the same RTP session with the same SSCR and
the same TS, by the different dynamic Payload Types of each layer, as
it is mandatory for SVC streams. This draft brings some
consistency to the multiplexing of part of encoding layers in a same
RTP session, that already share the same TS, as described in
draft-ietf-avt-rtp-svc-10.txt, ch 9.3.2

Regards,

Gérard BABONNEAU

De : [email-masked] [mailto:[email-masked]] De la part de [email-masked]
Envoyé : mardi 3 juin 2008 01:00
À : [email-masked]
Objet : I-D Action:draft-lennox-avt-rtp-layered-encoding-timestamps-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

Title : Real-Time Transport Protocol (RTP) Timestamps for Layered Encodings
Author(s) : J. Lennox, et al.
Filename : draft-lennox-avt-rtp-layered-encoding-timestamps-00.txt
Pages : 8
Date : 2008-06-02

The Real-Time Transport Protocol (RTP) specification defines how layered encodings can be sent over a layered transmission system. A source can stripe the progressive layers of a hierarchically represented signal across multiple RTP sessions, each carried on, for example, its own multicast group. These layered encodings are given special treatment in RTP, notably in that the same synchronization source (SSRC) identifier space is used across the sessions of all layers.
The RTP protocol specification does not, however, explicitly state how RTP timestamps are to be used with layered encodings. This document updates the RTP specification to require that RTP timestamps for layered encodings be synchronized, i.e. that every layer chooses the same random initial value for the timestamp.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-lennox-avt-rtp-layered-encoding-timestamps-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft.

--

BABONNEAU Gerard RD-MAPS-REN

REN/MAPS/DPC

Tel : +33 299124008

Email:
[email-masked]

R&D Rennes 4, rue du Clos-Courtel - BP 91226 - 35512 Cesson-Sevigne
Cedex - France

Mailer ThunderBird sous Mandriva

Installez simplement votre poste de travail Linux avec
http://web2000.rd.francetelecom.fr

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: Colin Perkins <[email-masked]>
Date: Thu, 12 Jun 2008 18:08:19 +0100

Hi,

I have no particular objection to this proposal in itself, but I  
believe that using the same SSRC across multiple layers is  
undesirable, and when different SSRC values are used for each layer,  
this proposal offers no benefit.

While using the same SSRC for each layer is simpler for some case, it  
makes multiplexing several layers onto the same session difficult  
(the suggestion below to demultiplex based on the RTP payload type  
doesn't work). Since managing multiple UDP ports is difficult, I  
would expect that multiplexing several layers onto the same port,  
with media-aware RTP translators dropping layers at network  
boundaries to perform adaptation, to be a common use case, and not  
something we should break.

Colin

On 10 Jun 2008, at 09:57, [email-masked] wrote:
> Hi,
>
> I fully agree to the main goal of this draft. Simplicity is a  
> guarantee of efficiency, notably for IPTV services.  Allowing a  
> common timestamp resolve the very important problem of latency to  
> access a video. This proposal is consistent with the SVC streams,  
> because all the layers and all the sessions  come from a single  
> source. So it makes sense to have the same SSRC and the same TS for  
> all the layers, particularly since encoding layers use the same  
> clock. Maybe it could be accurate to precise this draft does not  
> apply to encoding schemes from multiple independent sources (I  
> heard about sensor networks).
>
> About security considerations, in my understanding multiple keys  
> may be a benefit because it allows several quality to the user  
> depending of its account.
>
> multiplex some layers in the same RTP session with the same SSCR  
> and the same TS, by the different dynamic Payload Types of each  
> layer, as it is mandatory for SVC streams. This draft brings some  
> consistency to the multiplexing of part of encoding layers in a  
> same RTP session, that already share the same TS, as described in  
>> De : [email-masked] [mailto:i-d-announce- 
>> [email-masked]] De la part de [email-masked] Envoyé :  
>> mardi 3 juin 2008 01:00 À : [email-masked] Objet : I-D  
>> Action:draft-lennox-avt-rtp-layered-encoding-timestamps-00.txt A  
>> New Internet-Draft is available from the on-line Internet-Drafts  
>> directories. Title : Real-Time Transport Protocol (RTP) Timestamps  
>> for Layered Encodings Author(s) : J. Lennox, et al. Filename :  
>> draft-lennox-avt-rtp-layered-encoding-timestamps-00.txt  
>> Pages           : 8 Date : 2008-06-02 The Real-Time Transport  
>> Protocol (RTP) specification defines how layered encodings can be  
>> sent over a layered transmission system. A source can stripe the  
>> progressive layers of a hierarchically represented signal across  
>> multiple RTP sessions, each carried on, for example, its own  
>> multicast group. These layered encodings are given special  
>> treatment in RTP, notably in that the same synchronization source  
>> (SSRC) identifier space is used across the sessions of all layers.  
>> The RTP protocol specification does not, however, explicitly state  
>> how RTP timestamps are to be used with layered encodings. This  
>> document updates the RTP specification to require that RTP  
>> timestamps for layered encodings be synchronized, i.e. that every  
>> layer chooses the same random initial value for the timestamp. A  
>> URL for this Internet-Draft is: http://www.ietf.org/internet- 
>> drafts/draft-lennox-avt-rtp-layered-encoding-timestamps-00.txt  
>> Internet-Drafts are also available by anonymous FTP at: ftp:// 
>> ftp.ietf.org/internet-drafts/ Below is the data which will enable  
>> a MIME compliant mail reader implementation to automatically  
>> retrieve the ASCII version of the Internet-Draft.
>
> -- 
> Email: [email-masked]
> Installez simplement votre poste de travail Linux avec http:// 
> web2000.rd.francetelecom.fr
>
>

-- 
Colin Perkins
http://csperkins.org/

---

From: David R Oran <[email-masked]>
Date: Thu, 12 Jun 2008 13:14:02 -0400

> something we should break.
I agree with Colin. I wonder if there might be a way to get the  
desired behavior here by pre-signaling the SSRCs and indicating in the  
SDP that the set of SSRCs of the layers share a media clock and hence  
a timestamp domain, so you can synchronize without relying on the more  
general RTCP mechanisms?

---

From: Colin Perkins <[email-masked]>
Date: Thu, 12 Jun 2008 22:08:10 +0100

On 12 Jun 2008, at 21:42, Randell Jesup wrote:
> David R Oran <[email-masked]> writes:
> (Pre-)Signaling of SSRC values has a problem in that SSRCs are not  
> static -
> a collision can happen at any time.

See draft-ietf-mmusic-sdp-source-attributes-01.txt - there are  
mechanisms to avoid and resolve collisions with signalled SSRCs.

> The simplifying assumption that layers have to share a single  
> timebase, or
> even more simplified, share timestamp values, doesn't have the same  
> sort of
> collision problem that SSRC sharing does.
>
> Since I assume the layers are already known to be linked via the  
> SDP, you
> can make a simplifying assumption for the layers to share TS values  
> and
> timebase (or perhaps more accurately/appropriately, declare this to  
> be the
> case in the SDP).  That means that they're cross-synced, and can be  
> all
> synced to other RTP streams (and to NTP) with a single RTCP for any of
> them.  (And this would apply whether they're on the same port or not.)

Sure.

-- 
Colin Perkins
http://csperkins.org/

---

From: "Jonathan Lennox" <[email-masked]>
Date: Thu, 12 Jun 2008 17:12:51 -0400

> something we should break.

The question is if there's any benefit to multiplexing layers into an
RTP session by placing them in separate RTP streams, as opposed to doing
so in a payload-specific manner within a single stream.  It's certainly
the case that for H.264 SVC, SSRC-based layer multiplexing within a
session was present for a few revisions of the payload draft, but was
dropped for lack of a convincing use case.

The compelling reason for splitting a media stream across multiple RTP
streams is when you actually want different transport-layer behavior for
the streams, for example when the layers are distributed over different
multicast groups.  In this case the streams obviously have to go into
different RTP sessions, and RFC 3550 SSRC-alignment applies.

The case of adaptation at network boundaries is certainly a common use
case, but a media-aware network element can operate (in RTP terminology)
as a mixer, rather than as a translator, and drop layers from within an
RTP stream (fixing up sequence numbers to compensate).  Since it's
media-aware, it necessarily understands the payload format.  This avoids
problems of stream association and SSRC collision, especially if you're
also sending multiple distinct media sources over the session.

-- 
Jonathan Lennox
Vidyo, Inc
[email-masked]