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

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

> To my mind, the real
> question is whether a "non-interactive" marking/priority would deliver
> anything useful to application developers, 

Absolutely. As I understand things, a media stream in an interactive
session has one requirement that is definitely more stringent than
for a non-interactive session: lower latency. So the question is how
to ensure that the most suitable DSCP is chosen to achieve the required
latency. But that takes us back to
https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-15#section-5
where by some magic the code needs to know the flow type.

This is why trying to compress the subtleties of QoS into a "priority"
parameter is bound to fail. I don't understand how
https://tools.ietf.org/html/draft-ietf-rtcweb-transports-12#section-4.2
is going to work without extending the API.

Regards
   Brian


On 05/05/2016 13:41, Bernard Aboba wrote:
> 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
>>>
>>>
>>
>