IETF Logo Mail Archive

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

Michael Tuexen <michael.tuexen@lurchi.franken.de> Fri, 13 April 2018 06:03 UTC

Return-Path: <michael.tuexen@lurchi.franken.de>
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 020D6126D45 for <rtcweb@ietfa.amsl.com>; Thu, 12 Apr 2018 23:03:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=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 xXewfGTE9xCR for <rtcweb@ietfa.amsl.com>; Thu, 12 Apr 2018 23:03:31 -0700 (PDT)
Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 433E7126C22 for <rtcweb@ietf.org>; Thu, 12 Apr 2018 23:03:31 -0700 (PDT)
Received: from [IPv6:2003:cd:6f00:5e00:64b7:97b8:c253:28cb] (p200300CD6F005E0064B797B8C25328CB.dip0.t-ipconnect.de [IPv6:2003:cd:6f00:5e00:64b7:97b8:c253:28cb]) (Authenticated sender: lurchi) by drew.franken.de (Postfix) with ESMTPSA id 6BFDC721E281E; Fri, 13 Apr 2018 08:03:28 +0200 (CEST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
From: Michael Tuexen <michael.tuexen@lurchi.franken.de>
In-Reply-To: <CAK35n0Y_e-c=YKc0pFTiD+n_NkKhZXb1MaKscnCbgkWoiYsMxA@mail.gmail.com>
Date: Fri, 13 Apr 2018 08:03:27 +0200
Cc: Lennart Grahl <lennart.grahl@gmail.com>, RTCWeb IETF <rtcweb@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <4FFCC73B-7BFB-4A32-9B13-C4C0F5BA7408@lurchi.franken.de>
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>
To: Taylor Brandstetter <deadbeef@google.com>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/Q13qmFJLzByl1f_yPL4PRN2MpIs>
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 06:03:34 -0000

> 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.

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.

Best regards
Michael
> 
> On Thu, Apr 12, 2018 at 4:22 PM, Lennart Grahl <lennart.grahl@gmail.com> wrote:
> 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
>

v2.23.0 | Report a Bug | By Email