[rtcweb] Comments on draft-ietf-rtcweb-data-channel-06

[Magnus Westerlund <[e-mail]>]

Hi,

I did review the data channel draft prior to the meeting and thought I
would provide my comments.

1. Usage of RTCWeb vs WebRTC when referring to the whole solution. My
recollection was that we agreed to use WebRTC for this. I think we
should try to align this language. Audio, Security and RTP usage uses
WebRTC, while Data channel, overview and Transport uses RTCWeb.

2. Section 3.2:
   U-C 6:  Renegotiation of the set of media streams in the
      PeerConnection.

What "media streams" are being referred to here. Or is i better to
express this as "Renegotiation of the configuration of the PeerConnection."?

3. Section 3.2:
   U-C 7:  Proxy browsing, where a browser uses data channels of a
      PeerConnection to send and receive HTTP/HTTPS requests and data,
      for example to avoid local internet filtering or monitoring.

Yes, this may be something that is possible, but to express it as a use
cases intended to be supported might not be the best. We are after all
likely talking about circumventing local security policies. I would also
note that "Internet" is with capital I.

4. Section 4:
   Req. 1:   Multiple simultaneous data channels MUST be supported.
      Note that there may 0 or more media streams in parallel with the
      data channels, and the number and state (active/inactive) of the
      media streams may change at any time.

Which "media stream" are you referring to in the above?

5. Section 4:
   Req. 3:   Data channels MUST be congestion controlled; either
      individually, as a class, or in conjunction with the media
      streams, to ensure that data channels don't cause congestion
      problems for the media streams, and that the RTCWeb PeerConnection
      as a whole is fair with competing traffic such as TCP.

A: What "media stream" are you referring to here?

B: "and that the RTCWeb PeerConnection
      as a whole is fair with competing traffic such as TCP."

I don't think it is a MUST requirement. Neither am I convinced that a
PeerConnection needs to be fair with an unspecified number of TCP
traffic. It might be simplest to strike the last part.

6. Section 4:
[ TBD: how this is encoded and what the impact of this is. ]

Didn't we have some direction decisions on how priority was to be
handled at least locally by the end-point. Please add this to the draft.
I also hope that the way of representing priorities can get clearer from
an API perspective.

7. Section 5:
"   o  The congestion control is modifiable for integration with media
      stream congestion control."

I think this is an exaggeration, and not supported by current sets of
specifications, if it is supported please provide a reference.

8. Section 5:
"Using DTLS over UDP in combination with ICE enables NAT traversal in
IPv4 based networks."

I would like to point out that ICE do provide firewall traversal for
firewalls with certain type of filtering rules like the basic stateful
filtering. These apply to IPv6 equally, not only IPv4.

9.  Section 5:
"   Each SCTP user message contains a so called Payload Protocol
   Identifier (PPID) that is passed to SCTP by its upper layer and sent
   to its peer.  This value can be used to multiplex multiple protocols
   over a single SCTP association.  The sender provides for each
   protocol a specific PPID and the receiver can demultiplex the
   messages based on the received PPID."

I have some difficulties in determining the relevance of this in the
context of WebRTC. Can you please provide a clear explanation why PPID
are relevant here. Will not all traffic from an WebRTC endpoint use the
PPIDs associated with the data protocol, rather than any "native" PPIDs?

10. Section 5:

Can you please clarifiy the demultiplexing for WebRTC by discussing
STUN, vs SRTP vs DTLS and secondly that DTLS-SRTP and DTLS frames with
SCTP can co-exist in the same DTLS stack. At least on an level where you
can point to all the relevant sections in other specifications to
explain that these can coexist given certain constraints. This is likely
its own sub-section.

11. Section 5:

   o  shares the DTLS connection with the media channels.

what is "media channels"?

12. Section 5:
"  Since DTLS is typically implemented in user-land, the SCTP stack also
   needs to be a user-land stack."

I wonder what the message of this sentence is? The reason is that I
wonder what it should be saying if one implements DTLS in a kernel, or
similar if one despite a DTLS user-land stack uses a SCTP stack in the
kernel through access to raw sockets.

13. Section 5:
   Incoming ICMP or ICMPv6 messages can't be processed by the SCTP
   layer, since there is no way to identify the corresponding
   association.

