224 lines
7.6 KiB
Plaintext
224 lines
7.6 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
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]
|