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

["Paul E. Jones" <[e-mail]>]

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" <[e-mail]>
To: "Black, David" <[e-mail]>; "Cullen Jennings" 
<[e-mail]>
Cc: "[e-mail]" <[e-mail]>; "[e-mail]" 
<[e-mail]>; "[e-mail]" 
<[e-mail]>; "[e-mail]" 
<[e-mail]>
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:[e-mail]]
>>>Sent: Friday, April 15, 2016 10:48 AM
>>>To: Black, David
>>>Cc: Magnus Westerlund; [e-mail]; [e-mail]; 
>>>draft-ietf-tsvwg-
>>>[e-mail]; [e-mail]
>>>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 <[e-mail]> 
>>>>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  [phone]
>Färögatan 6                 | Mobile [phone]
>SE-164 80 Stockholm, Sweden | mailto: [e-mail]
>----------------------------------------------------------------------
>