Re: [clue] Draft new version: draft-holmberg-clue-data-channel-04

Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 13 March 2014 16:29 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: clue@ietfa.amsl.com
Delivered-To: clue@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8688B1A0A36 for <clue@ietfa.amsl.com>; Thu, 13 Mar 2014 09:29:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.035
X-Spam-Level:
X-Spam-Status: No, score=-0.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_110=0.6, J_CHICKENPOX_15=0.6, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56iwSI6O8n5Y for <clue@ietfa.amsl.com>; Thu, 13 Mar 2014 09:29:29 -0700 (PDT)
Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 060521A09F0 for <clue@ietf.org>; Thu, 13 Mar 2014 09:29:28 -0700 (PDT)
Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta12.westchester.pa.mail.comcast.net with comcast id czTk1n0080ldTLk5C4VNCB; Thu, 13 Mar 2014 16:29:22 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id d4VM1n00c3ZTu2S014VMDP; Thu, 13 Mar 2014 16:29:22 +0000
Message-ID: <5321DCE1.7030906@alum.mit.edu>
Date: Thu, 13 Mar 2014 12:29:21 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Christer Holmberg <christer.holmberg@ericsson.com>, "clue@ietf.org" <clue@ietf.org>
References: <7594FB04B1934943A5C02806D1A2204B1D210768@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D210768@ESESSMB209.ericsson.se>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1394728162; bh=Wi+5l3oR9n6EAE1kbVwFPdm6t5EYCNSetVEzYMue6uA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=YpKijBsEAfUV07gIN7rn5KrW+aP3NP0BIk+3nYQksfk2vgbjGpoQiFbx5YgTZJJBn PlCNH5lPJ3bZfjpRFk798dRSkFdpsbUkwi7743JQ/u4NN3DEOrqMOAIEqEmXHdrv60 MrcYEDneX/H+hg5gG47dSO7nxLa3Qk+hcP12eu5P0g+cdgswIjbL2/TXYRtNfBXgIg IcQVUc8K4pNouRxtrzsucDfu2sJja1zJHSJbZnN2I9m+DZr0te1/BM+CJqZnWVR5sS bhhSipEZb2IFlcWhQgOaqY6nkYEljgnB0OYU06Pwvn47PzIb3ycLa3+1dCHFQpneNy DkF5z+f4gOjYQ==
Archived-At: http://mailarchive.ietf.org/arch/msg/clue/mxJMpVTRj1tnYixNcVGNGBPHcrg
Cc: "clue-chairs@tools.ietf.org" <clue-chairs@tools.ietf.org>
Subject: Re: [clue] Draft new version: draft-holmberg-clue-data-channel-04
X-BeenThere: clue@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: CLUE - ControLling mUltiple streams for TElepresence <clue.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/clue>, <mailto:clue-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/clue/>
List-Post: <mailto:clue@ietf.org>
List-Help: <mailto:clue-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/clue>, <mailto:clue-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Mar 2014 16:29:30 -0000

Christer,

This is really starting to shape up well. I do have comments on this 
version, but IMO they don't impact adoption - they can be addressed 
either before or after. I want to talk to mary before initiating adoption.

Section 3.2:

I think this section could be weakened, to make DCEP the mechanism of 
last resort to establish the CLUE data channel, while *allowing* some 
other (currently unspecified) mechanism to preempt that.

For instance:

    In the absence of some other mechanism, a CLUE entity MUST use the
    Data Channel Establishment Protocol (DCEP) [I-D.ietf-rtcweb-
    data-channel], in order to open a CLUE Data Channel.

    (This document does not define any other mechanism for establishing
    the CLUE channel, but one may be defined in the future.)

Section 3.3.2:

    The usage of SCTP for the CLUE Data Channel ensures reliable
    transport of CLUE protocol [I-D.presta-clue-protocol] messages.

    NOTE: [I-D.ietf-rtcweb-data-channel] requires the support of the
    partial reliability extension defined in [RFC3758].  This is not
    needed for a CLUE Data Channel, as messages are required to always be
    sent reliably.  [I-D.ietf-rtcweb-data-channel] also mandates support
    of the limited retransmission policy defined in
    [I-D.tuexen-tsvwg-sctp-prpolicies].

I think you need to be stronger here, and say that the parital 
reliability and limited retransmission policies MUST NOT be used.

And when using DCEP, this is governed by the DCEP OPEN message 
parameters. I when opening the CLUE channel the Channel Type MUST be 
DATA_CHANNEL_RELIABLE. But this probably belongs in section 4.1.

Section 4.1:

I wonder if we want to include a version number in the protool name, 
just as another level of future-proofing.

Section 4.2:

This is a little vague about which of the pair of streams is reset.

Section 7.2 of draft-jesup-rtcweb-data-protocol-04 says more about this. 
(Though it has some editorial issues.) ISTM that should either be 
referenced or copied here.

Section 4.3:

This section (and maybe others) refers to "the offerer". I don't think 
this is very clear. I think it would be helpful to define a new term 
(role) (e.g. Master) that identifies which end of the session is 
responsible for maintaining the association. It could be the end that 
sends the first offer that mentions the SCTP m-line in the clue group, 
or it could be more complicated. But regardless, it is defined in one 
place, and other places just reference that term, rather than something 
confusing like "offerer".

Section 5.2:

Where did you get this proto value???

According to draft-ietf-mmusic-sctp-sdp-06 it should be DTLS/SCTP.

Section 5.4:

    In an offer, the offerer MUST NOT insert more than one "m=" line
    describing an SCTPoDTLS association to be used to realize a CLUE Data
    Channel.

I think this is a little strong. I think we can say that the clue group 
must contain exactly one DTLS/SCTP m-line. Potentially there could be 
others that aren't in the clue group - they aren't our concern.

I think it would be helpful to discuss the use of a=setup and 
a=connection here. (and in 5.5.) These may also provide a basis for 
defining which end takes future responsibility for maintaining the 
association.

(BUT, these also apply to DTLS. draft-ietf-mmusic-sdp-mux-attributes-01 
says that these attributes must be the same across a bundle. This 
constrains things.)

	Thanks,
	Paul

On 3/13/14 7:04 AM, Christer Holmberg wrote:
> Hi,
>
> Based on the discussions in London, I’ve submitted a new version (-04)
> of draft-holmberg-clue-data-channel.
>
> The draft now assumes that we will use the WebRTC Data Channel (that’s
> what it’s called at the moment…), and DCEP. There is a note regarding
> the usage of Richard’s draft, depending on the progress of the draft in
> MMUSIC.
>
> In London we also agreed to WG adopt the draft, so this is the version I
> intend to submit as draft-ietf-clue-00, as soon as the chairs give me a
> go ahead :)
>
> Thanks to everyone that have given input and comments so far – both on
> the list and in the meetings! J
>
> Regards,
>
> Christer
>