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

[Stephan Wenger <[e-mail]>]

Inline in blue.

S.





On 4/11/22, 08:24, "avt on behalf of Jonathan Lennox" <[e-mail] on behalf of [e-mail]> wrote:







    > On Apr 11, 2022, at 1:34 AM, Spencer Dawkins at IETF <[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.



    (There may be QUIC protocol extensions needed to support these low-latency congestion controllers, probably something like draft-huitema-quic-ts, but I think work’s ongoing on that pretty well already.)

    _______________________________________________

    Audio/Video Transport Core Maintenance

    [e-mail]

    https://www.ietf.org/mailman/listinfo/avt