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

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 11 Apr 2022 00:34:55 -0500

Hi, Colin,

On Fri, Mar 25, 2022 at 4:44 AM Colin Perkins <[email-masked]> wrote:

> Hi,
>
> To echo my comments at the mic during IETF 113.
>
> RFC 8888 describes the information the group believed needed to perform
> congestion control. QUIC already provides this information in connections.
>
> The RMCAT working group developed a number of RTP congestion control
> algorithms. I expect these could be incorporated into QUIC as alternatives
> to its current congestion control, if there was as need, but RMCAT isn’t
> chartered to do so.
>

ISTM that there are two issues here, wrapped around each other.

We don't have a way to signal congestion controllers in QUIC now, because
the choice of NewReno, or CUBIC, or BBRv1, or BBRv2, or whatever, doesn't
need that for HTTP/3 traffic.

I'm not sure (are others sure?) whether we would need to be able to choose
between media-oriented congestion controllers (SCReAM, or NADA, or
whatever) for RTP traffic. So, that's one interesting issue.

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

Best,

Spencer

> In the IRTF, ICCRG can provide advice about congestion control algorithms.
>
> Colin
>
>
> On 16 Feb 2022, at 01:12, Bernard Aboba <[email-masked]> wrote:
>
> At IETF 112, the W3C WebTransport WG presented a request for feedback to
> the AVTCORE WG:
>
> https://docs.google.com/presentation/d/1XB-RTt-ejDTillmkYcT3l6EBzNK7pARw51TqKcCxo8A/edit#slide=id.gfc2dae0c1a_0_125
>
> The request related to problems encountered with W3C WebTransport API use
> cases involving attempts to send media with low latency from client ->
> server. Currently, WebTransport implementations are based on BBRv1
> congestion control in QUIC and support datagram prioritization in an effort
> to improve QUIC datagram latency.
>
> The presentation today from M. Engelbart appears to shed light on the
> request, even though the results presented were based on NewReno CC instead
> of BBRv2/v2.
>
> Based on the experimental results, can we make any recommendations?  For
> example, can we say:
>
> 1.  Attempting to implement a low-latency congestion control algorithm for
> QUIC datagrams (e.g. SCReaM or GCC) on top of QUIC congestion control (New
> Reno, BBRv1/v2) isn't recommended.  Instead, it is preferred to implement
> an alternative CC algorithm within the QUIC implementation.
>
> 2. Naive prioritization schemes such as strict priority for QUIC datagrams
> result in high queueing delays, since reliable stream data will fill the
> congestion window when datagrams aren't being sent.  This problem will
> occur even with CC algorithms such as BBRv1/v2 (not just NewReno).
>
>
>
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>
>
>
>
> --
> Colin Perkins
> https://csperkins.org/
>
>
>
>
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>

---

From: Colin Perkins <[email-masked]>
Date: Mon, 11 Apr 2022 09:08:19 +0100

Hi Spencer,

> On 11 Apr 2022, at 06:34, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> Hi, Colin, 
> 
> On Fri, Mar 25, 2022 at 4:44 AM Colin Perkins <[email-masked] <mailto:[email-masked]>> wrote:
> Hi,
> 
> RFC 8888 describes the information the group believed needed to perform congestion control. QUIC already provides this information in connections.
> 
> The RMCAT working group developed a number of RTP congestion control algorithms. I expect these could be incorporated into QUIC as alternatives to its current congestion control, if there was as need, but RMCAT isn’t chartered to do so.
> 
> We don't have a way to signal congestion controllers in QUIC now, because the choice of NewReno, or CUBIC, or BBRv1, or BBRv2, or whatever, doesn't need that for HTTP/3 traffic. 
> 
> I'm not sure (are others sure?) whether we would need to be able to choose between media-oriented congestion controllers (SCReAM, or NADA, or whatever) for RTP traffic. So, that's one interesting issue. 
> 
> 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). 

I’d agree that, if such signalling is needed, the QUIC working group would be the right place to develop it. 

Does it need signalling though? Most (all?) of the congestion control algorithms for QUIC seem to be entirely driven by the sender, which knows that it’s sending media. 

Colin

>> On 16 Feb 2022, at 01:12, Bernard Aboba <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> At IETF 112, the W3C WebTransport WG presented a request for feedback to the AVTCORE WG:
>> https://docs.google.com/presentation/d/1XB-RTt-ejDTillmkYcT3l6EBzNK7pARw51TqKcCxo8A/edit#slide=id.gfc2dae0c1a_0_125 <https://docs.google.com/presentation/d/1XB-RTt-ejDTillmkYcT3l6EBzNK7pARw51TqKcCxo8A/edit#slide=id.gfc2dae0c1a_0_125>
>> 
>> The request related to problems encountered with W3C WebTransport API use cases involving attempts to send media with low latency from client -> server. Currently, WebTransport implementations are based on BBRv1 congestion control in QUIC and support datagram prioritization in an effort to improve QUIC datagram latency.
>> 
>> The presentation today from M. Engelbart appears to shed light on the request, even though the results presented were based on NewReno CC instead of BBRv2/v2. 
>> 
>> Based on the experimental results, can we make any recommendations?  For example, can we say: 
>> 
>> 1.  Attempting to implement a low-latency congestion control algorithm for QUIC datagrams (e.g. SCReaM or GCC) on top of QUIC congestion control (New Reno, BBRv1/v2) isn't recommended.  Instead, it is preferred to implement an alternative CC algorithm within the QUIC implementation. 
>> 
>> 2. Naive prioritization schemes such as strict priority for QUIC datagrams result in high queueing delays, since reliable stream data will fill the congestion window when datagrams aren't being sent.  This problem will occur even with CC algorithms such as BBRv1/v2 (not just NewReno). 
>> 
>> 
>> 
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/avt <https://www.ietf.org/mailman/listinfo/avt>
> 
> 
> 
> -- 
> Colin Perkins
> https://csperkins.org/ <https://csperkins.org/>
> 
> 
> 
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/avt <https://www.ietf.org/mailman/listinfo/avt>

