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

On Feb 23, 2014, at 4:07 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> 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.

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

> 
> 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.
> 
> 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.
> 
> * 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...
> - A contact for more information about this protocol
You need to provide a reference for the protocol. Isn't that enough?

Best regards
Michael
> 
> 	Thanks,
> 	Paul
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> 