Subject: Re: [rtcweb] DataChannels API and external negotiation

From: Michael Tuexen <[email-masked]>
Date: Mon, 1 Apr 2013 11:38:29 +0200

On Apr 1, 2013, at 10:15 AM, [email-masked] wrote:

>> /* If either maxRetransmitTime or maxRetransmitNum are set, it's
>>   unreliable, else it's a reliable channel.  If both are set it's an
>>   error.
> 
> I don't think so (except if it's a limitation of SCTP that I didn't
> know, so this message is useless). I think it would make sense to be
> able to set both maxRetransmitTime and maxRetransmitNum at the same
> time, only that since they are maximus limits it would be effective
> the first to be reached.
SCTP allows setting a single PR-SCTP policy packet. Supported ones are
limiting the number of retransmissions and time to live. Not a combination
of both. That is why you are only providing a single PR-SCTP value.

If you want to limit both, you need to define a new PR-SCTP policy. That
policy would also require two parameters (the number of retransmissions and
the time to live in ms) as parameters, not only one as we have currently.

So without defining a new PR-SCTP policy, the above text is correct.

Best regards
Michael
> 
> 
> 
> --
> "Si quieres viajar alrededor del mundo y ser invitado a hablar en un
> monton de sitios diferentes, simplemente escribe un sistema operativo
> Unix."
> – Linus Tordvals, creador del sistema operativo Linux
> 
>

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 1 Apr 2013 10:15:57 +0200

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 1 Apr 2013 11:45:49 +0200

Ok, thanks for the clarification.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 1 Apr 2013 09:48:41 -0700

This looks fine, but I'd like to bike shed just a little.

On 31 March 2013 19:29, Randell Jesup <[email-masked]> wrote:
> Here's a proposed API for DataChannels with external negotiation, per the
> recent Interim and IETF meeting (most of this was in my previous W3 email,
> but I've added info on when 'stream' is valid to read, and how even/odd
> roles are assigned for the IETF protocol). I'll note for the IETF folks that
> 'protocol' is in a JS dictionary object in this update, which avoids
> breaking any current experimental applications (and avoids them having any
> incentive to UA-sniff).  Also, I think it works better in the dictionary.
>
>   channel = peerconnection.createDataChannel(label, dictionary_object);
>
>    error.  outOfOrderAllowed can be used with any type of channel.  The
>    equivalent of UDP is { outOfOrderAllowed: true, maxRetransmitNum: 0 }.
>    The TCP equivalent is {}.
>
>    preset is set to true if the channel is being externally negotiated, and
>    no wireline OpenRequest message should be sent.  If preset is true,
> stream
>    can be optionally used to set a specific SCTP stream to use.  If it's
>    not set but preset is true, then the application should read the 'stream'
>    attribute from the returned DataChannel after onopen and convey it to the
>    other end to pass in via the DataChannelInit dictionary.
>  */

A lot of your text can be replaced by defaults on the dictionary.

I prefer 'ordered' over 'outOfOrderAllowed', even if it means an
inversion of the values.  'rtxCount' or 'retransmitCount' rather than
'maxRetransmitNum'  (max is implied).

'preset' doesn't sound right, maybe you could have 'inlineOpen'
(default: true) to convey what is really happening here.

> dictionary DataChannelInit {
>   boolean ordered = true;
>   unsigned short retransmitPeriod = 65535; // !
>   unsigned short retransmitCount = 65535;
>   DOMString protocol;    // default: undefined
>   boolean inlineOpen = true;
>   unsigned short stream;    // default: browser selected
> };

unsigned short is an unusual type for time intervals, even if you
don't foresee a need for more than 65 seconds.  Oh, and that assumes
that you are using milliseconds, right?

---

From: Randell Jesup <[email-masked]>
Date: Mon, 01 Apr 2013 15:58:49 -0400

On 4/1/2013 12:48 PM, Martin Thomson wrote:
> inversion of the values.

Probably is easier to understand, and defaults help.

>    'rtxCount' or 'retransmitCount' rather than

I don't know that removing 'max' helps here or hurts.  Also, 
sorta-acronyms like rtx are obvious to networking people; not so much to 
JS app developers.  I see only minimal advantage here to brevity.  Count 
might be an improvement on Num.

