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

Colin Perkins <csp@csperkins.org> Sun, 17 May 2015 12:00 UTC

Return-Path: <csp@csperkins.org>
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 232951A870B for <rtcweb@ietfa.amsl.com>; Sun, 17 May 2015 05:00:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level:
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 NbbAnQtSgwIP for <rtcweb@ietfa.amsl.com>; Sun, 17 May 2015 05:00:33 -0700 (PDT)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC99F1A906D for <rtcweb@ietf.org>; Sun, 17 May 2015 05:00:33 -0700 (PDT)
Received: from [82.132.245.123] (port=41016 helo=[10.168.26.11]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <csp@csperkins.org>) id 1YtxF8-0002yW-Rz; Sun, 17 May 2015 13:00:32 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
From: Colin Perkins <csp@csperkins.org>
X-Mailer: iPad Mail (12F69)
In-Reply-To: <3099D1C3-005C-4C14-AF0E-D9A79164467F@cooperw.in>
Date: Sun, 17 May 2015 13:00:24 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <62EF47FC-0298-4FCC-A7C4-59C4A75EC717@csperkins.org>
References: <3099D1C3-005C-4C14-AF0E-D9A79164467F@cooperw.in>
To: Alissa Cooper <alissa@cooperw.in>
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold = On =
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/kcKov9NUYmPbbklodqe7fzUizeg>
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: Sun, 17 May 2015 12:00:36 -0000

Hi Alissa,

Thanks for the review. Comments inline. 



> On 14 May 2015, at 00:58, Alissa Cooper <alissa@cooperw.in> wrote:
> 
> 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."

No objection on my part. 

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

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

Sure.

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

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

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

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

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

Okay to all the above. 

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

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

> s/needs to defined/needs to be defined/
> 
> s/enables more efficient/enable more efficient/

Okay.

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

Why not?

Cheers,
Colin


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