IETF Logo Mail Archive

Re: [rtcweb] Amount of streams supported for data channels

Lennart Grahl <lennart.grahl@gmail.com> Fri, 13 April 2018 14:14 UTC

Return-Path: <lennart.grahl@gmail.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 53563120721 for <rtcweb@ietfa.amsl.com>; Fri, 13 Apr 2018 07:14:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 dIOrX94U-2Je for <rtcweb@ietfa.amsl.com>; Fri, 13 Apr 2018 07:14:24 -0700 (PDT)
Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (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 690351201F2 for <rtcweb@ietf.org>; Fri, 13 Apr 2018 07:14:24 -0700 (PDT)
Received: by mail-wr0-x22e.google.com with SMTP id u11so8508086wri.12 for <rtcweb@ietf.org>; Fri, 13 Apr 2018 07:14:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:openpgp:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=31f2EvSuKy8Ii1tPy2MEh0ALokAp4HscXcihNM+SmO4=; b=M+oyyjVdvRUZd2L+aRXrEntv+gRo/OWj6Tdv1fjjqZY7egeoRUPRYujAy3vlEcC2em f2V5rBRU9I2hDGFkWgMsa8jXUW1LGr0ia97w0Cmbqtangmr50Cd3W8ulpkDTqIyM0XrO NR6yZ6loOJBa8oZKoMwfuWuic9JXO2g4xdEZZq67BXh4lxMzKpKkvB5UiFqdI0aqhiYS gZmZbhDj3u4aR3NJTvz6KSsn1aHBqwFPe8x7+YbvwTGkODayFr0CSXJZzo8psaehUYKQ EHdHkFduoi4eClZQHpbmDtqo1sVCl7sFlYlONctlUj6nlyu6bFsFNMGsBfQnzjKbK7gz eE7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=31f2EvSuKy8Ii1tPy2MEh0ALokAp4HscXcihNM+SmO4=; b=oBA/+Z7RFSwn8X6U82uF27TunLqcnpBeD4XPwhiRxWxaeP7mzR08sDzUswbm3/hSCT jdOcECFKqEDWoHOdPDIu05x5S8dZ5mzjKV5WtBBQTJS526E8TNG688LTbe9Kg+r85I3Q M8IKiZYnmENK6vGBc6STkxvEkpwN8garmQ7OT48yTOQeZ1HYtkgW2xfpgk34PdndSoJq 9kwBQzj9YLRMpcV//giUFPugUmOPnvFdZnaczFihN+ucwYB/upF4QYOWQFR0dvssQ2bF RHcC0dnfmDRjU36eGBpTZ3wjBMb0N0AUQdiDHdOQCgA8kd1Dg+AVgUc6vnH2pzpQU4vj HTMw==
X-Gm-Message-State: ALQs6tBQmVZ2D2Odp+9yfb/Q5anV0Kb0ZwRDDW9DdFaIG8eHMk48PRoG HN0f8xtVlhUgouxqLc7DM1RhxZKQ
X-Google-Smtp-Source: AIpwx4/K9aFFUucZB02WF2OsN5/KrvvFC7H+fWfxnj4u+biz/mV6E683efgAbvmhLBJrlSxa4ribjw==
X-Received: by 10.80.131.102 with SMTP id 93mr4397819edh.9.1523628862653; Fri, 13 Apr 2018 07:14:22 -0700 (PDT)
Received: from ?IPv6:2003:cd:6f24:eb00:5cda:3e20:eb99:6efc? (p200300CD6F24EB005CDA3E20EB996EFC.dip0.t-ipconnect.de. [2003:cd:6f24:eb00:5cda:3e20:eb99:6efc]) by smtp.gmail.com with ESMTPSA id b8sm3147636edi.14.2018.04.13.07.14.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Apr 2018 07:14:21 -0700 (PDT)
To: Michael Tuexen <michael.tuexen@lurchi.franken.de>, Taylor Brandstetter <deadbeef@google.com>
Cc: RTCWeb IETF <rtcweb@ietf.org>
References: <08aec6ec-62ce-a1e4-7781-06d50f5f66f5@gmail.com> <CAK35n0YekgWUSd8opG3YRaYKf4PVYZp9TAtN1beeQ-JO=kzv8A@mail.gmail.com> <7E12AF68-A247-469D-887E-065FEBD47D66@lurchi.franken.de> <CAK35n0Z491szZ+6R8Z+qMQxd2p6m4TT9_XZrjgYwsQPho2H+Kw@mail.gmail.com> <1683BDE2-6E74-40BD-966B-ED7DFEB58083@lurchi.franken.de> <2302437f-68b9-b68f-ac14-011f4cf4066d@gmail.com> <CAK35n0Y_e-c=YKc0pFTiD+n_NkKhZXb1MaKscnCbgkWoiYsMxA@mail.gmail.com> <4FFCC73B-7BFB-4A32-9B13-C4C0F5BA7408@lurchi.franken.de>
From: Lennart Grahl <lennart.grahl@gmail.com>
Openpgp: preference=signencrypt
Message-ID: <d542717b-0dfe-b359-02fe-b904a9cc0159@gmail.com>
Date: Fri, 13 Apr 2018 16:14:20 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <4FFCC73B-7BFB-4A32-9B13-C4C0F5BA7408@lurchi.franken.de>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/5xiNls3Pcd4m1JTTtSp32w505xA>
Subject: Re: [rtcweb] Amount of streams supported for 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: Fri, 13 Apr 2018 14:14:26 -0000

On 13.04.2018 08:03, Michael Tuexen wrote:
>> On 13. Apr 2018, at 06:28, Taylor Brandstetter <deadbeef@google.com> wrote:
>>
>>> FWIW, I don't believe any browser would count as an implementation with
>>> limited resources.
>>
>> If so, it could say "browsers MUST attempt to negotiate 65535 streams, but be prepared for negotiating fewer, e.g. when communicating with a non-WebRTC endpoint with limited resources"?
>>
>> Or could just add an explanation for the SHOULD; I don't have strong opinions about this.
> You can make a text suggestion... I would vote for an explanation of the SHOULD.

A suggestion:

   The number of streams negotiated during SCTP association setup SHOULD
   be 65535, which is the maximum number of streams that can be
   negotiated during the association setup. Implementations with limited
   resources may support less than 65535 streams to mitigate resource
   exhaustion when many streams are being used in parallel.

I hope that is enough of a hint towards browser implementations to read
the SHOULD as a MUST.

> However, please note that the ID is in the RFC Editor queue. So it is not
> just updating an ID. I'm not sure which changes except for the usual AUTH48 changes
> can be done anymore.

This is all still fairly new to me, so I don't know how to proceed. If
the section can't be changed any more, I guess it's not a big deal since
we at least have discussed it here and have a rough idea on how to
proceed regarding the W3C WebRTC spec.

Cheers
Lennart

v2.23.0 | Report a Bug | By Email