Re: [tsvwg] Last Call: <draft-ietf-tsvwg-rtcweb-qos-15.txt> (DSCP and other packet markings for WebRTC QoS) to Proposed Standard

[Magnus Westerlund <[e-mail]>]

Den 2016-04-18 kl. 15:04, skrev Black, David:
> So, summarizing Magnus's concerns with proposals:
>
>>> [1] Flow Type in application-facing browser API:
>
>>> Propose an additional sentence:
>>> OLD
>>>    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.
>>> NEW
>>>    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.  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.
>
> Magnus - does that new text suffice?

Yes.

>
>>> [2] What does "interactive" mean in an implementation?:
>>
>> We could add something along lines of ..... Currently in WebRTC, media sent over
>> RTP is assumed to be interactive while media streamed over HTTP is assumed not
>> to be. Future WebRTC extensions could allow streamed media over RTP.
>
> I believe the proposed additional sentence addresses the question of how a browser
> determines whether a video flow is interactive.  This proposed sentence will need to
> cite a WebRTC document that contains a statement to that effect, as I don't think this
> draft is the right place to be the primary reference for that statement.
>
> Magnus - would this approach be ok?

Yes.

/Magnus

>
> Thanks, --David
>
>> -----Original Message-----
>> From: Cullen Jennings [mailto:[e-mail]]
>> Sent: Friday, April 15, 2016 10:48 AM
>> To: Black, David
>> Cc: Magnus Westerlund; [e-mail]; [e-mail]; draft-ietf-tsvwg-
>> [e-mail]; [e-mail]
>> Subject: Re: [tsvwg] Last Call: <draft-ietf-tsvwg-rtcweb-qos-15.txt> (DSCP and
>> other packet markings for WebRTC QoS) to Proposed Standard
>>
>>
>>> On Apr 3, 2016, at 3:37 PM, Black, David <[e-mail]> wrote:
>>>
>>> I see a couple of Magnus's points that appear to need additional text
>>> in the draft:
>>>
>>> [1] Flow Type in application-facing browser API:
>>>
>>>>>>>> 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.
>>>
>>> [... snip ...]
>>>
>>>> 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.
>>>
>>> Propose an additional sentence:
>>> OLD
>>>    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.
>>> NEW
>>>    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.  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.
>>>
>>> I hesitate to say anything stronger than "MAY" here.
>>
>> Looks good.
>>
>>>
>>> [2] What does "interactive" mean in an implementation?:
>>
>> We could add something along lines of ..... Currently in WebRTC, media sent over
>> RTP is assumed to be interactive while media streamed over HTTP is assumed not
>> to be. Future WebRTC extensions could allow streamed media over RTP.
>>
>>
>>>
>>>> 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.
>>>
>>> Well, this TSVWG draft is definitely not the right place for a discussion of
>>> when a video flow is interactive or non-interactive - I hope we can agree
>>> on that.
>>>
>>> Beyond that, as Cullen (Jennings) is both an author of this document and
>>> one of the chairs of the rtcweb WG, I'd suggest that he and/or the rtcweb
>>> WG propose an appropriate location for discussion of when a video flow
>>> is interactive or non-interactive.  This TSVWG draft would then have an
>>> additional sentence added, e.g.,
>>>
>>> 	See [TBD] for further discussion of how to determine
>>> 	whether a video flow is interactive vs. non-interactive.
>>>
>>> I believe that the added reference here ([TBD] above) would be normative.
>>>
>>> Cullen?
>>
>> That discussion happened long ago for WebRTC and we decided we did not need
>> a JavaScript controls point in the WebRTC API to indicate if RTP was interactive or
>> not. If people start doing streaming video over RTP we can come back and revisit
>> this and trivially add an API to indicate that in the W3C WebRTC API. Part of what
>> drove this decision is the likes of Netflix / ITunes / Youtube are not asking the
>> browser vendors for streaming media over RTSP or RTP. They think HTTP works
>> much better for this. Thus the browser vendors see no need for non interactive
>> video over RTP. I agree with Magnus that this might change some day in the
>> future but right now, I think it's close enough that everyone can live with it.
>>
>> I'm not OK in treating it like some open issue that is still in discussion that
>> somehow holds up this spec - it's not.
>>
>>>
>>> Thanks, --David (as document  shepherd)
>>>
>
>


-- 

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------