Re: RTCDataChannel characteristics and failures -API description - comment to the 20140127 version

On 04 Feb 2014, at 19:40, Gunnar Hellstrom <gunnar.hellstrom@omnitor.se> wrote:

> On 2014-02-04 18:41, Martin Thomson wrote:
>> On 4 February 2014 03:52, Adam Bergkvist <adam.bergkvist@ericsson.com> wrote:
>>> Does the silence mean that people agree and are fine with these changes
>>> going into the spec? If anyone have any comments or suggestions, please
>>> comment.
>> Please don't assume silence == acceptance.  I'd prefer silence ==
>> ambivalence, or maybe silence == no thanks.
>> 
>> The proposed text is correct in part and too specific elsewhere.  I
>> agree with the note that reliable is instead equated with maximum
>> retry {count + time}.  I don't agree with setting specific numbers on
>> this, unless they are minimum requirements for support.
> A follow-up question:
> 
> If an application opens a data channel and requests the unreliable type with maximum 7 retries.
> And it turns out that the reliable type by default makes maximum 5 retries.
> 
> Will the channel establishment then accept to extend to 7 retries?
> Or what will happen?
Even if you configure the SCTP_PR_SCTP_RTX parameter larger than association.max.retrans
the association will be aborted after association.max.retrans consecutive retransmissions.
> 
> It looks a bit strange to have an unreliable channel that is more reliable than the reliable one.
It isn't. SCTP_PR_SCTP_RTX limits the number of retransmissions, it doesn't enforce them.
> But without documentation about the default retries for the reliable channel this situation might very well happen because the application programmer does not know the figure.

I think what is written in
http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-prpolicies-01
is clear. If not, please let me know.

Best regards
Michael
> 
> If it is agreed that it is illogical to set the unreliable channel more reliable than the reliable one, an addition to the API could say:
> "If the MaxRetries parameter is higher than the default maximum number of retries used for reliable channels, the channel will use the default number, but in other aspects perform as an unreliable channel (e.g. no channel disconnect after exceeded number of retries)." 

> 
> That would meet your view that the proposed text had too much detail, but it covers a logical gap in the API specification.
> 
> Gunnar
> 
> 
>

Received on Monday, 3 March 2014 14:57:53 UTC