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

[Randell Jesup <[e-mail]>]

On 10/24/2013 12:41 PM, Ejzak, Richard P (Richard) wrote:
> 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 "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?

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 Stream Identifier"?  For clarity I would prefer the latter, unless something else is intended.

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 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).

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

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 that SCTP could potentially allow this with API support, it seems confusing to describe capabilities not available from the API without some clarifying text.

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