Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-06.txt

From: [email-masked]
Date: Mon, 21 Oct 2013 12:13:13 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF.

	Title           : RTCWeb Data Channels
	Author(s)       : Randell Jesup
                          Salvatore Loreto
                          Michael Tuexen
	Filename        : draft-ietf-rtcweb-data-channel-06.txt
	Pages           : 15
	Date            : 2013-10-21

Abstract:
   The Real-Time Communication in WEB-browsers (RTCWeb) working group is
   charged to provide protocol support for direct interactive rich
   communication using audio, video, and data between two peers' web-
   browsers.  This document specifies the non-media data transport
   aspects of the RTCWeb framework.  It provides an architectural
   overview of how the Stream Control Transmission Protocol (SCTP) is
   used in the RTCWeb context as a generic transport service allowing
   WEB-browsers to exchange generic data from peer to peer.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-channel

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-data-channel-06

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Thu, 24 Oct 2013 16:41:43 +0000

I have some comments/questions about draft-ietf-rtcweb-data-channel-06.

The last paragraph of section 6.4 is a little ambiguous, but also seems to contradict the decision that the same stream identifier will be used in both directions.  I assume that "number" and "stream value" in the paragraph both refer to SCTP "stream identifier"?  Shouldn't the paragraph say that while SCTP does not constrain allocation of the stream identifier in the two directions, a bidirectional data channel is defined as a pair of streams in opposite directions that use the same stream identifier?

The discussion in the 3rd paragraph of section 6.5, which describes some constraints on external negotiation, is a bit confusing to me.  I assume that "picks a Stream" is intended to mean "picks a Stream Identifier"?  For clarity I would prefer the latter, unless something else is intended.

In the same paragraph, DTLS role is used as a possible way of determining whether one side can select odd or even stream identifiers, but this is problematic.  It must be possible for the side requesting (offering) the peer connection to open a data channel before DTLS role can be determined.  How can the application know whether to request an odd or even stream identifier for a data channel if it doesn't know the DTLS role yet?  May I suggest that a better example would be to say that selection is based on which side sends the initial SDP offer creating the peer connection (e.g., the initial offerer picks even stream identifiers and the initial answerer picks odd stream identifiers).

In the same paragraph, the last sentence points out that the other side must inform the protocol to expect data using the stream identifier selected by the first side, but must also select parameters for use with data that it sends.  I assume that this text requires that the same stream identifier be used for the streams in both directions, but this is not stated clearly.  If not, do you assume that external negotiation establishes unidirectional channels only?  If the latter, are the sending parameters relevant to the other side?  Is something else intended?

Section 6.6 says that the "higher level" can override the default reliability options with per-message options.  I don't think this is allowed by the API, or did I miss something?  While I know that SCTP could potentially allow this with API support, it seems confusing to describe capabilities not available from the API without some clarifying text.

Thanks,
Richard

---

From: Randell Jesup <[email-masked]>
Date: Sun, 27 Oct 2013 05:22:12 -0400

> I have some comments/questions about draft-ietf-rtcweb-data-channel-06.

Thanks!

> The last paragraph of section 6.4 is a little ambiguous, but also seems to contradict the decision that the same stream identifier will be used in both directions.  I assume that "number" and "stre…

Likely we should remove the Note in 6.4 that allows bidirectional 
streams to have different SCTP Stream numbers in each direction - I'm 
pretty sure this is left over from before the switch from 3-way 
handshake to 1-way declarative.

> The discussion in the 3rd paragraph of section 6.5, which describes some constraints on external negotiation, is a bit confusing to me.  I assume that "picks a Stream" is intended to mean "picks a…

I'll look; that seems reasonable.

> In the same paragraph, DTLS role is used as a possible way of determining whether one side can select odd or even stream identifiers, but this is problematic.  It must be possible for the side requ…

