Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-rtp-usage-23

[Alissa Cooper <[e-mail]>]

Thanks to both of you for your responses. Some comments in-line. If you can make these changes and rev the draft that would be great.

On May 20, 2015, at 10:32 AM, Magnus Westerlund <[e-mail]> wrote:

> 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 <[e-mail]> 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.”

WFM

> 
>> 
>>> == 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 think it would help to indicate that out-of-band coordination is needed.

> 
>> 
>>> =
>>> 
>>> 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 think this context would be a helpful addition for less familiar readers.

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

This is better, thanks. I don’t think including a PERC pointer is necessary at this point since that work is quite nascent.

Alissa

> 

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

Yep, thanks.

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