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

From: Alissa Cooper <[email-masked]>
Date: Wed, 13 May 2015 16:58:58 -0700

I have reviewed draft-ietf-rtcweb-rtp-usage-23 in preparation for IETF LC. Overall, the document is in really good shape. I have requested the LC, but I have a few substantive questions and suggestions I’d like to discuss while it is ongoing. I’ve also included a list of nits to be resolved together with any LC comments.

=== Substantive comments and questions ===

== Section 7:

"A future version of this memo will mandate the use of a congestion
   control algorithm that satisfies these requirements."

I can appreciate the intent here, but I think it's unwise to make this kind of guarantee while it's still unclear what RMCAT will produce and when. I would suggest instead something like:

"If a standardized congestion control algorithm that satisfies these requirements is developed in the future, this memo may be updated to mandate its use." 

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

== Section 12.1.3:

OLD
This is done according to three methods:
NEW
Three common methods for classifying IP packets are:

=

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

=

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?

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

=== Nits ===

== Section 4.1:

OLD
Support for the reduced minimum RTCP reporting interval described
      in Section 6.2 of [RFC3550] is REQUIRED.
NEW
Support for the reduced minimum RTCP reporting interval described
      in Section 6.2 of [RFC3550].
      
== Section 5.1.6:
s/This can be various reasons for this/There can be various reasons for this/

== Section 7.1:

OLD
A WebRTC Endpoint receiving media SHOULD signal
   its bandwidth limitations, these limitations have to be based on
   known bandwidth limitations, for example the capacity of the edge
   links.

NEW
A WebRTC Endpoint receiving media SHOULD signal
   its bandwidth limitations. These limitations have to be based on
   known bandwidth limitations, for example the capacity of the edge
   links.

== Section 11:

This sentence doesn't parse:
"This, as the sending party needs to change the CNAME to the one it
   uses, which implies that the sender has to use a local system clock
   as timebase for the synchronisation."

s/needs to defined/needs to be defined/

s/enables more efficient/enable more efficient/

== Section 16:
draft-ietf-mmusic-sdp-bundle-negotiation should not be listed as an informative reference.

---

From: Colin Perkins <[email-masked]>
Date: Sun, 17 May 2015 13:00:24 +0100

Hi Alissa,

Thanks for the review. Comments inline. 

> On 14 May 2015, at 00:58, Alissa Cooper <[email-masked]> wrote:
> 

No objection on my part. 

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

> Three common methods for classifying IP packets are:

Sure.

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

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. 

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

I'm happy to add some text, if you have any suggestions. 

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

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?

>   known bandwidth limitations, for example the capacity of the edge

Okay to all the above. 

>   as timebase for the synchronisation."

"Since the sending party needs to change the CNAME to the one it uses, this implies it has to use..."

> s/enables more efficient/enable more efficient/

Okay.

> draft-ietf-mmusic-sdp-bundle-negotiation should not be listed as an informative reference.

Why not?

Cheers,
Colin

-- 
Colin Perkins
http://csperkins.org/

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 20 May 2015 19:32:16 +0200

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:
>> 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: [email-masked]
----------------------------------------------------------------------

---

From: Alissa Cooper <[email-masked]>
Date: Sun, 24 May 2015 13:56:04 -0700

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 <[email-masked]> wrote:

> Hi,
> 
> Some additional comments on this. I have removed the parts where there appear to be agreement and no open issues.
> 
> 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

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

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

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

> Because we actually have normative inclusion of its header extension in Section 4.1:
> 
> We actually had it listed as both a normative and informative reference. I will remove the informative listing.

Yep, thanks.

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 25 May 2015 15:34:48 +0200

Hi,

some comments and suggested text based on your feedback. I think we 
should await the expiration of the IETF last call deadline on Thursday 
before submitting an update.

Alissa Cooper skrev den 2015-05-24 22:56:
> 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.
>
[snip]

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

Okay, I have attempted to reword the paragraph so that it now reads:

Flow-based differentiation will provide the same treatment to all 
packets within a transport-layer flow, i.e., relative prioritization is 
not possible. Moreover, if the resources are limited it might not be 
possible to provide differential treatment compared to best-effort for 
all the RTP packet streams used in a WebRTC session. The use of 
flow-based differentiation needs to be coordinated between the WebRTC 
system and the network(s). The WebRTC endpoint must know that flow-based 
differentiation may be used to provide the separation of the RTP packet 
streams onto different UDP flows to enable a more granular usage of flow 
based differentiation. The used flows, their 5-tuples and prioritization 
will need to be communicated to the network so that it can identify the 
flows correctly to enable prioritization. No specific protocol support 
for this is specified.

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

Okay, then I propose we add the following paragraph before the second 
last paragraph in the section:

Deep Packet Inspectors will, despite the SRTP media encryption, still be 
fairly capable at classifying the RTP streams. The reason is that SRTP 
leaves the first 12 bytes of the RTP header unencrypted. This enables 
easy RTP stream identification using the SSRC and provides the 
classifier with useful information that can be correlated to determine 
for example the stream's media type. Using packet sizes, reception 
times, packet inter-spacing, RTP timestamp increments and sequence 
numbers, fairly reliable classifications are achieved.

Cheers

Magnus Westerlund