|
Re: [tsvwg] Last Call: <draft-ietf-tsvwg-rtcweb-qos-15.txt> (DSCP and other packet markings for WebRTC QoS) to Proposed Standard
2016-03-30 06:44:22
Den 2016-03-23 kl. 23:46, skrev Cullen Jennings:
On Mar 23, 2016, at 3:07 AM, Magnus Westerlund
<magnus(_dot_)westerlund(_at_)ericsson(_dot_)com> wrote:
Hi,
Below is the first round on a question, that looks like it needs to
be addressed, thus I bring it into a public discussion.
Den 2016-03-22 kl. 19:48, skrev Paul E. Jones:
The other comment I have is the following:
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.
Yes, a browser knows if a MediaStreamTrack's source is a live
source, i.e. camera or microphone or a file. Which would
indicate the difference between interactive or non. However, I
don't understand what the Flow Type description for video
contains "with or without audio" as the flow definitions in
RTCWEB transport document all indicate flows as containing a
single media type. Can you please clarify?
This relates to the table that follows. The intent is that if a
WebRTC application is sending audio and video (e.g., a
videoconference call), then the same DSCP values might be used
for both the audio and video flows. On the other hand, if only a
video flow is sent alone (perhaps the audio source is an entirely
different device), then the browser can still use the same packet
marking.
So, I started commenting on this because, the "Flow Types" in the
table are not really defined. And my interpretation was not that
the audio could be given the same markings as the Video. I only
interpreted it as being valid for the video flow. Thus, I think the
actual "flow type" values in Table 1 needs to be better defined. To
my knowledge these types are not defined in any other RTCWeb
document.
Which codec it came from make is pretty clear if it is audio or video
in the browser implementation. The word “flow” has many meanings in
all the different contexts but it seems like section 4 is pretty
clear on breaking flow down into media and data types then breaking
media down into the various types in the table and defining them.
Are you getting at the issue of it a audio stream that is with a
synchronized video stream can use the same markings as the video
stream ? This tries to leave the options open and let people read
things like Section 4 of RFC 7657.
The main issue here is that to me it was not clear that "Interactive
Video with or without audio" allows for setting these DSCP values also
for the RTP stream containing audio also. This, I do see a need for
clarification on.
The Interactive vs Non-Interactive I do have an interpretation of what
it means. However, I fail to see how a WebRTC browser implementation is
going to be able to make that determination, and there are no API point
for indicating this distinction for the moment. But, I am fine to let
that through.
I think what is needed is a definition list for what is meant. I
can see that pointers for example into RFC 4594 may help making
these definitions more compact.
One thing that might be a bit tricky is actually the difference
between interactive and non-interactive (streaming) usages of
WebRTC RTP streams. It becomes a question if the WebRTC endpoint
actually accurately can classify these differences.
We decided at some point that if the browser is using SRTP, it is
assumed to be interactive and the webrtc specs point at using this.
If it is streamed over HTTP with something like DASH then it is non
interactive and browsers could use the non interactive markings but I
don’t think any of the streaming media docs have been updated yet to
point that out.
I agree with that. I also think there could be a potential development
where one could use video over RTP in a PeerConnection with a tweaked
configuration, much more delay tolerant that could be used also for
non-interactive delivery. But, that is just a potential future
modification or extension.
Yes, a live media source, like an camera or microphone can on first
order be used for classification as interactive, while a file
source is non-interactive. But even the first, can in the
application context be non-interactive. An example would be an
lecturer application. Relaxing the delay from the lecturer to the
audience is likely fine, especially if one have a "raise hand"
mechanism and only explicitly invites participants to ask
questions. To my knowledge there are no API surface to indicate
these preferences on the MediaStream or MediaStreamTrack level.
I think this document have a potential valuable difference for the
interactive vs non-interactive, but the rest of the current
solution has difficulties to utilize this difference. From my
perspective I am fine with retaining the difference, but the
definition must be clear so that implementers select the right one.
And likely the non-interactive will not be much utilized until
additional API knobs are created.
Agree but I think it is the WebRTC spec that needs to be clear on
that, not this draft.
The issue is that this document is called: DSCP and other packet
markings for WebRTC QoS. Then this document define something that is not
immediately mappable onto what is being defined in the other WebRTC
specifications. That is why I am raising that there need to be more
clear coupling. If that coupling is to mostly happen in another
document, can we at least then have a proposal on the table for that
change to ensure that the result is understandable.
cheers
Magnus Westerlund
----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB | Phone +46 10 7148287
Färögatan 6 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto:
magnus(_dot_)westerlund(_at_)ericsson(_dot_)com
----------------------------------------------------------------------
|
|