Re: [rtcweb] Comments on draft-ietf-rtcweb-data-protocol-03

[Michael Tuexen <[e-mail]>]

On 25 Feb 2014, at 17:49, Paul Kyzivat <[e-mail]> wrote:

> Inline
> 
> On 2/24/14 5:12 AM, Michael Tuexen wrote:
>> On Feb 23, 2014, at 4:07 AM, Paul Kyzivat <[e-mail]> wrote:
>> 
>>> A few comments on this draft:
>>> 
>>> * Section 5.1:
>>> 
>>>      DATA_CHANNEL_PARTIAL_RELIABLE_TIMED (0x02):  The channel provides
>>>         a partial reliable in-order bi-directional Communication
>>>         channel.  User messages might not be transmitted or
>>>         retransmitted after a specified life-time given in milli-
>>>         seconds in the Reliability Parameter.  This life-time starts
>>>         when providing the user message to the Javascript engine.
>>> 
>>> The last sentence above is troubling. This protocol won't always be used via Javascript. Can we please have a definition that
>> OK. What about replacing the last sentence with
>> 
>> This life-time starts when providing the user
>> message to the protocol stack.
> 
> *which* protocol stack?
> 
> This is part of the problem. As the documents are currently structured, there is a "data channel establishment protocol", but there is no "data channel protocol".
> 
> But in reality there *is* a (thin) data channel protocol. It just isn't described explicitly. In a browser it is perhaps just the code behind the data channel API. But in other environments it may need to be more explicit. It has some obligations. Presumably enforcing this "lifetime" parameter is one of them. Enforcing the use of sequenced messages between a DCEP open and receipt of ACK is another.
> 
>>> doesn't depend on that? Is the timing being done by SCTP, or are you assuming that a data channel layer on top of SCTP is doing this? Is it specific to SCEP, or is it still applicable when the channel has been established via external negotiation?
>> It is actually the time when the message is provided to the SCTP stack, but I think
>> there might be some code running between the SCTP code and the user code (let it be
>> JS or anything else). I'm assuming that there is no substantial buffering happening
>> there.
>>> 
>>> Does use of this option imply that retransmission continues until this time limit is reached? Or might it stop after some implementation defined number of retransmissions?
>> The only way the retransmissions don't happen until the time limit is reached, is that
>> SCTP decides that the association is broken because of excessive retransmissions.
>>> 
>>> The description of the reliability parameter says:
>>> 
>>>      This field is ignored if a reliable channel is used.
>>> 
>>> IMO folk wisdom says that some specific value (e.g., 0) should be prescribed to be used in such cases. That makes things more deterministic and provides more flexibility in extending the protocol in the future.
>> What about:
>> 
>> For reliable channels this field MUST be set to 0 on the sending side
>> and MUST be ignored no the receiving side.
> 
> WFM
> 
>>> The name "Protocol" (and "Protocol Length") here is troublesome, because it is ambiguous with other sorts of uses. (See my comment about this point earlier today wrt draft-ietf-rtcweb-data-channel-07.) Others (including draft-ejzak-mmusic-data-channel-sdpneg-00 and websockets) call this "subprotocol". Using that would make it a little less confusing.
>> In the W3C specification it is also called protocol, but the text talks about sub-protocol. Maybe we should do
>> the same here.
> 
> I'm not following the W3C part.
> 
> I'm just interested in getting consistency, and avoiding confusion.
> Right now there is a lot of confusion around the use of "protocol".
> 
>>> Also, ISTM that all of these things are applicable to externally negotiated channels, and so ought to be defined by draft-ietf-rtcweb-data-channel. (But of course their use in the DATA_CHANNEL_OPEN message belongs here.)
>> Reliability is discussed there, but I agree, we need to discuss label and protocol there, too.
> 
> Good!
> 
>>> * Section 8.4:
>>> 
>>> ISTM there ought to be a template of the minimum information that the specification for a registered (sub)protocol MUST (SHOULD?) include. E.g.,
>>> 
>>> - what Channel Type(s) are valid for this (sub)protocol
>> I assumed all...
> 
> ISTM that in *most* cases a if a (sub)protocol is designed for use with a reliable channel it won't work correctly with an unreliable channel.
> 
> And while things designed to work with an unreliable channel will probably continue to work with a reliable channel, they might not have the intended properties.
> 
> That's why its good to have some guidelines about what the specification must contain. It prevents people providing something sloppy and incomplete that isn't sufficient to use the (sub)protocol.
> 
>>> - A contact for more information about this protocol
>> You need to provide a reference for the protocol. Isn't that enough?
> 
> Depends on the form of the reference. Is the reference required to be publicly available? Stable?
> 
> Note the definition of FCFS policy in 5226:
> 
>      First Come First Served - Assignments are made to anyone on a
>            first come, first served basis.  There is no substantive
>            review of the request, other than to ensure that it is
>            well-formed and doesn't duplicate an existing assignment.
>            However, requests must include a minimal amount of clerical
>            information, such as a point of contact (including an email
>            address) and a brief description of how the value will be
>            used.  Additional information specific to the type of value
>            requested may also need to be provided, as defined by the
>            namespace.  For numbers, the exact value is generally
>            assigned by IANA; with names, specific text strings can
>            usually be requested.
> 
> Having a sufficient definition of what must be in the registry, and what must be in a reference from the registry is *more* important for FCFS than it is for some of the more restrictive policies. The policies that get careful review can perhaps depend on the reviewers stopping something that is incomplete.
> 
> IMO the registry ought to provide, directly or indirectly, enough information to implement/use the (sub)protocol.
I'll bring this up in the RTCWeb meeting.

Best regards
Michael
> 
> 	Thanks,
> 	Paul
> 
>> Best regards
>> Michael
>>> 
>>> 	Thanks,
>>> 	Paul
>>> 
>>> _______________________________________________
>>> rtcweb mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>> 
>> 
>> 
> 
>