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

[Magnus Westerlund <[e-mail]>]

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.
>
> On May 20, 2015, at 10:32 AM, Magnus Westerlund
> <[e-mail]> wrote:
>
[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"?
>>>
>>> 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.

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.

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

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

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