Subject: Re: [tsvwg] Last Call: <draft-ietf-tsvwg-rtcweb-qos-15.txt> (DSCP and other packet markings for WebRTC QoS) to Proposed Standard

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 03 May 2016 03:17:38 +0000

As I understand, we need this addition:

         Currently in WebRTC, media sent over RTP is assumed to be
         interactive <xref target="I-D.ietf-rtcweb-rtp-usage"/>
         while media streamed over HTTP <xref target="RFC7230"/>
         <xref target="RFC7540"/> is assumed not to be.  Future WebRTC
         extensions could allow streamed, non-interactive media over RTP.

I modified is slightly by adding "non-interactive" near the end and 
inserting a reference near "interactive", though this is perhaps a 
redundant reference since it appears elsewhere in the draft.

That RTP usage reference does not speak to HTTP, so I don't have a 
reference to "prove" that sentence above.  Is there a better reference?

Paul

------ Original Message ------
From: "Magnus Westerlund" <[email-masked]>
To: "Black, David" <[email-masked]>; "Cullen Jennings" 
<[email-masked]>
Cc: "[email-masked]" <[email-masked]>; "[email-masked]" 
<[email-masked]>; "[email-masked]" 
<[email-masked]>; "[email-masked]" 
<[email-masked]>
Sent: 4/19/2016 4:46:53 AM
Subject: Re: [tsvwg] Last Call: <draft-ietf-tsvwg-rtcweb-qos-15.txt> 
(DSCP and other packet markings for WebRTC QoS) to Proposed Standard

