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

["Pal Martinsen (palmarti)" <[e-mail]>]

On 12 Dec 2013, at 18:20 pm, Dan Wing <[e-mail]> wrote:

> This document does not explain why the media and data need to share the same 5-tuple.  For inspiration I re-read the introduction to draft-ietf-mmusic-sdp-bundle-negotiation, but it also does not explain the reason it multiplexes everything onto one port.  Is there a citation to why this multiplexing is necessary?  I ask because draft-ietf-rtcweb-transports makes a slight acknowledgement that per-packet DSCP marking is not always possible, but draft-ietf-rtcweb-transports does not provide much guidance for when using the same 5-tuple is harmful or is helpful or is necessary.  It seems draft-ietf-rtcweb-transports is a good place for the guidance between reduced call setup time (which I understand is the primary motivation, but again I don't know where that was written down) versus getting the OS to permit setting per-packet DSCP versus getting the network to assist with 5-tuple prioritization.
> 
I pretty much have the same questions. I think there was some remarks regarding BUNDLE, trickle-ICE, call setup times and how fast NATs can allocate new bindings. I like trickle-ICE for its potential to help with mobility scenarios, a newer ending trickling of candidates as the agents moves from wireless node to wireless node. I am unsure if the reduced complexity is worth the reduction of call setup times. 

> Other comments:
> 
> 
> 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.
> 
> In the case where per-packet DSCP cannot be set (due to OS limitations, I suppose?), should the I-D encourage the endpoint to perhaps avoid bundling, or explain trade-offs of multiplexing everything to one port versus using separate ports?
> 
We did some test with this a couple a years ago. As TCP packets tend to be buffered at the agent it was difficult to set a DSCP marking on a specific packet. Setting the socket option to change the DSCP markings, made all the packets going out from that buffer have the same marking. 

I find the idea of providing differentiated stream properties from a specific application intriguing. But I have a feeling that DSCP markings are not enough to get a well working solution going.

I think the section regarding DSCP markings should be removed. The discussions regarding mechanisms for QoS can probably benefit from waiting until the initial rtcweb spec is out of the door.

> 
> Section 2.2:
>   In order to deal with firewalls that block all UDP traffic, TURN
>   using TCP between the client and the server MUST be supported, and
>   TURN using TLS between the client and the server MUST be supported.
> 
> The "using TCP between the client and the server" is confusing.  How about just "In order to deal with firewalls that block all UDP traffic, TURN-TCP [RFC6062] MUST be supported, and ..." <continue with rest of sentence>.
> 
With TURN-TCP you create a TCP port on the public side of the TURN server. And you end up with a TCP candidate in the SDP.
I think the original intent with the text was to have a UDP port on the public side of the TURN server, but use TCP/TLS to send allocate request and such to the the TURN server. 

Should it be mentioned that sending to port 80 and 443 may also be beneficial to get through stubborn firewalls?


> 
> 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.
> 
> It doesn't require SRTP/AVPF/TCP profile, see http://tools.ietf.org/html/rfc6544#section-4.3 and the last paragraph of page 11 http://tools.ietf.org/html/rfc6544#page-11 specifically "If an agent is utilizing SRTP [RFC3711], it MAY include a mix of UDP and TCP candidates. "
> 
> 
> Section 2.2:
>   The following specifications MUST be supported:
> 
>   o  ICE [RFC5245]
> 
>   o  TURN, including TURN over TCP[RFC5766].
> 
> could be improved by clarifying ICE full implementation is necessary, and tightening TURN.  I suggest:
> 
>   "o  Full implementation of ICE [RFC5245]
>    o  TURN [RFC5766], except that TURN over TLS MAY be supported
* Full TURN [RFC5766] support, including UDP, TCP and TLS communication between agent and TURN server should be supported.

>    o  TURN over TCP [RFC6062]”
> 
* TURN-TCP [RFC6062] to support full TCP path of data channel. (Need rewording…)
> 
> 
> Section 2.2:
>   TURN over TLS [RFC5766] over TCP MAY be supported.  (QUESTION: SHOULD?  MUST?)
> 
> Remove that sentence and fold it into the MUST in the previous sentence, because TURN-over-TLS is defined in the main TURN RFC (RFC5766).
> 
> 
> Section 2.2:
>   For referring to STUN and TURN servers, this specification depends on
>   the STUN URI, [I-D.nandakumar-rtcweb-stun-uri].
> 
> Does that sentence need RFC2119 language?  It think it also needs to cite TURN URI, RFC5928.
> 
> 
> 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>.
> 
> I would just pull the demultiplexing algorithm into this I-D, as this I-D is where all of these protocols are brought together.  For reference, RFC5764 shows:
> 
>                   +----------------+
>                   | 127 < B < 192 -+--> forward to RTP
>                   |                |
>       packet -->  |  19 < B < 64  -+--> forward to DTLS
>                   |                |
>                   |       B < 2   -+--> forward to STUN
>                   +----------------+
> 
> 
> so to add SCTP it would be something like:
> 
>             +----------------+
>             | 127 < B < 192 -+--> forward to RTP
>             |                |
> packet -->  |	     B < 2   -+--> forward to STUN
>             |                |
>             |  19 < B < 64  -+--> forward to DTLS
>      	     +----------------+	      	       |
>      	      	      	      	      	       V
>                            +-------------------------+
>                     SCTP<--+- C-T = application_data |
>      	      	      	    | 	      	      	      |
>      	      	     DTLS<--+- C-T = <other>    	    |
>      	      	      	    +-------------------------+
> 
> 
> Where "C-T" is the TLS ContentType.
> 
> 
> 
> Related to this demultiplexing, it seems this document is best place to describe using ALPN for the DTLS session (see http://tools.ietf.org/html/draft-thomson-rtcweb-consent-00#section-3).
> 
+1 I like that description. Makes it easy for the implementers. 


.-.
Pål-Erik


> -d
> 
> 
> 
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb