[rtcweb] Review Comments on draft-ietf-rtcweb-transports-04.txt

[Magnus Westerlund <[e-mail]>]

Harald and WG,

I am catching up on the changes and improvements in the two latest
versions. I have tried to do a complete review through and match with my
previous comments.

First of all, I think the two revisions have improved a number of things.

1. Section 3.1:
   Platforms that do not give access to these interfaces will not be
   able to support a conforming RTCWEB implementation.

I am very split over this statement. We do want platforms to support per
packet DSCP markings, while at the same time we know we might not be
able to set DSCP at all for a transport flow (5-tuple). Thus, I wonder
if calling the implementations non-conformant due to the underlying
platform is a bit though.

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

But, to my understanding we have things that could benefit from getting
the information from ICMP, e.g. the SCTP MTU discovery mechanism. Thus,
I wonder if this statement should be changed to:

   This specification does not assume that the implementation will have
   access to ICMP or raw IP, however access to ICMP information can
   benefit the WebRTC implementation and its performance.

3. Section 3.4:
   TURN TCP candidates [RFC6062] MAY be supported.

   However, such candidates are not seen as providing any significant
   benefit.  First, use of TURN TCP would only be relevant in cases
   which both peers are required to use TCP to establish a
   PeerConnection.  Secondly, that use case is anyway supported by both
   sides establishing UDP relay candidates using TURN over TCP to
   connect to the relay server.  Thirdly, using TCP only between the
   endpoint and its relay may result in less issues with TCP in regards
   to real-time constraints, e.g. due to head of line blocking.

I think these two paragraphs should be moved to after the following
paragraph:

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

>From a discussion of WebRTC RTP or DTLS packets over TCP, it makes
better sense to first discuss the ICE TCP candidates, then discuss why
TCP candidates from TURN makes less so.

4. Section 3.4:
   If TCP connections are used, RTP framing according to [RFC4571] MUST
   be used, both for the RTP packets and for the DTLS packets used to
   carry data channels.

I think this paragraph forgets the encapsulation of the STUN messages
that ICE emits for initial path verification and nomination, as well as
for keep-alive and consent freshness.

5. section 3.4:

   NOTE IN DRAFT: This may be added.

I don't understand this note.

6. Section 3.5:

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

First of all, this pointer is the individual version rather than WG draft.

Secondly, I think the DCEP shall be mandated to be supported by an
WebRTC implementation in this specification, and thus become a normative
reference also.

7. Section 4:

   The RTCWEB prioritization model is that the application tells the
   RTCWEB implementation about the priority of media and data flows
   through an API.

As we have discussed before in regards to DART as well as
draft-ietf-tsvwg-rtcweb-qos has needs for clear definitions what is
meant with media and data flows here. But, reading this section it is
clear that the document itself has need for clear definitions.

A data flow appear to be the one of the SCTP streams that forms a single
data channel, as this is the level where we assign data priority.

A WebRTC media flows is a more complex beast. It is one or more RTP
packet streams (draft-ietf-avtext-grouping-taxonomy), i.e. the RTP
packets associated with an SSRC. However, due to FEC and RTP
retransmission as well as scalable codecs, there could be multiple SSRCs
that carries data associated and possibly necessary to be able to
perform media decoding. Thus, I think we are talking about the RTP
packet streams that are the result of a single MediaStreamTrack within
one RTCPeerConnection.

I would also note that Section 4.1 uses Media Stream instead of media
flow. There are need for alignment here.

8. Section 4.1:

I think this section is a good start. It clearly needs some more input.
Especially about the notes made.

In addition to the first three configurations, I think the one where one
has different transport flows per priority level for the media flows
appears to be one most likely to require mandating implementation
support. Yes this means that I also would like to mandate implementation
support for the one transport flow per media type configuration.

9. Section 4.1:

A receiving implementation MUST be able to receive media and data in
   all these configurations.

It is very unclear what "all" in the above sentence includes.

10. Section 4.2:

First of all I do wonder if this is the right solution. I haven't yet
spent enough time on the issue to know if the proposal is useful and
good enough, or if we need something else. I do encourage people to
consider this. However, considering Simon Perrault's comment, I do want
to state that I share Harald's view that this prioritization behavior
needs to be consistent over the implementations.

11. Section 4.2:
   This prioritization is independent of the
   media type, but will lead to packet loss due to full send buffers
   occuring first on the highest volume flows at any given priority
   level.

I think I have two questions here. First, I appears that you assume that
you have an API model where the framework will try to send and fail
rather than creating the data based on allowance or with the knowledge
that you can send a particular data amount. I think creating sender side
buffer overflow is a poor regulation model.

Secondly, I would not that this issue has a higher probability of
effecting the flow with most data first.

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