Re: [rtcweb] #13: Transport of DATA_CHANNEL_OPEN

[Randell Jesup <[e-mail]>]

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.

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

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]