Change Details

I've a local dummynet based testbed to do various tests. I'd appreciate any help in making sure this doesn't break anything else.

I've a local dummynet based testbed to do various tests. I'd appreciate any help in making sure this doesn't break anything else. I'll add some scenarios here to show what/how I am testing. 1) With a single packet drop, this is how it looks with the fix: (I am just showing relevant acks which trigger fast-retransmit) ``` 00:00:00.054513 IP 10.10.10.10.60460 > 10.10.11.12.http: Flags [.], ack 4576, win 1018, options [nop,nop,TS val 792866636 ecr 2286529430], length 0 00:00:00.054603 IP 10.10.10.10.60460 > 10.10.11.12.http: Flags [.], ack 4576, win 1040, options [nop,nop,TS val 792866637 ecr 2286529430,nop,nop,sack 1 {6024:7472}], length 0 00:00:00.056520 IP 10.10.10.10.60460 > 10.10.11.12.http: Flags [.], ack 4576, win 1040, options [nop,nop,TS val 792866638 ecr 2286529430,nop,nop,sack 1 {6024:8920}], length 0 00:00:00.058411 IP 10.10.10.10.60460 > 10.10.11.12.http: Flags [.], ack 4576, win 1040, options [nop,nop,TS val 792866639 ecr 2286529430,nop,nop,sack 1 {6024:10368}], length 0 00:00:00.058474 IP 10.10.11.12.http > 10.10.10.10.60460: Flags [.], seq 4576:6024, ack 141, win 1040, options [nop,nop,TS val 2286529460 ecr 792866639], length 1448: HTTP ``` Here, without the proposed fix, second ack would've reset the dupack counter to 0 as its an ack with SACK but also updates window. This would've taken more acks to trigger fast-retransmit.

I've a local dummynet based testbed to do various tests. I'd appreciate any help in making sure this doesn't break anything else. I'll add some scenarios here to show what/how I am testing. 1) With a single packet drop, this is how it looks with the fix: (I am just showing relevant acks which trigger fast-retransmit) ``` 00:00:00.054513 IP 10.10.10.10.60460 > 10.10.11.12.http: Flags [.], ack 4576, win 1018, options [nop,nop,TS val 792866636 ecr 2286529430], length 0 00:00:00.054603 IP 10.10.10.10.60460 > 10.10.11.12.http: Flags [.], ack 4576, win 1040, options [nop,nop,TS val 792866637 ecr 2286529430,nop,nop,sack 1 {6024:7472}], length 0 00:00:00.056520 IP 10.10.10.10.60460 > 10.10.11.12.http: Flags [.], ack 4576, win 1040, options [nop,nop,TS val 792866638 ecr 2286529430,nop,nop,sack 1 {6024:8920}], length 0 00:00:00.058411 IP 10.10.10.10.60460 > 10.10.11.12.http: Flags [.], ack 4576, win 1040, options [nop,nop,TS val 792866639 ecr 2286529430,nop,nop,sack 1 {6024:10368}], length 0 00:00:00.058474 IP 10.10.11.12.http > 10.10.10.10.60460: Flags [.], seq 4576:6024, ack 141, win 1040, options [nop,nop,TS val 2286529460 ecr 792866639], length 1448: HTTP ``` Here, without the proposed fix, second ack would've reset the dupack counter to 0 as its an ack with SACK but also updates window. This would've taken more acks to trigger fast-retransmit.