Re: ICE freezing and Bandwidth Estimation

On Thu, May 17, 2018 at 8:58 AM Bernard Aboba <Bernard.Aboba@microsoft.com>
wrote:

> In the draft F2F agenda sent to the mailing list yesterday, I have
> included a session on ICE freezing and Bandwidth Estimation.
>
> These topics might seem somewhat obscure, so an explanation of their
> potential relevance to "WebRTC NV" is in order.
>
> One of the implications of designing an NV API that does not utilize SDP
> is that the information currently provided by SDP will not be available
> unless API surface is added to explicitly provide that information.
>
> In the design of the ORTC API, the IceTransportController object was
> defined in order to enable the operation of ICE freezing and Bandwidth
> Estimation in the absence of SDP:
> http://draft.ortc.org/#rtcicetransportcontroller*
>
> By ordering IceTransport objects in a list, the IceTransportController can
> provide some of the same information for use in ICE freezing as is
> available in SDP with respect to ordering of m-lines and bundle groups.
>

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.


> As far as I know, there is only a single implementation of this (ORTC
> lib).
>
> The other use of the IceTransportController was for Bandwidth Estimation.
> Here the goal was to group together related IceTransports for the purpose
> of a group bandwidth estimate. Something along those lines (though grouping
> IceGatherer objects instead of IceTransports) was implemented in Edge
> ORTC.
>
> Since bandwidth usage is more directly related to RTP streams than to
> IceTransports, there has also been discussion of a potential RtpController
> object:
> https://github.com/w3c/ortc/issues/603
>
> Given that this topic has generated inconsistent implementations and
> differing points of view, some discussion might be worthwhile (assuming
> that the group is willing and we can find volunteers to lead it).
>

Where congestion control should go is a good question.  We currently have
an easy answer for SCTP (SctpTransport) and QUIC (QuicTransport). I think a
similar answer would make sense to me (RtpTransport).

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.

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.