[ortc] API for a shared bandwidth limit

taylor-b has just created a new issue for https://github.com/w3c/ortc:

== API for a shared bandwidth limit ==
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.).

**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 `RtpSender`s 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.

Please view or discuss this issue at 
https://github.com/w3c/ortc/issues/603 using your GitHub account

Received on Tuesday, 4 October 2016 22:30:37 UTC