[rtcweb] Diffserv QoS for Video

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

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)