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

[Bernard Aboba <[e-mail]>]

Brian said:

"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."

[BA] Overall, I'm not clear that this thread is asking the right questions,
or making correct statements about the existing API.  To my mind, the real
question is whether a "non-interactive" marking/priority would deliver
anything useful to application developers, not whether the API could
support it.

The encoding parameters can be used to allow an application to specify a
priority attribute.  If a "non-interactive" marking and associated priority
attribute were to be defined, the current API could allow applications to
specify that.  So citing a 4-year old version of the WebRTC 1.0
specification as justification for the lack of API functionality doesn't
make sense to me.   Since the browser just does what it is told to do by
the application, whether the browser "knows" whether the media is
interactive or not also does not matter.

The real question is whether a  "non-interactive" marking/priority setting
would be useful to application developers.

Uni-directional communications (e.g. "sendonly", "recvonly") is supported
within WebRTC.  Would those kind of flows benefit from a "non-interactive"
marking? In most cases, I suspect that in general it would not be useful (a
possible exception might be use of SVC codecs protecting only the base
layer with FEC/RTX).

It is conceivable that an application might want to attach a track to a
sender that isn't obtained from getUserMedia() (see:
http://w3c.github.io/mediacapture-main/) or getDisplayMedia() (see
https://w3c.github.io/mediacapture-screen-share/).  Again, the question is
whether a "non-interactive" marking/priority would be helpful in those
cases.  I suspect the answer to that is also "no" for similar reasons.

On Wed, May 4, 2016 at 5:36 PM, Brian E Carpenter <
[e-mail]> wrote:

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