Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Dan Wing <dwing@cisco.com>
In-Reply-To: <52128C29.4040402@alvestrand.no>
Date: Mon, 19 Aug 2013 16:20:58 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <EAF548B7-09BE-4C64-AC44-4EE02EFC96F7@cisco.com>
References: <20130819171507.30712.24757.idtracker@ietfa.amsl.com>
 <52128C29.4040402@alvestrand.no>
To: Harald Alvestrand <harald@alvestrand.no>
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-00.txt
Precedence: list

On Aug 19, 2013, at 2:20 PM, Harald Alvestrand <harald@alvestrand.no> =
wrote:

> As indicated in the -overview draft, it seemed logical to collect the =
information about the transport
> profile for RTCWEB in a separate document.
>=20
> It is only 6 pages including all boilerplate, and has a couple of open =
issues that the WG needs to address.
>=20
> I'll emit an updated -overview shortly, with the corresponding =
appendix removed.
>=20
> Let the reviews begin!

If per-*packet* DSCP setting is necessary (such as when bundling is =
used), both Section 2.1 and 2.2 should clarify that requirement.  For =
example FreeBSD's IPv4 stack didn't have that capability recently, per =
http://www.freebsd.org/cgi/query-pr.cgi?pr=3D165305.  I am sure many, =
many middleboxes don't have that capability (and might take action based =
on the first DSCP value they see, under the assumption that the 5-tuple =
flow will continue to use that same DSCP value).

Section 2.2,
"   In order to deal with symmetric NATs, TURN MUST be supported."

Two comments:  TURN is only necessary if both peers are behind NATs =
which perform endpoint-dependent mapping.  The "symmetric" term is =
overloaded and lacks precision, so I would really like it avoided.  I =
suggest:  "To deal with both peers being behind restrictive NATs, TURN =
MUST be supported."  Using a less-specific term like "restrictive" =
avoids a bunch of lengthy sentences of technical detail which aren't =
interesting, and this new wording explains that TURN is only needed when =
both endpoints are behind such restrictive NATs.

Section 2.2,
  "In order to deal with firewalls that block all UDP traffic, TURN over
   TCP MUST be supported.  (QUESTION: What about ICE-TCP?)"

ICE-TCP allows direct peer-to-peer communications using TCP, without a =
TURN server doing TCP-to-UDP interworking.  I would say the industry has =
less experience with ICE-TCP than with ICE or with TURN-over-TCP, and =
because of the less experience and because ICE-TCP is arguably an =
*optimization*, I would say ICE-TCP is a MAY.  It can't be a MUST-level =
requirement, at least by my threshold for MUST which is that =
interoperability is harmed or interoperability is impossible.

Section 2.2,
"   o  TURN, including TURN over TCP [[QUESTION: and TURN over TLS]],
      [RFC5766]."

Most -- but not all -- of the security obtained with TURN over TLS is =
achieved with TURN REST (draft-uberti-behave-turn-rest and =
draft-uberti-rtcweb-turn-rest).  I think the working group should =
consider if TURN REST satisfies the requirements, or if TURN over TLS is =
really, really necessary.

Section 2.3,
  "RTCWEB implementations MUST support multiplexing of SCTP/DTLS and RTP
   over the same port pair, as described in the DTLS_SRTP specification
   [RFC5764], section 5.1.2."

Really, the requirement is more than than what DTLS-SRTP specifies, =
because it only specifies shows how STUN, DTLS, and SRTP packets are =
demultiplexed, whereas WebRTC endpoints have to handle those three =
protocols as well as SCTP.  Somewhere -- perhaps =
draft-ietf-rtcweb-transports or elsewhere, a diagram of how the layering =
works would be useful.  Adapting the diagram from Section 5.1.2 of =
RFC5764, I believe incoming packet processing diagram looks like this:

           +----------------+
           | 127 < B < 192 -+--> forward to RTP
	   |                |
      	   |	      	       |   +------------------+
	   |                |   | DTLS processing  |
	   |                |   |                  |
packet --> |  19 < B < 64  -+-->+ appl. protocol  -+--> SCTP
           |                |   |  	      	      |
      	   |  	      	    |   | other protocols -+--> DTLS
	   |                |   |                  |
	   |                |   +------------------+=09
           |                |
           |       B < 2   -+--> forward to STUN/ICE
           +----------------+

-d



>=20
>             Harald
>=20
>=20
> On 08/19/2013 07:15 PM, internet-drafts@ietf.org wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
>>  This draft is a work item of the Real-Time Communication in =
WEB-browsers Working Group of the IETF.
>>=20
>> 	Title           : Transports for RTCWEB
>> 	Author(s)       : Harald Alvestrand
>> 	Filename        : draft-ietf-rtcweb-transports-00.txt
>> 	Pages           : 6
>> 	Date            : 2013-08-19
>>=20
>> Abstract:
>>    This document describes the data transport protocols used by =
RTCWEB,
>>    including the protocols used for interaction with intermediate =
boxes
>>    such as firewalls, relays and NAT boxes.
>>=20
>>=20
>>=20
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports
>>=20
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-rtcweb-transports-00
>>=20
>>=20
>> Please note that it may take a couple of minutes from the time of =
submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>=20
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>=20
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb