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

[Harald Alvestrand <[e-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.

The primary reason is reduced call setup failure frequency

We (Google Talk Video at the time) saw a pretty massive fall in failure 
rates when we switched on RTCP bundling (going from 4 ports to 2 ports) 
because of the reduced number of failures of the ICE setup - we see no 
reason to suspect that the reduction in failures going from 2 ports to 1 
port should be negligible.


>   Is there a citation to why this multiplexing is necessary?
No, we did not publish this result.

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

I don't know that we have data to push this in one direction or the other.

>
>
> 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 the language mirrors RFC 5766 section 4, but tightens the 
restrictions:

    To ensure interoperability, a TURN server MUST support the use of UDP
    transport between the client and the server, and SHOULD support the
    use of TCP and TLS transport.

The "server" in this case is the TURN server in both documents, I think. 
This could be made clearer.

>
>
> 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'm happy that it doesn't!
>
>
> 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).

RFC 5766 has TLS as SHOULD (see quote above). We already strengthened 
TCP from RFC 5766's SHOULD to MUST; I'm still uncertain if we should do 
the same for TLS, but MAY is weakening 5766, and I don't think we should.

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

Yep, and use RFC numbers for both.

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

If we agree that this is what we should do, we can either include a 
reference or simply incorporate Martin's text here. So far, I haven't 
seen a consensus around this draft (but that's the chairs' job to 
determine).


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