Are congestion control algorithms applied when the client isn't in the browser?

[friendlymatthew]

Hi,

If we're using a custom client like examples/client.rs that communicates with a wtransport server, do we bypass congestion control, since congestion control is enforced in the browser? This is for a CLI application.

QUIC datagrams are ACK-eliciting, which means they are acknowledged for the purpose of congestion control. [1]

But since congestion control algorithms are moved into the user space at both endpoints, will using a custom client like examples/client.rs remove such noise? Especially since there is no browser interfacing.

[BiagioFesta]

As you mentioned, QUIC standard (the underlying protocol behind HTTP3 and WebTransport) demands that both QUIC-Streams and QUIC-Datagrams frames are congestion controlled.

RFC9221@5.4:

DATAGRAM frames employ the QUIC connection's congestion controller.

This is required by the standard, not by browsers.

As consequence, wtransport follows that requirement.

---

Having said that, the underlying library used by wtransport that implements the QUIC stack (i.e., quinn) allows the possibility to configure a "custom" congestion control.

In the next release of this library, it will be possible to directly configure the underlying QUIC transport configuration: https://github.com/BiagioFesta/wtransport/blob/69f8a77512ed3920acabcf2e6097732c6c1c7735/wtransport/src/config.rs#L448

By using that, it would be possible to inject a custom quinn transport configuration and leverage this method. You might ending up implementing your custom congestion controller fulfilling quinn::congestion::Controller Trait; this latter allows altering the behavior of the congestion window when a congestion event is detected.

It might depend on your application, but generally it is not a good idea messing with the congestion controller. Standard algorithms (such as CUBIC) are well-known and tested for many years.

[friendlymatthew]

Thank you for the clarification!