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

[Stefan Holmer <[e-mail]>]

On Tue, Apr 12, 2022 at 7:17 PM Stephan Wenger <[e-mail]> wrote:

> 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).
>

Yes, I agree that's the preferred way.


> >
> > 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.
>

That was my understanding too, and I agree with it. :)


> >
> > 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>
>