Re: [rtcweb] [tsvwg] Diffserv QoS for Video

[Brian E Carpenter <[e-mail]>]

Thanks Bernard.

All the same, I think the phrasing I quoted at
https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-15#section-4
is problematic; it implies that there's a Boolean property "interactive"
which clearly is not supported in the encoding parameters.

Regards
   Brian

On 05/05/2016 11:01, Bernard Aboba wrote:
> Brian Carpenter said: 
> 
> "Then, is it clear how the browser "knows" this?"
> 
> [BA] The application explicitly provides information to the browser by setting the RTCRtpEncodingParameters.priority attribute
> via the sender.setParameters() API: 
> 
> dictionary RTCRtpEncodingParameters { unsigned long ssrc <http://w3c.github.io/webrtc-pc/#widl-RTCRtpEncodingParameters-ssrc>;
> |RTCRtpRtxParameters| rtx <http://w3c.github.io/webrtc-pc/#widl-RTCRtpEncodingParameters-rtx>; |RTCRtpFecParameters| fec
> <http://w3c.github.io/webrtc-pc/#widl-RTCRtpEncodingParameters-fec>; boolean active
> <http://w3c.github.io/webrtc-pc/#widl-RTCRtpEncodingParameters-active>; |RTCPriorityType| priority
> <http://w3c.github.io/webrtc-pc/#widl-RTCRtpEncodingParameters-priority>; unsigned long maxBitrate
> <http://w3c.github.io/webrtc-pc/#widl-RTCRtpEncodingParameters-maxBitrate>; unsigned long maxFramerate
> <http://w3c.github.io/webrtc-pc/#widl-RTCRtpEncodingParameters-maxFramerate>; DOMString rid
> <http://w3c.github.io/webrtc-pc/#widl-RTCRtpEncodingParameters-rid>; double scaleResolutionDownBy
> <http://w3c.github.io/webrtc-pc/#widl-RTCRtpEncodingParameters-scaleResolutionDownBy> = 1.0; };
> 
> 
> The Priority and QoS Model is described in the latest WebRTC 1.0 Editor's draft (http://w3c.github.io/webrtc-pc/) Section 4.10: 
> 
> 4.10 Priority and QoS Model
> 
> Many applications have multiple media flows of the same data type and often some of the flows are more important than others.
> WebRTC uses the priority and Quality of Service (QoS) framework described in [RTCWEB-TRANSPORT] and [TSVWG-RTCWEB-QOS] to
> provide priority and DSCP marking for packets that will help provide QoS in some networking environments. The priority setting
> can be used to indicate the relative priority of various flows. The priority API allows the JavaScript applications to tell the
> browser whether a particular media flow is high, medium, low or of very low importance to the application by setting
> the |priority|property of ||RTCRtpEncodingParameters|| objects to one of the following values.
> 
> 
>         4.10.1 RTCPriorityType Enum
> 
> 
> enum RTCPriorityType {
>     "very-low <http://w3c.github.io/webrtc-pc/#idl-def-RTCPriorityType.very-low>",
>     "low <http://w3c.github.io/webrtc-pc/#idl-def-RTCPriorityType.low>",
>     "medium <http://w3c.github.io/webrtc-pc/#idl-def-RTCPriorityType.medium>",
>     "high <http://w3c.github.io/webrtc-pc/#idl-def-RTCPriorityType.high>"
> };
> 
> 
> On Wed, May 4, 2016 at 1:28 PM, Brian E Carpenter <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     I fear I have an up-level question: what is the definition of "interactive"?
> 
>     draft-ietf-tsvwg-rtcweb-qos doesn't define it, presumably because it was
>     assumed to be obvious, but thinking about David's suggestions, I decided
>     that it isn't so obvious.
> 
>     https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-15#section-4 says:
> 
>        The following are the inputs provided by the WebRTC application to
>        the browser:
> 
>        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.
> 
>     Firstly, I'm puzzled by the apparent contradiction between the first
>     sentence (in which the app provides input to the browser) and the second
>     sentence (in which to the browser provides input to something else).
> 
>     Then, is it clear how the browser "knows" this? If David's statement below
>     about the API is correct, the browser actually cannot "provide this input"
>     as stated in the above quotation. Or I am confused.
> 
>     Finally, why is audio not also subdivided into interactive and
>     non-interactive? As far as I can see, both are logically possible.
> 
>     Regards
>        Brian
> 
>     On 05/05/2016 03:26, Black, David wrote:
>     > Greetings,
>     >
>     > I write as the shepherd for the WebRTC QoS draft (draft-ietf-tsvwg-rtcweb-qos).
>     > IETF Last Call on this draft uncovered an issue that appears to also require
>     > changes in the Web RTC transports draft (draft-ietf-rtcweb-transports).
>     >
>     > The Web RTC draft  specifies different Diffserv Codepoints (DSCPs) for use with
>     > Interactive vs. Non-Interactive Video (with or without audio in both cases):
>     > https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-15#section-5
>     >
>     > The IETF LC issue is: How does an implementer determine whether video is
>     > interactive vs. non-interactive?
>     >
>     > The answer (unexpected to at least me) is that this can't be done for current
>     > WebRTC - all video has to be treated as interactive because there's no API
>     > support to distinguish interactive video from non-interactive video.  That
>     > doesn't appear to be stated anywhere obvious, and a TSVWG draft seems
>     > like the wrong place to do so.
>     >
>     > Hence, this message contains initial proposed changes to both the WebRTC
>     > Transports draft and WebRTC QoS draft to resolve this issue without removing
>     > any of the DSCPs currently specified for video in the WebRTC QoS draft.
>     >
>     > We should resolve this within the next few days, as the WebRTC QoS draft is
>     > (finally!) on the IESG telechat agenda for May 19.
>     >
>     > --- WebRTC Transports draft - proposed changes
>     >
>     > In Section 4 Media Prioritization, after the following existing text:
>     >
>     >    For media, a "media flow", which can be an "audio flow" or a "video
>     >    flow", is what [RFC7656] calls a "media source", which results in a
>     >    "source RTP stream" and one or more "redundancy RTP streams".  This
>     >    specification does not describe prioritization between the RTP
>     >    streams that come from a single "media source".
>     >
>     > Add a new paragraph:
>     >
>     >    All media flows in WebRTC are assumed to be interactive; there is
>     >    no browser API support for non-interactive media, aside from sending
>     >    non-interactive media content via the data channel.
>     >
>     > This ought to cite a W3C reference for the WebRTC API - the following
>     > appears plausible:
>     >
>     >    [W3C.WD-webrtc-20120209]
>     >               Bergkvist, A., Burnett, D., Jennings, C., and A.
>     >               Narayanan, "WebRTC 1.0: Real-time Communication Between
>     >               Browsers", World Wide Web Consortium WD WD-webrtc-
>     >               20120209, February 2012,
>     >               <http://www.w3.org/TR/2012/WD-webrtc-20120209>.
>     >
>     > -- WebRTC QoS draft - proposed changes
>     >
>     > In Section 5 DSCP Mappings, after the following existing text:
>     >
>     >    The browser SHOULD first select the flow type of the flow.  Within
>     >    the flow type, the relative importance of the flow SHOULD be used to
>     >    select the appropriate DSCP value.
>     >
>     > Add a new paragraph:
>     >
>     >    The current WebRTC browser API does not support non-interactive
>     >    video; all video is assumed to be interactive [I-D.ietf-rtcweb-transports].
>     >    Browsers MUST NOT use the DSCP mappings for Non-Interactive Video
>     >    in Table 1.  Non-browser implementations of WebRTC MAY use the
>     >    DSCP mappings for Non-Interactive Video in Table 1 for video that is
>     >    known to not be interactive, e.g., all video in a video playback application
>     >    based on a custom implementation of the WebRTC protocols would not
>     >    be interactive.
>     >
>     > ------
>     >
>     > Comments are welcome - as noted, above,  we should resolve this in
>     > the next few days in order to avoid pulling the WebRTC QoS draft off
>     > of the May 19 IESG telechat agenda. Please reply to both the TSVWG and
>     > RTCWEB lists, as we need  a coherent solution across both drafts.
>     >
>     > I want to thank Colin Perkins for suggesting the video playback example.
>     >
>     > Thanks, --David (as WebRTC QoS draft shepherd)
>     >
>     >
> 
>     _______________________________________________
>     rtcweb mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/rtcweb
> 
>