> (default: true) to convey what is really happening here.

externallyNegotiated (default: false)?  Not great, but "inlineOpen" will 
be pretty meaningless to most developers who probably could care less if 
there's an in-band open message for a channel (whether externally 
negotiated or not) - or even know there's an in-band message.  Then 
again, 99% of developers don't need to care about this anyways.

> that you are using milliseconds, right?

Unsigned short has been the type in the protocol fields since the first 
draft (like a year).  Perhaps a silly optimization, though I think if 
you want partial reliability with >64K resends, or >64 seconds of retry 
that you *really* want reliable transmission (perhaps unordered, but 
reliable).   If we want to change it, now's the time, since we're 
breaking binary compatibility in FF with my landing today anyways.

-- 
Randell Jesup
[email-masked]

---

From: Martin Thomson <[email-masked]>
Date: Mon, 1 Apr 2013 13:24:47 -0700

On 1 April 2013 12:58, Randell Jesup <[email-masked]> wrote:
> I don't know that removing 'max' helps here or hurts.  Also, sorta-acronyms
> like rtx are obvious to networking people; not so much to JS app developers.
> I see only minimal advantage here to brevity.  Count might be an improvement
> on Num.

Yeah, 'rtx' is probably too aggressively short.

> externallyNegotiated (default: false)?  Not great, but "inlineOpen" will be
> pretty meaningless to most developers who probably could care less if
> there's an in-band open message for a channel (whether externally negotiated
> or not) - or even know there's an in-band message.  Then again, 99% of
> developers don't need to care about this anyways.

Yes, I didn't get a warm fuzzy from my suggested name either, but you
are right about the impact being relatively low.

Other ideas: "announceSettings" (default: true), "prearranged"
(default: false), "thisIsNotATest" (default: "yesItIs").

> draft (like a year).  Perhaps a silly optimization, though I think if you
> want partial reliability with >64K resends, or >64 seconds of retry that you
> *really* want reliable transmission (perhaps unordered, but reliable).   If
> we want to change it, now's the time, since we're breaking binary
> compatibility in FF with my landing today anyways.

Well, you'll be accepting a JS number, so it doesn't really matter
what the spec says.

---

From: Peter Thatcher <[email-masked]>
Date: Wed, 3 Apr 2013 09:05:46 -0700

I think moving protocol into the dictionary is a good idea.   In fact,
I'd like to see label move there as well, but that's probably asking
too much.

And now for a little of my own bikeshedding:

I don't understand way we have "stream" and "preset", since you can
only set "stream" if "preset" is true.  Why not just make the rule "if
stream is set, no in-band message is sent", and get rid of "preset"
altogether?  I really don't like the word "stream" sneaking in, since
it's so overloaded (MediaStream, RTP Stream, etc).  I'd prefer "sid"
or just "id".

I like the idea that reliable+ordered is the default, and both
reliability and ordered can be set independently.  I also prefer
"ordered" over "outOfOrderAllowed", and along with that I like the
idea of a "reliable" flag that, if false, is the equivalent of either
maxRetransmitNum:0 or maxRetransmitTime:0.  Finally, I think
"maxRetransmitTime" should make its units clear, perhaps calling it
"maxRetransmitMillis", and "maxRetransmitNum" could be shortened to
simply "maxRetransmits".

So the dictionary for my bikeshed would be:

dictionary DataChannelInit {
  DOMString protocol;
  unsigned short id;
  boolean ordered;
  boolean reliable;
  unsigned short maxRetransmits;
  unsigned short maxRetransmitMillis;
};

On Mon, Apr 1, 2013 at 1:24 PM, Martin Thomson <[email-masked]> wrote:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Randell Jesup <[email-masked]>
Date: Wed, 03 Apr 2013 12:19:20 -0400

> it's so overloaded (MediaStream, RTP Stream, etc).  I'd prefer "sid"

The reason was that I wanted a way to have the system select a stream to 
use (that you can then communicate externally to the other side); this 
avoids any chance of a collision with existing streams. If this is seen 
as not useful, then we can collapse it to a single entry.   (I also 
toyed with using stream 65535 as a flag to tell the system to allocate 
one; that seemed too hacky.)

