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

From: Lennart Grahl <[email-masked]>
Date: Wed, 11 Apr 2018 14:08:05 +0200

Hi,

there's an ongoing W3C spec discussion regarding the minimum amount of
streams that need to be supported by a WebRTC data channel
implementation, see: https://github.com/w3c/webrtc-pc/issues/1829

draft-ietf-rtcweb-data-channel-13, section-6.2 states:

   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.

Is there any reason why it needs to be a SHOULD? Could we make this a MUST?

Cheers
Lennart

---

From: Taylor Brandstetter <[email-masked]>
Date: Wed, 11 Apr 2018 11:50:01 -0700

The conclusion when this was discussed at IETF 88 was "Set it to maximum
and be done with it." Which sounds like MUST to me...

On Wed, Apr 11, 2018 at 5:08 AM, Lennart Grahl <[email-masked]>
wrote:

> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 11 Apr 2018 21:26:20 +0200

> On 11. Apr 2018, at 20:50, Taylor Brandstetter <deadbeef=[email-masked]> wrote:
> 
> The conclusion when this was discussed at IETF 88 was "Set it to maximum and be done with it." Which sounds like MUST to me....
I think the reason for the SHOULD was that it would allow implementations with limited resources and
knowing that they don't need that number of parallel data channels can use a lower number.

Best regards
Michael
> 
> On Wed, Apr 11, 2018 at 5:08 AM, Lennart Grahl <[email-masked]> wrote:
> Hi,
>

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 11 Apr 2018 21:26:20 +0200

Best regards
Michael

---

From: Taylor Brandstetter <[email-masked]>
Date: Wed, 11 Apr 2018 13:29:19 -0700

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

Discussion starts at 1:42:19:
https://www.ietf.org/audio/ietf88/ietf88-regencyd-20131104-1450-pm2.mp3

On Wed, Apr 11, 2018 at 12:26 PM, Michael Tuexen <
[email-masked]> wrote:

> and be done with it." Which sounds like MUST to me....

---

From: Taylor Brandstetter <[email-masked]>
Date: Wed, 11 Apr 2018 13:29:19 -0700

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 11 Apr 2018 23:24:13 +0200

> On 11. Apr 2018, at 22:29, Taylor Brandstetter <[email-masked]> 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.

Another point to be considered is that currently most implementations don't offer 65665 incoming streams.
So if you would change it to a MUST, not many implementations would be compliant.
If you change it to a MUST, I would expect that implementations ABORT the SCTP association when
the peer violates the specification by not requesting 65535 outgoing streams and allowing 65535
incoming streams.

So what do you gain by changing to from SHOULD to MUST?

Best regards
Michael
> 
> Discussion starts at 1:42:19: https://www.ietf.org/audio/ietf88/ietf88-regencyd-20131104-1450-pm2.mp3
> 
> On Wed, Apr 11, 2018 at 12:26 PM, Michael Tuexen <[email-masked]> wrote:

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 11 Apr 2018 23:24:13 +0200

Best regards
Michael

---

From: Lennart Grahl <[email-masked]>
Date: Fri, 13 Apr 2018 01:22:03 +0200

> 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

---

From: Taylor Brandstetter <[email-masked]>
Date: Thu, 12 Apr 2018 21:28:24 -0700

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

On Thu, Apr 12, 2018 at 4:22 PM, Lennart Grahl <[email-masked]>
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."

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 13 Apr 2018 08:03:27 +0200

> On 13. Apr 2018, at 06:28, Taylor Brandstetter <[email-masked]> wrote:
> 
> 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 <[email-masked]> wrote:

---

From: Lennart Grahl <[email-masked]>
Date: Fri, 13 Apr 2018 16:14:20 +0200

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

> just updating an ID. I'm not sure which changes except for the usual AUTH48 changes

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

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 13 Apr 2018 18:17:44 +0200

> On 13. Apr 2018, at 16:14, Lennart Grahl <[email-masked]> wrote:
> 
I would suggest to use (just changing one may to MAY):

  resources MAY support less than 65535 streams to mitigate resource

> proceed regarding the W3C WebRTC spec.
The document was finished and submitted to the RFC editor in January 2015.
It is stuck there because of MISREFS.

I guess one can change things with AD approval, but I don't want to go through
the whole WG LC and IETF LC procedure again for this change (which I consider
a clarification).

Best regards
Michael

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 28 Apr 2018 16:44:33 -0600

> On Apr 11, 2018, at 6:08 AM, Lennart Grahl <[email-masked]> wrote:
> 

Yes … when the WG was discussing this the thing that came up was WebRTC devices that are doing IoT stuff often will not have enough memory to do the state for 65k of them. So I don’t think we should require 65k data connections for all uses of rtcweb but theses devices are unlikely to be using the JS API so the question of what to do there is different.