Re: ICE freezing and Bandwidth Estimation

On 05/19/2018 02:25 AM, Bernard Aboba 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's been stats variables added for candidate pairs' RTT and
bandwidth estimate:

https://w3c.github.io/webrtc-stats/webrtc-stats.html#dom-rtcicecandidatepairstats-totalroundtriptime

The bandwidth estimates there are specified as the sum of bandwdth
estimates for the component streams.
There are techniques for group bandwidth estimates
(draft-ietf-rmcat-coupled-cc); if we want that as part of the
user-exposed model, we may need to have some place where it can live.
>
> 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 we don't want magic hidden connections between objects (do we?), we
need to provide a model.
I'd think this would be called a "congestion controller" object, not an
"ICE transport" object; I'm not sure whether it would relate to an
ICETransport or just to candidate pairs, given that sharing congestion
state between candidate pairs only makes sense if the candidate pairs
share a bottleneck.


-- 
Surveillance is pervasive. Go Dark.

Received on Monday, 21 May 2018 03:48:55 UTC