Since this option was almost solely for those who understand the 
underlying SCTP-ness of this, I used "stream", but I'm fine with 
"streamId" or "id" (or "index" might be better than "id", which sounds 
like a label of some sort).  I dislike "sid" for similar reasons to 
disliking "rtx".

> "maxRetransmitMillis", and "maxRetransmitNum" could be shortened to

Those seem reasonable (I'd use Millisec/MilliSec or perhaps MS instead 
of Millis -- how are millisecond time values in other HTML5 specs 
described?).  On "reliable:false" - is this just a shorthand for 
"ordered:false, maxRetransmits:0"?  If so, I'm probably ok with it - 
it's redundant, but makes it easy to use/read for a common case.

-- 
Randell Jesup
[email-masked]

---

From: Randell Jesup <[email-masked]>
Date: Wed, 03 Apr 2013 12:21:10 -0400

Adding W3 list back ("Reply List" replies to one list in TB), since this 
really is a W3 item anyways.

On 4/3/2013 12:19 PM, Randell Jesup wrote:
> The reason was that I wanted a way to have the system select a stream 
> to use (that you can then communicate externally to the other side); 
> this avoids any chance of a collision with existing streams. If this 
> is seen as not useful, then we can collapse it to a single entry.   (I 
> also toyed with using stream 65535 as a flag to tell the system to 
> allocate one; that seemed too hacky.)
>

-- 
Randell Jesup
[email-masked]

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 3 Apr 2013 20:16:24 +0200

On Apr 3, 2013, at 6:19 PM, Randell Jesup wrote:

> The reason was that I wanted a way to have the system select a stream to use (that you can then communicate externally to the other side); this avoids any chance of a collision with existing streams. If this is seen as not useful, then we can collapse it to a single entry.   (I also toyed with using stream 65535 as a flag to tell the system to allocate one; that seemed too hacky.)
> 
> Since this option was almost solely for those who understand the underlying SCTP-ness of this, I used "stream", but I'm fine with "streamId" or "id" (or "index" might be better than "id", which sounds like a label of some sort).  I dislike "sid" for similar reasons to disliking "rtx".
> 
> Those seem reasonable (I'd use Millisec/MilliSec or perhaps MS instead of Millis -- how are millisecond time values in other HTML5 specs described?).  On "reliable:false" - is this just a shorthand for "ordered:false, maxRetransmits:0"?  If so, I'm probably ok with it - it's redundant, but makes it easy to use/read for a common case.

Does this mean that if I want
ordered:true
maxRetransmits:0
or
ordered:false
maxRetransmits:1
I have to set reliable:true? That doesn't make sense... Also reliability is independent from
ordering.

I would prefer to avoid redundancy there.

Best regards
Michael

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 3 Apr 2013 20:37:03 +0200

I agree with Peter (all the parameter in a dictionary), also with the
one about to put the label inside it. Also this way, it would be the
label optional too and be able to identify the DataChannel this way
using the other parameters, as for example the protocol.

2013/4/3 Randell Jesup <[email-masked]>:
>> avoids any chance of a collision with existing streams. If this is seen as
>> not useful, then we can collapse it to a single entry.   (I also toyed with
>> using stream 65535 as a flag to tell the system to allocate one; that seemed
>> too hacky.)
>>
>> underlying SCTP-ness of this, I used "stream", but I'm fine with "streamId"
>> or "id" (or "index" might be better than "id", which sounds like a label of
>> some sort).  I dislike "sid" for similar reasons to disliking "rtx".
>>
>>
>> Those seem reasonable (I'd use Millisec/MilliSec or perhaps MS instead of
>> Millis -- how are millisecond time values in other HTML5 specs described?).
>> On "reliable:false" - is this just a shorthand for "ordered:false,
>> maxRetransmits:0"?  If so, I'm probably ok with it - it's redundant, but
>> makes it easy to use/read for a common case.
>>
>>
>>>

---

From: Peter Thatcher <[email-masked]>
Date: Wed, 3 Apr 2013 20:12:34 -0700

Randell, thanks for explaining.  I think it's a valid use case to say
"I don't want the in-band open message, but I do want you to choose
the SID for me".  In that case, I'm OK with a separate flag meaning
"send the in-band open message", and I'd prefer a name like
"sendOpenMessage" or "sendControlMessages", which would default to
true.

On "sid", If you don't like "sid", I'm OK with "id", or even
"streamid", but I prefer "id" over "streamid".  I don't like "index".

On "millis" vs. "millsecs", the closest thing in HTML I could find was
the Date object, which has "getMilliseconds".  That would lean us
toward "maxRetransmitMillieseconds", which seems too long.  But I
don't care too much about this name, and would be happy with any of
"maxRetransmitMs" or "maxRetransmitMillis",
"maxRetransmitMilliseconds", "maxRetransmitTime" or
"maxRetransmitDuration".

On "reliable: false", I'd say it's a synonym for "maxRetransmits: 0".
You can have "{ordered: true; reliable: false"} or "{ordered: false;
reliable: true}", which is the same as "{ordered:true,
maxRetransmits:0}" or "{ordered:false}", respectively.

