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

[Gunnar Hellstrom <[e-mail]>]

I took a look at the data channel draft.

I am missing descriptions of the requirements of how transmission 
failures are to be handled.

I suggest that section   6.6 "Transferring User Data on a Channel" is 
extended with a description on what happens if the transmission fails.
It is evident that there will be different actions for the different 
types of channels.

For unordered, unreliable channels, I assume that neither the 
transmitter nor the receiver will be notified of transmission failures.

For ordered, semi-reliable channels, I assume that the transmitter is 
notified about failure if the transmitting channel has no indication of 
successful transmission after the specified number of retransmissions or 
milliseconds.
Same with the receiver, but the error notification may not appear until 
next transmission is received, so that the gap can be detected.

Also the so called ordered reliable channel may fail. It just has a 
higher number of retries over a longer time. So, same information should 
be provided for that type.

And, is there just an error notification and then open for trying next 
transmission, or is the channel broken and needs to be opened again. I 
suggest that transmission can continue after the error notification.

Can duplications be guaranteed to be avoided in the ordered channel?
Can there be cases when the transmitter gets a notification about 
failure, but the receiver has received the data successfully?

How is this reflected in WebRTC API:s?

Thanks,

Gunnar

On 2013-11-11 14:54, Magnus Westerlund 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.
>
> 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]
> ----------------------------------------------------------------------
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb