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
----------------------------------------------------------------------