Michael, you don't have to set "reliable: true", since that's the
default.  This is only to allow "reliable: false" as a more readable
and easy to understand way of saying "maxRetransmits: 0".  It's purely
a convenience synonym.

Finally, if it's possible for us to make such a breaking change, I do
think it makes sense to optionally allow the browser to choose the
label, just as it optionally chooses the sid.  As such, I'll include
that idea in the dictionary I propose below so that createDataChannel
would take only one argument, this dictionary (like so:
createDataChannel({"label: XYZ", ...}).  If everyone else dislikes
this idea, then so be, take out that field and keep the rest.  I feel
more strongly about the rest of the names and options than I do about
that one.  But if we can make the change, I think it makes the method
cleaner and more flexible.

So, I update my proposed dictionary to be the following:

dictionary DataChannelInit {
  DOMString label;  //  default: chosen by browser.
  DOMString protocol;  // default: undefined
  unsigned short id;  // default: chosen by browser.
  boolean ordered = true;
  boolean reliable = true;  //  false is just a synonym for maxRetransmits: 0.
  unsigned short maxRetransmits;  // default:  "forever"
  unsigned short maxRetransmitMilliseconds;  // default: "forever"
  boolean sendOpenMessage = true;
};

---

From: "MARCON, JEROME (JEROME)" <[email-masked]>
Date: Wed, 10 Apr 2013 13:34:30 +0000

Randell,

What about data channel priority ?

Jerome

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] 
> De la part de Randell Jesup
> Envoyé : lundi 1 avril 2013 04:29
> À : [email-masked]
> Cc : [email-masked]
> Objet : [rtcweb] DataChannels API and external negotiation
> 
> Here's a proposed API for DataChannels with external 
> negotiation, per the recent Interim and IETF meeting (most of 
> this was in my previous W3 email, but I've added info on when 
> 'stream' is valid to read, and how even/odd roles are 
> assigned for the IETF protocol). I'll note for the IETF folks 
> that 'protocol' is in a JS dictionary object in this update, 
> which avoids breaking any current experimental applications 
> (and avoids them having any incentive to UA-sniff).  Also, I 
> think it works better in the dictionary.
> 
>     no wireline OpenRequest message should be sent.  If 
> preset is true, stream
>    boolean outOfOrderAllowed;
>    unsigned short maxRetransmitTime;
>    unsigned short maxRetransmitNum;
>    DOMString protocol;
>    boolean preset;
>    unsigned short stream;
> };
> 
> And I added to the DataChannel object webidl:
> 
>    readonly attribute DOMString protocol;
>    /* the 'stream' attribute is not valid until after onopen 
> has fired */
>    readonly attribute unsigned short stream;
> 
> 
> Even/odd roles for the underlying DataChannel protocol are 
> tied to the DTLS roles on the DTLS connection.  These are 
> only available after the DTLS connection is established, and 
> so we will set the even/odd roles when the initial 
> association is established (which is when onconnection fires, 
> and then any queued DataChannels would have onopen fire).
> 
> -- 
> Randell Jesup
> [email-masked]
>