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

"Paul E. Jones" <paulej@packetizer.com> Tue, 03 May 2016 03:17 UTC

Return-Path: <paulej@packetizer.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7955712B018; Mon, 2 May 2016 20:17:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.998
X-Spam-Level:
X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=packetizer.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9x7UmDZBxR-H; Mon, 2 May 2016 20:17:37 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AEDC12D0B1; Mon, 2 May 2016 20:17:37 -0700 (PDT)
Received: from [192.168.1.20] (cpe-098-122-181-215.nc.res.rr.com [98.122.181.215] (may be forged)) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id u433HVsb011520 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 May 2016 23:17:31 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1462245452; bh=gWq4ec2dUxTJdSBgjIqPzmJemEd3/xLRT3Qz/p+RdoQ=; h=From:To:Subject:Cc:Date:In-Reply-To:Reply-To; b=sgGrZHoyL4+8t1rqedgGKXFa0Xm3I+L8Q4uzGwh/ykMarHEge/biOfJJZJBfzY2iE Gp78B4rxe71hx6lgOlZiEX0jKmuk8tOz8LHlvWa/ZDqq+lg/0kuHzJpqTyKlHu1qT9 Zp6UZ0Aque3uPcaG2TDVi7ltwg3U4VupmH7rcngI=
From: "Paul E. Jones" <paulej@packetizer.com>
To: "Magnus Westerlund" <magnus.westerlund@ericsson.com>, "Black, David" <david.black@emc.com>, "Cullen Jennings" <fluffy@iii.ca>
Subject: Re: [tsvwg] Last Call: <draft-ietf-tsvwg-rtcweb-qos-15.txt> (DSCP and other packet markings for WebRTC QoS) to Proposed Standard
Date: Tue, 03 May 2016 03:17:38 +0000
Message-Id: <emfd25ee64-57d3-4cab-bb2e-9b7dbfd3eef7@sydney>
In-Reply-To: <5715F07D.1050502@ericsson.com>
User-Agent: eM_Client/6.0.24928.0
Mime-Version: 1.0
Content-Type: text/plain; format=flowed; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.16 (dublin.packetizer.com [10.137.60.122]); Mon, 02 May 2016 23:17:32 -0400 (EDT)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/Zzjsw80i_WapT4eSjBzbx7uFOas>
Cc: "tsvwg@ietf.org" <tsvwg@ietf.org>, "draft-ietf-tsvwg-rtcweb-qos@ietf.org" <draft-ietf-tsvwg-rtcweb-qos@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "tsvwg-chairs@ietf.org" <tsvwg-chairs@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: "Paul E. Jones" <paulej@packetizer.com>
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 May 2016 03:17:39 -0000

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" <magnus.westerlund@ericsson.com>
To: "Black, David" <david.black@emc.com>om>; "Cullen Jennings" 
<fluffy@iii.ca>
Cc: "ietf@ietf.org" <ietf@ietf.org>rg>; "tsvwg-chairs@ietf.org" 
<tsvwg-chairs@ietf.org>rg>; "draft-ietf-tsvwg-rtcweb-qos@ietf.org" 
<draft-ietf-tsvwg-rtcweb-qos@ietf.org>rg>; "tsvwg@ietf.org" 
<tsvwg@ietf.org>
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:fluffy@iii.ca]
>>>Sent: Friday, April 15, 2016 10:48 AM
>>>To: Black, David
>>>Cc: Magnus Westerlund; ietf@ietf.org; tsvwg-chairs@ietf.org; 
>>>draft-ietf-tsvwg-
>>>rtcweb-qos@ietf.org@ietf.org; tsvwg@ietf.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.black@emc.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)
>>>>
>>
>>
>
>
>--
>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.westerlund@ericsson.com
>----------------------------------------------------------------------
>