[v3.7] TCP Delay ACK in case no PSH flag is present causing extremly low download throughput for some clients

[fengming-ye]

Caused by commit 5442e47
Delay an ACK in case no PSH flag is present in the data packet

This improves TCP download throughput in some cases or for some clients.
But we detect extremly low TCP download throughput 6Mbps for some other clients,
which barely send us PSH frame.
In this case we do not send back ACK frame either on tcp_data_received(net process) or on sock_recvmsg_vmeth(after application process).
Thus ACK can only be triggered by 100ms timer, causing low throughput.

Previous code logic of tcp_data_received and sock_recvmsg_vmeth seems to reach balance of ACK.
When tcp_data_received finds receive window short, it will delay ACK and let application reads socket buffer.
And when sock_recvmsg_vmeth reads buffer, the receive window increases. And when it increases from short window to long window, it will send ACK.

But with PSH logic, when tcp_data_received delay ACK if PSH not present, receive window will quickly reduce to short window.
After that even with PSH flag present, we still delay ACK. But sock_recvmsg_vmeth in zsock_recv_stream->net_context_update_recv_wnd->tcp_update_recv_wnd, short_win_before and short_win_after are both true. So application will not send ACK either.

Above all this PSH commit is a nice improvement for throughput for some clients.
But we need to figure out fix on this compatibility issue.

[github-actions]

Hi @fengming-ye! We appreciate you submitting your first issue for our open-source project. 🌟

Even though I'm a bot, I can assure you that the whole community is genuinely grateful for your time and effort. 🤖💙

[jukkar]

The #76418 should improve the throughput, please try that.

[carlescufi]

Backport is merged