* [PATCH net] tcp: fix F-RTO may not work correctly when receiving DSACK
@ 2022-04-26 10:03 Pengcheng Yang
2022-04-28 17:06 ` Neal Cardwell
2022-04-28 17:40 ` patchwork-bot+netdevbpf
0 siblings, 2 replies; 4+ messages in thread
From: Pengcheng Yang @ 2022-04-26 10:03 UTC (permalink / raw)
To: Eric Dumazet, Neal Cardwell, Yuchung Cheng, netdev
Cc: David S. Miller, Hideaki YOSHIFUJI, David Ahern, Jakub Kicinski,
Paolo Abeni, Pengcheng Yang
Currently DSACK is regarded as a dupack, which may cause
F-RTO to incorrectly enter "loss was real" when receiving
DSACK.
Packetdrill to demonstrate:
// Enable F-RTO and TLP
0 `sysctl -q net.ipv4.tcp_frto=2`
0 `sysctl -q net.ipv4.tcp_early_retrans=3`
0 `sysctl -q net.ipv4.tcp_congestion_control=cubic`
// Establish a connection
+0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
+0 bind(3, ..., ...) = 0
+0 listen(3, 1) = 0
// RTT 10ms, RTO 210ms
+.1 < S 0:0(0) win 32792 <mss 1000,sackOK,nop,nop,nop,wscale 7>
+0 > S. 0:0(0) ack 1 <...>
+.01 < . 1:1(0) ack 1 win 257
+0 accept(3, ..., ...) = 4
// Send 2 data segments
+0 write(4, ..., 2000) = 2000
+0 > P. 1:2001(2000) ack 1
// TLP
+.022 > P. 1001:2001(1000) ack 1
// Continue to send 8 data segments
+0 write(4, ..., 10000) = 10000
+0 > P. 2001:10001(8000) ack 1
// RTO
+.188 > . 1:1001(1000) ack 1
// The original data is acked and new data is sent(F-RTO step 2.b)
+0 < . 1:1(0) ack 2001 win 257
+0 > P. 10001:12001(2000) ack 1
// D-SACK caused by TLP is regarded as a dupack, this results in
// the incorrect judgment of "loss was real"(F-RTO step 3.a)
+.022 < . 1:1(0) ack 2001 win 257 <sack 1001:2001,nop,nop>
// Never-retransmitted data(3001:4001) are acked and
// expect to switch to open state(F-RTO step 3.b)
+0 < . 1:1(0) ack 4001 win 257
+0 %{ assert tcpi_ca_state == 0, tcpi_ca_state }%
Fixes: e33099f96d99 ("tcp: implement RFC5682 F-RTO")
Signed-off-by: Pengcheng Yang <yangpc@wangsu.com>
---
net/ipv4/tcp_input.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 1595b76..c54accc 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -3867,7 +3867,8 @@ static int tcp_ack(struct sock *sk, const struct sk_buff *skb, int flag)
tcp_process_tlp_ack(sk, ack, flag);
if (tcp_ack_is_dubious(sk, flag)) {
- if (!(flag & (FLAG_SND_UNA_ADVANCED | FLAG_NOT_DUP))) {
+ if (!(flag & (FLAG_SND_UNA_ADVANCED |
+ FLAG_NOT_DUP | FLAG_DSACKING_ACK))) {
num_dupack = 1;
/* Consider if pure acks were aggregated in tcp_add_backlog() */
if (!(flag & FLAG_DATA))
--
1.8.3.1
^ permalink raw reply related [flat|nested] 4+ messages in thread* Re: [PATCH net] tcp: fix F-RTO may not work correctly when receiving DSACK
2022-04-26 10:03 [PATCH net] tcp: fix F-RTO may not work correctly when receiving DSACK Pengcheng Yang
@ 2022-04-28 17:06 ` Neal Cardwell
2022-04-28 17:11 ` Eric Dumazet
2022-04-28 17:40 ` patchwork-bot+netdevbpf
1 sibling, 1 reply; 4+ messages in thread
From: Neal Cardwell @ 2022-04-28 17:06 UTC (permalink / raw)
To: Pengcheng Yang
Cc: Eric Dumazet, Yuchung Cheng, netdev, David S. Miller,
Hideaki YOSHIFUJI, David Ahern, Jakub Kicinski, Paolo Abeni
On Tue, Apr 26, 2022 at 6:04 AM Pengcheng Yang <yangpc@wangsu.com> wrote:
>
> Currently DSACK is regarded as a dupack, which may cause
> F-RTO to incorrectly enter "loss was real" when receiving
> DSACK.
>
> Packetdrill to demonstrate:
>
> // Enable F-RTO and TLP
> 0 `sysctl -q net.ipv4.tcp_frto=2`
> 0 `sysctl -q net.ipv4.tcp_early_retrans=3`
> 0 `sysctl -q net.ipv4.tcp_congestion_control=cubic`
>
> // Establish a connection
> +0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
> +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
> +0 bind(3, ..., ...) = 0
> +0 listen(3, 1) = 0
>
> // RTT 10ms, RTO 210ms
> +.1 < S 0:0(0) win 32792 <mss 1000,sackOK,nop,nop,nop,wscale 7>
> +0 > S. 0:0(0) ack 1 <...>
> +.01 < . 1:1(0) ack 1 win 257
> +0 accept(3, ..., ...) = 4
>
> // Send 2 data segments
> +0 write(4, ..., 2000) = 2000
> +0 > P. 1:2001(2000) ack 1
>
> // TLP
> +.022 > P. 1001:2001(1000) ack 1
>
> // Continue to send 8 data segments
> +0 write(4, ..., 10000) = 10000
> +0 > P. 2001:10001(8000) ack 1
>
> // RTO
> +.188 > . 1:1001(1000) ack 1
>
> // The original data is acked and new data is sent(F-RTO step 2.b)
> +0 < . 1:1(0) ack 2001 win 257
> +0 > P. 10001:12001(2000) ack 1
>
> // D-SACK caused by TLP is regarded as a dupack, this results in
> // the incorrect judgment of "loss was real"(F-RTO step 3.a)
> +.022 < . 1:1(0) ack 2001 win 257 <sack 1001:2001,nop,nop>
>
> // Never-retransmitted data(3001:4001) are acked and
> // expect to switch to open state(F-RTO step 3.b)
> +0 < . 1:1(0) ack 4001 win 257
> +0 %{ assert tcpi_ca_state == 0, tcpi_ca_state }%
>
> Fixes: e33099f96d99 ("tcp: implement RFC5682 F-RTO")
> Signed-off-by: Pengcheng Yang <yangpc@wangsu.com>
> ---
Thanks for the fix and test! Both look good to me. The patch passes
all of our team's packetdrill tests, and this new test passes as well.
Acked-by: Neal Cardwell <ncardwell@google.com>
Tested-by: Neal Cardwell <ncardwell@google.com>
thanks,
neal
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [PATCH net] tcp: fix F-RTO may not work correctly when receiving DSACK
2022-04-28 17:06 ` Neal Cardwell
@ 2022-04-28 17:11 ` Eric Dumazet
0 siblings, 0 replies; 4+ messages in thread
From: Eric Dumazet @ 2022-04-28 17:11 UTC (permalink / raw)
To: Neal Cardwell
Cc: Pengcheng Yang, Yuchung Cheng, netdev, David S. Miller,
Hideaki YOSHIFUJI, David Ahern, Jakub Kicinski, Paolo Abeni
On Thu, Apr 28, 2022 at 10:06 AM Neal Cardwell <ncardwell@google.com> wrote:
>
>
> Thanks for the fix and test! Both look good to me. The patch passes
> all of our team's packetdrill tests, and this new test passes as well.
>
> Acked-by: Neal Cardwell <ncardwell@google.com>
> Tested-by: Neal Cardwell <ncardwell@google.com>
>
Indeed, thank you all for a nice changelog, nice patch, and exhaustive
tests from Neal.
Reviewed-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH net] tcp: fix F-RTO may not work correctly when receiving DSACK
2022-04-26 10:03 [PATCH net] tcp: fix F-RTO may not work correctly when receiving DSACK Pengcheng Yang
2022-04-28 17:06 ` Neal Cardwell
@ 2022-04-28 17:40 ` patchwork-bot+netdevbpf
1 sibling, 0 replies; 4+ messages in thread
From: patchwork-bot+netdevbpf @ 2022-04-28 17:40 UTC (permalink / raw)
To: Pengcheng Yang
Cc: edumazet, ncardwell, ycheng, netdev, davem, yoshfuji, dsahern,
kuba, pabeni
Hello:
This patch was applied to netdev/net.git (master)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 26 Apr 2022 18:03:39 +0800 you wrote:
> Currently DSACK is regarded as a dupack, which may cause
> F-RTO to incorrectly enter "loss was real" when receiving
> DSACK.
>
> Packetdrill to demonstrate:
>
> // Enable F-RTO and TLP
> 0 `sysctl -q net.ipv4.tcp_frto=2`
> 0 `sysctl -q net.ipv4.tcp_early_retrans=3`
> 0 `sysctl -q net.ipv4.tcp_congestion_control=cubic`
>
> [...]
Here is the summary with links:
- [net] tcp: fix F-RTO may not work correctly when receiving DSACK
https://git.kernel.org/netdev/net/c/d9157f6806d1
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2022-04-28 17:40 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-04-26 10:03 [PATCH net] tcp: fix F-RTO may not work correctly when receiving DSACK Pengcheng Yang
2022-04-28 17:06 ` Neal Cardwell
2022-04-28 17:11 ` Eric Dumazet
2022-04-28 17:40 ` patchwork-bot+netdevbpf
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).