Summary

  • RFC 2348’s prototype moved a 2.25 MB TFTP transfer from 23.85 to 4.90 seconds without an intermediate gateway when blocks grew from 512 to 8,192 octets.
  • The larger block was 16× the old payload size; the measured elapsed time fell about 80%, not 16×. The RFC itself warns that blocks beyond path MTU add fragmentation and reassembly costs.

The old TFTP bargain was simplicity. A small machine could ask for a file, receive one data block, acknowledge it and wait for the next. The protocol’s familiar 512-octet block kept each exchange modest, which suited diskless systems whose boot code lived in limited ROM. But stop-and-wait also made every acknowledgement a pause. On a local network with a larger frame budget, much of that rhythm could be spent sending headers and waiting rather than carrying file data.

In May 1998, RFC 2348 proposed a narrow change: let a client request a different blksize. The negotiation machinery came from RFC 2347, which appended options to a read or write request and used an Option Acknowledgment (OACK) to answer. The server could accept a value no larger than the client’s request; it could not invent an option the client had not asked for. The client then had to use the acknowledged value or end the transfer. If an older server ignored the option, the exchange could continue using ordinary TFTP behavior. This was an extension, not a silent rewrite of the baseline.

The proposed range was wide: 8 through 65,464 data octets per block, excluding TFTP’s four-octet header. RFC 2348 illustrated 1,428 octets as an Ethernet-MTU example after accounting for TFTP, UDP and IP headers. That number was a worked example, not a universal setting. The option value answered what the two TFTP endpoints agreed to send; it did not prove that every link and tunnel along the route could carry the resulting IP packet without fragmentation.

The document included its own experiment rather than a claim about all networks. Two HP-UX 9000 systems transferred 2.25 MB files in octet mode over a lightly loaded Ethernet. The authors averaged five runs, with and without one intermediate gateway. At 512 octets per block, the reported times were 23.85 seconds on the path without a gateway and 37.05 seconds with one. At 8,192 octets they were 4.90 and 6.15 seconds. The elapsed-time ratios work out to about 4.87× and 6.02×; the reductions are about 79.5% and 83.4%.

So what does the RFC’s “16x” comparison mean? The payload block became sixteen times larger: 8,192 divided by 512. It did not make the observed transfer sixteen times faster. The same comparison reports roughly an 80% time reduction, consistent with the raw five-run averages. That distinction matters because a block-size ratio, a packet-count reduction and a wall-clock speedup are different quantities. The gains were still impressive: larger blocks meant fewer data packets, fewer acknowledgements and fewer waits, plus less per-packet framing and processing overhead.

The limit was written beside the result. If a block exceeded the path MTU, IP fragmentation and reassembly began adding overhead; the RFC expected the penalty to become more noticeable as gateways accumulated. A block that is efficient on the test Ethernet may be an awkward fit after a smaller link, encapsulation or tunnel. The experiment did not test a diverse set of Internet paths, quantify variance, or identify a generally optimal block size. It established a mechanism and reported a bounded prototype result, not a deployment census.

Later work exposed another tuning axis. RFC 7440 defines a TFTP windowsize, allowing several consecutive blocks before waiting for an acknowledgement. Window depth and block size can both alter the stop-and-wait cost, but they are not the same knob. And later RFC 8900 discusses why IP fragmentation is fragile in operational networks; that later guidance should not be projected backward as evidence that the 1998 prototype failed. The original warning is enough: negotiated payload is not path-wide proof.

RFC 2348’s useful historical lesson is therefore more measured than “bigger is faster.” It showed exactly why a small protocol might negotiate a larger unit, demonstrated a substantial reduction under stated conditions, and named the network boundary that could reverse the trade. The result was not a magic number. It was an invitation to measure the path the transfer actually used.

The sources are the original TFTP specification, RFC 1350, the negotiation rules in RFC 2347, the contemporaneous timeout and transfer-size options in RFC 2349, and the later TFTP window and fragmentation documents, RFC 7440 and RFC 8900.