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

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

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