Subject: [avtext] WGLC: draft-ietf-avtext-rid-01.txt

From: Jonathan Lennox <[email-masked]>
Date: Wed, 23 Mar 2016 08:18:40 +0000

This is to announce a 1.5 week Working Group Last Call for

	draft-ietf-avtext-rid-01

as proposed standard.

Please review and provide any comments you may have on the document by Sunday, April 3 (the beginning of the Buenos Aires IETF meeting). Comments should be sent to the document authors and the AVTEXT WG list.

If you review the document but do not have any comments, please send a note to that effect as well.

Thank you!

        Jonathan (AVTEXT co-chair)

---

From: Bo Burman <[email-masked]>
Date: Tue, 29 Mar 2016 15:36:11 +0000

I've reviewed this and have the following comments:

1) In section 3 you use capitalized versions of terms from RFC7656. One of the late changes in the publication process of RFC7656 was to not use capitalized terms, so you might want to align to non-capitalized versions. No strong opinion on that one, though.

2) Would it be correct, semantically, to add the following text at the end of the second paragraph in section 3; "...to refer to this construct of a source RTP stream that originates either from an encoded stream or a dependent stream, but is not a redundancy RTP stream"? If so, I suggest to make that clarification, or otherwise change text in that paragraph to make it clear.

3) To align with a recent update of draft-ietf-avtext-sdes-hdr-ext, IANA registration of RID and RRID in RTP SDES Compact Header Extensions registry should also be added to sections 5.1 and 5.2, respectively, like:

5.1:
...
   It is requested that the following SDES item is registered in the
   RTP SDES Compact Header Extensions registry:

   Extension URI: urn:ietf:params:rtp-hdrext:sdes:rid
   Description:   Source Description: RTP Stream Identifier
                  (SDES RID)
   Contact:       Authors of [RFCXXXX]
   Reference:     [RFCXXXX]

5.2:
...
   It is requested that the following SDES item is registered in the
   RTP SDES Compact Header Extensions registry:

   Extension URI: urn:ietf:params:rtp-hdrext:sdes:rrid
   Description:   Source Description: Redundancy RTP Stream Identifier
                  (SDES RRID)
   Contact:       Authors of [RFCXXXX]
   Reference:     [RFCXXXX]

Cheers,
Bo

> -----Original Message-----
> From: avtext [mailto:[email-masked]] On Behalf Of Jonathan Lennox
> Sent: den 23 mars 2016 09:19
> To: [email-masked]
> Subject: [avtext] WGLC: draft-ietf-avtext-rid-01.txt
> 
> Please review and provide any comments you may have on the document by Sunday, April 3 (the beginning of the
> Buenos Aires IETF meeting). Comments should be sent to the document authors and the AVTEXT WG list.
> 
> _______________________________________________
> avtext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avtext

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 29 Mar 2016 09:25:52 -0700

I have reviewed the document and have the following comment:

Need for RRID.  Currently, draft-ietf-mmusic-rid does not make use of the
RRID.  As I understand it, no WebRTC browsers are currently planning to
implement the RRID.  Furthermore, neither the WebRTC 1.0 API nor ORTC
supports the RRID.

Given this, do we really need to include the RRID in this document?

Minor editorial issues below

On Wed, Mar 23, 2016 at 1:18 AM, Jonathan Lennox <[email-masked]> wrote:

> Please review and provide any comments you may have on the document by
> Sunday, April 3 (the beginning of the Buenos Aires IETF meeting). Comments
> should be sent to the document authors and the AVTEXT WG list.
>

---

From: Colin Perkins <[email-masked]>
Date: Wed, 30 Mar 2016 16:38:53 +0100

> On 23 Mar 2016, at 08:18, Jonathan Lennox <[email-masked]> wrote:
> 

The introduction to this draft still says:

>    To address this situation, we define a new RTCP SDES identifier that
>    uniquely identifies a single stream. 

shortly followed by:

>                                                       when this new
>    identifier is in use, it appears (and contains the same value) in
>    both in the Redundancy RTP Stream as well as the stream it is
>    correcting.

That seems contradictory to me. 

I understand that there’s no consensus to make the RID a unique per-stream identifier, and I’m not asking to revisit that discussion. However, the draft does need to be revised to not claim that the RID uniquely identifies a stream, since it doesn’t in all cases.

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

---

From: Adam Roach <[email-masked]>
Date: Wed, 30 Mar 2016 14:07:44 -0500

On 3/29/16 11:25, Bernard Aboba wrote:
> Need for RRID.  Currently, draft-ietf-mmusic-rid does not make use of 
> the RRID.  As I understand it, no WebRTC browsers are currently 
> planning to implement the RRID.  Furthermore, neither the WebRTC 1.0 
> API nor ORTC supports the RRID.
>

> I understand that there’s no consensus to make the RID a unique per-stream identifier, and I’m not asking to revisit that discussion. However, the draft does need to be revised to not claim that th…

I'm finding this a bit perplexing. RRID provides the means to uniquely 
identify a stream (making the introductory text true). The introductory 
text motivates the inclusion of RRID, and the presence of RRID satisfies 
the goal stated in the introduction.

