[rtcweb] Comments on draft-ietf-rtcweb-data-channel-07

Paul Kyzivat <pkyzivat@alum.mit.edu> Sun, 23 February 2014 00:20 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 B11E71A0213 for <rtcweb@ietfa.amsl.com>; Sat, 22 Feb 2014 16:20:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 9ATzmDkjlh7q for <rtcweb@ietfa.amsl.com>; Sat, 22 Feb 2014 16:20:12 -0800 (PST)
Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id AF73F1A020F for <rtcweb@ietf.org>; Sat, 22 Feb 2014 16:20:11 -0800 (PST)
Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta15.westchester.pa.mail.comcast.net with comcast id VcFV1n0050ldTLk5FcL6Me; Sun, 23 Feb 2014 00:20:06 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id VcL61n00M3ZTu2S01cL6Ny; Sun, 23 Feb 2014 00:20:06 +0000
Message-ID: <53093EB6.5080500@alum.mit.edu>
Date: Sat, 22 Feb 2014 19:20:06 -0500
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: "rtcweb@ietf.org" <rtcweb@ietf.org>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1393114807; bh=JAqBtS+m6Ro8KnA6bWEbf/9NqwELCLM7nrEwXBcnAkA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=GohEMtF9eMUnobd6NwCQSP1vrJEtTIJaCyfRv8pTtd39td5a44C6rQC73qnRfmWy/ oPifg4+VoXcjR4cXE5avq1mHh7n6/cuwzq+7uQwXs/e4YH1vEvg45bb3Dc1cGPzeo9 dx4GmIWwBdfgyqYW9B3eIEaIEh2fvDlaOILbeEzz5Cqc/hb2BWb+TQZXSP0VGoyJqK PhExgo1eph6aLDHHEpmCA7u+HFb34v8VA+LoLkymzE/QP36orXsExzes8K8anaCRp8 +LsURpzqT3KjchVGLAYXcLRoySZKeL9GbvYTwXcConHTs+K39CmU15dnKMx785xFJJ Ezp6YYylkvHJg==
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/HFf-OY4P4ke8iTsdxAvgsfaEbk0
Subject: [rtcweb] Comments on draft-ietf-rtcweb-data-channel-07
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: Sun, 23 Feb 2014 00:20:14 -0000

(Catching up before the meeting)
Here are some comments on the latest version. There don't necessarily 
relate to recent changes. Rather they come from my perspective trying to 
use this for CLUE, whether using a webrtc endpoint or not.

* Section 5:

This section says:

    Each SCTP user message contains a so called Payload Protocol
    Identifier (PPID) that is passed to SCTP by its upper layer and sent
    to its peer.  This value can be used to multiplex multiple protocols
    over a single SCTP association.  The sender provides for each
    protocol a specific PPID and the receiver can demultiplex the
    messages based on the received PPID.  The PPID is used to distinguish
    UTF-8 encoded user data and binary encoded userdata.  The Data
    Channel Establishment Protocol defined in
    [I-D.ietf-rtcweb-data-protocol] uses also a specific PPID to be
    distinguished from user data.

The language has proved extremely confusing to several people who 
haven't followed the development and discussion of this from the 
beginning. It is because of the extreme ambiguity in the use of 
"protocol". While I guess we can't rename PPID, the other language could 
be clarified.

The problem is that we have SCTP protocol, "WebRTC Data Channel 
Establishment Protocol", and within the DATA_CHANNEL_OPEN message of the 
WebRTC Data Channel Establishment Protocol we have a "Protocol" field.

We also have layering of protocols and implementations. So it isn't 
clear above who "sender" and "receiver" above apply to. (Could be code 
that is calling the SCTP stack, or code that is calling the "data 
channel stack", or the browser, or a javascript application on top of 
browser.

IIUC, javascript users don't have any visibility to the PPID. But others 
implementing data channels may.

How about:

    Each SCTP user message contains a so called Payload Protocol
    Identifier (PPID) that is passed to SCTP by the data channel layer
    and sent to its peer.  This value is used to multiplex WebRTC Data
    Channel Establishment Protocol messages (defined in [I-D.ietf-rtcweb-
    data-protocol]) with messages containing user data on a data
    channel. The PPID is also used to distinguish UTF-8 encoded user
    data and binary encoded user data.

Also in this section is Figure 2 that shows layering. I'm unclear if 
"WEBRTC DATA" in intended to include rtcweb-data-protocol or not. That 
is defined in a separate draft, is mandatory to support but optional to 
use. So it could go either way. Might be good to clarify:


                  +---------+
                  |CHANNEL  |
                  |PROTOCOL |
                  +---------+
                  |DATA     |
                  |CHANNEL  |
                  +---------+
                  | SCTP    |
    +-----------------------+
    | STUN | SRTP | DTLS    |
    +-----------------------+
    |         ICE           |
    +-----------------------+
    | UDP1 | UDP2 | ...     |
    +-----------------------+

* Section 6.5

This section contains:

    Data channels can be opened by using internal or external
    negotiation.  The details are out of scope of this document.

    A simple protocol for internal negotiation is specified in
    [I-D.ietf-rtcweb-data-protocol] and MUST be supported.

But internal and external negotiation are not defined in this document.

I *thought* that internal negotiation was by definition negotiation by 
use of rtcweb-data-protocol. (draft-ejzak-mmusic-data-channel-sdpneg-00 
thinks so too, but calls it "in-band negotiation".)

There should be a good definition of these terms, or reference to one. 
And more discussion if there can be other kinds of internal negotiation. 
(If so, how would one be chosen?)

* Section 6.6:

Say:

    All data sent on a Channel in both directions MUST be sent over the
    underlying stream using the reliability defined when the Channel was
    opened unless the options are changed, or per-message options are
    specified by a higher level.

Is the recipient to consider it an error if messages are received with 
options different from those defined for the channel?

Also, is it an error if messages are received with a PPID that isn't 
specified in Section 8? (And what about PPID 50?)

How are such channel errors to be treated?

	Thanks,
	Paul