The Trivial File Transfer Protocol was born in 1981 (RFC 783, Karen Sollins) and standardized in RFC 1350 in 1992. Its defining feature was stubbornness: send a 512-byte block, wait for an ACK, send the next block, wait for an ACK. Lockstep. On a 100 ms link this caps throughput at roughly 5 KB/s regardless of how fat your pipe is. That was fine when TFTP's job was loading a diskless workstation's kernel across a coax segment. It became painful the moment TFTP escaped the LAN.

And TFTP never went away. You use it every day without noticing. PXE boot pulls pxelinux.0 and its config over TFTP. Cisco IOS, Juniper Junos, Arista EOS, and countless embedded devices still upgrade firmware via TFTP. VoIP phones fetch provisioning files over TFTP. Emergency recovery images live on TFTP servers. It is the plumbing under datacenter provisioning.

The problem RFC 7440 solves. Imaging a rack of forty servers over stock TFTP could take hours because each 512-byte block costs a full round trip. Even with the blksize option from RFC 2348 (which allows larger blocks, sometimes up to the path MTU), you are still one-block-per-RTT. This is the sender's fault, not the network's.

The design. RFC 7440 introduces a single new option negotiated during the read/write request: windowsize. The client requests a window of N blocks (1–65535). The server sends N consecutive blocks, then pauses for a single ACK acknowledging the last received block number. Acknowledgements are cumulative: one ACK for the whole window. On timeout or a gap detected via a stale ACK, the sender rewinds to the block after the last acknowledged one and continues from there. That is the whole mechanism.

• No per-packet ACKs, no selective ACKs, no reordering logic.
• No congestion control. TFTP still doesn't do that; the RFC waves at operator judgement.
• Fully backwards compatible: servers that don't understand the option omit it from their OACK and the client falls back to windowsize 1.
• Combined with a blksize near the path MTU, a window of 8–16 turns TFTP from a curiosity into a serviceable bulk transport, easily saturating gigabit LANs.

Why cumulative ACKs and not sliding windows? Because TFTP's implementations are tiny. TFTP servers ship in ROM monitors, PXE stacks, bootloaders, and 20 KB embedded binaries. A cumulative-ACK burst is trivial to add; a real sliding window with per-packet state is not. The RFC deliberately kept the state machine within reach of a bootloader author.

Nice piece of trivia. Patrick Masotta wrote Serva, a Windows-based PXE/TFTP server used widely by IT sysadmins for OS deployment. He implemented windowsize in Serva first, measured that it made TFTP roughly two orders of magnitude faster on typical LANs, and then wrote up the operational experience as an RFC. It is a textbook case of "rough consensus and running code" — a single vendor codifying a de facto improvement so other implementations could interoperate. Within a few years, dnsmasq, tftpd-hpa, and most enterprise switch TFTP clients supported it.

The lesson for modern engineers. Lockstep protocols age catastrophically the moment latency exceeds their assumptions. If you find yourself designing an ACK-per-message request/response and it will ever cross a WAN, a satellite link, or even a congested LAN, batch your acknowledgements. RFC 7440 shows how cheap the fix can be — a handful of new lines in the state machine, and a 30-year-old protocol becomes usable again.