Re: [rtcweb] *MUST* DCEP?

Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 04 March 2014 14:53 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7C9C1A0167 for <rtcweb@ietfa.amsl.com>; Tue, 4 Mar 2014 06:53:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.635
X-Spam-Level:
X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_17=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 V9zfCaqZf-2B for <rtcweb@ietfa.amsl.com>; Tue, 4 Mar 2014 06:53:10 -0800 (PST)
Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 595241A00B9 for <rtcweb@ietf.org>; Tue, 4 Mar 2014 06:53:10 -0800 (PST)
Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta10.westchester.pa.mail.comcast.net with comcast id ZQ6X1n0031ap0As5ASt7oe; Tue, 04 Mar 2014 14:53:07 +0000
Received: from dhcp-a663.meeting.ietf.org ([31.133.166.99]) by omta22.westchester.pa.mail.comcast.net with comcast id ZSqv1n01P2904qf3iSqye8; Tue, 04 Mar 2014 14:51:05 +0000
Message-ID: <5315E850.5070700@alum.mit.edu>
Date: Tue, 04 Mar 2014 14:50:56 +0000
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: Ted Hardie <ted.ietf@gmail.com>
References: <5315B2E8.7010703@alum.mit.edu> <CA+9kkMAstUJHgMNRHE1EokqnNhyX0W+YPKvq7_=Miq4+Tbi5aw@mail.gmail.com>
In-Reply-To: <CA+9kkMAstUJHgMNRHE1EokqnNhyX0W+YPKvq7_=Miq4+Tbi5aw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1393944787; bh=qUWSdVc9y0M3JqteLQqX4I6Fi7GPx1PO/jNufBK7GA8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=pEx6HoK5eNzXvX+D7bDsnuk0q+ogmNcNJTL0dwp7ddq29VIr6rarGAishPWt20Xrn 6tj4Tmn9e86voqmLSEo3KifikAcS+4FWdT7WohKKd3yws2bMP6jjkdihzIWkYevPcJ fIm55mh9sNU/Zedfj2hnk48QkbP0A7exVKaHkgVUf9vu3ZSt2v/tJg66lMrljyeGge m6ZVuznmoQiabZVZ+ORi/gSwDxFRaj2R2nHwMAvazUxvSQKr1XgHh0uji1phHbXtGh Zi8ZZlz7X/I2XYv7I2BUMCU2J8M3+2jqJw6UadEpUBvUFxTX0KiuUvlNxR970rCoUH Q8iOJZ1yYG+oQ==
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/vs1Rz9b3SwxTsawLD1UAGCg4Ajw
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] *MUST* DCEP?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Mar 2014 14:53:11 -0000

IIUC rtcweb is predicated on the assumption that there is a single 
entity orchestrating the "system" including both of the endpoints of the 
sctp association. You therefore assume that you can a priori assume that 
both ends conform to your "systems document".

A sip endpoint doesn't have that. A major purpose of the signaling and 
the O/A exchange is to find out what we agree to. We won't know in 
advance if the other endpoint follows the CLUE "systems document".

ISTM that you are defining things so that we must use some mechanism to 
negotiate an application-specific agreement between the two ends about 
use of data channels *before* using any data channels.

With the ejzak draft we can use the O/A to negotiate a specific clue 
subprotocol, and then have a reasonable expectation that we can follow 
our own documentation of that protocol to go on.

Using DCEP would be more straightforward, especially for browser based 
endpoints. But if we can't even depend on support of DCEP when we have a 
data channel SCTP association, then DCEP is less useful.

	Thanks,
	Paul

On 3/4/14 11:17 AM, Ted Hardie wrote:
> On Tue, Mar 4, 2014 at 11:03 AM, Paul Kyzivat <pkyzivat@alum.mit.edu
> <mailto:pkyzivat@alum.mit.edu>> wrote:
>
>     Ted,
>
>     (I think this was open issue #8)
>
>     You closed discussion on this, saying that this should be specified
>     in some rtcweb "system" document. IIUC, then I disagree.
>
>     This is important to others besides rtcweb. We want to use this
>     mechanism, both with and without components that are implementing
>     rtcweb. Certainly for non-browsers.
>
>
> Help me understand why it wouldn't then be in their systems documents?
>
> Ted
>
>
>     This ultimately comes down to what I can expect after having
>     negotiated (in SDP) the establishment of an SCTP association. When
>     doing so, I use a=sctpmap to negotiate the how the association will
>     be used. If I intend to use data channels and DCEP then I want an
>     assurance that the other end does too. (That is the purpose of the
>     SDP negotiation.)
>
>     AFAIK, current when I specify 'a=sctpmap:webrtc-datachannel' (or
>     'a=sctp-datachannel' depending on where I look), that means the
>     other side supports data channels *and* guarantees support for DCEP.
>     There is no means to indicate support for data channels *without* DCEP.
>
>     I don't see any urgent need to have data channels without DCEP, as
>     long as *use* of DCEP is optional.
>
>     IMO things would be less confusing if the two documents were merged
>     into one, that defines the *Data Channel Protocol* (that runs over
>     SCTP). This protocol runs over pairs of SCTP streams, has a small
>     number of messages (open, ack, string-payload, binary-payload,
>     close), and encodes them in SCTP using SCTP messages with particular
>     payloads and SCTP stream reset. The open and ack messages would be
>     optional.
>
>              Thanks,
>              Paul
>
>