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

[Bernard Aboba <[e-mail]>]

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 priorityproperty 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]> 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]
> https://www.ietf.org/mailman/listinfo/rtcweb
>