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

[Paul Kyzivat <[e-mail]>]

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.

	Thanks,
	Paul

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