Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-rtp-usage-23
Magnus Westerlund <magnus.westerlund@ericsson.com> Wed, 20 May 2015 17:32 UTC
Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63E651A89BB for <rtcweb@ietfa.amsl.com>; Wed, 20 May 2015 10:32:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.801
X-Spam-Level:
X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
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 Ymnt7-8hRv6U for <rtcweb@ietfa.amsl.com>; Wed, 20 May 2015 10:32:20 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C42371A89B8 for <rtcweb@ietf.org>; Wed, 20 May 2015 10:32:19 -0700 (PDT)
X-AuditID: c1b4fb3a-f79ec6d000006dc0-65-555cc521e05f
Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id D0.14.28096.125CC555; Wed, 20 May 2015 19:32:17 +0200 (CEST)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.77) with Microsoft SMTP Server id 14.3.210.2; Wed, 20 May 2015 19:32:17 +0200
Message-ID: <555CC520.7010800@ericsson.com>
Date: Wed, 20 May 2015 19:32:16 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Colin Perkins <csp@csperkins.org>, Alissa Cooper <alissa@cooperw.in>
References: <3099D1C3-005C-4C14-AF0E-D9A79164467F@cooperw.in> <62EF47FC-0298-4FCC-A7C4-59C4A75EC717@csperkins.org>
In-Reply-To: <62EF47FC-0298-4FCC-A7C4-59C4A75EC717@csperkins.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrALMWRmVeSWpSXmKPExsUyM+Jvra7i0ZhQg3fTtSymn/nLaLH85QlG i7X/2tkdmD2+PHnJ5DHt/n02jyVLfjIFMEdx2aSk5mSWpRbp2yVwZXx78oel4JpeRe++T4wN jBtVuxg5OSQETCR+PF3PDGGLSVy4t56ti5GLQ0jgKKPEhD1fmCCc5YwSNx6/YQSp4hXQlvj5 o5kVxGYRUJWYP+UjC4jNJmAhcfNHIxuILSoQJTH18ToWiHpBiZMzn4DZIgIeEhsebASzmQXU Je4sPscOYgsLOEv07HwNNlNIoEji0M52sBpOAUeJ27tfs0PUW0jMnH+eEcKWl2jeOpsZol5b oqGpg3UCo+AsJOtmIWmZhaRlASPzKkbR4tTi4tx0IyO91KLM5OLi/Dy9vNSSTYzAID645bfV DsaDzx0PMQpwMCrx8C54FR0qxJpYVlyZe4hRmoNFSZzXsyskVEggPbEkNTs1tSC1KL6oNCe1 +BAjEwenVAOjnX3JE3Pe7Sn/Hl+VV5Z6JHhRbtnVtrsWL3qn/q9mXPd4Usfzxe+5eIwWGsSY nzgYcGNqtfaE5zPbH6T7aJpKb9WyWRh2Y4LAQd6sl7kzXkzdIBXuJ+Sqd5pBJuW4wNoLW24t efPC7lO1+vZV8u5mX7ZN1JusricmmTXprL7olpB2Fsmvi5cFKrEUZyQaajEXFScCAJJh1sdD AgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/lxRCvOm4uDrwwCd1LiiSGCA9B6Y>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-rtp-usage-23
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 May 2015 17:32:24 -0000
Hi, Some additional comments on this. I have removed the parts where there appear to be agreement and no open issues. Colin Perkins skrev den 2015-05-17 14:00: >> On 14 May 2015, at 00:58, Alissa Cooper <alissa@cooperw.in> wrote: > >> == Section 11: >> >> "Note: this doesn't result in a tracking issue, since the creation >> of matching CNAMEs depends on existing tracking." >> >> I don't quite get this note. Is this trying to say that using the >> same CNAME in this case does not facilitate cross-service tracking >> because the CNAME re-use only occurs within a single origin? > > That's part of it. Also, that using the same CNAME for several > streams that are part of a single call is okay, and indeed needed for > lip-sync, since there are other ways of telling that these streams > are part of the same call. Yes, it really is a matter that this stays within an origin and the binding if needed would be exposed anyway. I think the text will be a bit clearer with the minor tweak at the end to clarify that is really is within one origin. "Note: this doesn't result in a tracking issue, since the creation of matching CNAMEs depends on existing tracking within a single origin." > >> == Section 12.1.3: >> >> "When flow- based differentiation is available, the WebRTC Endpoint >> needs to know about it so that it can provide the separation of the >> RTP packet streams onto different UDP flows to enable a more >> granular usage of flow based differentiation." >> >> I feel like this needs a bit more explanation since I assume it's >> not terribly commonplace for an endpoint to be able to find out >> that flow-based differentiation is taking place. Is there some >> mechanism you can point to that provides this information in some >> cases, or is this basically saying "wouldn't it be nice if >> endpoints could find this out somehow"? > > We could say "The use of flow-based differentiation needs to be > signalled to the WebRTC Endpoint, so it knows to provide the > separation..."? The point is that the endpoint can't enable this > without being told that it' so be used, and what parameters are to be > used. Yes, this is better formulation. My understanding is that so far, there need to be some out-of-band coordination between the network provider and the WebRTC based service that uses the network prioritization. > >> = >> >> I note that there is discussion of how DiffServ and flow-based >> classification might work for RTP traffic in the WebRTC context, >> but not DPI. Is there anything to be said, in particular given the >> SRTP requirement? Actually, I think you are at least partly wrong. A DPI can despite SRTP with encryption actually do quite significant classification due to the information exposed. First of all SRTP exposes the first 12 bytes of the RTP packet. Thus the SSRC is available, enabling RTP stream level tracking. This can then be used with RTP packet frequency and size analysis to determine which RTP streams are audio and which are video for example. Thus enabling such prioritization. The API level priorities are not exposed, so it can't take that into account unless they are exposed in the DSCP field. > > I'm happy to add some text, if you have any suggestions. Yes, I would like to have some indication from people who don't know this in and out to what appears necessary here. > >> == Section 13: >> >> "The use of the encryption of the header extensions are >> RECOMMENDED, unless there are known reasons, like RTP middleboxes >> or third party monitoring that will greatly benefit from the >> information, and this has been expressed using API or signalling. >> If further evidence are produced to show that information leakage >> is significant from audio level indications, then use of >> encryption needs to be mandated at that time." >> >> I'm not sure that "known reasons" are quite enough to justify the >> SHOULD-level requirement here. It would help if you could elaborate >> specific legitimate use cases where a middlebox or a specific kind >> of third party makes use of the audio level information and how >> that information provides a great benefit. > > The issue is that middle boxes use the audio level information in the > header extensions to perform voice activity-based source switching. > Sending audio level information in the header extension is preferable > to trusting the middle box with access to the media. We can add some > words to explain this further, and perhaps a pointer to the PERC > working group, if chartered? I suggest that we make the RTP middlebox usage clearer: The use of the encryption of the header extensions are RECOMMENDED, unless there are known reasons, like RTP middleboxes performing voice activity based source selection or third party monitoring that will greatly benefit from the information, and this has been expressed using API or signalling. > >> == Section 16: draft-ietf-mmusic-sdp-bundle-negotiation should not >> be listed as an informative reference. > > Why not? Because we actually have normative inclusion of its header extension in Section 4.1: Such endpoints MUST implement the RTCP SDES MID item described in [I-D.ietf-mmusic-sdp-bundle-negotiation]. We actually had it listed as both a normative and informative reference. I will remove the informative listing. Cheers 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 ----------------------------------------------------------------------
- [rtcweb] AD evaluation: draft-ietf-rtcweb-rtp-usa… Alissa Cooper
- Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-rtp… Colin Perkins
- Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-rtp… Magnus Westerlund
- Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-rtp… Alissa Cooper
- Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-rtp… Magnus Westerlund