[Bug 286631] TCP SACK: CWND set to 2 MSS after successful SACK recovery

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=286631

--- Comment #3 from JY <yjaeyong@gmail.com> ---
Here I posted the tcp internal states in tcp_sack_doack at the start and end of
the function. What I see interesting is the "sacked_bytes and
sack_bytes_rexmit.

As I understand sacked_bytes is how much data is delivered by SACK and
sack_bytes_rexmit is how much data is actually sent as sack-recovery. And I see
sacked_bytes are larger than sack_bytes_rexmit which seems odd.

It looks like this happens in the case CWND growth is limited by receiver-side
window and the few segments are lost. In such case, TCP is not able to send
sack-recoveries as as sacked_bytes is counting how many bytes are received
through sack-blocks hence causing this discrepancy.

And when this happens, tcp_compute_pipe calculation gives negative values and
cause issues. 


tcp_sack_doack-ENTER fack 0 una 2865053040 ack 2865053040 sch 0 SACK blocks:
[2865054452..2865061512] SACK holes: none
tcp_sack_doack-LEAVE fack 2865061512 una 2865053040 ack 2865053040 sch 1
delivered 7060 sacked_bytes 7060 sack_bytes_rexmit 0 SACK holes:
[2865053040..2865054452]
tcp_sack_doack-ENTER fack 2865061512 una 2865053040 ack 2865053040 sch 0 SACK
blocks: [2865054452..2865069984] SACK holes: [2865053040..2865054452]
tcp_sack_doack-LEAVE fack 2865069984 una 2865053040 ack 2865053040 sch 1
delivered 8472 sacked_bytes 15532 sack_bytes_rexmit 1412 SACK holes:
[2865053040..2865054452]
tcp_sack_doack-ENTER fack 2865069984 una 2865053040 ack 2865053040 sch 0 SACK
blocks: [2865054452..2865074220] SACK holes: [2865053040..2865054452]
tcp_sack_doack-LEAVE fack 2865074220 una 2865053040 ack 2865053040 sch 1
delivered 4236 sacked_bytes 19768 sack_bytes_rexmit 1412 SACK holes:
[2865053040..2865054452]
tcp_sack_doack-ENTER fack 2865074220 una 2865053040 ack 2865053040 sch 0 SACK
blocks: [2865054452..2865075632] SACK holes: [2865053040..2865054452]
tcp_sack_doack-LEAVE fack 2865075632 una 2865053040 ack 2865053040 sch 1
delivered 1412 sacked_bytes 21180 sack_bytes_rexmit 1412 SACK holes:
[2865053040..2865054452]


One more concern is, even if sacked_bytes are correctly calculated (which is
smaller or equal to sack_bytes_rexmit), I believe such CWND choke up still
happens. As the way CWND is calculated at the post recovery is based on the
pipe size. The pipe size is actually chocked by the condition
(receiver-window-limited-CWND). 

I am not sure if this is a valid concern, please let me know your opinions. I
am willing to test some ideas to resolve this issue as well.

-- 
You are receiving this mail because:
You are the assignee for the bug.