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

[Michael Tuexen <[e-mail]>]

On Nov 12, 2013, at 2:45 PM, Magnus Westerlund <[e-mail]> wrote:

> Hi,
> 
> I did review the Data Channel Protocol on my way to IETF, and here are
> my comments.
Hi Magnus,

thank you very much for the comments. I've submitted a new version according
to the comments below.
> 
> 1. Section 4:
> 
>   o  the outgoing SCTP stream.
> 
> What about incoming SCTP stream?
Changed to "the SCTP streams."
> 
> 2. Section 4:
>   The data channel protocol uses a two way handshake to open a data
>   channel.  The side wanting to open a data channel selects an unused
>   Stream and sends a DATA_CHANNEL_OPEN message.  The peer responds with
>   a DATA_CHANNEL_ACK message.  Then the data channel is open.  Please
>   note that the opening side can send user messages before the
>   DATA_CHANNEL_ACK is received.  These data channel messages are sent
>   on the same Stream as the user messages belonging to the data
>   channel.  The demultiplexing is based on the SCTP payload protocol
>   identifier.
> 
> I find this paragraph a bit confusing on the following things:
> 
> A. Is the DATA_CHANNEL_OPEN message sent on that selected stream?
> B. Is the DATA_CHANNEL_ACK sent on the peers corresponding stream number
> as the DATA_CHANNEL_OPEN was received on?
> C. "These data channel messages" does this refer to
> DATA_CHANNEL_OPEN/ACK, maybe be more explicit.
> D. "The demultiplexing is based on the SCTP payload protocol
>   identifier." Do you mean PPIDs here. And could you be more explicit
> about of how this works. Am I wrong in the understanding that you have
> have one PPID for this control protocol. But, you are not explicit about
> if which PPID user messages could use.
OK, I have updated the above paragraph:

<t>The data channel protocol uses a two way handshake to open a data channel
by combining two SCTP streams, one in each direction, with the same
SCTP stream identifier.
The side wanting to open a data channel selects an SCTP stream identifier
for which the corresponding incoming and outgoing SCTP stream is unused
and sends a DATA_CHANNEL_OPEN message on this outgoing SCTP stream.
The peer responds with a DATA_CHANNEL_ACK message on its corresponding
outgoing SCTP stream. Then the data channel is open.
Please note that the opening side can send user messages before the
DATA_CHANNEL_ACK is received.
Data channel control messages are sent on the same Stream as the user
messages belonging to the data channel.
The demultiplexing is based on the SCTP payload protocol identifier (PPID),
since the data channel control protocol uses a specific PPID.</t>
> 
> 3. Section 4:
>   The protocol field is to ease cross-application interoperation
>   ("federation") by identifying the data being passed with an IANA-
>   registered string, and may be useful for homogenous applications
>   which may create more than one type of Channel.
> 
> One more case where I think it is fuzzy what is refered to. Is the
> "protocol field" an identifier for the PPID to use, or something else?
No, it is something different.
> What type of IANA registered string is being used here? Which registry
> and field value are referenced?
The one defined in Section 8.4.
> 
> 4. Section 5.1:
>   Priority: 2 bytes (integer)
>      The priority of the channel.
> 
> What is the definition of the priority field value?
It is the priority of the channel. I changed the text to:

The higher the number, the lower the priority. In particular,
0 is the highest priority.

However, I'm not sure if this should be unsigned. Also the W3C document
doesn't specify it yet.
> 
> 5. Section 5.1:
>   Reliability Parameter: 4 bytes
> 
> I would recommend that you make a table under this parameter where you
> make clear the interpretation of the field under differetn channel types.
OK, I have added:

The following table summarises this:</t>
</list></t>
<texttable>
<ttcol align='left'>Channel Type</ttcol>
<ttcol align='center'>Reliability Parameter</ttcol>
<c>DATA_CHANNEL_RELIABLE</c>                         <c>Ignored</c>
<c>DATA_CHANNEL_RELIABLE_UNORDERED</c>               <c>Ignored</c>
<c>DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT</c>          <c>Number of RTX</c>
<c>DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED</c><c>Number of RTX</c>
<c>DATA_CHANNEL_PARTIAL_RELIABLE_TIMED</c>           <c>Lifetime in ms</c>
<c>DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED</c> <c>Lifetime in ms</c>
</texttable>
> 
> 6. Section 5.1
> 
>   Protocol: Variable Length (sequence of characters)
>      The protocol for the channel.  This may be an empty string.  If
>      used, it is an IANA-registered protocol (see Section 8.4).
> 
> Can you please be explicit about which IANA registry that is relevant
> here. What is the meaning of an empty string?
There is already a reference to the registry (Section 8.4). How
can it be more explicit?
If you use an empty string it is unspecified. I have changed it to:

The protocol for the channel. If this is an empty string the
protocol us unspecified. If it is an non-empty string, it specifies
an IANA-registered protocol (see <xref target='iana_protocol'/>).

> 
> 7. Section 6.
> What PPID shall be used when sending the user data?
The document describes a protocol for opening a data channel (see first sentence
of section 4), not for using or closing it. Sending user data is
done the same on all data channel, not matter how they are set up. That
is why sending user data is described in draft-ietf-rtcweb-data-channel.
> 
> 8. Section 6.
> Therefore, receiving an
>   SCTP stream reset request for a stream on which no DATA_CHANNEL_ACK
>   message has been received indicates to the sender of the
>   corresponding DATA_CHANNEL_OPEN message the failure of the data
>   channel setup procedure.
> 
> What is allowed to do after having received the reset on a
> DATA_CHANNEL_OPEN? Can one try to send a new OPEN?
Sure. I added:

After also successfully resetting the corresponding outgoing
SCTP stream, a new DATA_CHANNEL_OPEN message can be sent on the stream.

> 
> 9. Section 8.2:
>               | Reserved          | 0x00      | [RFCXXXX] |
>               | Reserved          | 0x01      | [RFCXXXX] |
> 
> Why is these values reserved, please include the motivation for this in
> the description of the registry.
OK. I have added:

<t>Please note that the values 0x00 and 0x01 are reserved to avoid
interoperability problems, since they have been used in earlier versions
of the document.</t>

> 
> 10. Section 8.4:
>   IANA is requested to create a new registration table "Protocol
>   Registry" for the data channel protocol to manage the "Protocol"
>   field of type string in DATA_CHANNEL_OPEN messages (see Section 5.1).
> 
> "Protocol Registry" is a lousy name on a registry. Secondly, I think the
I agree that it is a lousy name, but I couldn't come up with a better one.
Maybe Randell can? Or you can?
> purpose of this registry needs to be better described.
Randell?

Best regards
Michael
> 
> 
> Cheers
> 
> Magnus Westerlund
> 
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  [phone]
> Färögatan 6                | Mobile [phone]
> SE-164 80 Stockholm, Sweden| mailto: [e-mail]
> ----------------------------------------------------------------------
> 
>