Subject: [rtcweb] AD review of draft-ietf-rtcweb-data-channel

From: Richard Barnes <[email-masked]>
Date: Fri, 8 Aug 2014 16:27:33 -0400

I have reviewed this document in preparation for IETF Last Call.  I have
gone ahead and requested last call, but there are some comments below that
I would like to be addressed before the document goes to the IESG.
--Richard

MAJOR:

Section 6.2.
I'm very concerned about interoperability of data channels given that,
e.g., (1) DCEP [draft-ietf-rtcweb-data-protocol] is not required, and (2)
DCEP only works if it is used by both endpoints (it resets any streams that
are used without DCEP negotiation).  In order to avoid interoperability
failure of this type, whatever mechanism is used to establish an SCTP
association that is used for data channels must also negotiate the
mechanism(s) that will be used to establish data channels over that
association.  That could be directly (by negotiating some data channels at
the same time as the association), or indirectly (by indicating that DCEP
or some other protocol will be used), but either way, the endpoints of the
association need to know how data channels will be negotiated before they
can create any data channels.  This section needs to state this requirement
so that applications using data channels can know that they need to meet it.

Section 6.4.
This section lists in passing several properties of a data channel, but
doesn't give a full definition of all the things that need to be defined in
order to define a data channel.  Fortunately, such a list is given in
draft-ietf-rtcweb-data-protocol (Section 4); I would suggest moving that
here.

MINOR / EDITORIAL:

Figures 1 and 2 list ICE as a separate layer.  That seems incorrect, since
ICE isn't actually involved once the connection is set up.

Section 6.4. "... in-sequence, out-of-sequence, reliable and unreliable as
properties of channels"
"... (as opposed to SCTP, which applies these concepts to messages)"

Section 6.4. "... and waiting for onopen to fire ... meaning of the streams"
This sentence doesn't really parse, and it's not clear why these API-level
considerations are relevant here.

Section 6.4. "stream SCTP identifier" -> "SCTP stream identifier" ?

Section 6.6. "The sender SHOULD disable the Nagle algorithm..."
A reference to RFC 1122 would be helpful here.

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 11 Aug 2014 12:53:15 +0200

On 08/08/2014 10:27 PM, Richard Barnes wrote:
> I have reviewed this document in preparation for IETF Last Call.  I 
> have gone ahead and requested last call, but there are some comments 
> below that I would like to be addressed before the document goes to 
> the IESG.
> --Richard
>
>
> MAJOR:
>
> Section 6.2.
> e.g., (1) DCEP [draft-ietf-rtcweb-data-protocol] is not required, and 
> (2) DCEP only works if it is used by both endpoints (it resets any 
> streams that are used without DCEP negotiation).  In order to avoid 
> interoperability failure of this type, whatever mechanism is used to 
> establish an SCTP association that is used for data channels must also 
> negotiate the mechanism(s) that will be used to establish data 
> channels over that association.  That could be directly (by 
> negotiating some data channels at the same time as the association), 
> or indirectly (by indicating that DCEP or some other protocol will be 
> used), but either way, the endpoints of the association need to know 
> how data channels will be negotiated before they can create any data 
> channels.  This section needs to state this requirement so that 
> applications using data channels can know that they need to meet it.

I *think* this is a concern we have discussed before, and decided that 
it's not relevant.

There are two states a receiver can be in:

1) It has external knowledge of what is expected on a particular data 
channel
2) It has no such external knowledge.

There are two actions a sender can do:

A) Send a data-protocol open packet
B) Send data without a data-protocol packet

This produces four outcomes:

1A: The sender sends an open packet that the receiver was not expecting.
1B: The sender sends data, and the receiver knows what to expect. All is OK.
2A: The sender sends an open packet, and the receiver knows from the 
packet what to do. All is OK.
2B: The sender sends data, and the receiver has no configuration to match.

1A and 2B are the problematic cases, and both can occur only as a result 
of misconfiguration, where the two sides have different opinions.

The WG decided to leave out the actual mechanism for this configuration 
from the spec, and most emphatically did not design an SDP-based 
mechanism to negotiate some channels.

The WG also decided that this decision is done for each channel 
independently - there is no need for an overall decision for all 
channels up front. As long as a channel number is free, either mechanism 
can start using it.

