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

Alissa Cooper <alissa@cooperw.in> Wed, 13 May 2015 23:59 UTC

Return-Path: <alissa@cooperw.in>
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 72A081B31B9 for <rtcweb@ietfa.amsl.com>; Wed, 13 May 2015 16:59:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 gA9l54OklgO2 for <rtcweb@ietfa.amsl.com>; Wed, 13 May 2015 16:59:08 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E3831B31AC for <rtcweb@ietf.org>; Wed, 13 May 2015 16:59:08 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id BB47220756 for <rtcweb@ietf.org>; Wed, 13 May 2015 19:59:07 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Wed, 13 May 2015 19:59:07 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=Do6 2zKjDUFJOFCY//ZmNqqJ6oHg=; b=F/OQ2rBH6MiG/AHzw+lx/JSPWdUsgHqumlk R7xo7eepD3pYTdbFy3DIn3df5B6yC1Vbzd552qWpNFcmKl3LnyigXs6KXOpWn4DE 7mb3eEEbCaseGwp6mzl7sAbcbFJcKoH7I223ggjRBwuA5x0+dx0tssXOr3IFYIIv JqFkl4tc=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=Do62zKjDUFJOFCY//ZmNqqJ6oHg=; b=iqJS8 f+i9xmi8yUC1JmBrfljG/hB3df6DVEzs68OL8MWUIk6XDDg//3UZB6e3D0o4I5MO 9fQxbPrJHgz0RmX6hR10nzzkaasrnl72AbKNIwMn8bAXSTXYdZZtVXTjy28nzNRp InaUOOyeQLElGJiJr7CLVa6CweWb9dCxFE1kIU=
X-Sasl-enc: YOnB+DgE4mvEPuMHCwLVgnQigPyKq4kJ9Pwck4FUPEyT 1431561547
Received: from sjc-alcoop-8817.cisco.com (unknown [128.107.241.178]) by mail.messagingengine.com (Postfix) with ESMTPA id 35AC6C00013 for <rtcweb@ietf.org>; Wed, 13 May 2015 19:59:06 -0400 (EDT)
From: Alissa Cooper <alissa@cooperw.in>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Message-Id: <3099D1C3-005C-4C14-AF0E-D9A79164467F@cooperw.in>
Date: Wed, 13 May 2015 16:58:58 -0700
To: rtcweb@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/F3WWF02ldp6YjRzMvLJM1VqAlA4>
Subject: [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, 13 May 2015 23:59:10 -0000

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.