Hi Team,
I'm reaching out to you since I want to share an observation we have made while
doing PXE boot of client notebooks. One of the first steps while doing Network
Boot is to download an image by TFTP. This image has a size of 1.7 MB. While
the client is downloading this we have observed 1Gbit/s or even 10 Gbit/s links
are suddenly saturated with TFTP traffic. So we started doing tcpdumps and
tried to understand the trigger.
Finally it turned out, that reordering of IP packets or packetloss can trigger
this. We are now able to reproduce anytime by simulating packetloss or
reordering.

What happens (all good)
- Client and server are negotiating to TFTP transfer with window size 4
- Server is sending DATA 1,2,3,4
- Client is receiving 1,2,3,4 and sends an ACK for packet 4
- Server is receiving ACK for packet and sends out DATA 5,6,7,8

Now reordering / loss kicks in
Loss of DATA 6
- Client is receiving DATA 5,7,8 and therefore it sends ACK for DATA 5
- Server is receiving ACK for DATA 5 and sends out DATA 6,7,8,9

Loss of DATA 7
- Client is receiving data 6,8,9 and sends out ACK for DATA 6
- Server is receiving ACK for DATA 6 and sends out DATA 7,8,9,10

Reordering of DATA 7,8
- Client is receiving data 8,7,9,10 and sends out ACK for DATA 6
- Server is receiving ACK for DATA 6 and sends out DATA 7,8,9,10

This finally ends in a TFTP "Storm" which is filling up almost any link within
milliseconds. Once the image is successfully downloaded after sometimes
5 minutes, the client is booting into it. There it does other TFTP downloads,
which are not showing this kind of behavior in same network conditions. So it
seems to be specific to the TFTP client implementation in the BIOS of the
clients.

After opening cases at our notebook vendors it turned out, that they use EDK2
code in their BIOS actually doing the TFTP transfer. After some digging in the
code, bugs and feature requests, we finally found
"Bug 886 - RFC 7440 - TFTP windowsize option support" [1]

It looks like this implementation is covering the parameter negotiation, but
not the management of the receive window and retransmission behavior.
While window size 1 has retransmission timeouts and network latency as
"congestion avoidance", window size 4 seems to bypass all those barriers.
ACKs are immediately sent out, if an expected packet is not there.

I hope we can discuss this here and find a way to fix this.

Thanks in advance and kind regards,
Thomas

[1] https://bugzilla.tianocore.org/show_bug.cgi?id=886

Hi all, unfortunately we never received any answer or input regarding this topic. Is anybody able to help us with this? We also wrote to contributors of the code to this, but also here we did not get a step further.

Any input is highly appreciated. Thomas