It seems to me we can proceed in one of two ways:

 1. Strip RRID from the document, thereby eliminating the ability to
    uniquely identify streams, and remove the consequently erroneous
    statement from the introduction, or

 2. Leave RRID in the document, which makes the cited statement in the
    introduction actually true -- effectively, leave the current
    document as-is.

I'd be interested in hearing Bernard and Colin's take on this, and even 
*more* interested in having additional parties weigh in.

/a

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 30 Mar 2016 15:12:32 -0700

Adam said:

"It seems to me we can proceed in one of two ways:

   1. Strip RRID from the document, thereby eliminating the ability to
   uniquely identify streams, and remove the consequently erroneous statement
   from the introduction, or

   2. Leave RRID in the document, which makes the cited statement in the
   introduction actually true -- effectively, leave the current document as-is.

I'd be interested in hearing Bernard and Colin's take on this, and even
*more* interested in having additional parties weigh in."

[BA] I agree with your assessment of the choices.  My only request is that
the document actually reflect what implementers intend to support, in the
absence of the  additional requirements language provided in RFC 6919 which
describes the apparent status of the RRID quite well (but alas is only an
April 1 RFC):

1 <https://tools.ietf.org/html/rfc6919#section-1>.  MUST (BUT WE KNOW YOU WON'T)

   The phrase "MUST (BUT WE KNOW YOU WON'T)" is used to indicate
   requirements that are needed to meet formal review criteria (e.g.,
   mandatory-to-implement security mechanisms), when these mechanisms
   are too inconvenient for implementers to actually implement.

On Wed, Mar 30, 2016 at 12:07 PM, Adam Roach <[email-masked]> wrote:

>    uniquely identify streams, and remove the consequently erroneous statement
>    from the introduction, or
>
>    introduction actually true -- effectively, leave the current document as-is.
>
>

---

From: Adam Roach <[email-masked]>
Date: Wed, 30 Mar 2016 17:15:10 -0500

On 3/30/16 17:12, Bernard Aboba wrote:
> [BA] I agree with your assessment of the choices.  My only request is 
> that the document actually reflect what implementers intend to 
> support, in the absence of the  additional requirements language 
> provided in RFC 6919 which describes the apparent status of the RRID 
> quite well (but alas is only an April 1 RFC):

Ah, I thought it was clear that support for either or both mechanisms is 
completely optional and independent of each other. Would it help to add 
text to that effect?

/a

---

From: Colin Perkins <[email-masked]>
Date: Wed, 30 Mar 2016 23:30:04 +0100

> On 30 Mar 2016, at 20:07, Adam Roach <[email-masked]> wrote:
>> Need for RRID.  Currently, draft-ietf-mmusic-rid does not make use of the RRID.  As I understand it, no WebRTC browsers are currently planning to implement the RRID.  Furthermore, neither the WebRTC 1.0 API nor ORTC supports the RRID.   
>> 
> I'm finding this a bit perplexing. RRID provides the means to uniquely identify a stream (making the introductory text true). The introductory text motivates the inclusion of RRID, and the presence of RRID satisfies the goal stated in the introduction.
> 
> 	• Strip RRID from the document, thereby eliminating the ability to uniquely identify streams, and remove the consequently erroneous statement from the introduction, or
> 
> 	• Leave RRID in the document, which makes the cited statement in the introduction actually true — effectively, leave the current document as-is.

I read the Introduction as saying *both* that the RID has to be unique for each stream, *and* that the RID has to have the same value in the main stream and in the redundant stream. This seems like a contradiction, irrespective of what you do with the RRID. The fix might be as simple as changing “To address this situation, we define a new RTCP SDES identifier that uniquely identifies a single stream” to “…that identifies a stream and any redundant encoding of that stream”.

> I'd be interested in hearing Bernard and Colin's take on this, and even *more* interested in having additional parties weigh in.

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

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 31 Mar 2016 16:30:42 +0200

Hi,

Here are my comments on the draft-ietf-avtext-rid-01. I think it is very 
good that we have an upcoming meeting where we can discuss the below issues.

1. Abstract:

    This document defines and registers an RTCP SDES item, RID, for
    identification of RTP streams associated with Encoded Streams and
    Dependent Streams.

Should this really use plural of RTP streams as well as Encoded Streams. 
A particular RID value is the identifier for one Encoded or Dependent 
Stream in its RTP packetized form plus. Thus I think this abstract could 
be clearer.  However, I think it may need to addressed anyway based on 
comment 3 and 4.

2. Section 1:

RTP sessions frequently consist of multiple streams, each of which is
    identified at any given time by its SSRC; however, the SSRC
    associated with a stream is not guaranteed to be stable over its
    lifetime.  Within a session, these streams can be tagged with a
    number of identifiers, including CNAMEs and MSIDs
    [I-D.ietf-mmusic-msid].  Unfortunately, none of these have the proper
    ordinality to refer to an individual stream; all such identifiers can
    appear in more than one stream at a time.  While approaches that use
    unique Payload Types (PTs) per stream have been used in some
    applications,

