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

[Harald Alvestrand <[e-mail]>]

(following up on old mail)

On 12/12/2013 06:20 PM, Dan Wing 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.
>
> 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?

Added a section.
>
>
> 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>.

Actually this illustrates the issue. This is not TURN-TCP, it's TURN 
(RFC 5766) section 2.1.
>
>
> 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. "

I removed all mention of profiles. It belongs in the RTP draft.
>
>
> 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
>      o  TURN over TCP [RFC6062]"
>
>
> 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).

I moved ICE up a bit. This section repeated (and contradicted) earlier text.
>
>
> 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.

The main purpose of this mention was to get the document into the 
normative dependency chain. I think the reference is in JSEP now, so I 
can delete it from here.

>
>
> 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.

This doesn't make much sense to me. When I look at

https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-5

all the stuff that isn't "application data" is basically internal to the 
DTLS machinery. That's not what I usually call demultiplexing, it's just 
the running of the DTLS machinery at that level.

>
>
>
> 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).

I'll leave a decision on use or non-use of ALPN to the chairs, and 
insert text here if needed.

>
> -d
>
>
>
>