Re: [rtcweb] Possible to lose initial messages sent by reliable, out-of-band negotiated data channels

Taylor Brandstetter <deadbeef@google.com> Wed, 13 June 2018 22:48 UTC

Return-Path: <deadbeef@google.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90FDD130E96 for <rtcweb@ietfa.amsl.com>; Wed, 13 Jun 2018 15:48:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -18.21
X-Spam-Level:
X-Spam-Status: No, score=-18.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 0qYGK5xtxmdp for <rtcweb@ietfa.amsl.com>; Wed, 13 Jun 2018 15:48:18 -0700 (PDT)
Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C961D130EB1 for <rtcweb@ietf.org>; Wed, 13 Jun 2018 15:48:17 -0700 (PDT)
Received: by mail-vk0-x22a.google.com with SMTP id 200-v6so2542363vkc.0 for <rtcweb@ietf.org>; Wed, 13 Jun 2018 15:48:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dtaUcqRI9cmJdxXcvAF00w+WH/+8C8kwm+JT+hOD8p4=; b=EjaSoOvvURseJMtiKbpcBaVY65rnLpOh3F6ozkxLcLpXVFNLcU8mmb6imUfz+RlAAA eYkTP88QSQKZPxSRvj1LuKRvgUAbMast1HAW+7Sz9oLM0uo2F5tnYJizDlklfoExI3Dn 9fisDMifanXIcwY3cgDxdZQZmFkwTqCEikCheLuu5hVmiuh7lm4T8oZTkDCkm37k7TFs WWjkjVhmoUkcSrKkC8XCTGZFDupGY8KsX//D2N9krpJ/kwtBu4eIBUQIn3IIWdWlPKp6 us0wRQ+mW9bImryNdZ28gzcyCpiDgposFhpiXacLfIAm7haObPir39+LQPR1wvM/PjPh yJwQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dtaUcqRI9cmJdxXcvAF00w+WH/+8C8kwm+JT+hOD8p4=; b=Z9imxbQiUOwjXsX8H+bO+ojjqwErXTkOdHHEUGQkPNBoNPiod1LPA5VUiZanGSGyHn ClEr2hkQoaT+GLPA9mjaJkAJwoGCWeJ5cy/kfFBI2j6dumB1sEOfSDHu4nvbhoMF5iI/ s72o+RAVVJx4clZrFPekYzGxKbUqoDHrNnC8GkNukpTeJm7JeEbr7q052wqv7bYgWckn 1sBL0WZpRk9L41KZFS60fUM/Bg9uIk9imFevo6c2SOKUu2/fLLDUSmcMguAardzA4St0 jHw/QijXbGDF9CxtzJP33lmnR9qIyejDuqBS1VpQAeSry1aaljIvlm1xUZu94fVWvWwb ifKg==
X-Gm-Message-State: APt69E3nJeRJgj+bY3Ede0o4sixOT6elIIWRxd2yKsp4rTLoNgDqr9nK I02mPWqY5owaaCc02ME/0HQoXE1EGd+mV1PhGZA4o3ln
X-Google-Smtp-Source: ADUXVKJgEMmajBxhFSaQ/oYzYmvMcbS0naHkh7xoOfSkzlCLudCKedcX1QRs1Gsoh9AUcaj1MU867DuAwcs5LPG64lg=
X-Received: by 2002:a1f:6d03:: with SMTP id i3-v6mr62933vkc.198.1528930096548; Wed, 13 Jun 2018 15:48:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a1f:9302:0:0:0:0:0 with HTTP; Wed, 13 Jun 2018 15:48:15 -0700 (PDT)
In-Reply-To: <4C57BFED-4A4D-4B9E-931A-173E1FE493DF@iii.ca>
References: <CAK35n0bLdXMVOeh+R5EHegMT4+7eP0dWZ+-7Y82VJkTC4wk5QQ@mail.gmail.com> <4C57BFED-4A4D-4B9E-931A-173E1FE493DF@iii.ca>
From: Taylor Brandstetter <deadbeef@google.com>
Date: Wed, 13 Jun 2018 15:48:15 -0700
Message-ID: <CAK35n0a6Ua3YOJS1DfdsMDWuk4wW4vWdZfiUJDK8XinSQnb9NQ@mail.gmail.com>
To: Cullen Jennings <fluffy@iii.ca>
Cc: RTCWeb IETF <rtcweb@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004b141d056e8dc7bf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/3w9zgjppXhsjlozMEj_ibre2YWk>
Subject: Re: [rtcweb] Possible to lose initial messages sent by reliable, out-of-band negotiated data channels
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.26
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 13 Jun 2018 22:48:23 -0000

It sounds like you and Christer are suggesting the same thing: "don't allow
messages to be sent until you're sure the other peer has a channel to
receive them". Except that there's no way for the WebRTC stack to know
that, since these channels are not signaled in SDP or any in-band message.

On Wed, Jun 13, 2018 at 1:32 PM, Cullen Jennings <fluffy@iii.ca> wrote:

>
>
> On May 31, 2018, at 12:24 PM, Taylor Brandstetter <
> deadbeef=40google.com@dmarc.ietf.org> wrote:
>
> One might expect that a "reliable" data channel is guaranteed to be, well,
> reliable. But in current implementations, the first messages may be lost if
> the application is negotiating the channels out-of-band, and creates the
> receiving channel too late.
>
> Here's a fiddle that demonstrates this (happens with Chrome and Firefox):
> https://jsfiddle.net/o2m8tp20/
>
> Normally this isn't an issue, because a typical application would create
> the out-of-band negotiated channels before the first offer/answer is
> complete, and thus before the SCTP association is established. Meaning that
> by the time a data channel is "open", it's guaranteed that the other peer
> has a corresponding channel.
>
> But if for whatever reason, an application creates a data channel *after*
> the SCTP association is established, then it will instantly be "open" as
> soon as it's created. If a message is sent at this point, and it's received
> by the other peer before it's created its corresponding data channel, then
> the message will just be discarded.
>
> So, how should we deal with this? Some possibilities:
>
>    1. Say "this is expected behavior" and document it better, breaking
>    the reliability promise.
>    2. Run the closing procedure if a message is received on a stream
>    before a data channel is ready to receive it.
>    3. Don't even allow an out-of-band negotiated channel to be created
>    after the SCTP association is established.
>    4. Buffer these messages for up to X seconds (or up to X bytes), to be
>    delivered to the data channel once it's created. Run the closing procedure
>    if X is exceeded.
>
> I'd vote for #2. Adding additional buffering logic seems like overkill if
> this isn't a use case we really intended to support.
>
>
> I lean toward something that just did not allow the  out-of-band channel
> negotiation be used until it was set up.
>
> But whatever we do, not option 1
>
>
>
>
>
>
>
>
>
>
>
>