I think the usage of Stream should at least on the first usage say "RTP 
Stream" and with a reference to RFC7656 to make it clear what entity you 
are discussing in this paragraph.

3. Section 3:

    For Encoded Streams, the RID refers to the "Source RTP Stream" as
    defined by [RFC7656] Section 2.1.10.  For Dependent Streams, it
    refers to the RTP Stream that, like the Source RTP Stream of an
    Encoded Stream, is the RTP Stream that is not a Redundancy RTP
    Stream.  For conciseness, we define the term "RID RTP Stream" to
    refer to this construct.

I think this definition is not correct. From my perspective it might be 
better to talk about the RTP stream produced by the media packetizer 
from a encoded or set of dependent streams. I write a set of dependent 
stream as on RTP stream can be produced by packetizing multiple 
dependent streams in the same. This would occur if one is not producing 
different RTP streams for all produced scalability layers.

However, the main issue is that the definition does not correctly 
identifies what the RID refers to. To my understanding the RID refers to 
one RTP stream [A] packetized from either one encoded stream and zero or 
more dependent streams, or one or more dependent streams and the one or 
more redundancy streams protecting the RTP stream [A].

This also has the consequence that RID RTP Stream is not a suitable term 
as the RID identifies an possible aggregate of RTP streams, one source 
and zero or more redundancy RTP streams.

The above changed definition could be used, however I am not certain 
that it is what we really like to use here. For that purpose see next 
comment.

4. Section 3:

    For clarity, when RID is used, Redundancy RTP Streams that can be
    used to repair Received RTP Streams will use the same RID value as
    the Received RTP Stream they are intended to be combined with.  If
    applications want to identify individual redundancy streams, they can
    add an RRID to them instead of or in addition to the RID.

So the intention with RRID, is to identify Redundancy RTP streams. 
Considering that RID doesn't actually only represent the source RTP 
stream for the media, there is a mismatch. Also, the needs for RRID is 
also not clear, however, the basics of identifying the RTP stream only 
has the advantage of high likelihood of re-use in other mechanisms.

However, I would like to take a collected consideration of the RID and 
RRID definitions and actually propose that we change the RID definition. 
To be clear on that this is another definition this new identifier I 
will refer to as RTP Stream IDentifier (SID).

The definition of SID would be: "An identifier for a single RTP stream."

This of course have implication on the RID mechanism expressing the 
payload format constraints. However, I think it fulfil the basic needs 
very nicely. The a=rid lines points at a SID for which is the RTP stream 
for which the set of constraints apply.

This is the basic part of the RID proposal. And this removes the need 
for RRID, as also Redundancy RTP streams can have a SID, if needed by 
the application. We get a generic basic identification that is likely to 
be re-usable while solving the current needs.

Some may protest, hey but we are loosing the coupling method between the 
source RTP stream and the Redundancy stream. Yes, I have a proposal 
below for how to resolve that, but at the same time, it is this coupling 
that creates the complicated definition of the RID SDES item. And this 
is actually quite a separate problem. One which has existed for some 
time, and may actually benefit from being taken on a separate work item. 
Especially as we may want to retrofit the outcome onto some existing 
mechanisms such as RTP Retransmission and Generic XOR FEC to enable 
single RTP session usage efficiently for both.

So below is a possible solution if one desire to have a way of coupling 
the redundancy stream to the source RTP stream already in signalling and 
identifying it with the same properties as we get with RID for the 
Source RTP streams.

The solution is simple, we simply have a=RID lines also for the 
Redundancy RTP streams. Then we define a new constraint which I will 
call "protect" which is a list of SIDs that points at one or more RTP 
streams for which this Redundancy RTP Stream is constrained to protect 
and provide redundancy for.

An basic SDP example for this would be the following:

    m=video 10000 RTP/SAVPF 100 101 108 109
    a=rtpmap:100 H264/90000
    a=fmtp:100 profile-level-id=42401f; packetization-mode=0
    a=rtpmap:101 H264/90000
    a=fmtp:101 profile-level-id=42401f; packetization-mode=1
    a=rtpmap:108 rtx/90000
    a=fmtp:108 apt=100
    a=rtpmap:109 rtx/90000
    a=fmtp:109 apt=101
    a=sendrecv
    a=mid:v1 (max resolution)
    a=rid:1 send max-width=1280;max-height=720;max-fps=30
    a=rid:2 recv max-width=1280;max-height=720;max-fps=30
    a=rid:A send pt=108,109;protect=1
    a=rid:B recv pt=108,109;protect=2

So at RTP session startup when the offerer of the above starts sending 
it will send two RTP streams from the above block. One for the video 
using SID=1 and another for the RTX packets using SID=A.

5. Section 4 and 6.

What I am missing in this is a discussion of privacy and the potential 
for tracking the streams across an RTP system. This is usually fine, but 
may reveal things to a third party, thus their value should be protected 
towards third parties.

The next part of this issue is the generation of these values should 
avoid leaking any information about the user and implementation. This 
leads to the question if the values should be using random values, with 
tag lengths as needed by the application.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------