]> git.ipfire.org Git - thirdparty/haproxy.git/commit
BUG/MINOR: quic: fix BBB max bandwidth oscillation issue.
authorFrederic Lecaille <flecaille@haproxy.com>
Thu, 12 Dec 2024 10:08:26 +0000 (11:08 +0100)
committerFrederic Lecaille <flecaille@haproxy.com>
Fri, 13 Dec 2024 13:42:43 +0000 (14:42 +0100)
commitb47e1e65df1b468bcd84f02fbc1eb4e1fd7e2bc9
tree73ef6d9549e06a51b7d9eb9c222e4afd5f9ea0ea
parent1dbf6b8bedadd5d287ab44e1a387a89e2fc6c70b
BUG/MINOR: quic: fix BBB max bandwidth oscillation issue.

Remove the code in relation with BBR.ack_phase as per this commit:
https://github.com/ietf-wg-ccwg/draft-ietf-ccwg-bbr/pull/5/commits/ee98c12ad6f0e93153656218a7df1b1ef92618d7

I do now kwow at this time why such a request was pushed on GH for the BBR v3 draft
pseudo-code. That said, the use of such an ack phase seemed confusing, adding much
more information about a BBR flow state than needed. Indeed, the ack phase
state is modified several times in the BBR draft pseudo-code but only used to
decide if the max bandwidth filter virtual clock had to be incremented by
BBRAdvanceMaxBwFilter().

In addition to this, when discussing about haproxy BBR implementation with
Neal Cardwell on the BBR development google group about an oscillation issue
of the max bandwidth (BBR.max_bw), I concluded that this was due to the fact
that its filter virutal clock was too often update, due to the ack phase wich
was stalled in BBR_ACK_PHASE_ACKS_PROBE_STOPPING state for too long. This is
where Neal asked me to test the aforementioned commit. This definitively
makes the max bandwidth (BBR.max_bw) oscillation issue disappear.

Another solution would have been to add a new ack phase enum afer
BBR_ACK_PHASE_ACKS_PROBE_STOPPING. BBR_ACK_PHASE_ACKS_PROBE_STOPPED
would have been a good candidate.

Remove the code in relation with BBR.ack_phase.

Must be backported to 3.1.
src/quic_cc_bbr.c