RFC 1783

RFC 1783: TFTP Blocksize Option ✨

Okay bestie, this is RFC 1783, and it's giving official Standards Track energy 💅 It's from the Network Working Group, dated March 1995, and the authors are G. Malkin (Xylogics, Inc.) and A. Harkin (Hewlett Packard Co.) 🧚 It updates RFC 1350 (the TFTP protocol itself 👑). The header doesn't list any RFCs it obsoletes.

---

Status of This Memo

Okay so this doc is an Internet standards track protocol spec for the Internet community, and it's literally asking for discussion and suggestions for improvements 🫶 For the current standardization state and status of this protocol, check the current edition of "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈

Abstract

The Trivial File Transfer Protocol [1] is a simple, lock-step file transfer protocol that lets a client get or put a file onto a remote host 📁 One of its main jobs is booting diskless nodes on a Local Area Network 💻 It's used because it's super simple to implement in a small node's limited ROM space 🤏 The catch is that the 512-byte blocksize isn't the most efficient choice on a LAN whose MTU may be 1500 bytes or greater 🙈

This document describes a TFTP option that lets the client and server negotiate a blocksize that actually fits the network medium 🦋 The TFTP Option Extension mechanism is described in [2] ✨

Blocksize Option Specification

Here's the vibe: the TFTP Read Request or Write Request packet gets a blocksize option added to it, like this 🎀

+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+
|  opc  |filename| 0 |  mode  | 0 | blksize| 0 | #octets| 0 |
+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+

Here's what each field does:

• opc: the opcode field. It's either a 1 for Read Requests or a 2 for Write Requests, as defined in [1] 🍓
• filename: the name of the file to be read or written, as defined in [1]. It's a NULL-terminated field 📄
• mode: the transfer mode, which is "netascii", "octet", or "mail", as defined in [1]. Also NULL-terminated 💜
• blksize: the Blocksize option, "blksize" (case insensitive). NULL-terminated too 🌸
• #octets: the number of octets in a block, written in ASCII. Valid values range from "8" to "65464" octets, inclusive. NULL-terminated, obviously 🦋

Here's an example, and it's a whole mood 😭

+-------+--------+---+--------+---+--------+---+--------+---+
|   1   | foobar | 0 | binary | 0 | blksize| 0 |  1432  | 0 |
+-------+--------+---+--------+---+--------+---+--------+---+

This is a Read Request for the file named "foobar", in binary transfer mode, with a block size of 1432 bytes. That's the Ethernet MTU, minus the UDP and IP header lengths 🔥

If the server is down to accept the blocksize option, it sends an Option Acknowledgment (OACK) to the client 🫶 The specified value MUST be less than or equal to the value the client asked for. Then the client MUST either use the size from the OACK, or send an ERROR packet with error code 8 to terminate the transfer 💀

The rules for figuring out the final packet are the same as in [1] ✨ Receiving a data packet with a data length less than the negotiated blocksize means it's the final packet. If the blocksize is bigger than the size of the packet, the first packet is the final packet. And if the amount of data is an integral multiple of the blocksize, an extra data packet with no data gets sent to end the transfer 🏁

Proof of Concept

Okay, receipts time 🧾 Performance tests were run on the prototype implementation with a bunch of block sizes. They ran on a lightly loaded Ethernet, between two HP-UX 9000 machines, in "octet" mode, on 2.25MB files. The average (5x) transfer times for paths with (g-time) and without (n-time) an intermediate gateway are graphed below 📊

         |
      37 +      g
         |
      35 +
         |
      33 +
         |
      31 +
         |
      29 +
         |
      27 +
         |             g              blocksize   n-time   g-time
      25 +                            ---------   ------   ------
    s    |       n                      512       23.85    37.05
    e 23 +                g            1024       16.15    25.65
    c    |                             1432       13.70    23.10
    o 21 +                             2048       10.90    16.90
    n    |                             4096        6.85     9.65
    d 19 +                             8192        4.90     6.15
    s    |
      17 +                    g
         |             n
      15 +
         |                n
      13 +
         |
      11 +                    n
         |                           g
       9 +
         |
       7 +                           n
         |                                  g
       5 +                                  n
         "
       0 +------+------+--+---+------+------+---
               512    1K  |  2K     4K     8K
                        1432
                  blocksize (bytes)

Next, here's how the transfer times compare without a gateway, between the standard 512-byte blocksize and the negotiated ones 🤩

   1024     2x   -32%
   1432   2.8x   -42%
   2048     4x   -54%
   4096     8x   -71%
   8192    16x   -80%

As expected, transfer time goes down as the blocksize goes up 📉 The reason is simple: fewer packets get sent. Going from 512 bytes to 1024 bytes doesn't just halve the number of data packets, it also halves the number of acknowledgement packets, plus the number of times the data transmitter has to wait for an ACK 🙌 There's also a secondary win from less per-packet framing and processing overhead ✨

Okay but here's the catch 🙈 If the blocksize goes past the path MTU, IP fragmentation and reassembly start adding overhead. That gets more noticeable the more gateways are in the path.

Security Considerations

Security issues are not discussed in this memo 🔒 So, no shade, but no promises either 💀

References

[1] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350, MIT, July 1992.

[2] Malkin, G., and A. Harkin, "TFTP Option Extension", RFC 1782, Xylogics, Inc., Hewlett Packard Co., March 1995.

Authors' Addresses

Gary Scott Malkin Xylogics, Inc. 53 Third Avenue Burlington, MA 01803

Phone: (617) 272-8140 EMail: gmalkin@xylogics.com

Art Harkin Internet Services Project Information Networks Division 19420 Homestead Road MS 43LN Cupertino, CA 95014

Phone: (408) 447-3755 EMail: ash@cup.hp.com