[rtcweb] Comments on draft-ietf-rtcweb-transports-01

[Magnus Westerlund <[e-mail]>]

Hi,

Here are my review comments on draft-ietf-rtcweb-transports-01:

1. Front page: I would strongly suggest moving requirements language
into some numbered section.

2. Section 2.1:

   o  TCP.  This is used for HTTP/WebSockets, as well as for TURN/SSL
      and ICE-TCP.

Are there really any need for ICE-TCP? Can't this simply be removed?

3. Section 2.1:
   For both protocols, this specification assumes the ability to set the
   DSCP code point of the sockets opened on a per-packet basis, in order
   to achieve the prioritizations described in [I-D.ietf-rtcweb-qos].

First, I don't think one can assume the ability to set DSCP code points.
I think one should express that it is desirable to do it.

Secondly, I think one has to be aware that setting DSCP on a per packet
basis may be less commonly working than even just marking a flow
consistently.

Thirdly, the I-D.ietf-rtcweb-qos is dead, and if anything it should be
replaced by draft-dhesikan-tsvwg-rtcweb-qos-02.

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

As this means all packets in the flow gets same treatment, one can point
out that using multiple RTP sessions and transport flows allow one to
have multiple different priority levels.

5. Section 2.1:
   This specification does not assume that the implementation will have
   access to ICMP or raw IP.

I think it should point out the advantage of being capable of receiving
ICMP in MTU discovery.

In addition I think you can bring up the benefits from being capable of
setting DF bit.

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

I would question if this at all should be discussed. First of all a
TURN/TCP or TURN/TLS/TCP relay fulfills the needs to cross a only TCP
allowing firewall. Secondly, if one likes to use TCP/TLS/RTP/SAVPF then
one would need to use RFC 4571 framing, or do you have another proposal?
I would also note that such a combination do require us to do a bit of
specification work to bring RFC 4571 up to date to allow us use both
profiles beyond AVP as well as indicating usage of DTLS-SRTP over that
TCP framing. Considering that this appears to be a redundant and less
likely to work mechanism I would propose to remove it from consideration
even for MAY.

7. Section 2.2.:

   o  TURN, including TURN over TCP[RFC5766].

Missing space between TCP and reference.

8. Section 2.2:

   TURN over TLS over TCP MAY be supported.  (QUESTION: SHOULD?  MUST?)

I think MAY is a fine level for this. But it clearly should be an issue
raised to the WG for further debate.

9. Section 2.3:
   The setup protocol for RTCWEB data channels is described in
   [I-D.jesup-rtcweb-data-protocol].

That draft is now a WG draft.

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

A. I would note that one actually must be capable of multiplexing DTLS,
RTP and STUN messages on the same port pair.

B. What about that needed reference. I think it is
draft-ietf-rtcweb-data-channel that should have this text.

11. Section 4:

I think this document do need to discuss DSCP and ICMP and the issues
they can cause. Or possibly provide input to the security consideration
document.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------