From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1783.txt | 283 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 283 insertions(+) create mode 100644 doc/rfc/rfc1783.txt (limited to 'doc/rfc/rfc1783.txt') diff --git a/doc/rfc/rfc1783.txt b/doc/rfc/rfc1783.txt new file mode 100644 index 0000000..167ff19 --- /dev/null +++ b/doc/rfc/rfc1783.txt @@ -0,0 +1,283 @@ + + + + + + +Network Working Group G. Malkin +Request for Comments: 1783 Xylogics, Inc. +Updates: 1350 A. Harkin +Category: Standards Track Hewlett Packard Co. + March 1995 + + + TFTP Blocksize Option + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + The Trivial File Transfer Protocol [1] is a simple, lock-step, file + transfer protocol which allows a client to get or put a file onto a + remote host. One of its primary uses is the booting of diskless + nodes on a Local Area Network. TFTP is used because it is very + simple to implement in a small node's limited ROM space. However, + the choice of a 512-byte blocksize is not the most efficient for use + on a LAN whose MTU may 1500 bytes or greater. + + This document describes a TFTP option which allows the client and + server to negotiate a blocksize more applicable to the network + medium. The TFTP Option Extension mechanism is described in [2]. + +Blocksize Option Specification + + The TFTP Read Request or Write Request packet is modified to include + the blocksize option as follows: + + +-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+ + | opc |filename| 0 | mode | 0 | blksize| 0 | #octets| 0 | + +-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+ + + opc + The opcode field contains either a 1, for Read Requests, or 2, + for Write Requests, as defined in [1]. + + filename + The name of the file to be read or written, as defined in [1]. + This is a NULL-terminated field. + + + + +Malkin & Harkin [Page 1] + +RFC 1783 TFTP Blocksize Option March 1995 + + + mode + The mode of the file transfer: "netascii", "octet", or "mail", + as defined in [1]. This is a NULL-terminated field. + + blksize + The Blocksize option, "blksize" (case insensitive). This is a + NULL-terminated field. + + #octets + The number of octets in a block, specified in ASCII. Valid + values range between "8" and "65464" octets, inclusive. This + is a NULL-terminated field. + + For example: + + +-------+--------+---+--------+---+--------+---+--------+---+ + | 1 | foobar | 0 | binary | 0 | blksize| 0 | 1432 | 0 | + +-------+--------+---+--------+---+--------+---+--------+---+ + + is a Read Request, for the file named "foobar", in binary transfer + mode, with a block size of 1432 bytes (Ethernet MTU, less the UDP and + IP header lengths). + + If the server is willing 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 specified by the client. The + client must then either use the size specified in the OACK, or send + an ERROR packet, with error code 8, to terminate the transfer. + + The rules for determining the final packet are unchanged from [1]. + The reception of a data packet with a data length less than the + negotiated blocksize is the final packet. If the blocksize is + greater than the size of the packet, the first packet is the final + packet. If amount of data to be transfered is an integral multiple + of the blocksize, an extra data packet containing no data is sent to + end the transfer. + + + + + + + + + + + + + + + +Malkin & Harkin [Page 2] + +RFC 1783 TFTP Blocksize Option March 1995 + + +Proof of Concept + + Performance tests were run on the prototype implementation using a + variety of block sizes. The tests were run on a lightly loaded + Ethernet, between two HP-UX 9000, in "octet" mode, on 2.25MB files. + The average (5x) transfer times for paths with (g-time) and without + (n-time) a intermediate gateway are graphed as follows: + + | + 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) + + + + +Malkin & Harkin [Page 3] + +RFC 1783 TFTP Blocksize Option March 1995 + + + The comparisons between transfer times (without a gateway) between + the standard 512-byte blocksize and the negotiated blocksizes are: + + 1024 2x -32% + 1432 2.8x -42% + 2048 4x -54% + 4096 8x -71% + 8192 16x -80% + + As was anticipated, the transfer time decreases with an increase in + blocksize. The reason for the reduction in time is the reduction in + the number of packets sent. For example, by increasing the blocksize + from 512 bytes to 1024 bytes, not only are the number of data packets + halved, but the number of acknowledgement packets is also halved + (along with the number of times the data transmitter must wait for an + ACK). A secondary effect is the efficiency gained by reducing the + per-packet framing and processing overhead. + + Of course, if the blocksize exceeds the path MTU, IP fragmentation + and reassembly will begin to add more overhead. This will be more + noticable the greater the number of gateways in the path. + +Security Considerations + + Security issues are not discussed in this memo. + +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. + + + + + + + + + + + + + + + + + + +Malkin & Harkin [Page 4] + +RFC 1783 TFTP Blocksize Option 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 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Malkin & Harkin [Page 5] + -- cgit v1.2.3