TFTP Windowsize Option
Extracted elements (19)
The appropriate windowsize depends on underlying networking technology and topology. Rather than mandating a fixed value, the extension allows negotiation so operators can tune for their environment. The example configuration (windowsize=8, blksize=1456, 6 max retries, 1s timeout, 80µs inter-packet delay) is scaled for a 1 Gbit/s Ethernet environment.
The windowed scheme dramatically reduces transfer time by reducing the number of synchronous acknowledgements exchanged. Measurements on Gigabit Ethernet showed a windowsize of 4 reduced transfer time by 70%, windowsize 16 by 84%, and windowsize 64 by 86% compared to the lockstep (windowsize 1) baseline, motivating the extension over the existing blocksize-only optimization.
The rules for determining the final packet are unchanged from RFC 1350 and RFC 2348; only the window transmission and acknowledgment flow is modified by this extension.
The windowsize option is negotiated using the TFTP Option Extension mechanism defined in RFC 2347. If the server does not support the option it will ignore it, and the transfer proceeds as standard lockstep TFTP per RFC 1350, ensuring backward compatibility with non-implementing servers.
If the server accepts the windowsize option, it sends an OACK whose specified value MUST be less than or equal to the value specified by the client.
Implementations SHOULD always set a maximum number of retries for datagram retransmissions, and after reaching that threshold a transfer SHOULD always be aborted to prevent pathological retransmission conditions.
In the case of a data block sequence error, the DRCV SHOULD notify the DSND by sending an ACK corresponding to the last data block correctly received, and the DSND SHOULD send a new window whose beginning MUST be set based on the out-of-sequence ACK received.
In the case of an expected ACK not timely reaching the DSND (timeout), the last received ACK SHALL set the beginning of the next windowsize data block window to be sent.
Operators SHOULD test various windowsize values and SHOULD be conservative when selecting a windowsize value because beyond a certain point the benefit of increasing the windowsize is subject to diminishing returns.
The Data Receiver (DRCV) MUST send to the DSND the ACK of the last data block of the window in order to confirm successful receipt of the data block window.
The Data Sender (DSND) MUST cyclically send the agreed windowsize consecutive data blocks before stopping and waiting for the ACK of the transferred window.
The rate at which TFTP UDP datagrams are sent SHOULD follow the congestion control guidelines in Section 3.1 of RFC 5405 (Unicast UDP Usage Guidelines).
Traffic with windowsize = 1 MUST be equivalent to traffic specified by RFC 1350, preserving backward compatibility with the original lockstep TFTP protocol.
Upon receiving an OACK, the client MUST either use the size specified in the OACK or send an ERROR packet with error code 8 to terminate the transfer.
The '#blocks' field specifies the number of consecutive blocks in a window. Valid values MUST be between 1 and 65535 blocks inclusive. The windowsize refers to the number of consecutive blocks transmitted before stopping and waiting for acknowledgment of the last block transmitted.
The reception of a data window with fewer blocks than the negotiated windowsize signals the final window. If the windowsize exceeds the total data to transfer, the first window is also the final window.
TFTP includes no login or access control mechanisms. Care must be taken when using TFTP for file transfers where authentication, access control, confidentiality, or integrity checking are needed, as those services must be supplied above or below the TFTP layer. TFTP file transfers are NOT RECOMMENDED where inherent protocol limitations could raise insurmountable liability concerns.
TFTP includes no protection against an on-path attacker. Care must be taken in controlling windowsize values according to data sender, data receiver, and network environment capabilities. The windowsize extension itself does not pose additional security risks beyond those already present in TFTP.
The TFTP Read Request or Write Request packet is extended with two new NULL-terminated ASCII fields appended after the mode field: the literal string 'windowsize' (case insensitive) and the #blocks value as a base-10 ASCII string. All fields except the 2-byte 'opc' field MUST be ASCII strings followed by a single-byte NULL character.