anchao commented on PR #6562: URL: https://github.com/apache/incubator-nuttx/pull/6562#issuecomment-1179772759
Hi @a-lunev > Are you confirming there is not the issue with rexmit_seq variable you explained above if #5589+#5598 are applied over 1ded8bb ? > Could you send TCP dump demonstrating the issue (Wireshark or tcpdump) for analysis and provide instructions how to reproduce that case? In https://github.com/apache/incubator-nuttx/pull/5589 in February I wrote to you that I emulated a loss of two segments in a row (https://github.com/apache/incubator-nuttx/pull/5589+https://github.com/apache/incubator-nuttx/pull/5598 applied over https://github.com/apache/incubator-nuttx/commit/1ded8bbabbe0b23e3242be17fb87d418966778b2) and there were no issues with recovery. It recovered just fine even in that case. Yes, I confirm that there will still be issues that cannot be recovered normally, the following are the commits I have added based on the current master branch ``` commit 7a0bcb88445f6a4a4769840dbbade79f74e2c96b (HEAD) Author: Alexander Lunev <alexanderlu...@mail.ru> Date: Thu Feb 24 05:48:29 2022 +0300 net/tcp(buffered): upgraded the Fast Retransmit algorithm from RFC 2001 to RFC 5681 net/tcp/Kconfig | 40 ++++++++++++++++++---------------------- net/tcp/tcp.h | 21 ++++++++++++++------- net/tcp/tcp_send_buffered.c | 58 +++++++++++++++++++++++++++++++--------------------------- net/tcp/tcp_wrbuffer.c | 6 ------ 4 files changed, 63 insertions(+), 62 deletions(-) commit 6493e29e9db11dad5fcc5a4f5e6f9db1bfa44a91 Author: Alexander Lunev <alexanderlu...@mail.ru> Date: Tue Feb 22 23:25:30 2022 +0300 net/tcp(buffered): retransmit only one the earliest not acknowledged segment (according to RFC 6298 (5.4)). The issue is the same as it was in tcp_send_unbuffered.c and tcp_sendfile.c. net/tcp/tcp.h | 3 --- net/tcp/tcp_appsend.c | 29 +++++++++++------------------ net/tcp/tcp_send_buffered.c | 254 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++------------------------------------------------------------------------------------------------------------------------------------------------------------- 3 files changed, 108 insertions(+), 178 deletions(-) commit 8ad49276bd372cd130f5c7dc759f8f39a61c2f22 Author: chao.an <anc...@xiaomi.com> Date: Mon Jul 11 00:40:54 2022 +0800 Revert "net/tcp(buffered): retransmit only one the earliest not acknowledged segment" This reverts commit 669fb83706c5ee8c93b78e685dba794d28786211. net/tcp/tcp.h | 3 +++ net/tcp/tcp_appsend.c | 29 ++++++++++++++++++----------- net/tcp/tcp_send_buffered.c | 86 ++++++++++++-------------------------------------------------------------------------- 3 files changed, 33 insertions(+), 85 deletions(-) ``` I have a minor hack that can trigger the packet loss. You can make other changes according to your test requirements. At present, this patch will cause 3 consecutive segments to be dropped. You can adjust its performance through DROP_COUNT. The expectation is that which can get the connection back after an RTO timeout ``` diff --git a/arch/sim/src/sim/up_netdriver.c b/arch/sim/src/sim/up_netdriver.c index 773a718607..c5db4f3a12 100644 --- a/arch/sim/src/sim/up_netdriver.c +++ b/arch/sim/src/sim/up_netdriver.c @@ -61,6 +61,7 @@ #include <debug.h> #include <string.h> +#include <stdio.h> #include <nuttx/kmalloc.h> #include <nuttx/wqueue.h> @@ -69,6 +70,9 @@ #include <nuttx/net/arp.h> #include <nuttx/net/pkt.h> +#include <nuttx/net/ip.h> +#include <nuttx/net/tcp.h> + #include "up_internal.h" /**************************************************************************** @@ -273,6 +277,28 @@ static int netdriver_txpoll(struct net_driver_s *dev) { /* Send the packet */ +#define DROP_COUNT 3 + static uint32_t tx_counter = DROP_COUNT; + + tx_counter++; + + if (dev->d_len > 1400) + { + extern uint32_t tcp_getsequence(FAR uint8_t *seqno); + FAR struct ipv4_hdr_s *ipv4 = (FAR struct ipv4_hdr_s *)&dev->d_buf[NET_LL_HDRLEN(dev)]; + FAR struct tcp_hdr_s *tcp; + + if (ipv4->proto == IP_PROTO_TCP) + { + if ((tx_counter % 4096) < DROP_COUNT) + { + tcp = (FAR struct tcp_hdr_s *)&dev->d_buf[54 - TCP_HDRLEN]; + printf("DROP lost seqno: %u\n", tcp_getsequence(tcp->seqno)); + return 0; + } + } + } + NETDEV_TXPACKETS(dev); netdev_send(dev->d_buf, dev->d_len); NETDEV_TXDONE(dev); diff --git a/boards/sim/sim/sim/configs/rpserver/defconfig b/boards/sim/sim/sim/configs/rpserver/defconfig index db071998c7..b735af0d8d 100644 --- a/boards/sim/sim/sim/configs/rpserver/defconfig +++ b/boards/sim/sim/sim/configs/rpserver/defconfig @@ -23,6 +23,9 @@ CONFIG_FS_RPMSGFS=y CONFIG_IDLETHREAD_STACKSIZE=4096 CONFIG_INIT_ENTRYPOINT="nsh_main" CONFIG_INPUT=y +CONFIG_IOB_BUFSIZE=256 +CONFIG_IOB_NBUFFERS=256 +CONFIG_IOB_THROTTLE=32 CONFIG_IOEXPANDER=y CONFIG_IOEXPANDER_RPMSG=y CONFIG_LIBC_HOSTNAME="server" @@ -36,6 +39,8 @@ CONFIG_NETDEV_STATISTICS=y CONFIG_NETINIT_DHCPC=y CONFIG_NETINIT_THREAD=y CONFIG_NETUTILS_DHCPC=y +CONFIG_NETUTILS_IPERF=y +CONFIG_NETUTILS_IPERFTEST_DEVNAME="eth0" CONFIG_NETUTILS_USRSOCK_RPMSG=y CONFIG_NET_ARP_SEND=y CONFIG_NET_BROADCAST=y @@ -47,6 +52,7 @@ CONFIG_NET_RPMSG_DRV=y CONFIG_NET_STATISTICS=y CONFIG_NET_TCP=y CONFIG_NET_TCPBACKLOG=y +CONFIG_NET_TCP_NWRBCHAINS=32 CONFIG_NET_TCP_WRITE_BUFFERS=y CONFIG_NET_UDP=y CONFIG_NET_UDP_WRITE_BUFFERS=y ``` Below is my test log: test sim config: sim/rpserver ``` server> iperf -c 192.168.1.111 -i 1 IP: 192.168.1.134 mode=tcp-client sip=192.168.1.134:5001,dip=192.168.1.111:5001, interval=1, time=30 Interval Transfer Bandwidth -0.00- 1.01 sec 5767168 Bytes 45.29 Mbits/sec 1.01- 2.02 sec 5767168 Bytes 0.00 Mbits/sec 2.02- 3.03 sec 5767168 Bytes 0.00 Mbits/sec 3.03- 4.04 sec 5767168 Bytes 0.00 Mbits/sec DROP lost seqno: 11497156 DROP lost seqno: 11498602 DROP lost seqno: 11500048 4.04- 5.05 sec 11550720 Bytes 45.81 Mbits/sec 5.05- 6.06 sec 11550720 Bytes 0.00 Mbits/sec 6.06- 7.07 sec 11550720 Bytes 0.00 Mbits/sec 7.07- 8.08 sec 11550720 Bytes 0.00 Mbits/sec 8.08- 9.09 sec 11550720 Bytes 0.00 Mbits/sec ```   You will find that if multiple segments are dropped consecutively, the recovery is very slow -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