-- 
Colin Perkins
https://csperkins.org/

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 11 Apr 2022 12:44:08 +0200

On Mon, Apr 11, 2022 at 10:08 AM Colin Perkins <[email-masked]> wrote:

> Does it need signalling though? Most (all?) of the congestion control
> algorithms for QUIC seem to be entirely driven by the sender, which knows
> that it’s sending media.
>
>
I agree, this should be more a WebTransport API  to allow the JS app to
inform the QUIC stack in the browser to use a media-friendly delay
sensitive quic CC (BBR, COPA, etc). I don't think that this API should
specify the exact CC algorithm, and it should be left up to the
implementation to choose which one to use. At the QUIC level, it could be
needed to allow the sender to turn on an extended feedback mechanism so the
reveicer provide a more accurate timing information of the packet arrival
timestamps and maybe expose those stats to the js app so it can implement
the media bwe algorithm by itself.

I would like also to take the opportunity to introduce David Baldassin who
has been working on reproducing the results of the "Congestion Control for
Real-time Media over QUIC" paper and has found some interesting results we
will be likely to share in upcoming IETF meetings. Also, he is also working
on extending the test to support different QUICK implementations with more
support of CC algos (BBR/COPA) and also test with webrtc GCC bwe.

Best regards
Sergio

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 11 Apr 2022 11:23:45 -0400

> On Apr 11, 2022, at 1:34 AM, Spencer Dawkins at IETF <[email-masked]> wrote:
> 

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.

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

---

From: Stephan Wenger <[email-masked]>
Date: Mon, 11 Apr 2022 16:19:24 +0000

Inline in blue.

S.

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.

    [email-masked]

---

From: David Baldassin <[email-masked]>
Date: Mon, 11 Apr 2022 18:20:35 +0200

Hi,

Thank you Sergio for the introduction.
I would be happy to share my results and contribute to the effort for
real-time media over QUIC and CC algorithms.

Best regards,
David

On Mon, Apr 11, 2022 at 12:45 PM Sergio Garcia Murillo <
[email-masked]> wrote:

>> I'm not sure (are others sure?) whether we would need to be able to
>> choose between media-oriented congestion controllers (SCReAM, or NADA, or

-- 
David Baldassin

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 11 Apr 2022 21:09:48 +0200

El lun, 11 abr 2022 18:19, Stephan Wenger <[email-masked]> escribió:

> Inline in blue.
>
> S.
>
>
>
>
>
> On 4/11/22, 08:24, "avt on behalf of Jonathan Lennox" <
> [email-masked] on behalf of [email-masked]> 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.
>

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

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 11 Apr 2022 13:08:03 -0700

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.

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%E2%91%A0

Some stream stats are in the works (see:
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.

 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.

---

From: Stefan Holmer <[email-masked]>
Date: Tue, 12 Apr 2022 14:06:47 +0200

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 <[email-masked]>
wrote:

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

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.

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

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

---

From: Joerg Ott <[email-masked]>
Date: Tue, 12 Apr 2022 18:11:36 +0200

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 <[email-masked] 
> <mailto:[email-masked]>> 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
>     <https://w3c.github.io/webtransport/#web-transport-stats>
>     <https://w3c.github.io/webtransport/#web-transport-stats%E2%91%A0>
> 
>     https://github.com/w3c/webtransport/pull/395
>     <https://github.com/w3c/webtransport/pull/395>) but they also aren't
>     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.
> 
> 
> 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
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
> 
> 
>         El lun, 11 abr 2022 18:19, Stephan Wenger <[email-masked]
>         <mailto:[email-masked]>> escribió:
> 
>             Inline in blue.____
> 
>             S.____
> 
>             __ __
> 
>             __ __
> 
>             On 4/11/22, 08:24, "avt on behalf of Jonathan Lennox"
>             <[email-masked] <mailto:[email-masked]> on
>             behalf of [email-masked]
>             <mailto:[email-masked]>> wrote:____
> 
>             __ __
> 
>             __ __
> 
>             __ __
> 
>                  > On Apr 11, 2022, at 1:34 AM, Spencer Dawkins at IETF
>             <[email-masked]
>             <mailto:[email-masked]>> 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.
> 
> 
> 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
>         <https://www.ietf.org/mailman/listinfo/avt>
> 
>     <https://www.ietf.org/mailman/listinfo/avt>
>

---

From: Stephan Wenger <[email-masked]>
Date: Tue, 12 Apr 2022 17:17:26 +0000

correct. S.

Sent from my iPhone

> On Apr 12, 2022, at 09:11, Joerg Ott <[email-masked]> 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 <[email-masked] <mailto:[email-masked]>> wrote:
>>    Sergio said:
>> 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.
>>                 > On Apr 11, 2022, at 1:34 AM, Spencer Dawkins at IETF
>>                 > ____
>>                 > But even if we don't need to choose between
>>                 > ____
>>                 > I suspect the QUIC working group would be a fine
>> 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.

---

From: Stefan Holmer <[email-masked]>
Date: Wed, 13 Apr 2022 09:11:56 +0200

> > the underlying transport, so you don't have to measure yourself (again).

Yes, I agree that's the preferred way.

> > run but rather to provide sufficient richness in the API that all kinds

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

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