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

[Dave Taht <[e-mail]>]

On Mon, Dec 16, 2013 at 2:41 PM, Dan Wing <[e-mail]> wrote:
>
> On Dec 16, 2013, at 7:58 AM, Harald Alvestrand <[e-mail]> wrote:
>
>> 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.

I would certainly agree that robust call negotiation is a problem with
nat, but less so on ipv6 and non-natted technologies.

However voip and video providers have been using multiple ports for
years (anyone here from asterisk, freeswitch or webex?),
and after call negotiation is completed separate tuples help.

I'll raise the question at the next vuc videoconference I get to. They
are on fridays, new attendies and presenters are always welcome:

https://www.facebook.com/voipusers

>
> 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).
>
>
>>>  Is there a citation to why this multiplexing is necessary?
>> No, we did not publish this result.
>
> I see.
>
>
>>>   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.

Incidentally dscp values are not what I consider part of the 5 tuple,
which is src,dst,srcport,dstport,proto. I'm not sure if that's clear
here.

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

Right now setting per-packet dscp and ecn values can be done via a
complex sendmsg call in Linux, for udp. It requires
(I think) a setsockopt to do it on tcp. Windows cannot set it at all
without admin privs. I've been writing some code to test this sort of
stuff but I doubt it or the relevant rfc will be ready for this ietf.

I don't care all that much about dscp stuff, do care about ecn in the
context of videoconferencing, and like a voip tuple for
a reliable timebase.

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

There is a difference between tcp and udp transports here.

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

How could you tell? Diffserv markings get stomped on in transit from
providers like comcast, so even if your local
router is doing qos/packet scheduling/aqm from markings none of that
information survives.

I would LOVE to have voip/video data from free.fr's network which
deployed fq_codel last year, and from the upcoming
adoption of pie for docsis 3.1.

> 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.
>
>
>
>>
>>>
>>>
>>> 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.
>
> 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
>
>
>>>
>>>
>>> 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
>>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html