Re: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-00.txt

[Dan Wing <[e-mail]>]

On Aug 20, 2013, at 12:25 AM, Michael Tuexen <[e-mail]> wrote:

> 
> On Aug 20, 2013, at 1:20 AM, Dan Wing <[e-mail]> wrote:
> 
>> 
>> On Aug 19, 2013, at 2:20 PM, Harald Alvestrand <[e-mail]> wrote:
>> 
>>> As indicated in the -overview draft, it seemed logical to collect the information about the transport
>>> profile for RTCWEB in a separate document.
>>> 
>>> It is only 6 pages including all boilerplate, and has a couple of open issues that the WG needs to address.
>>> 
>>> I'll emit an updated -overview shortly, with the corresponding appendix removed.
>>> 
>>> 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=165305.  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...

Yes, that is what the URL I cited says.  But more important than celebrating that FreeBSD was recently updated to get this capability is that the I-D document this as a requirement of the underlying OS.

-d


> 
> Best regards
> Michael
>> 
>> 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
>> 	   |                |   |                  |
>> 	   |                |   +------------------+	
>>          |                |
>>          |       B < 2   -+--> forward to STUN/ICE
>>          +----------------+
>> 
>> -d
>> 
>> 
>> 
>>> 
>>>           Harald
>>> 
>>> 
>>> On 08/19/2013 07:15 PM, [e-mail] 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.
>>>> 
>>>> 	Title           : Transports for RTCWEB
>>>> 	Author(s)       : Harald Alvestrand
>>>> 	Filename        : draft-ietf-rtcweb-transports-00.txt
>>>> 	Pages           : 6
>>>> 	Date            : 2013-08-19
>>>> 
>>>> 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.
>>>> 
>>>> 
>>>> 
>>>> The IETF datatracker status page for this draft is:
>>>> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports
>>>> 
>>>> There's also a htmlized version available at:
>>>> http://tools.ietf.org/html/draft-ietf-rtcweb-transports-00
>>>> 
>>>> 
>>>> 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.
>>>> 
>>>> Internet-Drafts are also available by anonymous FTP at:
>>>> ftp://ftp.ietf.org/internet-drafts/
>>>> 
>>>> _______________________________________________
>>>> rtcweb mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>> 
>>> _______________________________________________
>>> rtcweb mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>> 
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>> 
>