Based on my testing, the tcp-bbr may over-estimate the BW during loss recovery. The packet.delivered in BBR paper is recorded by the m_lastAckedSeq, which is the cumulative ACK while there may be lots of SACK ignored. During loss recovery, new data can still get sent if window allows. This can potentially lead to BW over-estimation when their ACKs get back and cumulatively ack all the already SACKed data.
It seems that the line 389 of tcp-bbr.cc, i.e., if (!m_in_retrans_seq) {, tries to avoid the issue, but not completely resolves it. To address it, we can extend that line to:
if (!m_in_retrans_seq && tcb->m_congState==TcpSocketState::CA_OPEN) {
Based on my testing, the tcp-bbr may over-estimate the BW during loss recovery. The
packet.deliveredin BBR paper is recorded by them_lastAckedSeq, which is the cumulative ACK while there may be lots of SACK ignored. During loss recovery, new data can still get sent if window allows. This can potentially lead to BW over-estimation when their ACKs get back and cumulatively ack all the already SACKed data.It seems that the
line 389oftcp-bbr.cc, i.e.,if (!m_in_retrans_seq) {, tries to avoid the issue, but not completely resolves it. To address it, we can extend that line to:if (!m_in_retrans_seq && tcb->m_congState==TcpSocketState::CA_OPEN) {