>Den 2016-04-18 kl. 15:04, skrev Black, David:
>>So, summarizing Magnus's concerns with proposals:
>>
>>>>[1] Flow Type in application-facing browser API:
>>
>>>>Propose an additional sentence:
>>>>OLD
>>>>    o  Flow Type: The browser provides this input as it knows if the 
>>>>flow
>>>>       is audio, interactive video with or without audio, 
>>>>non-interactive
>>>>       video with or without audio, or data.
>>>>NEW
>>>>    o  Flow Type: The browser provides this input as it knows if the 
>>>>flow
>>>>       is audio, interactive video with or without audio, 
>>>>non-interactive
>>>>       video with or without audio, or data.  For audio that is 
>>>>associated
>>>>       with a video flow, the flow type of the associated video MAY
>>>>       be used instead of the associated audio type.
>>
>>Magnus - does that new text suffice?
>
>Yes.
>
>>
>>>>[2] What does "interactive" mean in an implementation?:
>>>
>>>We could add something along lines of ..... Currently in WebRTC, 
>>>media sent over
>>>RTP is assumed to be interactive while media streamed over HTTP is 
>>>assumed not
>>>to be. Future WebRTC extensions could allow streamed media over RTP.
>>
>>I believe the proposed additional sentence addresses the question of 
>>how a browser
>>determines whether a video flow is interactive.  This proposed 
>>sentence will need to
>>cite a WebRTC document that contains a statement to that effect, as I 
>>don't think this
>>draft is the right place to be the primary reference for that 
>>statement.
>>
>>Magnus - would this approach be ok?
>
>Yes.
>
>/Magnus
>
>>
>>Thanks, --David
>>
>>>-----Original Message-----
>>>From: Cullen Jennings [mailto:[email-masked]]
>>>Sent: Friday, April 15, 2016 10:48 AM
>>>To: Black, David
>>>Cc: Magnus Westerlund; [email-masked]; [email-masked]; 
>>>draft-ietf-tsvwg-
>>>[email-masked]; [email-masked]
>>>Subject: Re: [tsvwg] Last Call: <draft-ietf-tsvwg-rtcweb-qos-15.txt> 
>>>(DSCP and
>>>other packet markings for WebRTC QoS) to Proposed Standard
>>>
>>>
>>>>On Apr 3, 2016, at 3:37 PM, Black, David <[email-masked]> 
>>>>wrote:
>>>>
>>>>I see a couple of Magnus's points that appear to need additional 
>>>>text
>>>>in the draft:
>>>>
>>>>[1] Flow Type in application-facing browser API:
>>>>
>>>>>>>>>o Flow Type: The browser provides this input as it knows if
>>>>>>>>>the flow is audio, interactive video with or without audio,
>>>>>>>>>non-interactive video with or without audio, or data.
>>>>
>>>>[... snip ...]
>>>>
>>>>>The main issue here is that to me it was not clear that 
>>>>>"Interactive
>>>>>Video with or without audio" allows for setting these DSCP values 
>>>>>also
>>>>>for the RTP stream containing audio also. This, I do see a need for
>>>>>clarification on.
>>>>
>>>>Propose an additional sentence:
>>>>OLD
>>>>    o  Flow Type: The browser provides this input as it knows if the 
>>>>flow
>>>>       is audio, interactive video with or without audio, 
>>>>non-interactive
>>>>       video with or without audio, or data.
>>>>NEW
>>>>    o  Flow Type: The browser provides this input as it knows if the 
>>>>flow
>>>>       is audio, interactive video with or without audio, 
>>>>non-interactive
>>>>       video with or without audio, or data.  For audio that is 
>>>>associated
>>>>       with a video flow, the flow type of the associated video MAY
>>>>       be used instead of the associated audio type.
>>>>
>>>>I hesitate to say anything stronger than "MAY" here.
>>>
>>>Looks good.
>>>
>>>>
>>>>[2] What does "interactive" mean in an implementation?:
>>>
>>>We could add something along lines of ..... Currently in WebRTC, 
>>>media sent over
>>>RTP is assumed to be interactive while media streamed over HTTP is 
>>>assumed not
>>>to be. Future WebRTC extensions could allow streamed media over RTP.
>>>
>>>
>>>>
>>>>>The issue is that this document is called: DSCP and other packet
>>>>>markings for WebRTC QoS. Then this document define something that 
>>>>>is not
>>>>>immediately mappable onto what is being defined in the other WebRTC
>>>>>specifications. That is why I am raising that there need to be more
>>>>>clear coupling. If that coupling is to mostly happen in another
>>>>>document, can we at least then have a proposal on the table for 
>>>>>that
>>>>>change to ensure that the result is understandable.
>>>>
>>>>Well, this TSVWG draft is definitely not the right place for a 
>>>>discussion of
>>>>when a video flow is interactive or non-interactive - I hope we can 
>>>>agree
>>>>on that.
>>>>
>>>>Beyond that, as Cullen (Jennings) is both an author of this document 
>>>>and
>>>>one of the chairs of the rtcweb WG, I'd suggest that he and/or the 
>>>>rtcweb
>>>>WG propose an appropriate location for discussion of when a video 
>>>>flow
>>>>is interactive or non-interactive.  This TSVWG draft would then have 
>>>>an
>>>>additional sentence added, e.g.,
>>>>
>>>>  See [TBD] for further discussion of how to determine
>>>>  whether a video flow is interactive vs. non-interactive.
>>>>
>>>>I believe that the added reference here ([TBD] above) would be 
>>>>normative.
>>>>
>>>>Cullen?
>>>
>>>That discussion happened long ago for WebRTC and we decided we did 
>>>not need
>>>a JavaScript controls point in the WebRTC API to indicate if RTP was 
>>>interactive or
>>>not. If people start doing streaming video over RTP we can come back 
>>>and revisit
>>>this and trivially add an API to indicate that in the W3C WebRTC API. 
>>>Part of what
>>>drove this decision is the likes of Netflix / ITunes / Youtube are 
>>>not asking the
>>>browser vendors for streaming media over RTSP or RTP. They think HTTP 
>>>works
>>>much better for this. Thus the browser vendors see no need for non 
>>>interactive
>>>video over RTP. I agree with Magnus that this might change some day 
>>>in the
>>>future but right now, I think it's close enough that everyone can 
>>>live with it.
>>>
>>>I'm not OK in treating it like some open issue that is still in 
>>>discussion that
>>>somehow holds up this spec - it's not.
>>>
>>>>
>>>>Thanks, --David (as document  shepherd)
>>>>
>>
>>
>
>
>--
>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: "Black, David" <[email-masked]>
Date: Tue, 3 May 2016 15:29:15 +0000

