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

"Ravindran, Parthasarathi (NSN - IN/Bangalore)" <> Tue, 12 November 2013 18:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 91A2011E8121 for <>; Tue, 12 Nov 2013 10:33:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cN9jGkCeqIF0 for <>; Tue, 12 Nov 2013 10:33:48 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 732AF11E8122 for <>; Tue, 12 Nov 2013 10:33:34 -0800 (PST)
Received: from ([]) by ( with ESMTP id rACIXW9s007172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 12 Nov 2013 19:33:32 +0100
Received: from ([]) by ( with ESMTP id rACIXUUE021824 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Nov 2013 19:33:31 +0100
Received: from ([]) by ([]) with mapi id 14.03.0123.003; Wed, 13 Nov 2013 02:33:29 +0800
From: "Ravindran, Parthasarathi (NSN - IN/Bangalore)" <>
To: ext Magnus Westerlund <>, "Harald Tveit Alvestrand" <>, "" <>
Thread-Topic: [rtcweb] Comments on draft-ietf-rtcweb-transports-01
Thread-Index: AQHO37I3PiD2CpYvFEa5TFD9+s8TOpoh62lQ
Date: Tue, 12 Nov 2013 18:33:29 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R)
X-purgate: clean
X-purgate: This mail is considered clean (visit for further information)
X-purgate-size: 5039
X-purgate-ID: 151667::1384281212-00004A43-EC1DA466/0-0/0-0
Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-transports-01
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 12 Nov 2013 18:33:52 -0000

Hi Magnus,

ICE-TCP shall be used by WebRTC gateways and conference scenario. The related usecases are discussed in (PNTAW mailing alias). So, it should not be simply be removed.


-----Original Message-----
From: [] On Behalf Of ext Magnus Westerlund
Sent: Tuesday, November 12, 2013 7:50 PM
To: Harald Tveit Alvestrand;
Subject: [rtcweb] Comments on draft-ietf-rtcweb-transports-01


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:

rtcweb mailing list