[rtcweb] Comments on draft-ietf-rtcweb-transports-01

Magnus Westerlund <magnus.westerlund@ericsson.com> Tue, 12 November 2013 14:19 UTC

Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id D98E211E813D for <rtcweb@ietfa.amsl.com>; Tue, 12 Nov 2013 06:19:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.74
X-Spam-Status: No, score=-103.74 tagged_above=-999 required=5 tests=[AWL=-1.141, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id PQLKo2m510CU for <rtcweb@ietfa.amsl.com>; Tue, 12 Nov 2013 06:19:14 -0800 (PST)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net []) by ietfa.amsl.com (Postfix) with ESMTP id 7414511E815F for <rtcweb@ietf.org>; Tue, 12 Nov 2013 06:19:05 -0800 (PST)
X-AuditID: c1b4fb38-b7f2c8e000006d25-1a-528238d87c12
Received: from ESESSHC019.ericsson.se (Unknown_Domain []) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id FC.DD.27941.8D832825; Tue, 12 Nov 2013 15:19:04 +0100 (CET)
Received: from [] ( by smtp.internal.ericsson.com ( with Microsoft SMTP Server id 14.2.328.9; Tue, 12 Nov 2013 15:19:04 +0100
Message-ID: <5282391D.3050002@ericsson.com>
Date: Tue, 12 Nov 2013 15:20:13 +0100
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Harald Tveit Alvestrand <harald@alvestrand.no>, "rtcweb@ietf.org" <rtcweb@ietf.org>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDJMWRmVeSWpSXmKPExsUyM+Jvre4Ni6Ygg2+7xSyO9XWxWaz9187u wORxZcIVVo8lS34yBTBFcdmkpOZklqUW6dslcGWs2XmDreC7YsW/S7YNjJ+kuhg5OSQETCSa m44zQ9hiEhfurWfrYuTiEBI4wiix5WEbM4SznFFibs8CNpAqXgFtiUe7fzOC2CwCqhKNvVPY QWw2AQuJmz8awWpEBYIlzr9azA5RLyhxcuYTFhBbRCBSYunnrWC9wkCbe+6tZO1i5ADaLC7R 0xgEEmYW0JOYcrWFEcKWl2jeOhvsOCGgtQ1NHawTGPlnIZk6C0nLLCQtCxiZVzFyFKcWJ+Wm GxlsYgSG2MEtvy12MF7+a3OIUZqDRUmc9+Nb5yAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFIN jPwblinNX15b9CYqITur0ksxpbCBU78qNLj9WQ+/R+SSnivNFYbX+TJr9FQu63SZz7FKSNxk GaDS4OTMol/VV29bVufQzHd1kX9DaqV9kFaAQiBbruWdi3FR397PV9mYHndhuVOV9CFBuaOl XL05gtsaDm7Yun8X4zeG7LxFd6PEJyfL8CuxFGckGmoxFxUnAgDqmIi+/wEAAA==
Subject: [rtcweb] Comments on draft-ietf-rtcweb-transports-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
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: Tue, 12 Nov 2013 14:19:26 -0000


Here are my review comments on draft-ietf-rtcweb-transports-01:

1. Front page: I would strongly suggest moving requirements language
into some numbered section.

2. Section 2.1:

   o  TCP.  This is used for HTTP/WebSockets, as well as for TURN/SSL
      and ICE-TCP.

Are there really any need for ICE-TCP? Can't this simply be removed?

3. Section 2.1:
   For both protocols, this specification assumes the ability to set the
   DSCP code point of the sockets opened on a per-packet basis, in order
   to achieve the prioritizations described in [I-D.ietf-rtcweb-qos].

First, I don't think one can assume the ability to set DSCP code points.
I think one should express that it is desirable to do it.

Secondly, I think one has to be aware that setting DSCP on a per packet
basis may be less commonly working than even just marking a flow

Thirdly, the I-D.ietf-rtcweb-qos is dead, and if anything it should be
replaced by draft-dhesikan-tsvwg-rtcweb-qos-02.

4. Section 2.1:
   If DSCP code points can only be set on a per-socket basis, not per-
   packet, one loses the ability to have the network discriminate
   reliably between classes of traffic sent over the same transport, but
   this does not prevent communication.

As this means all packets in the flow gets same treatment, one can point
out that using multiple RTP sessions and transport flows allow one to
have multiple different priority levels.

5. Section 2.1:
   This specification does not assume that the implementation will have
   access to ICMP or raw IP.

I think it should point out the advantage of being capable of receiving
ICMP in MTU discovery.

In addition I think you can bring up the benefits from being capable of
setting DF bit.

6. Section 2.2:
   ICE TCP candidates [RFC6062] MAY be supported; this may allow
   applications to achieve peer-to-peer communication across UDP-
   blocking firewalls, but this also requires use of the SRTP/AVPF/TCP
   profile of RTP.

I would question if this at all should be discussed. First of all a
TURN/TCP or TURN/TLS/TCP relay fulfills the needs to cross a only TCP
allowing firewall. Secondly, if one likes to use TCP/TLS/RTP/SAVPF then
one would need to use RFC 4571 framing, or do you have another proposal?
I would also note that such a combination do require us to do a bit of
specification work to bring RFC 4571 up to date to allow us use both
profiles beyond AVP as well as indicating usage of DTLS-SRTP over that
TCP framing. Considering that this appears to be a redundant and less
likely to work mechanism I would propose to remove it from consideration
even for MAY.

7. Section 2.2.:

   o  TURN, including TURN over TCP[RFC5766].

Missing space between TCP and reference.

8. Section 2.2:

   TURN over TLS over TCP MAY be supported.  (QUESTION: SHOULD?  MUST?)

I think MAY is a fine level for this. But it clearly should be an issue
raised to the WG for further debate.

9. Section 2.3:
   The setup protocol for RTCWEB data channels is described in

That draft is now a WG draft.

10. Section 2.3:
   RTCWEB implementations MUST support multiplexing of DTLS and RTP over
   the same port pair, as described in the DTLS_SRTP specification
   [RFC5764], section 5.1.2.  Further separation of the DTLS traffic
   into SCTP and "other" is described in <need reference>.

A. I would note that one actually must be capable of multiplexing DTLS,
RTP and STUN messages on the same port pair.

B. What about that needed reference. I think it is
draft-ietf-rtcweb-data-channel that should have this text.

11. Section 4:

I think this document do need to discuss DSCP and ICMP and the issues
they can cause. Or possibly provide input to the security consideration


Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVM
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com