[PATCH net-next] tcp: fix tcp_ofo_queue() to avoid including too much DUP SACK range

[PATCH net-next] tcp: fix tcp_ofo_queue() to avoid including too much DUP SACK range

[xin.guo]

If the new coming segment covers more than one skbs in the ofo queue,
and which seq is equal to rcv_nxt , then the sequence range
that is not duplicated will be sent as DUP SACK,  the detail as below,
in step6, the {501,2001} range is clearly including too much
DUP SACK range:
1. client.43629 > server.8080: Flags [.], seq 501:1001, ack 1325288529,
win 20000, length 500: HTTP
2. server.8080 > client.43629: Flags [.], ack 1, win 65535, options
[nop,nop,TS val 269383721 ecr 200,nop,nop,sack 1 {501:1001}], length 0
3. Iclient.43629 > server.8080: Flags [.], seq 1501:2001,
ack 1325288529, win 20000, length 500: HTTP
4. server.8080 > client.43629: Flags [.], ack 1, win 65535, options
[nop,nop,TS val 269383721 ecr 200,nop,nop,sack 2 {1501:2001}
{501:1001}], length 0
5. client.43629 > server.8080: Flags [.], seq 1:2001,
ack 1325288529, win 20000, length 2000: HTTP
6. server.8080 > client.43629: Flags [.], ack 2001, win 65535,
options [nop,nop,TS val 269383722 ecr 200,nop,nop,sack 1 {501:2001}],
length 0

Signed-off-by: xin.guo <guoxin0309@gmail.com>
---
 net/ipv4/tcp_input.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 8ec92dec321a..6194ddf46024 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -4973,7 +4973,7 @@ static void tcp_ofo_queue(struct sock *sk)
 		if (before(TCP_SKB_CB(skb)->seq, dsack_high)) {
 			__u32 dsack = dsack_high;
 			if (before(TCP_SKB_CB(skb)->end_seq, dsack_high))
-				dsack_high = TCP_SKB_CB(skb)->end_seq;
+				dsack = TCP_SKB_CB(skb)->end_seq;
 			tcp_dsack_extend(sk, TCP_SKB_CB(skb)->seq, dsack);
 		}
 		p = rb_next(p);
-- 
2.43.0

Re: [PATCH net-next] tcp: fix tcp_ofo_queue() to avoid including too much DUP SACK range

[Jakub Kicinski]

On Tue, 17 Jun 2025 23:37:06 +0800 xin.guo wrote:
> If the new coming segment covers more than one skbs in the ofo queue,
> and which seq is equal to rcv_nxt , then the sequence range
> that is not duplicated will be sent as DUP SACK,  the detail as below,
> in step6, the {501,2001} range is clearly including too much
> DUP SACK range:
> 1. client.43629 > server.8080: Flags [.], seq 501:1001, ack 1325288529,
> win 20000, length 500: HTTP
> 2. server.8080 > client.43629: Flags [.], ack 1, win 65535, options
> [nop,nop,TS val 269383721 ecr 200,nop,nop,sack 1 {501:1001}], length 0
> 3. Iclient.43629 > server.8080: Flags [.], seq 1501:2001,
> ack 1325288529, win 20000, length 500: HTTP
> 4. server.8080 > client.43629: Flags [.], ack 1, win 65535, options
> [nop,nop,TS val 269383721 ecr 200,nop,nop,sack 2 {1501:2001}
> {501:1001}], length 0
> 5. client.43629 > server.8080: Flags [.], seq 1:2001,
> ack 1325288529, win 20000, length 2000: HTTP
> 6. server.8080 > client.43629: Flags [.], ack 2001, win 65535,
> options [nop,nop,TS val 269383722 ecr 200,nop,nop,sack 1 {501:2001}],
> length 0

Looks reasonable, AFAICT, tho perhaps there's some implicit benefit from
reporting end of the DSACK == rcv_next..

Could you please add the info about how the packet from step 6 looks
"after" this patch? So we have before / after comparison?

With that please resend and make sure you include _all_ maintainers that
the get_maintainer script points out. You missed CCing Eric D.
-- 
pw-bot: cr

Re: [PATCH net-next] tcp: fix tcp_ofo_queue() to avoid including too much DUP SACK range

[Xin Guo]

Thanks Jakub,  I will add more info and resend.

Regards
Guo Xin.
On Tue, Jun 24, 2025 at 2:57 AM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Tue, 17 Jun 2025 23:37:06 +0800 xin.guo wrote:
> > If the new coming segment covers more than one skbs in the ofo queue,
> > and which seq is equal to rcv_nxt , then the sequence range
> > that is not duplicated will be sent as DUP SACK,  the detail as below,
> > in step6, the {501,2001} range is clearly including too much
> > DUP SACK range:
> > 1. client.43629 > server.8080: Flags [.], seq 501:1001, ack 1325288529,
> > win 20000, length 500: HTTP
> > 2. server.8080 > client.43629: Flags [.], ack 1, win 65535, options
> > [nop,nop,TS val 269383721 ecr 200,nop,nop,sack 1 {501:1001}], length 0
> > 3. Iclient.43629 > server.8080: Flags [.], seq 1501:2001,
> > ack 1325288529, win 20000, length 500: HTTP
> > 4. server.8080 > client.43629: Flags [.], ack 1, win 65535, options
> > [nop,nop,TS val 269383721 ecr 200,nop,nop,sack 2 {1501:2001}
> > {501:1001}], length 0
> > 5. client.43629 > server.8080: Flags [.], seq 1:2001,
> > ack 1325288529, win 20000, length 2000: HTTP
> > 6. server.8080 > client.43629: Flags [.], ack 2001, win 65535,
> > options [nop,nop,TS val 269383722 ecr 200,nop,nop,sack 1 {501:2001}],
> > length 0
>
> Looks reasonable, AFAICT, tho perhaps there's some implicit benefit from
> reporting end of the DSACK == rcv_next..
>
> Could you please add the info about how the packet from step 6 looks
> "after" this patch? So we have before / after comparison?
>
> With that please resend and make sure you include _all_ maintainers that
> the get_maintainer script points out. You missed CCing Eric D.
> --
> pw-bot: cr