[rtcweb] Diffserv QoS for Video - summary

["Black, David" <[e-mail]>]

Many thanks for the productive comments - I'm replying to my own message in an attempt to summarize the discussion and what ought to be done to the drafts as a result.

-- [A] Brian Carpenter asked: what is the definition of "interactive"?

Paul Jones answered: from RFC 4594, which comes from G.1010.

IMHO, both drafts should cite RFC 4594 and G.1010 for this discussion and definition.

-- [B] Brian Carpenter asked about whether the WebRTC API supports a parameter to distinguish interactive video from non-interactive video.

The definitive answer from a number of sources (e.g., Stefan Håkansson) is "No."   There is additional text in the tsvwg-rtcweb-qos draft that will need to be revised to align with this answer (e.g., for WebRTC, there is no input to the browser to distinguish interactive vs. non-interactive video and the browser SHOULD NOT try to do so on its own).

-- [C] Bernard Aboba wondered  whether a "non-interactive" marking/priority would deliver anything useful to application developers independent of whether or not it's supported in the WebRTC API..

My perception is that the answer here is "Yes" which leads to leaving the Non-Interactive Video flow type in the tsvwg-rtcweb-qos draft, but making it clear that use of Web RTC via the browser API currently does not (and cannot) use that flow type.

-- [D] Finally, Brian Carpenter asked about non-interactive audio:

  Finally, why is audio not also subdivided into interactive and
  non-interactive? As far as I can see, both are logically possible.

I believe the answer is a lack of interest combined with absence of support in WebRTC "running code".

Further comments?

Absent further discussion, I'll work offline with the draft authors on text changes for both drafts in accordance with this summary.

Thanks, --David

> -----Original Message-----
> From: Black, David
> Sent: Wednesday, May 04, 2016 11:26 AM
> To: [e-mail]; [e-mail]
> Cc: Black, David
> Subject: Diffserv QoS for Video
> 
> 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)