That breaks down when a server decides to connect two offers together 
(i.e. an offer could be transformed into an answer to an existing offer 
(and the same for the other direction) without either side knowing).  
This is done in SIP servers all the time (surprised me the first time I 
ran into it), along with offers that originate "in the middle" from the 
server or SBC.   Kinda evil, but stuff like this will be done I believe, 
given the server is also normally supplying the JS application and so it 
would expect this behavior.

The stream ID used is selected once the DTLS role is known.  In W3 
terms, the channel.id isn't a valid value immediately when calling 
createDataChannel before SetLocal/RemoteDescription.  Before that 
happens (at the W3 api level), we currently return an invalid ID (65535 
- max per the data channel spec is 65534).

> In the same paragraph, the last sentence points out that the other side must inform the protocol to expect data using the stream identifier selected by the first side, but must also select paramete…

They must inform the other side in some manner so that the other side 
knows why data is appearing on a specific stream id.  The W3 side is 
based on the assumption that DataChannels (W3 level) are bidirectional 
and have a consistent 'id' value on both sides.  (see comments about 6.4 
above)

The intention was to define an external negotiation as the equivalent to 
internal - i.e. reliability settings SHOULD be provided, and SHOULD 
match on both sides.  This was specifically not a MUST, and the decision 
to match or not is in the application's hands.

> Section 6.6 says that the "higher level" can override the default reliability options with per-message options.  I don't think this is allowed by the API, or did I miss something?  While I know tha…

The current WebRTC W3 API does not allow for this.  However, this draft 
is designed to work if that were to change, as there's no technical 
reason the IETF-level spec has to require that.  (This is similar to the 
use of SHOULD on matching the reliability options in external 
negotiation.)  For example, perhaps CLUE would use data-channels, and 
would want to use an optional per-message reliability to override the 
default.  This would require that both ends know and expect this can happen.

-- 
Randell Jesup -- rjesup a t mozilla d o t com

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 28 Oct 2013 20:20:47 +0100

On Oct 27, 2013, at 10:22 AM, Randell Jesup <[email-masked]> wrote:

> Likely we should remove the Note in 6.4 that allows bidirectional streams to have different SCTP Stream numbers in each direction - I'm pretty sure this is left over from before the switch from 3-way handshake to 1-way declarative.
We might want to bring this up in the presentation on data channels at the IETF.
Just to make sure everyone has the same understanding on external negotiated channels...

Best regards
Michael
> That breaks down when a server decides to connect two offers together (i.e. an offer could be transformed into an answer to an existing offer (and the same for the other direction) without either side knowing).  This is done in SIP servers all the time (surprised me the first time I ran into it), along with offers that originate "in the middle" from the server or SBC.   Kinda evil, but stuff like this will be done I believe, given the server is also normally supplying the JS application and so it would expect this behavior.
> 
> The stream ID used is selected once the DTLS role is known.  In W3 terms, the channel.id isn't a valid value immediately when calling createDataChannel before SetLocal/RemoteDescription.  Before that happens (at the W3 api level), we currently return an invalid ID (65535 - max per the data channel spec is 65534).
> 
> They must inform the other side in some manner so that the other side knows why data is appearing on a specific stream id.  The W3 side is based on the assumption that DataChannels (W3 level) are bidirectional and have a consistent 'id' value on both sides.  (see comments about 6.4 above)
> 
> The intention was to define an external negotiation as the equivalent to internal - i.e. reliability settings SHOULD be provided, and SHOULD match on both sides.  This was specifically not a MUST, and the decision to match or not is in the application's hands.
> 
> The current WebRTC W3 API does not allow for this.  However, this draft is designed to work if that were to change, as there's no technical reason the IETF-level spec has to require that.  (This is similar to the use of SHOULD on matching the reliability options in external negotiation.)  For example, perhaps CLUE would use data-channels, and would want to use an optional per-message reliability to override the default.  This would require that both ends know and expect this can happen.
> 
> -- 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>