RE: [tsvwg] Last Call: <draft-ietf-tsvwg-rtcweb-qos-15.txt> (DSCP and other packet markings for WebRTC QoS) to Proposed Standard
"Black, David" <david.black@emc.com> Tue, 03 May 2016 16:31 UTC
Return-Path: <david.black@emc.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 80D1F12DA48; Tue, 3 May 2016 09:31:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.316
X-Spam-Level:
X-Spam-Status: No, score=-5.316 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emc.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 78ZZN1XztjJ9; Tue, 3 May 2016 09:31:05 -0700 (PDT)
Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (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 3A38212DA22; Tue, 3 May 2016 09:21:45 -0700 (PDT)
Received: from maildlpprd02.lss.emc.com (maildlpprd02.lss.emc.com [10.253.24.34]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u43GLdgb018830 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 3 May 2016 12:21:42 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com u43GLdgb018830
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1462292502; bh=fauDVQCpo1LVI1tnFr9A7djYg/U=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=svaXg6VvO/wT+Os7mn2DdUkPCOPpLkA0x9GCMSI6eJuiTskLAfvV5SKYu68aG2SNX 2Ef+XEiYbRN3pdmqT4gfu3pnYVYOwNvgPHCAnUV58OsPxqSFsE0mTQ4YIgDaD7ZD3i WZp/Jc7TNIHIEkZizZe4rHsGJsydc5q0H0ooXUOM=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com u43GLdgb018830
Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd02.lss.emc.com (RSA Interceptor); Tue, 3 May 2016 12:19:52 -0400
Received: from MXHUB219.corp.emc.com (MXHUB219.corp.emc.com [10.253.68.89]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u43GLPq4016535 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 3 May 2016 12:21:26 -0400
Received: from MX104CL02.corp.emc.com ([169.254.8.9]) by MXHUB219.corp.emc.com ([10.253.68.89]) with mapi id 14.03.0266.001; Tue, 3 May 2016 12:21:25 -0400
From: "Black, David" <david.black@emc.com>
To: "Paul E. Jones" <paulej@packetizer.com>, Magnus Westerlund <magnus.westerlund@ericsson.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
Thread-Topic: [tsvwg] Last Call: <draft-ietf-tsvwg-rtcweb-qos-15.txt> (DSCP and other packet markings for WebRTC QoS) to Proposed Standard
Thread-Index: AQHRg5nK94t/8iR5sU+B/9y+8LxFIp9nE2eAgADT/gCACkcQgIAGp9UQgBKxIQCABFTqQIABj5CAgBWkpgCAAIR84IAATCyA///E2LA=
Date: Tue, 03 May 2016 16:21:25 +0000
Message-ID: <CE03DB3D7B45C245BCA0D243277949362E991374@MX104CL02.corp.emc.com>
References: <5715F07D.1050502@ericsson.com> <emfd25ee64-57d3-4cab-bb2e-9b7dbfd3eef7@sydney> <CE03DB3D7B45C245BCA0D243277949362E991130@MX104CL02.corp.emc.com> <D0E69A2D-B862-4EFD-BC18-7E6476388B52@packetizer.com>
In-Reply-To: <D0E69A2D-B862-4EFD-BC18-7E6476388B52@packetizer.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.96.39.178]
Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949362E991374MX104CL02corpem_"
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com
X-RSA-Classifications: public
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/Tz6_PyBtjjPgZnZB6NO1c5sXGI4>
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>, "Black, David" <david.black@emc.com>, "tsvwg-chairs@ietf.org" <tsvwg-chairs@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
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 16:31:12 -0000
> As a process question, where does that note go and why would it be a note for the RFC editor vs. language for readers? The note will go into the datatracker because the Web RTC RTP usage draft (draft-ietf-rtcweb-rtp-usage) is in the RFC Editor Queue: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/ Sorry for not mentioning that draft status in my earlier email. One of the ART ADs would submit the RFC Editor Note, after Cullen and the rtcweb WG come up with its text, including figuring out where in the RTP usage draft to insert these statements. Thanks, --David From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Tuesday, May 03, 2016 10:44 AM To: Black, David; Magnus Westerlund; Cullen Jennings Cc: ietf@ietf.org; tsvwg-chairs@ietf.org; draft-ietf-tsvwg-rtcweb-qos@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 David, The text you proposed for the flow type I incorporated. Since everyone agreed with the language, I didn't present it here. I'll wait for Cullen's reply on the note. As a process question, where does that note go and why would it be a note for the RFC editor vs. language for readers? Or an I misinterpreting the intent? Paul ________________________________ From: "Black, David" <david.black@emc.com<mailto:david.black@emc.com>> Sent: May 3, 2016 11:29:15 AM EDT To: "Paul E. Jones" <paulej@packetizer.com<mailto:paulej@packetizer.com>>, Magnus Westerlund <magnus.westerlund@ericsson.com<mailto:magnus.westerlund@ericsson.com>>, Cullen Jennings <fluffy@iii.ca<mailto:fluffy@iii.ca>> Cc: "ietf@ietf.org<mailto:ietf@ietf.org>" <ietf@ietf.org<mailto:ietf@ietf.org>>, "tsvwg-chairs@ietf.org<mailto:tsvwg-chairs@ietf.org>" <tsvwg-chairs@ietf.org<mailto:tsvwg-chairs@ietf.org>>, "draft-ietf-tsvwg-rtcweb-qos@ietf.org<mailto:draft-ietf-tsvwg-rtcweb-qos@ietf.org>" <draft-ietf-tsvwg-rtcweb-qos@ietf.org<mailto:draft-ietf-tsvwg-rtcweb-qos@ietf.org>>, "tsvwg@ietf.org<mailto:tsvwg@ietf.org>" <tsvwg@ietf.org<mailto:tsvwg@ietf.org>>, "Black, David" <david.black@emc.com<mailto:david.black@emc.com>> Subject: RE: [tsvwg] Last Call: <draft-ietf-tsvwg-rtcweb-qos-15.txt> (DSCP and other packet markings for WebRTC QoS) to Proposed Standard Paul, 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's item [2], please make sure that item [1] is also covered. 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? With careful reading, one can discern that the Web RTC RTP usage draft (draft-ietf-rtcweb-rtp-usage) implies that all Web RTC usage is interactive, but some subtlety is involved. IMHO, relying on implementers to grasp that sort of "do what I mean" rationale is problematic. 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, and non-interactive Web RTC media flows currently use HTTP (and would that be HTTP over the Web RTC data channel or something else)? 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. Thanks, --David (as draft shepherd) -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Monday, May 02, 2016 10:18 PM To: Magnus Westerlund; Black, David; Cullen Jennings Cc: ietf@ietf.org<mailto:ietf@ietf.org>; tsvwg-chairs@ietf.org<mailto:tsvwg-chairs@ietf.org>; draft-ietf-tsvwg-rtcweb-qos@ietf.org<mailto:draft-ietf-tsvwg-rtcweb-qos@ietf.org>; tsvwg@ietf.org<mailto: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 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<mailto:magnus.westerlund@ericsson.com>> To: "Black, David" <david.black@emc.com<mailto:david.black@emc.com>>; "Cullen Jennings" <fluffy@iii.ca<mailto:fluffy@iii.ca>> Cc: "ietf@ietf.org<mailto:ietf@ietf.org>" <ietf@ietf.org<mailto:ietf@ietf.org>>; "tsvwg-chairs@ietf.org<mailto:tsvwg-chairs@ietf.org>" <tsvwg-chairs@ietf.org<mailto:tsvwg-chairs@ietf.org>>; "draft-ietf-tsvwg-rtcweb-qos@ietf.org<mailto:draft-ietf-tsvwg-rtcweb-qos@ietf.org>" <draft-ietf-tsvwg-rtcweb-qos@ietf.org<mailto:draft-ietf-tsvwg-rtcweb-qos@ietf.org>>; "tsvwg@ietf.org<mailto:tsvwg@ietf.org>" <tsvwg@ietf.org<mailto: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<mailto:ietf@ietf.org>; tsvwg-chairs@ietf.org<mailto:tsvwg-chairs@ietf.org>; draft-ietf-tsvwg- rtcweb-qos@ietf.org<mailto:rtcweb-qos@ietf.org>; tsvwg@ietf.org<mailto: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<mailto:david.black@emc.com>> wrote: I see a couple of Magnus's points that appear to need additi! onal 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 as! sociated 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 imme! diately 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 whet! her 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<mailto:magnus.westerlund@ericsson.com> ________________________________
- Re: [tsvwg] Last Call: <draft-ietf-tsvwg-rtcweb-q… Magnus Westerlund
- Re: [tsvwg] Last Call: <draft-ietf-tsvwg-rtcweb-q… Cullen Jennings
- Re: [tsvwg] Last Call: <draft-ietf-tsvwg-rtcweb-q… Magnus Westerlund
- RE: [tsvwg] Last Call: <draft-ietf-tsvwg-rtcweb-q… Black, David
- Re: [tsvwg] Last Call: <draft-ietf-tsvwg-rtcweb-q… Cullen Jennings
- RE: [tsvwg] Last Call: <draft-ietf-tsvwg-rtcweb-q… Black, David
- Re: [tsvwg] Last Call: <draft-ietf-tsvwg-rtcweb-q… gorry
- Re: [tsvwg] Last Call: <draft-ietf-tsvwg-rtcweb-q… Magnus Westerlund
- Re: [tsvwg] Last Call: <draft-ietf-tsvwg-rtcweb-q… Paul E. Jones
- RE: [tsvwg] Last Call: <draft-ietf-tsvwg-rtcweb-q… Black, David
- RE: [tsvwg] Last Call: <draft-ietf-tsvwg-rtcweb-q… Paul E. Jones
- Re: [tsvwg] Last Call: <draft-ietf-tsvwg-rtcweb-q… Ted Hardie
- RE: [tsvwg] Last Call: <draft-ietf-tsvwg-rtcweb-q… Black, David
- RE: [tsvwg] Last Call: <draft-ietf-tsvwg-rtcweb-q… Black, David
- Re: [tsvwg] Last Call: <draft-ietf-tsvwg-rtcweb-q… Ted Hardie
- RE: [tsvwg] Last Call: <draft-ietf-tsvwg-rtcweb-q… Black, David
- Re: [tsvwg] Last Call: <draft-ietf-tsvwg-rtcweb-q… Colin Perkins