Would it be useful to have an API to set a bandwidth limit that's shared between IceTransports (or RtpSenders)?

Use cases

• An endpoint (or the endpoint it's communicating with) is on a metered network, and the user wants to limit the total bandwidth to reduce cost from their ISP.
• The application wants to limit the bandwidth to reduce load on a middlebox (SFU/MCU/etc.) or other intermediate entity.

Limitations with existing methods

You could use RtpEncodingParameters.maxBitrate to effectively accomplish this. Say the application has two video tracks, one of which requires more bits than the other (maybe it's larger, or just prioritized higher). The application wants to limit the total bandwidth to approx. 3Mbps, so it sets a maxBitrate of 2Mbps and 1Mbps on the two senders.

But this approach has limitations:

• The application is not in the best position to decide the balance between the two video tracks, since bitrate is codec/resolution/content-dependent. The browser has more information it can use to do a better job balancing. A 2:1 ratio may work well for one call, but not for another.
• With a hard maxBitrate on each sender, the balance between them can't responsively change over time. Suppose one video track experiences a momentary increase in motion, requiring a higher bitrate to maintain quality. Even if the other track has bits to spare, the track experiencing motion can't "borrow" these bits because it's constrained by its own maximum. It would be unreasonable to expect the application to respond to this, but not unreasonable for the browser to.

Solution

Allow the application to specify a maximum bandwidth that constrains a set of IceTransports (or possibly RtpSenders; see below). Practically speaking, this would just mean that if the bandwidth estimator produces a larger estimate, it's ignored in favor of the application-set maximum.

Some ideas for how the API would look:

• Add a method to IceTransportController, since it's currently described as handling bandwidth estimation for a group of transports.
  • Issue with this approach: We're unlikely to combine the RTP and SCTP bandwidth allocation (I assume). So this API really affects the RTP level, not the ICE transport level. If you have an IceTransportController only used for SCTP, it would be strange for this method to not have any effect.
• Introduce a new object (RtpTransport?) that groups RtpSenders for the purposes of bandwidth estimation and allocation. Avoids the above problem.
  • Does this mean you could have two RtpSenders that use the same IceTransport but a different bandwidth estimator? Does that make sense in any circumstance? I'm unsure how the API could be designed to prevent this.