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

["Paul E. Jones" <[e-mail]>]

Brian,

>I fear I have an up-level question: what is the definition of 
>"interactive"?

That comes from RFC 4594, which comes from G.1010.

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

This paragraph has been modified during the course of discussions during 
LC.  The text now reads:

     Flow Type: The application provides this input because it knows
     if the flow is audio, interactive video with or without
     audio, non-interactive video with or without audio, or data.
     For audio that is associated with a video flow, the flow
     type of the associated video MAY be used instead of the
     associated audio type.

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

This should have been "application", as it's providing this input to the 
browser, in spite of the fact that the current API does not allow the 
application to indicate interactive or not.

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

Yeah, the browser would not know.  At present, it can only assume it's 
interactive based on the fact it is an RTP video and audio flow.

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

For WebRTC, audio alone is "interactive" in nature (which is why it's 
marked EF).  However, if one is sending audio and video it makes sense 
to mark them both same way to get the same PHB and hopefully have them 
queued in the same buffers along the path.  Sending audio as EF and 
possibly having a PHB that results in packets arriving much faster than 
corresponding video packets marked as AF42 is not at all helpful for 
applications that have to synchronize the audio and video flows.

I can think of examples of potentially non-interactive video (e.g., 
whiteboard, app sharing, or presentation video).  Likewise, if audio is 
sent with a presentation video it would make sense for the audio to be 
marked similarly to the corresponding video.

Paul