huitema
commented
9 months ago Hello @meejei, sorry for not responding sooner! Are you using picoquic to do measurements, or are you asking me a generic question about QUIC? Also, could you please tell me what you define as "the CWIN of QUIC"?
The QUIC specification in RFC9002 defines a variant of the RENO algorithm. Picoquic implements that as a possible choice -- deployments can choose between RENO, CUBIC and BBR. Those three algorithms each have their own logic. BBR, for example, mostly rely on rate control and only uses the CWIN parameter as a safety.
The Cubic implementation for Picoquic is found in /picoquic/cubic.c. It defines the parameters as:
cubic_state->C = 0.4;
cubic_state->beta = 7.0 / 8.0;These parameters were chosen in 2017, at a time when we wanting Cubic for QUIC having roughly the same behavior as two Cubic connections for TCP, based on discussions of typical usage in browsers. Or at least that's what I recall.
The Threshold formula that you mention is not part of the Cubic specification in RFC9438. The window is reduced when packet losses are detected, and interpreted as a sign of congestion. For QUIC, packet losses are detected per RFC9002.
Hello!!
I am conducting an experiment to compare the CWIN of CUBIC and QUIC with different loss rates.
I thought the CWIN of QUIC would be higher than CUBIC if the loss rate increased, and the result was measured the same.
What I'm curious about is that QUIC reduces the CWIN when the time interval between the oldest and most recently lost packets exceeds the threshold, ( ※ Threshold: (smoothed_rtt + 4 rttvar + max_ack_delay) kPersistentCongestionThreshold )
CWIN is reduced by W(t) ← W(t) (1 - 𝛽), and CUBIC generally has a beta of 0.3 but QUIC of 0.3/2 = 0.15. ( ※ W(t*): CWIN size at the time of packet loss initially set to Wmax)
I wanted to know if these functions were applied to picoquic and if there was something I was mistaken about, so I wrote this.
Have a nice day!