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

[[e-mail]]

Looks good to me, but I'd prefer /as/because/

Gorry

> 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?
>
>> > [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?
>
> 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)
>> >
>