Summary: I disagree with the concern. I think this issue has been 
discussed, and the WG has found consensus that it is a problem that does 
not need to be solved.

Harald

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 26 Aug 2014 21:39:29 +0200

On 08 Aug 2014, at 22:27, Richard Barnes <[email-masked]> wrote:

> I have reviewed this document in preparation for IETF Last Call.  I have gone ahead and requested last call, but there are some comments below that I would like to be addressed before the document goes to the IESG.
> --Richard
Richard,

thank you very much for the review. See my comments in-line.

Best regards
Michael
> 
> 
> MAJOR:
> 
> Section 6.2. 
> I'm very concerned about interoperability of data channels given that, e.g., (1) DCEP [draft-ietf-rtcweb-data-protocol] is not required, and (2) DCEP only works if it is used by both endpoints (it resets any streams that are used without DCEP negotiation).  In order to avoid interoperability 
Streams are only reset, if they are already used.
> failure of this type, whatever mechanism is used to establish an SCTP association that is used for data channels must also negotiate the mechanism(s) that will be used to establish data channels over that association.  That could be directly (by negotiating some data channels at the same time as the association), or indirectly (by indicating that DCEP or some other protocol will be used), but either way, the endpoints of the association need to know how data channels will be negotiated before they can create any data channels.  This section needs to state this requirement so that applications using data channels can know that they need to meet it.
I don't think they need it at the time the association is created, they need this information
at the time a data channel is created. This is described in the first paragraph of section 6.5.
What about changing there:
   The details are out of scope of this document.
to
   The details are out of scope of this document.  Applications using
   data channels need to use the negotiation methods consistently on
   both end-points.
> 
> Section 6.4. 
> This section lists in passing several properties of a data channel, but doesn't give a full definition of all the things that need to be defined in order to define a data channel.  Fortunately, such a list is given in draft-ietf-rtcweb-data-protocol (Section 4); I would suggest moving that here.
I agree, this is much cleaner in draft-ietf-rtcweb-data-protocol. What about using

6.4.  WebRTC Data Channel Definition

   One strong wish is for the application-level API to be close to the
   API for WebSockets, which implies bidirectional streams of data and a
   textual field called 'label' used to identify the meaning of the data
   channel.

   The realization of a data channel is a pair of one incoming stream
   and one outgoing SCTP stream having the same SCTP stream identifier.
   How these SCTP stream identifiers are selected is protocol and
   implementation dependent.  This allows a bidirectional communication.

   Additionally, each data channel has the following properties in each
   direction:

   o  reliable or unreliable message transmission.  In case of
      unreliable transmissions, the same level of unreliability is used.
      Please note that in SCTP this is a property of an SCTP user
      message and not of an SCTP stream.

   o  in-order or out-of-order message delivery for message sent.
      Please note that in SCTP this is a property of an SCTP user
      message and not of an SCTP stream.

   o  A priority, which is a 2 byte unsigned integer.  These priorities
      MUST be interpreted as weighted-fair-queuing scheduling priorities
      per the definition of the corresponding stream scheduler
      supporting interleaving in [I-D.ietf-tsvwg-sctp-ndata].  For use
      in WebRTC, the values used SHOULD be one of 128 ("below normal"),
      256 ("normal"), 512 ("high") or 1024 ("extra high").

   o  an optional label.

   o  an optional protocol.

   Please note that for a data channel being negotiated with the
   protocol specified in [I-D.ietf-rtcweb-data-protocol] all of the
   above properties are the same in both directions.

Does this address your comment?
> 
> 
> 
> MINOR / EDITORIAL:
> 
> Figures 1 and 2 list ICE as a separate layer.  That seems incorrect, since ICE isn't actually involved once the connection is set up.
Doesn't ICE continue to run connectivity checks continuously and even allows changes
of the IP addresses being used for the communication?
> 
> Section 6.4. "... in-sequence, out-of-sequence, reliable and unreliable as properties of channels"
See above.
> This sentence doesn't really parse, and it's not clear why these API-level considerations are relevant here.
See above.
> Section 6.4. "stream SCTP identifier" -> "SCTP stream identifier" ?
Changed.
> A reference to RFC 1122 would be helpful here.
OK. Added as an Informative Reference.
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb