Subject: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-rtp-usage-24: (with COMMENT)

From: "Ben Campbell" <[email-masked]>
Date: Mon, 08 Jun 2015 20:04:08 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-rtcweb-rtp-usage-24: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Edit: Meta-Comment: The notify field for this draft seems sparse.

I found this in general to be informative and well written, given the
rather large scope of information. I do have a few comments/questions:

Substantive:

-- 4.9: The discussion of RTCPeerConnection in this section seems to need
a normative reference to [W3C.WD-webrtc-20130910] (or a local
explanation, if there are issues normatively referencing that doc.)

-- 5.1: This section seems to need a normative reference to
topologies-update. There is normative language here to the effect of
“Don’t do these things” where it seems like one needs to read that doc to
understand what the “things” mean.

-- 7.1, first paragraph: "applications MUST also implement congestion
control to
   allow them to adapt to changes in network capacity."
   
   Is that the aformentioned not-yet-standardized congestion control
algorithm, or something else? 
   
-- 11, 2nd paragraph from end:

It seems like the msid reference should be normative.

-- 12.1.3:

seems like a mention of draft-ietf-dart-dscp-rtp might be in order now.
IIRC, when I did a gen-art review on a much older version, the thought
was that if draft-ietf-dart-dscp-rtp was far enough along when it was
time to publish this draft, it would make sense to add a mention. It's in
the RFC editor queue now, in MISSREF on a dependency that I think this
draft shares.

-- 13: 3rd paragraph:

Isn't that security solution MTU as well as MTI? If so, it might be worth
mentioning it here.
   
Editorial:

-- 11, paragraph 3: "...can be feeding multiple..."

Consider "... can feed multiple ..."

paragraph 4: "This is motivating the discussion..."

consider "This motivates the discussion..."  (or possibly "motivated")

paragraph 5: "... each of different MediaStreamTracks ..."

missing "the"

paragraph 6: "... relay/forward ..."

consider "... relay or forward ..."

-- 12.1, last sentence "... ways in which WebRTC Endpoints can configure
and use
   RTP sessions is outlined."
   
s/is/are

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 9 Jun 2015 10:51:10 +0200

Hi Ben,

Thanks for the review, some inline comments. Will address these after 
Thursday when we know the rest of IESGs views.

> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/

Do I understand that you want a reference in the second paragraph at the 
mentioning of RTCPeerConnection? As it is reference in the previous 
paragraph, I assumed that people would not be confused on what we talk 
about.

I guess the second issue is that the reference is classified as 
informative and should be normative. Changing the classification is 
simple, it will however create a need to ensure that the publication of 
this document is held until the W3C document reaches Recommendation 
status if I understand the rules and recommendations correctly.

> understand what the “things” mean.

I do understand the reasoning behind your comment. I personally do not 
agree the need for using normative references for documents that import 
a term for a concept. We already had this discussion around the 
topologies document's status.

I have no issue with reclassifying the reference, but I do note that we 
will have to re-run the IETF last call as this will now be a down-ref.

> algorithm, or something else?

As we have no standardized congestion control yet, we can't point to 
anything. But, an implementation must implement something, even if 
completely proprietary.

> It seems like the msid reference should be normative.

Our intention was to keep this informative. Therefore the chosen style 
of writing that sentence. The actual normative inclusion of MSID into 
the WebRTC solution is done by JSEP.

The TSVWG document referenced do normatively reference the DART 
document. But, we could include the DART document in the same sentence 
as the TSVWG document.

> Isn't that security solution MTU as well as MTI? If so, it might be worth

You mean Mandatory to Use, not Maximum Transmission Unit, don't you? 
Yes, it is mandatory to use, we can make that clear.

Will deal with the editorials
>     RTP sessions is outlined."

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

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 09 Jun 2015 09:32:06 -0500

> Thursday when we know the rest of IESGs views.

Thanks for the response. Comments inline.

[...]

> Do I understand that you want a reference in the second paragraph at 
> the mentioning of RTCPeerConnection? As it is reference in the 
> previous paragraph, I assumed that people would not be confused on 
> what we talk about.
>

I'm okay with the reference where it is--my comment was more about 
normativity (see comment to next paragraph)

> simple, it will however create a need to ensure that the publication 
> of this document is held until the W3C document reaches Recommendation 

I think the reader will at least need a high level understanding of the 
meaning of RTCPeerConnection to implement the normative requirements in 
this section. If the W3C doc is not going to be sufficiently mature in 
the immediate future, it might be good enough to put a couple of 
sentences in this doc about the meaning of RTCPeerConnection. (The full 
interface spec is probably not needed.)

> agree the need for using normative references for documents that 
> import a term for a concept. We already had this discussion around the 

(I'm not sure if you meant "do _not_ understand", but I expected you to 
disagree :-)  )

I realize there is not universal agreement on whether BCP 97 applies to 
terminology. I think it can in some cases. But in this case, I think we 
are going beyond just terminology. The topology doc describes structure 
and behavior associated with each topology. I assume it is informational 
because it is descriptive rather than prescriptive.

>
> I have no issue with reclassifying the reference, but I do note that 
> we will have to re-run the IETF last call as this will now be a 
> down-ref.

