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

[Michael Tuexen <[e-mail]>]

On Nov 11, 2013, at 2:54 PM, Magnus Westerlund <[e-mail]> wrote:

> 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.
OK. Changed to WebRTC. Although the WG uses rtcweb as its acronym...
> 
> 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."?
I think the media streams of the PeerConnection are considered...
However, you might want to reconfigure the PeerConnection. So, yes, your
text makes sense. I changed the use case.
> 
> 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.
Change to Internet. The use case seems important, since there are already
implementations doing this (possibly not using data channels, don't know).
Randell: What do you think?
> 
> 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?
The PeerConnection can have 0 or more media streams (SRTP on the wire)
in addition to data channels. I changed it to:

<t>Multiple simultaneous data channels MUST be supported.
Note that there may 0 or more media streams in parallel with the data channels
in the same PeerConnection, and the number and state (active/inactive) of
these media streams may change at any time.</t>

> 
> 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?
The media streams of the PeerConnection...
> 
> 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.
But if you remove the last part the CC of the data channel only needs
to ensure that it doesn't case congestion problems for the media channels.
So if there are no media streams, the CC of the data channels could be
much more aggressive than TCP. I don't think this is what we want. So
I keep that for now. But I'm open for discussion.

Changed to:

<t>Data channels of a PeerConnection MUST be congestion controlled;
either individually, as a class, or in conjunction with the media streams
of the PeerConnection, to ensure that data channels don't cause congestion
problems for these media streams, and that the WebRTC PeerConnection as
a whole is fair with competing traffic such as TCP.</t>

> 
> 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 think we decided to have priorities for data channels, which are not strict
priorities. That is all. The W3C document doesn't mention it.
> I also hope that the way of representing priorities can get clearer from
> an API perspective.
I agree. However, I'm not a member of W3C...
> 
> 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.
I think you can specify an alternate CC for SCTP. This is not done
right now, but it is doable. Therefore, I don't think it is a exaggeration,
it is just not done yet... If you have a suggestion for an better wording,
I'm open for suggestions.
> 
> 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.
Correct. I changed the wording to

Using DTLS over UDP in combination with ICE enables middlebox traversal
in IPv4 and IPv6 based networks.

> 
> 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?
We use one PPID for the Data Channel Establishment Protocol, one for
UTF-8 encoded user data and one for binary encoded user data. So we use
it...

I added at the end of the paragraph:

The PPID is used to distinguish UTF-8 encoded user data and binary encoded
userdata. The Data Channel Establishment Protocol defined in
<xref target='I-D.ietf-rtcweb-data-protocol'/> uses also a specific PPID to
be distinguished from user data.
> 
> 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.
Not sure... 
The demultiplexing STUN vs. SRTP vs. DTLS is described in
http://tools.ietf.org/html/rfc5764#section-5.1.2
SCTP is the only payload of DTLS. So there is no demultiplexing
done. I have added:

Please note that the demultiplexing STUN vs. SRTP vs. DTLS is done
as described in Section 5.1.2 of <xref target='RFC5764'/> and SCTP
is the only payload of DTLS.
> 
> 11. Section 5:
> 
>   o  shares the DTLS connection with the media channels.
> 
> what is "media channels"?
... the media channels of the PeerConnection.
> 
> 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
That you can't use a kernel SCTP stack, even if available.
> wonder what it should be saying if one implements DTLS in a kernel, or
I haven't seen this yet. I think you can do the encrypt/decrypt part,
but doing the key management stuff in kernel land doesn't seem appropriate.
> similar if one despite a DTLS user-land stack uses a SCTP stack in the
> kernel through access to raw sockets.
How can the lower layer run in userland when the upper layer runs in
kernel land?
> 
> 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.
No, it is not an API issue. The ICMP message contains the encrypted
DTLS packet which contains the SCTP packet. Normally, only part of the message
is returned. I think only 8 bytes of payload is returned. So this is
not enough for the DTLS header at all. So you simply might not have
enough information.
> 
> 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?
Yes. Changed to
<t>This SCTP stack and its upper layer MUST support the usage of multiple
SCTP streams.
> 
> 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?
OK. Changed to
Since SCTP does not support the negotiation of a congestion control algorithm
yet, alternate congestion controls SHOULD either only require a different
sender side behavior using existing information carried in the association or
need also specify a negotiation of of a congestion control algorithm.</t>
> 
> 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?

Changed to not REQUIRED, since NOT REQUIRED is not an RFC 2119 term.
> 
> 
> 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?
It has been adopted.
> 
> 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?
Randell? Salvatore? I don't think there is anything specified yet.
> 
> 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?
I think it should read ICE, not 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?
Since the Data Channel Establishment Protocol only covers setting up
the data channel via an internal mechanism. The above described the
external mechanism.
> 
> 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?
It will be signalled via SDP...
> 
> 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?
In Section 6.6.
> 
> 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.
OK. Please note that that ID is targeting for an Informational RFC...

Base on the above, I submitted a new revision.

Best regards
Michael
> 
> 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]
> ----------------------------------------------------------------------
> 
>