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

From: Dan Wing <[email-masked]>
Date: Thu, 12 Dec 2013 09:20:03 -0800

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?

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

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

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

-d

---

From: Wesley Eddy <[email-masked]>
Date: Thu, 12 Dec 2013 12:45:31 -0500

I also noticed something pretty strange in section 2.1, which
seems to indicate the desire to set the DSCP per-packet within
a TCP connection.  That doesn't compute, for two reasons:

- the application has no clue how the bytestream that it sends
  into a TCP socket will be segmented into individual packets

- different DSCPs within a TCP connection would create reordering
  and TCP HoL blocking, completely defeat the purpose of using
  different DSCPs

IMHO, discussing DSCP here is not necessary and causes more
confusion than it creates in value.  I would suggest that it
simply not be mentioned unless how to actually use it properly
is determined.

On 12/12/2013 12:20 PM, Dan Wing wrote:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
> 
> 

-- 
Wes Eddy
MTI Systems

---

From: "Chenxin (Xin)" <[email-masked]>
Date: Fri, 13 Dec 2013 06:14:06 +0000

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

[Xin] how about the RFC 6544?

>   TURN over TLS [RFC5766] over TCP MAY be supported.  (QUESTION:

[Xin]  I remembered there were discussion that the ICE-TCP is useful in conference server usecase with a FW.  So ICE TCP is better to change from MAY to SHOULD. 
>
>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).
>

Best Regards,
  Xin

---

From: "Eggert, Lars" <[email-masked]>
Date: Fri, 13 Dec 2013 12:35:27 +0000

Hi,

the document should also describe how it addresses the requirements raised in RFC5405.

Lars

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Fri, 13 Dec 2013 13:22:15 +0000

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

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

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

>    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…)
> 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:
+1 I like that description. Makes it easy for the implementers. 

.-.
Pål-Erik

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 16 Dec 2013 16:58:06 +0100

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:

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

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

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.

> 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 i…

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

> Does that sentence need RFC2119 language?  It think it also needs to cite TURN URI, RFC5928.

Yep, and use RFC numbers for both.

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

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

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 16 Dec 2013 17:02:46 +0100

>    and TCP HoL blocking, completely defeat the purpose of using

Good points. I'll rephrase to limit the per-packet desire to be for UDP, 
and say that DSCP for TCP has to be per socket.

(Q: How do existing implementations deal with changes to DSCP settings 
over the lifetime of a TCP connection? Do they just start applying the 
new DSCP at some random point in time?)

> simply not be mentioned unless how to actually use it properly
Are you suggesting that the RTCWEB protocol suite should ignore the use 
of DSCP?

I perhaps wouldn't mind that, actually, in the interest of getting the 
protocol suite out, but it does mean that DSCP will be set 
inconsistently by applications.

If we're going to use it at all, I think it needs to be mentioned here.

---

From: Dan Wing <[email-masked]>
Date: Mon, 16 Dec 2013 11:41:17 -0800

On Dec 16, 2013, at 7:58 AM, Harald Alvestrand <[email-masked]> wrote:

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

Life is nothing but trade-offs.  Can the transport draft provide justification/explanation for doing this collapse of multiple streams into the same (transport) socket.  There is a tension between that decision against existing network gear that only does QoS on TCP/UDP port (but can't do QoS on TCP/UDP port and DSCP).

> No, we did not publish this result.

I see.

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

The I-D is not even discussing that there is a trade off.  I think the transport document should discuss this decision.  The presence of data is a different problem; even if 99% of networks seen by Google don't do QoS, that private satellite network may well benefit from QoS and need to do its QoS using TCP/UDP ports (rather than DSCP).  Guidance to implementors seems beneficial to me.

> Actually the language mirrors RFC 5766 section 4, but tightens the restrictions:
> 

draft-ietf-rtcweb-transports should make it clearer that it is restricting language from rfc5766.

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

Thanks.

-d

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

---

From: Wesley Eddy <[email-masked]>
Date: Mon, 16 Dec 2013 15:01:50 -0500

> If we're going to use it at all, I think it needs to be mentioned here.

I think the use of different DSCP values for flows multiplexed
between the same UDP ports is a great long-term thing to think
about, but is a complete distraction from near-term need to get
stable RTCWEB specs done, and is not a necessary feature.

It can always be added later, if there's value, and if it can be
done in a way that's compatible with the rest of the DiffServ
universe.  It isn't something that needs to be implemented in
a compatible way between senders and receivers; only the
sender sets the DSCP, so there is even room here for the
implementations to do different things if it does turn out to
be useful, or if they wind up deployed in environments with
different PHBs or other queueing mechanisms implemented.

-- 
Wes Eddy
MTI Systems