Yes, that is an issue. You will note I made this a comment, not a 
discuss :-)  I will leave it up to you guys and Alissa to decide if this 
is needed badly enough to go through another LC. (For the record, 
there's some work going on to update 97 to allow more discretion around 
this sort of thing without triggering pointlessly repeated last calls.)

> anything. But, an implementation must implement something, even if 

It would be helpful to either clarify the "even if proprietary" part, or 
perhaps move this sentence closer to the bit about no standardized 
mechanism. (But this is not a show stopper.)

> the WebRTC solution is done by JSEP.

Okay. It might be helpful, but not required, to state this sentence in 
the form of "[jsep] specifies that..."

> document. But, we could include the DART document in the same sentence 

I'm okay leaving it to the deeper conversation in the TSVWG doc. I 
mainly mentioned it because I had thought the intent was to add the 
mention here if the dart draft was sufficiently far along in the process 
when this draft was submitted.

> Yes, it is mandatory to use, we can make that clear.

Yes, mandatory to use. :-)

[...]

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 11 Jun 2015 14:04:25 +0200

Hi,

Inline

> interface spec is probably not needed.)

I think might have to up level this discussion a bit. We always know 
that we where going to need to put in normative references somewhere 
between the IETF RFCs and the W3C WebRTC specifications. I think it is 
time we realize the implications of that. And I think this document, 
JSEP, and Overview at least are going to need to have correct references 
to the W3C specifications. Thus, I would suggest that we convert them to 
normative references and then let them hang in missref until the are 
ready to publish. The W3C WebRTC spec currently have a lot of normative 
references to drafts in the rtcweb wg, including this. So RFC-editor and 
W3C equivalent will need to have a coordination step.

My suggestion is that we do change the W3C references to normative.

> (I'm not sure if you meant "do _not_ understand", but I expected you to

I actually mean I do understand some of the thinking, I simply think it 
is flawed and has downsides making me have another view on what is to be 
considered normative references.

> because it is descriptive rather than prescriptive.

I will agree with you that the topology will be used in such way that it 
is often normative.

>> we will have to re-run the IETF last call as this will now be a down-ref.
>

Lets get the downref last call out of the way as soon as we have updated 
the draft. That way the WG (and rest of IETF) will have two weeks to 
review the changes.

> mechanism. (But this is not a show stopper.)

Ok,

I propose that we add this sentence: "The congestion control algorithm 
will have to be proprietary until a standardized congestion control 
algorithm is available." into the first paragraph in 7.1:

    WebRTC Endpoints MUST implement the RTP circuit breaker algorithm
    that is described in [I-D.ietf-avtcore-rtp-circuit-breakers].  The
    RTP circuit breaker is designed to enable applications to recognise
    and react to situations of extreme network congestion.  However,
    since the RTP circuit breaker might not be triggered until congestion
    becomes extreme, it cannot be considered a substitute for congestion
    control, and applications MUST also implement congestion control to
    allow them to adapt to changes in network capacity.  The congestion
    control algorithm will have to be proprietary until a standardized
    congestion control algorithm is available.  Any future RTP congestion
    control algorithms are expected to operate within the envelope
    allowed by the circuit breaker.

Does this satisfies your concerns?

> the form of "[jsep] specifies that..."

So what you want is that paragraph to read more like this?

    Javascript Session Establishment Protocol [I-D.ietf-rtcweb-jsep]
    specifies that the binding between the WebRTC MediaStreams,
    MediaStreamTracks and the SSRC is done as specified in "Cross Session
    Stream Identification in the Session Description Protocol"
    [I-D.ietf-mmusic-msid].  The MSID document [I-D.ietf-mmusic-msid]
    also defines, in section 4.1, how to map unknown source packet stream
    SSRCs to MediaStreamTracks and MediaStreams.

> when this draft was submitted.

Actually, I think I found a simple way of referencing it, and it is 
relevant in that discussion. So the sentence is proposed to read:

     However, depending on the QoS
    mechanism and what markings that are applied, this can result in not
    only different packet drop probabilities but also packet reordering,
    see [I-D.ietf-tsvwg-rtcweb-qos] and [I-D.ietf-dart-dscp-rtp] for
    further discussion.

> Yes, mandatory to use. :-)

So text proposed to be changed to.

    A mandatory to implement and use
    media security solution is created by combining this secured RTP
    profile and DTLS-SRTP keying [RFC5764] as defined by Section 5.5 of
    [I-D.ietf-rtcweb-security-arch].

Cheers

Magnus Westerlund

---

From: "Ben Campbell" <[email-masked]>
Date: Fri, 12 Jun 2015 16:00:10 -0500

Hi,

Comments inline. I removed parts that do not seem to need further 
discussion.

On 11 Jun 2015, at 7:04, Magnus Westerlund wrote:

[...]
> Does this satisfies your concerns?

Yes, thanks.

> SSRCs to MediaStreamTracks and MediaStreams.

Yes, I think that helps.

[...]

> see [I-D.ietf-tsvwg-rtcweb-qos] and [I-D.ietf-dart-dscp-rtp] for

That works for me.

> [I-D.ietf-rtcweb-security-arch].

That works for me.

Thanks!

Ben.