Re: [tsvwg] Last Call: <draft-ietf-tsvwg-rtcweb-qos-15.txt> (DSCP and ot

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:fluffy(_at_)iii(_dot_)ca]
Sent: Friday, April 15, 2016 10:48 AM
To: Black, David
Cc: Magnus Westerlund; ietf(_at_)ietf(_dot_)org; 
tsvwg-chairs(_at_)ietf(_dot_)org;
draft-ietf-tsvwg-
rtcweb-qos(_at_)ietf(_dot_)org; tsvwg(_at_)ietf(_dot_)org
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 
<david(_dot_)black(_at_)emc(_dot_)com> 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)

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