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

[Magnus Westerlund <[e-mail]>]

Hi,

I have reviewed the Transports for RTCWEB
(draft-ietf-rtcweb-transports-02) and have the following comments.

1. Section 1.

 This document focuses on the data
   transport protocos that are used by conforming implementations.

Missing "l" in protocos.

2. Section 3.1:
   For both protocols, IPv4 and IPv6 support is assumed; applications
   MUST be able to utilize both IPv4 and IPv6 where available.

What "applications" are intended in this sentence. I get a feeling that
"applications" here could be replaced by "WebRTC implementations"


3. Section 3.1:
   For UDP, 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.dhesikan-tsvwg-rtcweb-qos] when multiple media types are
   multiplexed.  It does not assume that the DSCP codepoints will be
   honored, and does assume that they may be zeroed or changed, since
   this is a local configuration issue.

I wonder if this should be moved into 3.2 section instead. At least the
part in 3.1 should focus on the DSCP setting part on the transport flow.
The implications of it working or not should be moved to 3.2. A forward
pointer to that second can be used instead.

4. Order of Section 3.2 and 3.3.

I think the order should be swapped between 3.2. and 3.3. That way the
Multiplexing section can provide definitions of all the stream concepts
that exists in WebRTC and how they can be combined. More about this later.

5. Content of Section 3.2

This section needs to be expanded to start with a general discussion of
how QoS can be applied to get a benefit. But, I think one need to be
clear that it can't be assumed to be available in implementations or
WebRTC based applications.

It needs to also discuss flow-based QoS mechanism. What are the
implications if that is what is available and what choices does one have
to address this by configuring the multiplexing different. I think this
is the logical place to take the main discussion of that, as it can
address both RTP streams and the data channel together. Please consider
pointers to appropriate discussion in Section 12.1.3 in
draft-ietf-rtcweb-rtp-usage.

I do note that writing this section appropriately is difficult until the
content of draft-dhesikan-tsvwg-rtcweb-qos has firmed up.

6. Content of Section 3.3:

I think this section should focus on making clear what different types
of streams that exist in the WebRTC context, and what choices of
multiplexing that are possible. Basically ensure that the full set of
combinations are made clear.

A. All RTP packet streams and data channel over a single UDP flow.

B. All RTP packet streams over one UDP flow and the data channel over
another UDP flow.

C. The RTP packet streams over different UDP flows based on content type
and separate data channel.

D. Each RTP packet stream over its own UDP flow (RTP session) and the
data channel over its own UDP flow.

The above with the additional dimension, that each RTP sessions, RTCP
can be in its own UDP flow.

There is also a question if the data channel can be aggregated with only
one RTP session, where there are multiple ones configured.

The QoS related discussion of this can be moved to the QoS section to
keep that focused.

However, the discussion of the pro and cons with having one or more flow
is good and could even be expanded to list reasons such as legacy
interop over a gateway.

7. Section 3.3:
   RTCWEB implementations MUST support the ability to send and receive
   multiple SSRCs on the same transport, and MUST support the ability to
   send and receive multiple SSRCs on multiple simultaneous transports,
   including the ability to send and receive audio and video on the same
   transport.

I think this sentence is restating what is already required by Section
4.1 in draft-ietf-rtcweb-rtp-usage: If you want to enforce this, I
suggest to do that by reference to that text rather than using RFC 2119
normative statements.


8. Section 3.4:
   ICE [RFC5245] MUST be supported.  The implementation MUST be a full
   ICE implementation, not ICE-Lite.

   In order to deal with situations where both parties are behind NATs
   which perform endpoint-dependent mapping (as defined in [RFC5128]
   section 2.4), TURN [RFC5766] MUST be supported.

These paragraph implies STUN and TURN server configuration. Should that
configuration question be discussed with the appropriate pointers to the
API?

9. Section 3.4:
   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.
   See [RFC5766] section 2.1 for details.

I think the following part: "TURN using TLS between" should be changed
over "TURN using TLS over TCP between" to make it clear that this is
using TLS/TCP rather than TLS/FOO.

10. Section 3.4:
   TURN TCP candidates [RFC6062] SHOULD be supported; this allows
   applications to achieve peer-to-peer communication when both parties
   are behind UDP-blocking firewalls using a single TURN server.  (In
   this case, one can also achieve communication using two TURN servers
   that use TCP between the server and the client, and UDP between the
   TURN servers.)

My understanding of RFC6062 is that it allows one to establish a vanilla
TCP connection on the far side of the TURN server as well as connecting
that one to an almost vanilla TCP connection (just a initial TURN
ConnectionBind request) that A establish to the TURN server, i.e.
WebRTC-A -(Turn/TCP)-> TURN_Server -(TCP)-> WebRTC-B.

The end-result is that a relayed vanilla TCP connection is established
between the WebRTC endpoints (A and B). As the WebRTC transport so far
defined only works with datagrams, i.e. DTLS or RTP/RTCP packets they
can't be sent natively over a TCP byte stream. Thus, if this mode of
operation is to be supported a framing is required on this leg.

A possibility here could be RFC 4571 if one want to go this way.

11. Section 3.4:

   ICE-TCP candidates [RFC6544] MAY be supported; this may allow
   applications to communicate to peers with public IP addresses across
   UDP-blocking firewalls without using a TURN server.

Also this option would need to use a framing of the datagrams.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------