Re: [rtcweb] #13: Transport of DATA_CHANNEL_OPEN

["Ejzak, Richard P (Richard)" <[e-mail]>]

> On 4/29/2013 6:34 PM, Randell Jesup wrote:
> On 4/29/2013 7:11 AM, Ejzak, Richard P (Richard) wrote:
> > After remaining neutral during most of this discussion about the need
> for OPEN, I've finally come to the conclusion that Matthew is right.
> The only thing the OPEN provides is the label, which is just an opaque
> string with no meaning to the browser or any intermediaries.  It only
> has application significance.  If this is the case, why not just use
> stream id?  What can you possibly do with label that you can't do with
> pre-assigned stream ids (this is a serious question to Randell since it
> is fundamental to whether we need OPEN)?  Since label only has meaning
> when both browsers run the same application, what does it matter if you
> agree on a set of opaque strings to correspond to various functions or
> just agree on a set of stream ids for these functions?  It doesn't
> change the complexity of the code and it doesn't even change the
> readability of the code if you just enumerate the reserved stream ids
> and "label" them in the code.
> 
> ok, multi-point response:
> 
> Please review the proposed JS API & dictionary posted here and the W3
> list a while ago (4 weeks?)
> 
> 1) Label isn't the only data transmitted in the Open message. Protocol
> (which is particularly important to inter-operating apps, though can
> still be useful for homogenous apps), and also having the channel
> parameters be symmetric.  Channels don't have to be symmetric, but if
> they aren't then the receiver of the initial data would need to know by
> some external method what the reverse channel parameters should be, and
> then do operations to set it to the appropriate transfer mode.

For homogeneous apps, the choice of channel parameters can as easily be tied to the stream id as the label.   

The SCTP protocol id field should indicate the subprotocol being carried in the data channel, so I don't see the need to separately announce this. 

For non-homogeneous apps, there is no basis to negotiate anything until some standard subprotocols (beyond "raw data") are defined.  In some cases the subprotocol will dictate the channel parameters to be used (or will at least severely constrain the options), so defaults could be assumed in simple cases.  In most more complex cases you will need a real negotiation mechanism (instead of OPEN) since most protocols require negotiation of additional parameters that can't be expressed or negotiated using OPEN (e.g., the t.140 cps).

> 
> 2) labels can specify some easy tags for the channel.  For example, in
> a "Hangout", if the server opens up a private chat channel on behalf of
> another participant, it might do "pc.createDataChannel("Tom", {
> protocol: "application/funkychat"});".    The server might also open
> one
> with a label "Sarah", etc.  I also envisioned (in this mailing list) an
> FTP-like file transfer setup where the label is the filename being
> transferred.  (Think dragging a directory of files onto your chat
> session to transfer to the other person.)

This might be useful for some homogeneous apps, but the repeated use of the word "might" in your text implies that this is not a necessity and that there are reasonable alternatives.

My real point is just that the justification for OPEN is weak and we could easily do without it (assuming the proper handling of the protocol id).  Please consider this as a friendly proposal to enhance/simplify the current DataChannel proposal that should be considered if there is enough support.

> 
> That said, you can always push anything signaled in Open into an
> initial message in an ordered reliable channel.  When it's NOT ordered
> and reliable, then it gets more complex for the application to get
> initial setup done for simple uses (retries to handle packet loss, in-
> application acks, out-of-order delivery, etc, just to set up the
> channel, or run a separate reliable negotiation channel (more likely),
> which would need to be at least 1RTT to avoid races with trying to use
> the unreliable channel before it's set up, etc.  Yes, applications can
> deal with all this, but some applications will want a simple JS API and
> simple setup.  And it will be tough to get right in a 0-RTT use for
> non-reliable channels.
> 
> 3) I proposed something similar to your proposal a year ago, and
> discussion and comments from people expecting to use this convinced me
> to adapt the protocol proposal to include label (in particular comments
> from Justin Uberti, but there were others).   Perhaps some of them can
> chime in, as I can only do so well at describing how they intend or
> hope to use label.  The other major piece, protocol, was added at the
> strong request from the people in the room at IETF Atlanta.
> 
> Matthew's proposal is effectively little different than Martin's
> proposal from IETF Orlando (or Matthew's assumed proposal, as his
> comments aren't exactly an alternative proposal and some of the
> comments imply a different model with an RTMFP-like initial packet
> (i.e.
> Open....).  Per the minutes and earlier comments here, the agreement
> was to adopt the Open draft, and not proceed with either of the two
> alternatives given.  I'll leave how to resolve this issue to the
> chairs, and until told otherwise will continue to work on turning the
> personal draft into a WG document.  (And re-iterate my comments from
> before - I think we have a solution here that everyone can work with,
> even if it's not everyone's first choice.)
> 
> 
> 
> --
> Randell Jesup
> [e-mail]
> 
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb