BBR2 logs an ERROR, when there is "bytes in flight" mismatch between QuicUnackedPacketMap and Bbr2NetworkModel
- Dominant language
- C++
- Stars
- 897
- Forks
- 177
- PR merge metrics
- No merged PRs in 30d
Description
We observed that BBR2 logs the following ERROR:
https://github.com/google/quiche/blob/4069625b5260ab0df30f733e17d6ab7d1703cbce/quiche/quic/core/congestion_control/bbr2_misc.cc#L155
One scenario that leads to this error:
This can happen during processing of ACKs, when sent packet is at first marked as LOST, but later an ACK for this packet is received. There are two entities that estimate "bytes in flight" and process the ACKs:
1. QuicUnackedPacketMap, see QuicUnackedPacketMap:bytes_in_flight()
2.Bbr2NetworkModel/BandwidthSampler, see Bbr2NetworkModel::OnCongestionEventStart
When a packet is marked as LOST, QuicUnackedPacketMap is updated and the packet is removed from "bytes in flight".
Later, when a ACK for this packet is received, QuicUnackedPacketMap does NOT modify "bytes in flight" again, as the packet is not in flight anymore. There is the following check:
`
void QuicUnackedPacketMap::RemoveFromInFlight(QuicTransmissionInfo* info) {
if (info->in_flight) {
...
`
However, such a check is not applied when processing ACKs in Bbr2NetworkModel/BandwidthSampler, and the counter that computes the number of acked bytes is increased despite the fact that the packet is not "in flight" anymore.
This leads to a mismatch between "bytes in flight" from QuicUnackedPacketMap and "bytes in flight" from Bbr2NetworkModel/BandwidthSampler. In that case the ERROR message can be logged.
Contributor guide
Assessment
This issue has not been assessed yet.