Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <530CD7C2.7050106@alum.mit.edu>
Date: Mon, 3 Mar 2014 15:24:50 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <B53E738C-3621-4C45-A352-5CDF2A295733@lurchi.franken.de>
References: <530965D5.9090105@alum.mit.edu>
 <1B3F1D52-0F89-4F87-AB70-C1FAA73EC8EC@lurchi.franken.de>
 <530CD7C2.7050106@alum.mit.edu>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/qr5EzNxWTDmHgB7A-sNdvgn0OR8
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-data-protocol-03
Precedence: list

On 25 Feb 2014, at 17:49, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

> Inline
>=20
> On 2/24/14 5:12 AM, Michael Tuexen wrote:
>> On Feb 23, 2014, at 4:07 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> =
wrote:
>>=20
>>> A few comments on this draft:
>>>=20
>>> * Section 5.1:
>>>=20
>>>      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.
>>>=20
>>> 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
>>=20
>> This life-time starts when providing the user
>> message to the protocol stack.
>=20
> *which* protocol stack?
>=20
> 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".
>=20
> 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.
>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> The description of the reliability parameter says:
>>>=20
>>>      This field is ignored if a reliable channel is used.
>>>=20
>>> 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:
>>=20
>> For reliable channels this field MUST be set to 0 on the sending side
>> and MUST be ignored no the receiving side.
>=20
> WFM
>=20
>>> 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.
>=20
> I'm not following the W3C part.
>=20
> I'm just interested in getting consistency, and avoiding confusion.
> Right now there is a lot of confusion around the use of "protocol".
>=20
>>> 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.
>=20
> Good!
>=20
>>> * Section 8.4:
>>>=20
>>> ISTM there ought to be a template of the minimum information that =
the specification for a registered (sub)protocol MUST (SHOULD?) include. =
E.g.,
>>>=20
>>> - what Channel Type(s) are valid for this (sub)protocol
>> I assumed all...
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
>>> - A contact for more information about this protocol
>> You need to provide a reference for the protocol. Isn't that enough?
>=20
> Depends on the form of the reference. Is the reference required to be =
publicly available? Stable?
>=20
> Note the definition of FCFS policy in 5226:
>=20
>      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.
>=20
> 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.
>=20
> 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
>=20
> 	Thanks,
> 	Paul
>=20
>> Best regards
>> Michael
>>>=20
>>> 	Thanks,
>>> 	Paul
>>>=20
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>=20
>>=20
>>=20
>=20
>=20