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

[Ted Hardie <[e-mail]>]

On Tue, May 3, 2016 at 8:29 AM, Black, David <[e-mail]> wrote:

> Paul,
>
> Cullen - would you be amenable to drafting a blunt RFC Editor note
> for the RTP usage draft to state that all current Web RTC RTP usage is
> for interactive media,


If you stop here, I personally think it is fine.


> and non-interactive Web RTC media flows currently
> use HTTP (and would that be HTTP over the Web RTC data channel or
> something else)?
>

I'm not so happy adding a description of where other media travels.  That's
going to be
app-specific, and since saying "we don't know this" in the document does
not help
implementers, I'd personally rather leave it out.



> Obviously, the rtcweb WG will have to sign off on that RFC Editor note,
> but this looks like a relatively short path to addressing the problem.
>
>
Do you want to summarize the issue to the wg now, or wait until there is a
candidate RFC editor note?

Ted


> Thanks, --David (as draft shepherd)
>
> > -----Original Message-----
> > From: Paul E. Jones [mailto:[e-mail]]
> > Sent: Monday, May 02, 2016 10:18 PM
> > To: Magnus Westerlund; Black, David; Cullen Jennings
> > Cc: [e-mail]; [e-mail];
> [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
> >
> > As I understand, we need this addition:
> >
> >          Currently in WebRTC, media sent over RTP is assumed to be
> >          interactive <xref target="I-D.ietf-rtcweb-rtp-usage"/>
> >          while media streamed over HTTP <xref target="RFC7230"/>
> >          <xref target="RFC7540"/> is assumed not to be.  Future WebRTC
> >          extensions could allow streamed, non-interactive media over RTP.
> >
> > I modified is slightly by adding "non-interactive" near the end and
> > inserting a reference near "interactive", though this is perhaps a
> > redundant reference since it appears elsewhere in the draft.
> >
> > That RTP usage reference does not speak to HTTP, so I don't have a
> > reference to "prove" that sentence above.  Is there a better reference?
> >
> > Paul
> >
> > ------ Original Message ------
> > From: "Magnus Westerlund" <[e-mail]>
> > To: "Black, David" <[e-mail]>; "Cullen Jennings"
> > <[e-mail]>
> > Cc: "[e-mail]" <[e-mail]>; "[e-mail]"
> > <[e-mail]>; "[e-mail]"
> > <[e-mail]>; "[e-mail]"
> > <[e-mail]>
> > Sent: 4/19/2016 4:46:53 AM
> > Subject: Re: [tsvwg] Last Call: <draft-ietf-tsvwg-rtcweb-qos-15.txt>
> > (DSCP and other packet markings for WebRTC QoS) to Proposed Standard
> >
> > >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]
> > >----------------------------------------------------------------------
> > >
>
>