summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1783.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1783.txt')
-rw-r--r--doc/rfc/rfc1783.txt283
1 files changed, 283 insertions, 0 deletions
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]
+