Bbr3::new computes the initial pacing rate with a 1 ms RTT because no SRTT exists yet: startup_pacing_gain * InitialCwnd / 1 ms, about 266 Mbps for a 12 kB window. Until startup exits, BBRSetPacingRateWithGain only raises the rate (if full_bw_reached || rate > pacing_rate). A flow that stays application-limited never exits startup — its delivery-rate samples never plateau — so the placeholder is kept for the life of the flow and the flow is effectively unpaced: every burst leaves at line rate.
Where it bites: a second multipath path opened after the handshake and fed a rate-limited source (a media encoder). In my setup the path reported a constant 266 Mbps pacing rate for entire sessions; frame-sized bursts overflowed a 25-packet queue with 28 % loss, while the first path, which had exited startup during the handshake, paced normally.
Linux BBR handles exactly this with has_seen_rtt: once the first RTT sample exists, the pacing rate is re-initialised from InitialCwnd / SRTT (bbr_init_pacing_rate_from_rtt) and grows from there. The draft's BBRInitPacingRate says the same (InitialCwnd / (SRTT ? SRTT : 1ms)); it is just only evaluated once, before an SRTT exists.
Repro as a unit test on Bbr3: one packet acknowledged with a 40 ms RTT leaves pacing_rate at 33 276 000 B/s; the value the draft implies is 831 900 B/s. I have a fix with that test and will open a PR referencing this issue.
The same construction is in quinn's open BBRv3 PR (quinn-rs/quinn#2481), which I understand this implementation came from.
Bbr3::newcomputes the initial pacing rate with a 1 ms RTT because no SRTT exists yet:startup_pacing_gain * InitialCwnd / 1 ms, about 266 Mbps for a 12 kB window. Until startup exits,BBRSetPacingRateWithGainonly raises the rate (if full_bw_reached || rate > pacing_rate). A flow that stays application-limited never exits startup — its delivery-rate samples never plateau — so the placeholder is kept for the life of the flow and the flow is effectively unpaced: every burst leaves at line rate.Where it bites: a second multipath path opened after the handshake and fed a rate-limited source (a media encoder). In my setup the path reported a constant 266 Mbps pacing rate for entire sessions; frame-sized bursts overflowed a 25-packet queue with 28 % loss, while the first path, which had exited startup during the handshake, paced normally.
Linux BBR handles exactly this with
has_seen_rtt: once the first RTT sample exists, the pacing rate is re-initialised fromInitialCwnd / SRTT(bbr_init_pacing_rate_from_rtt) and grows from there. The draft'sBBRInitPacingRatesays the same (InitialCwnd / (SRTT ? SRTT : 1ms)); it is just only evaluated once, before an SRTT exists.Repro as a unit test on
Bbr3: one packet acknowledged with a 40 ms RTT leavespacing_rateat 33 276 000 B/s; the value the draft implies is 831 900 B/s. I have a fix with that test and will open a PR referencing this issue.The same construction is in quinn's open BBRv3 PR (quinn-rs/quinn#2481), which I understand this implementation came from.