Also here I get a bit confused, I assume what you are after is the issue
that incoming ICMP messages will be arriving related to the UDP flow,
not in relation to an kernel SCTP association, thus there is a routing
issue for ICMP to reach the above DTLS existing SCTP association. Not
impossible to solve, just not available with existing APIs.

14. Section 5:
   "This protocol stack MUST support the usage of multiple SCTP streams."

I wonder which layer is affected by this. Isn't this only affecting SCTP
implementation and the higher layers? Can't you be more specific thus?

15. Section 5:
   Using a congestion control
   different from the standard one might improve the impact on the
   parallel SRTP media streams.  Since SCTP does not support the
   negotiation of a congestion control algorithm, alternate congestion
   controls SHOULD only require a different sender side behavior using
   existing information carried in the association.

A: I wonder if adding a "yet" into the second sentence to make clear
that in the future there might be support for negotiating congestion
control.

B: Also, what happens if one violate the SHOULD and require receiver
side information and the peer don't support it. That clearly can't be
acceptable? Can this be formulated in some other way that is tighter
without preventing sender side changes?

16. Section 6.1:
   o  The dynamic address reconfiguration extension defined in [RFC5061]
      MUST be used to signal the support of the stream reset extension
      defined in [RFC6525], other features of [RFC5061] MUST NOT be
      used.

A question, are theses other features, destructive to the SCTP
association, or simply unnecessary to implement? If it is the first,
then I think MUST NOT be used is fine, but if else, why not simple say
that they are NOT REQUIRED to be implemented?


17. Section 6.1:
   o  The partial reliability extension defined in [RFC3758] MUST be
      supported.  In addition to the timed reliability PR-SCTP policy
      defined in [RFC3758], the limited retransmission policy defined in
      [I-D.tuexen-tsvwg-sctp-prpolicies] MUST be supported.

So what is the status of this individual document, did it get adopted
into TSVWG? I think this is an important question, as it is one thing
where we can consider going forward without the extension and add it
later when ready?

18. Section 6.2:
"  Additionally,
   the negotiation SHOULD include some type of congestion control
   selection. "

Okay, this appears very fuzzy. And what name space or specifications are
you going to use to negotiate what the different options are?

19. Section 6.3:
It will use the DTLS connection selected via SDP;
   typically this will be shared via BUNDLE or equivalent with DTLS
   connections used to key the DTLS-SRTP media streams.

In which way is the DTSL connection "selected" via SDP?

20. Section 6.2:

   When one side wants to open a channel using external negotiation, it
   picks a Stream.  This can be based on the DTLS role (the client picks
   even stream identifiers, the server odd stream identifiers) or done
   in a different way.  However, the application is responsible for
   avoiding collisions with existing Streams.  If it attempts to re-use
   a Stream which is part of an existing Channel, the addition SHOULD
   fail.  In addition to choosing a Stream, the application SHOULD also
   inform the protocol of the options to use for sending messages.  The
   application MUST ensure in an application-specific manner that the
   other side will also inform the protocol that the selected Stream is
   to be used, and the parameters for sending data from that side.

So why is this specified here and not in the Data Protocol? Especially
using RFC 2119 terms, it appears to be colliding or at least overlapping
specifications?

21. Section 6.6
   It is recommended that message size be kept within certain size
   bounds (TBD) as applications will not be able to support arbitrarily-
   large single messages.

I guess this will be resolved by the WG session agreement, or?

22.

Section 8:
              +---------------------+-----------+-----------+
              | Value               | SCTP PPID | Reference |
              +---------------------+-----------+-----------+
              | DOMString Last      | 51        | [RFCXXXX] |
              | Binary Data Partial | 52        | [RFCXXXX] |
              | Binary Data Last    | 53        | [RFCXXXX] |
              | DOMString Partial   | 54        | [RFCXXXX] |
              +---------------------+-----------+-----------+

Where are the definitions of these definitions?

23. Section 10.2:

   [I-D.tuexen-tsvwg-sctp-prpolicies]
              Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto,
              "Additional Policies for the Partial Delivery Extension of
              the Stream Control Transmission Protocol", draft-tuexen-
              tsvwg-sctp-prpolicies-03 (work in progress), October 2013.

This is a normative reference.

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