bufferedAmount property on PresentationConnection

[tidoust]

Still looking at similarities with WebSockets and WebRTC data channels, I note that they both define a bufferedAmount property that returns the number of bytes of application data queued using send() but not yet transmitted to the network.

This property is typically useful for a Web app to handle congestion issues and e.g. prioritize messages to transmit or otherwise postpone non essential transmissions. Should we have a similar mechanism?

WebRTC goes a bit farther than WebSockets and also defines a bufferedAmountLowThreshold and a bufferedamountlow event.

[mfoltzgoogle]

We currently require that the messages are sent in-order but don't require a concept of a buffer or queue. One could imagine that messaging is implemented by IPC (for the 1-UA scenario) or server messaging (where the messages may be buffered outside the context of the user agent). How would we define the bufferedAmount attribute to cover all these cases?

[tidoust]

These are good points. I suspects we can find workarounds, e.g. using specific values for bufferedAmount to avoid introducing additional requirements on the data channel. The property could always return 0 when IPC is used as it probably does not introduce noticeable delivery lags from an application perspective. Similarly, a -1 value (or a separate flag) could mean "I do not know".

The main question for me is whether such a feature is needed. My understanding is that congestion control got added to WebSockets and RTCDataChannel because developers asked for it, in particular to control the sending of large chunks of data. Some of it can probably be implemented at the application level, through "ack" messages from the other side for instance.

Unless people in the group think that it must be added to the spec, I would suggest not to introduce congestion control and rather ask people for feedback on whether such a mechanism should be added to the spec when we issue the call for wide review.

[mfoltzgoogle]

As long as there is a reasonable accommodation when the concept of "bufferedAmount" does not apply to a particular messaging transport, I'm fine with adding it. But it feels like an enhancement that could be added later, and I would still like to see when it would be useful in practice.

[mfoltzgoogle]

Note, also, that the Streams spec allows explicit management of backpressure (buffer length) [1]. So this enhancement could be addressed by adding Streams support to the PresentationConnection interface.

[1] https://streams.spec.whatwg.org/#queuing-strategies

[tidoust]

I agree that this can be added later on, that we haven't heard about concrete use cases that would make it a priority, and that a bufferedAmount property is just one of the possible solutions in any case.

PROPOSED RESOLUTION: Close #241 "bufferedAmount property on PresentationConnection". We will not add a congestion control mechanism in this version of the Presentation API

[mfoltzgoogle]

Closing for now. We can reopen if use cases or demand arise.