Re: [AVTCORE] Response to W3C WebTransport WG Request from IETF 112

[Stephan Wenger <[e-mail]>]

correct. S.

Sent from my iPhone

> On Apr 12, 2022, at 09:11, Joerg Ott <[e-mail]> wrote:
> 
> Agreed.  But you will want to be to collect congestion control cues from
> the underlying transport, so you don't have to measure yourself (again).
> 
> And if I understood Stephan correctly, he was not arguing that the the
> lower layer should have the information about which application would be
> run but rather to provide sufficient richness in the API that all kinds
> of applications on top.
> 
> Jörg
> 
>> On 12.04.22 14:06, Stefan Holmer wrote:
>> I agree with Sergio here, I think for WebTransport to be really useful for RTC there's a need to have app level control of congestion control. Based on experience from libwebrtc, the congestion control is constantly being improved, and I think it's far from a solved problem. To allow for RTC apps on WebTransport to be competitive I think they'd benefit a lot from being able to innovate on the congestion control side.
>> On Mon, Apr 11, 2022 at 10:08 PM Bernard Aboba <[e-mail] <mailto:[e-mail]>> wrote:
>>    Sergio said:
>>    "I don't think that the webtransport api and the browser stack
>>    should have this information, it is completely up to the application
>>    to control what is the behaviour based on the current bw estimation.
>>    Moreover, I doubt that the webtransport stack could provide a valid
>>    bw estimation usable by the app at all.
>>    IMHO the bwe needs to be calculated at the js app level and just
>>    needs the quic cc not mess too much and if possible provide the
>>    reception time stats for the sent packets"
>>    [BA] It is left to the Javascript application to decide the
>>    transport mode, audio/video multiplexing approach, loss recovery
>>    strategy and mechanism for controlling the encoder rate.  The
>>    WebTransport API doesn't know and doesn't care whether the
>>    transported media is G711, G722, Opus, VP8/VP9, H.264, AV1, etc.
>>    Currently there is no priority support, so it's up to the
>>    application how to apportion the bandwidth between audio and video
>>    streams.
>>    The current WebTransport stats are very bare bones:
>>    https://w3c.github.io/webtransport/#web-transport-stats
>>    <https://w3c.github.io/webtransport/#web-transport-stats>
>>    https://w3c.github.io/webtransport/#web-transport-stats%E2%91%A0
>>    <https://w3c.github.io/webtransport/#web-transport-stats%E2%91%A0>
>>    Some stream stats are in the works (see:
>>    https://github.com/w3c/webtransport/pull/395
>>    <https://github.com/w3c/webtransport/pull/395>) but they also aren't
>>    elaborate (at least compared with WebRTC-stats).
>>    You'll notice there is no bandwidth estimate, nor is any info
>>    provided on acknowledgements or reception times.  Since a Javascript
>>    application using the WebTransport API is not integrated with the
>>    QUIC stack, info on ACKs was not considered relevant since the
>>    application could not be presumed to have received a datagram just
>>    because it was ACK'd at the QUIC layer; the datagram could have been
>>    subsequently dropped in the browser datagram reception queue after
>>    being ACK'd.  Similarly, in the browser, the reception time doesn't
>>    reflect the total one-way delay because there are additional delays
>>    and queues both on the sender and receiver side.
>> You could imagine a WebTransport that had a circuit-breaker style CC and either exposed feedback only about the send and arrival time of each packet to the application, without any guarantees of whether the application on the other end actually got hold of the packet in the end. With a circuit-breaker style CC you could also leave it to the app to handle that feedback/signaling entirely in the app-layer, at the cost of additional overhead.
>>      However, the receiver can calculate the goodput on  streams and
>>    datagram flows and provide this info to the sender to help with
>>    encoder rate adaptation.
>>    On Mon, Apr 11, 2022 at 12:10 PM Sergio Garcia Murillo
>>    <[e-mail]
>>    <mailto:[e-mail]>> wrote:
>>        El lun, 11 abr 2022 18:19, Stephan Wenger <[e-mail]
>>        <mailto:[e-mail]>> escribió:
>>            Inline in blue.____
>>            S.____
>>            __ __
>>            __ __
>>            On 4/11/22, 08:24, "avt on behalf of Jonathan Lennox"
>>            <[e-mail] <mailto:[e-mail]> on
>>            behalf of [e-mail]
>>            <mailto:[e-mail]>> wrote:____
>>            __ __
>>            __ __
>>            __ __
>>                 > On Apr 11, 2022, at 1:34 AM, Spencer Dawkins at IETF
>>            <[e-mail]
>>            <mailto:[e-mail]>> wrote:____
>>                 > ____
>>                 > But even if we don't need to choose between
>>            media-oriented congestion controllers, we would need a QUIC
>>            extension to allow us to say "we're doing media, so don't
>>            use the congestion controllers you might use for non-media
>>            traffic". ____
>>                 > ____
>>                 > I suspect the QUIC working group would be a fine
>>            place to work on that extension (and if we did it anywhere
>>            else, QUIC would either ask, or be asked, to review that
>>            work anyway). ____
>>            __ __
>>                 It’s not clear to me that you need a *protocol*
>>            extension to signal this?  Monolithically, a sender knows
>>            that it’s sending media, and can choose its congestion
>>            control algorithm appropriately.____
>>            __ __
>>                 You definitely would need *API* signaling to indicate
>>            from the application to the QUIC stack that media is being
>>            sent, and thus an appropriate low-latency congestion
>>            controller should be chosen.  This is absolutely relevant to
>>            the W3C API, and thus should probably be communicated in the
>>            liaison statement response.____
>>            __ __
>>            Right.  And ideally, that API signaling would be powerful
>>            enough to differentiate between different media and their
>>            requirements.  For example:____
>>            -G711 audio has zero elasticity; if CC were to kick in, the
>>            realistic choices are to ignore the CC, or terminate the
>>            session.  No middle ground. ____
>>            -Multi-resolution pre-coded video (think DASH) has some
>>            flexibility, but bitrate adjustment can take many hundred
>>            milliseconds to seconds.____
>>            -a software-based real-time video encoder can be built to
>>            have a lot of flexibility, on very short notice—but, the
>>            application/user may not like the encoder to exercise that
>>            flexibility.  For example, broadcast contribution
>>            applications and their encoders would not want to start
>>            skipping frames, go down with the resolution, or too far up
>>            with the QP, even if that would make the CC happy.  Video
>>            conferencing, OTOH, could cope with all of that, up to a
>>            certain pain-point.
>> These are good examples of why CC for media (and RTC in particular) is complicated, and probably one of the reasons why (AFAIK) no RTC CC implementations that use off-the-shelf algorithms or interfaces.
>> You may want to (try to) be smart about how you evaluate whether the bandwidth of the connection allows you to turn on a higher resolution video stream, to avoid having to waste bits on padding data. You may not want to saturate the connection at all times to make sure the CC operates correctly. In fact, you may want to make sure to only probe for higher bandwidth when you feel like it's "safe" to do so from a media quality view. This would likely require some closer interaction with the CC.
>>        I don't think that the webtransport api and the browser stack
>>        should have this information, it is completely up to the
>>        application to control what is the behaviour based on the
>>        current bw estimation.
>>        Moreover, I doubt that the webtransport stack could provide a
>>        valid bw estimation usable by the app at all.
>>        IMHO the bwe needs to be calculated at the js app level and just
>>        needs the quic cc not mess too much and if possible provide the
>>        reception time stats for the sent packets.
>>        Best regards
>>        Sergio
>>        _______________________________________________
>>        Audio/Video Transport Core Maintenance
>>        [e-mail] <mailto:[e-mail]>
>>        https://www.ietf.org/mailman/listinfo/avt
>>        <https://www.ietf.org/mailman/listinfo/avt>
>>    _______________________________________________
>>    Audio/Video Transport Core Maintenance
>>    [e-mail] <mailto:[e-mail]>
>>    https://www.ietf.org/mailman/listinfo/avt
>>    <https://www.ietf.org/mailman/listinfo/avt>