Re: ICE freezing and Bandwidth Estimation

On Fri, May 18, 2018 at 5:25 PM Bernard Aboba <Bernard.Aboba@microsoft.com>
wrote:

> On May 18, 2018, at 16:24, Peter Thatcher <pthatcher@google.com> wrote:
> >
> > I think for WebRTC NV it would be better to simplify and say that all
> IceTransports are separate ICE agents and no freezing happens.  I'm pretty
> sure most browsers don't, and never will, implement freezing behavior
> anyway.  And I don't think any applications really care anyway about the
> theoretical benefit that would come from freezing.  It's more likely they
> care about things like controlling when relay server is used or not, or if
> backup candidates pairs are used and that sort of thing.
>
> [BA] +1.
>
> In Edge ORTC we largely ignore freezing which was one of the reasons we
> did not initially see value in IceTransportController.  So far that does
> not seem to have resulted in any ICE interoperability issues.  So I agree
> we don’t need to worry about freezing.
>
> Peter also said:
>
> “ICE-based BWE makes no sense to me.  It's the wrong layer for that.  I
> suppose if the app could control the timing of checks and know when
> responses come back (as with SLICE), then an app could do some form of BWE,
> but limited by the global ICE pacer/limiter. “
>
> [BA] I understand the concept of estimating throughput or latency for a
> candidate pair and can think of some uses for that (like choosing the
> selected pair), though I’m not clear how much of this needs to be exposed
> to the application.
>
> There *might* be a use case for estimating or restricting bandwidth in a
> mesh conference (e.g. imposing a collective limit on multiple RtpSenders).
> But as you say, that would seem to be motivation for an RtpController, not
> an IceTransportController object.
>
> So overall, I’m left scratching my head.  What were we thinking??
>
> > If we want BWE exposed to the app, expose a way to get a BWE value from
> the SctpTransport, QuicTransport, and/or RtpTransport.  That would be
> useful.
>
> [BA] I can certainly see value in that from a statistical point of view.
> Is there reason to consider this outside the Stats API?


If the encoders are separated from the transport, then someone needs to
read the BWE value from the transport and feed it into the encoders (and
decided how to allocate bandwidth among them).  This would also give the
app complete control over bitrate allocation between streams.