Paul,

> redundant reference since it appears elsewhere in the draft.

That's item [2], please make sure that item [1] is also covered.

> reference to "prove" that sentence above.  Is there a better reference?

With careful reading, one can discern that the Web RTC RTP usage draft
(draft-ietf-rtcweb-rtp-usage) implies that all Web RTC usage is interactive,
but some subtlety is involved.  IMHO, relying on implementers to grasp
that sort of "do what I mean" rationale is problematic.

Cullen - would you be amenable to drafting a blunt RFC Editor note
for the RTP usage draft to state that all current Web RTC RTP usage is
for interactive media, and non-interactive Web RTC media flows currently
use HTTP (and would that be HTTP over the Web RTC data channel or
something else)?

Obviously, the rtcweb WG will have to sign off on that RFC Editor note,
but this looks like a relatively short path to addressing the problem.

Thanks, --David (as draft shepherd)

> From: Paul E. Jones [mailto:[email-masked]]
> Sent: Monday, May 02, 2016 10:18 PM
> To: Magnus Westerlund; Black, David; Cullen Jennings
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [tsvwg] Last Call: <draft-ietf-tsvwg-rtcweb-qos-15.txt> (DSCP and

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 03 May 2016 11:44:27 -0400

David,

The text you proposed for the flow type I incorporated. Since everyone agreed with the language, I didn't present it here.

I'll wait for Cullen's reply on the note.

As a process question, where does that note go and why would it be a note for the RFC editor vs. language for readers? Or an I misinterpreting the intent?

Paul

-------- Original Message --------
From: "Black, David" <[email-masked]>
Sent: May 3, 2016 11:29:15 AM EDT
To: "Paul E. Jones" <[email-masked]>, Magnus Westerlund <[email-masked]>, Cullen Jennings <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "Black, David" <[email-masked]>
Subject: RE: [tsvwg] Last Call: <draft-ietf-tsvwg-rtcweb-qos-15.txt> (DSCP and other packet markings for WebRTC QoS) to Proposed Standard

Paul,

---

From: Ted Hardie <[email-masked]>
Date: Tue, 3 May 2016 09:20:04 -0700

On Tue, May 3, 2016 at 8:29 AM, Black, David <[email-masked]> wrote:

> for interactive media,

If you stop here, I personally think it is fine.

> and non-interactive Web RTC media flows currently

I'm not so happy adding a description of where other media travels.  That's
going to be
app-specific, and since saying "we don't know this" in the document does
not help
implementers, I'd personally rather leave it out.

> but this looks like a relatively short path to addressing the problem.
Do you want to summarize the issue to the wg now, or wait until there is a
candidate RFC editor note?

Ted

---

From: "Black, David" <[email-masked]>
Date: Tue, 3 May 2016 16:21:25 +0000

> As a process question, where does that note go and why would it be a note for the RFC editor vs. language for readers?

The note will go into the datatracker because the Web RTC RTP usage draft (draft-ietf-rtcweb-rtp-usage) is in the RFC Editor Queue:
                https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/
Sorry for not mentioning that draft status in my earlier email.

One of the ART ADs would submit the RFC Editor Note, after Cullen and the rtcweb WG come up with its text, including figuring out where in the RTP usage draft to insert these statements.

Thanks, --David

From: Paul E. Jones [mailto:[email-masked]]
Sent: Tuesday, May 03, 2016 10:44 AM
To: Black, David; Magnus Westerlund; Cullen Jennings
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [tsvwg] Last Call: <draft-ietf-tsvwg-rtcweb-qos-15.txt> (DSCP and other packet markings for WebRTC QoS) to Proposed Standard

David,

Paul
________________________________
From: "Black, David" <[email-masked]<mailto:[email-masked]>>
Sent: May 3, 2016 11:29:15 AM EDT
To: "Paul E. Jones" <[email-masked]<mailto:[email-masked]>>, Magnus Westerlund <[email-masked]<mailto:[email-masked]>>, Cullen Jennings <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Black, David" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [tsvwg] Last Call: <draft-ietf-tsvwg-rtcweb-qos-15.txt> (DSCP and other packet markings for WebRTC QoS) to Proposed Standard

Paul,

Thanks,

--David (as draft shepherd)

 -----Original Message-----
 From: Paul E. Jones [mailto:[email-masked]]
 Sent: Monday, May 02, 2016 10:18 PM
 To: Magnus Westerlund; Black, David; Cullen Jennings
 Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
 [email-masked]<mailto:[email-masked]>
 Subject: Re: [tsvwg] Last Call: <draft-ietf-tsvwg-rtcweb-qos-15.txt> (DSCP and
 other packet markings for WebRTC QoS) to Proposed Standard

 Paul

 ------ Original Message ------
 From: "Magnus Westerlund" <[email-masked]<mailto:[email-masked]>>
 To: "Black, David" <[email-masked]<mailto:[email-masked]>>; "Cullen Jennings"
 <[email-masked]<mailto:[email-masked]>>
 Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>"
 <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>"
 <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>"
 <[email-masked]<mailto:[email-masked]>>
 Sent: 4/19/2016 4:46:53 AM
 Subject: Re: [tsvwg] Last !

 Call:

<draft-ietf-tsvwg-rtcweb-qos-15.txt>
 (DSCP and other packet markings for WebRTC QoS) to Proposed Standard

Yes.

Yes.

/Magnus

Thanks, --David

-----Original Message-----
From: Cullen Jennings [mailto:[email-masked]]
Sent: Friday, April 15, 2016 10:48 AM
To: Black, David
Cc: Magnus Westerlund; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
draft-ietf-tsvwg-
[email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [tsvwg] Last Call: <draft-ietf-tsvwg-rtcweb-qos-15.txt>
(DSCP and
other packet markings for WebRTC QoS) to Proposed Standard

On Apr 3, 2016, at 3:37 PM, Black, David <[email-masked]<mailto:[email-masked]>>
wrote:

I see a couple of Magnus's points that appear to need additi!

 onal
text
in the draft:

[... snip ...]

       be used instead of the as!

 sociated

audio type.

Looks good.

imme!

 diately

mappable onto what is being defined in the other WebRTC

  whet!

 her a

video flow is interactive vs. non-interactive.

Cullen?

I'm

not OK in treating it like some open issue that is still in
discussion that
somehow holds up this spec - it's not.

--
Magnus Westerlund

________________________________

________________________________

Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]<mailto:[email-masked]>

________________________________

---

From: "Black, David" <[email-masked]>
Date: Tue, 3 May 2016 16:38:08 +0000

Ted,

Thanks for expressing concerns ... I have an alternative suggestion:

> I'm not so happy adding a description of where other media travels.

Thinking out loud - what if we put the text to cover both interactive media usage
of RTP and non-interactive media usage of something else into the Web RTC transports
draft (https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/)?

That draft has the requisite broader scope, and it’s even not at the RFC Editor(!).

> I'm not so happy adding a description of where other media travels.  That's going
> to be app-specific, and since saying "we don't know this" in the document does not
> help implementers, I'd personally rather leave it out.

Would it be reasonable (in the transports draft) to say that
                - interactive video uses RTP and
                - non-interactive video does not use RTP?

That’s close to the minimum language that’s needed to close out the original issue
in this draft (tsvwg-rtcweb-qos), namely that implementers need a clearly specified
means of determining whether video is interactive vs. non-interactive.

Thanks, --David

From: Ted Hardie [mailto:[email-masked]]
Sent: Tuesday, May 03, 2016 11:20 AM
To: Black, David
Cc: Paul E. Jones; Magnus Westerlund; Cullen Jennings; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [tsvwg] Last Call: <draft-ietf-tsvwg-rtcweb-qos-15.txt> (DSCP and other packet markings for WebRTC QoS) to Proposed Standard

On Tue, May 3, 2016 at 8:29 AM, Black, David <[email-masked]<mailto:[email-masked]>> wrote:
Paul,

I'm not so happy adding a description of where other media travels.  That's going to be
app-specific, and since saying "we don't know this" in the document does not help
implementers, I'd personally rather leave it out.

> From: Paul E. Jones [mailto:[email-masked]<mailto:[email-masked]>]
> >>>From: Cullen Jennings [mailto:[email-masked]<mailto:[email-masked]>]
> >Ericsson AB                 | Phone  +46 10 7148287<tel:%2B46%2010%207148287>
> >Färögatan 6                 | Mobile +46 73 0949079<tel:%2B46%2073%200949079>

---

From: Ted Hardie <[email-masked]>
Date: Tue, 3 May 2016 09:54:31 -0700

On Tue, May 3, 2016 at 9:38 AM, Black, David <[email-masked]> wrote:

> That's going
I think that's likely to work.  If it doesn't, because there are apps which
are planning to use
RTP for game fill media or similar, then we need an API surface to indicate
the different uses.
That solves the problem in a more general way.

regards,

Ｔed

> *From:* Ted Hardie [mailto:[email-masked]]
> *Sent:* Tuesday, May 03, 2016 11:20 AM
> *To:* Black, David
> *Cc:* Paul E. Jones; Magnus Westerlund; Cullen Jennings; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
>
> *Subject:* Re: [tsvwg] Last Call: <draft-ietf-tsvwg-rtcweb-qos-15.txt>
> That's going to be

---

From: "Black, David" <[email-masked]>
Date: Tue, 3 May 2016 18:47:55 +0000

> I think that's likely to work.  If it doesn't, because there are apps which are planning to use
> RTP for game fill media or similar, then we need an API surface to indicate the different uses.
Good - I’ll write up some text with a suggested location in the Web RTC transports draft and send it to the rtcweb WG mailing list in the next few days.

Thanks, --David

From: Ted Hardie [mailto:[email-masked]]
Sent: Tuesday, May 03, 2016 11:55 AM
To: Black, David
Cc: Paul E. Jones; Magnus Westerlund; Cullen Jennings; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [tsvwg] Last Call: <draft-ietf-tsvwg-rtcweb-qos-15.txt> (DSCP and other packet markings for WebRTC QoS) to Proposed Standard

On Tue, May 3, 2016 at 9:38 AM, Black, David <[email-masked]<mailto:[email-masked]>> wrote:
Ted,

I think that's likely to work.  If it doesn't, because there are apps which are planning to use
RTP for game fill media or similar, then we need an API surface to indicate the different uses.
That solves the problem in a more general way.
regards,

Ｔed

Thanks, --David

From: Ted Hardie [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, May 03, 2016 11:20 AM
To: Black, David
Cc: Paul E. Jones; Magnus Westerlund; Cullen Jennings; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

---

From: Colin Perkins <[email-masked]>
Date: Tue, 3 May 2016 19:23:22 +0100

> On 3 May 2016, at 17:38, Black, David <[email-masked]> wrote:
> 
> Ted,
>  
> Thinking out loud - what if we put the text to cover both interactive media usage of RTP and non-interactive media usage of something else into the Web RTC transports draft (https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/)?
>  

I tend to think this is a better place. Non-interactive use of RTP would configure the mechanisms described in the rtp-usage draft differently to interactive use, and could use larger playout buffers, different DSCP values, etc., but I wouldn’t expect anything in the rtp-usage draft would be invalid for non-interactive use.

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