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

From: Paul Kyzivat <[email-masked]>
Date: Sat, 22 Feb 2014 22:07:01 -0500

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

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

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.

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

* 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
- A contact for more information about this protocol

	Thanks,
	Paul

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 24 Feb 2014 11:12:39 +0100

On Feb 23, 2014, at 4:07 AM, Paul Kyzivat <[email-masked]> wrote:

> 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.  
> 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.,
> 
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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 25 Feb 2014 12:49:54 -0500

Inline

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

> and MUST be ignored no the receiving side.

WFM

> In the W3C specification it is also called protocol, but the text talks about sub-protocol. Maybe we should do

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

> Reliability is discussed there, but I agree, we need to discuss label and protocol there, too.

Good!

>> - what Channel Type(s) are valid for this (sub)protocol

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.

> 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