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

Taylor Brandstetter <deadbeef@google.com> Thu, 31 May 2018 18:24 UTC

Return-Path: <deadbeef@google.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 9772312EA55 for <rtcweb@ietfa.amsl.com>; Thu, 31 May 2018 11:24:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.509
X-Spam-Status: No, score=-17.509 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_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id kzVPijFMFTUU for <rtcweb@ietfa.amsl.com>; Thu, 31 May 2018 11:24:27 -0700 (PDT)
Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (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 B247012EB67 for <rtcweb@ietf.org>; Thu, 31 May 2018 11:24:27 -0700 (PDT)
Received: by mail-ua0-x234.google.com with SMTP id i2-v6so15654113uah.0 for <rtcweb@ietf.org>; Thu, 31 May 2018 11:24:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=5h0uf1/Jt0w1Q00AsARw3vKCBCItevCs2yY073aTWYU=; b=SriZVjS5QU7SeEmyWVuI8Yu38J9uO9I+JijMT0pggNNtSdLXWn+4HX5UQ/K06r9p8T 9eJa+QXvf9DPfpolFZWmxabn+VogcK3g093h3fHAw0s9cLjsmXZYzKo93ITPVja+L7a2 KjRst/rjQe8FHgStEJdD5jND38h5w8SAQ2nerljfcDQhEMjlv65eVeH8eGGKn+KMnlC+ /qS3dKi0XrZV0KQF8PAyPqzrJT8vjsOmKvLPTYv7/ujH1RKpLktaNMsBaZriJ9jLurVw TpCunh5qehWOerw639IuvNSWOHgCoR4dV2fT80XLcFpOz9YF/xIDtni0zyagEwNZCTr9 BmEA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=5h0uf1/Jt0w1Q00AsARw3vKCBCItevCs2yY073aTWYU=; b=fMVoVIyY4UnFUeEISNJtuKerFTSn7Q7kYHKSEYMdYd2JSRB2M7dS/yBKjVItHqD0e/ sK2pPyb1tlw/42AmW2PjqP4yMzZa6hh4iLSGQqR3fSwe4XII2bzv0GZXeqIddLFVsoj+ 8kDodXcqb22fTcTVh4Z2cujC9LSQ/iL7n3bJLq9/IblituemwG+FII1anaJRoubRIDcD GMX/veaQWhCQjn/2dDxReycthIS8irC9AR0Pt8e5Ng8xImmrWFUy5r/YCLeKkOo/Jhm2 +xfDvj8eC222GjbxAvC61P0yLP0d4/h552jmaVY55oTfkcT7QwgxINsnP7QhhRJ4qZtF e0Cw==
X-Gm-Message-State: ALKqPwdd4LdznGvEGM9IFPTsMlWTrFOj6mFa8UoWmLB3mfVazMJrTR6S hr6Dy9/IizGGJg8aEj+F5ims03POrrk8nJ6P5znifkQVckM=
X-Google-Smtp-Source: ADUXVKKAioj5fmzrnk55wGDaobN7rvOvjuu+WkZSlmxO66b3VsPgFBoIQYmB/x3EDUrHrRHjcc5haDZjVWYy9EUAYgE=
X-Received: by 2002:a9f:3d6b:: with SMTP id m43-v6mr4943451uai.129.1527791065890; Thu, 31 May 2018 11:24:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a1f:9302:0:0:0:0:0 with HTTP; Thu, 31 May 2018 11:24:25 -0700 (PDT)
From: Taylor Brandstetter <deadbeef@google.com>
Date: Thu, 31 May 2018 11:24:25 -0700
Message-ID: <CAK35n0bLdXMVOeh+R5EHegMT4+7eP0dWZ+-7Y82VJkTC4wk5QQ@mail.gmail.com>
To: RTCWeb IETF <rtcweb@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c6882b056d849356"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/lIuiu91_L2nOh935eAqifrs_ius>
Subject: [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.22
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: Thu, 31 May 2018 18:24:31 -0000

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):

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.

Corresponding webrtc-pc issue: https://github.com/w3c/webrtc-pc/issues/1879