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

Lennart Grahl <lennart.grahl@gmail.com> Thu, 12 April 2018 23:22 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 6C11C124D6C for <rtcweb@ietfa.amsl.com>; Thu, 12 Apr 2018 16:22:08 -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 wR_83mbfM7NG for <rtcweb@ietfa.amsl.com>; Thu, 12 Apr 2018 16:22:06 -0700 (PDT)
Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::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 8D42F12422F for <rtcweb@ietf.org>; Thu, 12 Apr 2018 16:22:06 -0700 (PDT)
Received: by mail-wr0-x22a.google.com with SMTP id y7so6604420wrh.10 for <rtcweb@ietf.org>; Thu, 12 Apr 2018 16:22:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:openpgp:cc:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Gc+uZ278nyO6FvL1Obq1aPO2Oz2n5Mlp6POiZYBGokY=; b=BtNxjlkOT/Zk/UC39ysytxzhPPIWq649rvE7dCQyq3k4F/KdG59uKUzm1N4U5XBIeW IpeKjjpMxMRj3RuCoMynHzOwG15hS6TNE8wJItMTO8cdGsRc0CKbvr6EGUvw7/Ub9HeS HV8+7K4S5qBH+/uFSzoZ8T/99R68ub21e+THp0cbffZj9KaUxoriyVb0vQES0DDzhAhp QIshw9HU3L2Tue5DiWvJXgwK2RWDk0yd0phaN8Ad9SRrEzjibw5WtCIINiV70UmlotYL uhBejkcFzwX49PmZCpZNhsN5sWyRKXQJlpAkD/MSfTRvUe5kGWe0o0ZlvO4tfkRULWlH esVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:cc:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Gc+uZ278nyO6FvL1Obq1aPO2Oz2n5Mlp6POiZYBGokY=; b=BfoCMN16GyfcPOyVYGYZXBwZIi6oyRy8t8cVPpNTbv2FXlxRZQtMYkccOmvB8NajeO htBgvKBj52GDgvK4l2jyr01ka2uLNiwVKLd34Z+3HFxPDg/4H8fU1ycFVQZU17B550fa Q8CLujj2oo7qPTyl1LQTq87ryr8nO3dEmwUnkIV584Lqdj3oQULaM1IPqIh/qeC63C35 Hya8pzB9yfPhBjUBqqJ0+UZgINHNh37X1Qj1GyMNvi4Q0ojEJJMZkeBtOcptskoB6zBg Nqix+C/51ccCNekj4AnKTHGhUBNyMya0bDaq24S1iXGJAzmDoXOAz6aw88AC/uw2uwSc wpuA==
X-Gm-Message-State: ALQs6tAy1HIn5CACoeWlYggXt8D10T7vpFVJL005uA2Cq0awJRuoz+jM qcEtvVhfaOW9mOxPsxWaOFU=
X-Google-Smtp-Source: AIpwx48G9lNuqDX5t8+mL1rPqEVd82zI9Wmzl3RhhDANMX0b0AeLC3Ulal6a6OPD3ze28Ph8J0ee8Q==
X-Received: by 10.223.134.213 with SMTP id 21mr1907587wry.221.1523575324801; Thu, 12 Apr 2018 16:22:04 -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 k28sm7725734wrk.96.2018.04.12.16.22.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Apr 2018 16:22:04 -0700 (PDT)
To: 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>
From: Lennart Grahl <lennart.grahl@gmail.com>
Openpgp: preference=signencrypt
Message-ID: <2302437f-68b9-b68f-ac14-011f4cf4066d@gmail.com>
Date: Fri, 13 Apr 2018 01:22:03 +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: <1683BDE2-6E74-40BD-966B-ED7DFEB58083@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/EzEQoW8xlDTWTXUluJ_B_qjiIFw>
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: Thu, 12 Apr 2018 23:22:08 -0000

On 11.04.2018 23:24, Michael Tuexen wrote:
>> On 11. Apr 2018, at 22:29, Taylor Brandstetter <deadbeef@google.com> wrote:
>>
>> I listened to the recording, and this was the main point being discussed, but the conclusion seemed to be "efficient implementations shouldn't use much (or any) memory for unused streams; we shouldn't make sacrifices in the protocol just to reduce implementation complexity."
> You can implement it in a way to not use much memory for unused streams. However, you need some memory
> for stream you use. That is why I referred to the number of streams used in parallel.

So, implementations with limited resources may still choose to negotiate
less than that to prevent running into exhausting their resources. That
makes sense to me, so I would withdraw the request to make it a MUST.
Could this explanation be added as a comment to the draft, so it's clear
why it's not a MUST?

FWIW, I don't believe any browser would count as an implementation with
limited resources. But I get that there are other implementations
outside of the browser and it may make sense there to limit the amount
of streams. And since we can interoperate with them, we need to handle
it some way or another in the W3C WebRTC spec.

Taylor, any objections?

Cheers
Lennart