Hello @Aurimas Kurauskas ,
Here is another thread on Microsoft Q&A describing essentially the same problem: https://learn.microsoft.com/en-us/answers/questions/89768/slow-wired-upload-speed-vs-linux-on-same-hardware.html
The command that I would suggest to start a trace is pktmon start --capture --comp nics --flags 0x10 --trace --provider Microsoft-Windows-TCPIP --keywords 0x200700000000 --level 16 --file-name why.etl and the command to stop the trace is pktmon stop
The trace needs to be run on the sending system (the system where the congestion control is taking place). In your case this is the server. The trace just needs to capture a few seconds of activity during the "upload" (from the server to the client). The trace will capture all network activity of the server during the trace. The trace will grow in size quite quickly, so it is worthwhile trying to construct a short test scenario that "captures"/exhibits the problem.
Most (actually all) of the performance problems that I have helped with in this forum occurred when the client was sending data (and the traces were made on the client system); there are probably more "confidentiality" issues when tracing on a server. If you are still willing to share the captured data, I would suggest making it available via a file sharing service such that readers have to "request" access. Alternatively you can try to contact me directly (perhaps via LinkedIn - I am the only "Gary Nebbett" there) to discuss other transfer mechanisms.
Gary