[rtcweb] Data Channel Protocol: Prevent DATA_CHANNEL_OPEN glare

Christer Holmberg <christer.holmberg@ericsson.com> Mon, 10 February 2014 10:07 UTC

Return-Path: <christer.holmberg@ericsson.com>
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 71BF81A06BF for <rtcweb@ietfa.amsl.com>; Mon, 10 Feb 2014 02:07:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.239
X-Spam-Level:
X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 nzwSyYNi_AGt for <rtcweb@ietfa.amsl.com>; Mon, 10 Feb 2014 02:07:18 -0800 (PST)
Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id CA5E41A05DE for <rtcweb@ietf.org>; Mon, 10 Feb 2014 02:07:17 -0800 (PST)
X-AuditID: c1b4fb32-b7f4c8e0000012f5-64-52f8a4d4624e
Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 50.E9.04853.4D4A8F25; Mon, 10 Feb 2014 11:07:17 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0387.000; Mon, 10 Feb 2014 11:07:16 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: Data Channel Protocol: Prevent DATA_CHANNEL_OPEN glare
Thread-Index: Ac8mR2/m3LFj8oi+SFKLxbYiytu9PA==
Date: Mon, 10 Feb 2014 10:07:15 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1D166CFA@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.16]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D166CFAESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOLMWRmVeSWpSXmKPExsUyM+Jvje7VJT+CDJ4u47RY+6+d3YHRY8mS n0wBjFFcNimpOZllqUX6dglcGas/rGEvmGtacb93MXMD42q9LkZODgkBE4muqQsYIWwxiQv3 1rN1MXJxCAmcYJSYcmUeC4SzmFFi+r0fTF2MHBxsAhYS3f+0QRpEBNQlLj+8wA5iCwvYS6z9 /JIFpEREwEXi3g0PiBI9idt3XrKC2CwCqhIv134B28Ur4Cvx/d9bMJsRaO/3U2uYQGxmAXGJ W0/mM0HcIyCxZM95ZghbVOLl43+sELaixM6z7cwQ9fkSN2ctZYWYKShxcuYTlgmMQrOQjJqF pGwWkjKIuI7Egt2f2CBsbYllC18zw9hnDjxmQhZfwMi+ilGyOLW4ODfdyEAvNz23RC+1KDO5 uDg/T684dRMjMDIObvlttIPx5B77Q4zSHCxK4rzXWWuChATSE0tSs1NTC1KL4otKc1KLDzEy cXBKNTBOPnhJ/+2ePr3oCc8kJF2Tb5wsebn2Hufd73smagRrZ8WENnzli3cs5bnzfXHkwz1P 3q+SL1m4yOXugpLYyA1WDBczl1yzmSI+b8uqW38e3Z91uLT1wIavK9foal3JfNj3J8r0pEfi Fndj9oPXjbLyW12f/z6/7feJFUf2h8fX6jnEGf3ISzjZr8RSnJFoqMVcVJwIAK0WP+ZaAgAA
Subject: [rtcweb] Data Channel Protocol: Prevent DATA_CHANNEL_OPEN glare
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: Mon, 10 Feb 2014 10:07:20 -0000

Hi,

As is defined in the data channel protocol, an entity can send data once DATA_CHANNEL_OPEN has been sent, before the associated DATA_CHANNEL_ACK is received.

The draft also says that, if both endpoints send DATA_CHANNEL_OPEN at the same time, using different stream id values, the result may be TWO data channels, with data sent on both.

However, as is also indicated, the draft does not provide a mechanism to prevent/handle such glare situation.

I personally think there shall be a way to prevent such situation, or otherwise I'm sure we are going to end up with interoperability problems.

Couldn't we e.g. say that, by default, the DTLS client is responsible for sending the DATA_CHANNEL_OPEN? Then there is no risk for glare, and it could even use both an even or odd stream id value.

Regards,

Christer