idnits 2.17.1 draft-malkin-tftpexts-blksize-opt-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 114 has weird spacing: '...ocksize n-ti...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 1998) is 9598 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1782 (ref. '2') (Obsoleted by RFC 2347) Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 draft-malkin-tftpexts-blksize-opt-02.txt G. Malkin / Bay Networks 3 TFTP Blocksize Option A. Harkin / Hewlett Packard Co. 4 Obsoletes RFC 1783 January 1998 6 TFTP Blocksize Option 8 Abstract 10 The Trivial File Transfer Protocol [1] is a simple, lock-step, file 11 transfer protocol which allows a client to get or put a file onto a 12 remote host. One of its primary uses is the booting of diskless 13 nodes on a Local Area Network. TFTP is used because it is very 14 simple to implement in a small node's limited ROM space. However, 15 the choice of a 512-octet blocksize is not the most efficient for use 16 on a LAN whose MTU may 1500 octets or greater. 18 This document describes a TFTP option which allows the client and 19 server to negotiate a blocksize more applicable to the network 20 medium. The TFTP Option Extension mechanism is described in [2]. 22 Status of this Memo 24 This document is an Internet-Draft. Internet-Drafts are working 25 documents of the Internet Engineering Task Force (IETF), its areas, 26 and its working groups. Note that other groups may also distribute 27 working documents as Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 To learn the current status of any Internet-Draft, please check the 35 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 36 Directories on ds.internic.net (US East Coast), nic.nordu.net 37 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 38 Rim). 40 Blocksize Option Specification 42 The TFTP Read Request or Write Request packet is modified to include 43 the blocksize option as follows. Note that all fields except "opc" 44 are NULL-terminated. 46 +-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+ 47 | opc |filename| 0 | mode | 0 | blksize| 0 | #octets| 0 | 48 +-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+ 50 opc 51 The opcode field contains either a 1, for Read Requests, or 2, 52 for Write Requests, as defined in [1]. 54 filename 55 The name of the file to be read or written, as defined in [1]. 57 mode 58 The mode of the file transfer: "netascii", "octet", or "mail", 59 as defined in [1]. 61 blksize 62 The Blocksize option, "blksize" (case in-sensitive). 64 #octets 65 The number of octets in a block, specified in ASCII. Valid 66 values range between "8" and "65464" octets, inclusive. The 67 blocksize refers to the number of data octets; it does not 68 include the four octets of TFTP header. 70 For example: 72 +-------+--------+---+--------+---+--------+---+--------+---+ 73 | 1 | foobar | 0 | binary | 0 | blksize| 0 | 1428 | 0 | 74 +-------+--------+---+--------+---+--------+---+--------+---+ 76 is a Read Request, for the file named "foobar", in binary transfer 77 mode, with a block size of 1428 octets (Ethernet MTU, less the TFTP, 78 UDP and IP header lengths). 80 If the server is willing to accept the blocksize option, it sends an 81 Option Acknowledgment (OACK) to the client. The specified value must 82 be less than or equal to the value specified by the client. The 83 client must then either use the size specified in the OACK, or send 84 an ERROR packet, with error code 8, to terminate the transfer. 86 The rules for determining the final packet are unchanged from [1]. 87 The reception of a data packet with a data length less than the 88 negotiated blocksize is the final packet. If the blocksize is 89 greater than the amount of data to be transfered, the first packet is 90 the final packet. If the amount of data to be transfered is an 91 integral multiple of the blocksize, an extra data packet containing 92 no data is sent to end the transfer. 94 Proof of Concept 96 Performance tests were run on the prototype implementation using a 97 variety of block sizes. The tests were run on a lightly loaded 98 Ethernet, between two HP-UX 9000, in "octet" mode, on 2.25MB files. 99 The average (5x) transfer times for paths with (g-time) and without 100 (n-time) a intermediate gateway are graphed as follows: 102 | 103 37 + g 104 | 105 35 + 106 | 107 33 + 108 | 109 31 + 110 | 111 29 + 112 | 113 27 + 114 | g blocksize n-time g-time 115 25 + --------- ------ ------ 116 s | n 512 23.85 37.05 117 e 23 + g 1024 16.15 25.65 118 c | 1428 13.70 23.10 119 o 21 + 2048 10.90 16.90 120 n | 4096 6.85 9.65 121 d 19 + 8192 4.90 6.15 122 s | 123 17 + g 124 | n 125 15 + 126 | n 127 13 + 128 | 129 11 + n 130 | g 131 9 + 132 | 133 7 + n 134 | g 135 5 + n 136 " 137 0 +------+------+--+---+------+------+--- 138 512 1K | 2K 4K 8K 139 1428 140 blocksize (octets) 142 The comparisons between transfer times (without a gateway) between 143 the standard 512-octet blocksize and the negotiated blocksizes are: 145 1024 2x -32% 146 1428 2.8x -42% 147 2048 4x -54% 148 4096 8x -71% 149 8192 16x -80% 151 As was anticipated, the transfer time decreases with an increase in 152 blocksize. The reason for the reduction in time is the reduction in 153 the number of packets sent. For example, by increasing the blocksize 154 from 512 octets to 1024 octets, not only are the number of data 155 packets halved, but the number of acknowledgement packets is also 156 halved (along with the number of times the data transmitter must wait 157 for an ACK). A secondary effect is the efficiency gained by reducing 158 the per-packet framing and processing overhead. 160 Of course, if the blocksize exceeds the path MTU, IP fragmentation 161 and reassembly will begin to add more overhead. This will be more 162 noticable the greater the number of gateways in the path. 164 Security Considerations 166 The basic TFTP protocol has no security mechanism. This is why it 167 has no rename, delete, or file overwrite capabilities. This document 168 does not add any security to TFTP; however, the specified extensions 169 do not add any additional security risks. 171 References 173 [1] Sollins, K., "The TFTP Protocol (Revision 2)", Request for 174 Comments 1350 (STD 33), October 1992. 176 [2] Malkin, G., Harkin, A., "TFTP Option Extension", RFC 1782 March 177 1995. 179 Authors' Addresses 181 Gary Scott Malkin 182 Bay Networks 183 8 Federal Street 184 Billerica, MA 10821 186 Phone: (978) 916-4237 187 EMail: gmalkin@baynetworks.com 189 Art Harkin 190 Networked Computing Division 191 Hewlett-Packard Company 192 19420 Homestead Road MS 43LN 193 Cupertino, CA 95014 195 Phone: (408) 447-3755 196 EMail: ash@cup.hp.com