You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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) {
The text was updated successfully, but these errors were encountered:
Based on my testing, the tcp-bbr may over-estimate the BW during loss recovery. The
packet.delivered
in 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 389
oftcp-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) {
The text was updated successfully, but these errors were encountered: