Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <EAF548B7-09BE-4C64-AC44-4EE02EFC96F7@cisco.com>
Date: Tue, 20 Aug 2013 09:25:35 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <F1280E9D-D43F-4E0F-9394-3A468C556B68@lurchi.franken.de>
References: <20130819171507.30712.24757.idtracker@ietfa.amsl.com>
 <52128C29.4040402@alvestrand.no>
 <EAF548B7-09BE-4C64-AC44-4EE02EFC96F7@cisco.com>
To: Dan Wing <dwing@cisco.com>
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-00.txt
Precedence: list

On Aug 20, 2013, at 1:20 AM, Dan Wing <dwing@cisco.com> wrote:

>=20
> On Aug 19, 2013, at 2:20 PM, Harald Alvestrand <harald@alvestrand.no> =
wrote:
>=20
>> 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!
>=20
> 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).
Support for per-packet TOS/DSCP information to be received/sent was =
added in FreeBSD 8.4 and 9.1...

Best regards
Michael
>=20
> Section 2.2,
> "   In order to deal with symmetric NATs, TURN MUST be supported."
>=20
> 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.
>=20
> 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?)"
>=20
> 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.
>=20
> Section 2.2,
> "   o  TURN, including TURN over TCP [[QUESTION: and TURN over TLS]],
>      [RFC5766]."
>=20
> 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.
>=20
> 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."
>=20
> 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:
>=20
>           +----------------+
>           | 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
>           +----------------+
>=20
> -d
>=20
>=20
>=20
>>=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
>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>=20