idnits 2.17.1 draft-zcao-core-speedy-blocktran-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (November 7, 2018) is 1997 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3748' is defined on line 269, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CORE WG Z. Cao 3 Internet-Draft K. Jin 4 Intended status: Informational B. Fu 5 Expires: May 11, 2019 D. Zhang 6 Huawei 7 November 7, 2018 9 Speeding Up CoAP Block-wise Transfer 10 draft-zcao-core-speedy-blocktran-00 12 Abstract 14 This document specifies a method to speed up block-wise transfer in 15 CoAP. With this, the client can indicate its willingness to be 16 responded with a sequence of blocks without issuing request for each 17 block one by one. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on May 11, 2019. 36 Copyright Notice 38 Copyright (c) 2018 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Conventions used in this document . . . . . . . . . . . . . . 2 55 3. Speedy Blockwise Transfer . . . . . . . . . . . . . . . . . . 2 56 3.1. The Speedy Block Option . . . . . . . . . . . . . . . . . 2 57 3.2. Example Follow-chart . . . . . . . . . . . . . . . . . . 4 58 3.3. Retransmission Considerations . . . . . . . . . . . . . . 5 59 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 61 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 62 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 65 1. Introduction 67 When performing the block-wise CoAP transfer as defined in [RFC7959] 68 , the Client needs to continuously send requests to the Server, using 69 the BLOCK options to specify the exact segment that is expected. As 70 a consequence, the Server can only acknowledge different blocks one 71 by one according to the request. Such a design was a reasonable 72 choice since the server can be implemented to be truly stateless and 73 lightweight. However, there are some cases where the server is 74 capable of keeping necessary states so that the transfer can be 75 performed in a more efficiently and faster way, e.g., the server 76 being a firmware upgrade device without constraints defined for CoAP. 77 This document describes such a proposal that is used to speed up the 78 CoAP block transfer. 80 2. Conventions used in this document 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in [RFC2119]. 86 3. Speedy Blockwise Transfer 88 3.1. The Speedy Block Option 90 We introduce a new option called 'BlockS', the format being specified 91 in Figure 1. The client can include this option in the payload of 92 the request to indicate its willingness to fetch the block content in 93 a speedy way. 95 +-----+---+---+---+---+--------+--------+--------+---------+ 96 | No. | C | U | N | R | Name | Format | Length | Default | 97 +-----+---+---+---+---+--------+--------+--------+---------+ 98 | TBD | C | U | - | - | BlockS | uint | 0-4 | (none) | 99 +-----+---+---+---+---+--------+--------+--------+---------+ 101 Figure 1: The Speedy Block Option 103 The value of the BlockS option is a variable-size unsigned integer. 104 This integer value encodes these four fields: NUM, M, SIZE, and 105 SPDYWND; NUM, M and SIZE are defined the same as [RFC7959]. 107 NUM: the relative number of the block (NUM) within a sequence of 108 blocks with the given size. (4, 12, 20 bit) 110 M: whether more blocks are following (M) (1-bit); 112 SIZE: the size of the block (SIZX) (3-bit), the actually size in 113 octct equals to (2**(SZX+4)); 115 SPDYWND(8-bit): the allowance of maximum window size used for speed- 116 up, for a total of SPDYWND messages, the Server will solicitate an 117 acknowledgement from the client 119 if the client includes the BlockS option in its request, it indicates 120 it will be willing and capable to receive a bunch of blocks without 121 sending the request one by one. Since the client is fully awared of 122 its capacity, it MUST indicate the SPDYWND value in the BlockS option 123 explicitly. 125 Upon receiving a request with the BlockS option, the Server will 126 check the SPDYWND value in the request. It will calculate how many 127 blocks (according to the SIZE value) the requested content consists 128 of, and if this value being smaller than the SPDYWND, it will send 129 the first block by changing the SPDYWND to the actually size (in 130 block). 132 The first block is piggyback in the Acknowledgement of the client 133 request. for the next (SPDYWND-1) messages, the server will send the 134 content in a NON message. for every SPDYWND responding messages, the 135 server will send a CON message to solicitate an acknowledgement from 136 the client to make sure that the client is still alive. 138 if the Server does not support the BlockS option, it will neglect 139 this message. The client, under this case, needs to implement a 140 timeout mechanism, so that it can switch to other block-wise transfer 141 (Block1 or Block2) as specified in [RFC7959]. 143 3.2. Example Follow-chart 145 In the following example, the client specifies its SPDYWND as 5, but 146 the server finds out the representation only consists of 4 blocks, it 147 will change the SPDYWND value to 4 in the BlockS option. The client 148 will recognize this as an indication of actually length of the 149 resource, continue to receive the content response until the M(More) 150 bit being unset. 152 CLIENT SERVER 153 | | 154 | CON [MID=1234], GET, T=0xFA /status, S:0/0/64/5 ------> | 155 | | 156 | <----ACK [MID=1234],T=0xFA, 2.05 Content, S:0/1/64/4 | 157 | | 158 | <----NON [MID=2000],T=0xFA, 2.05 Content, S:1/1/64/4 | 159 | | 160 | <----NON [MID=2001],T=0xFA, 2.05 Content, S:2/1/64/4 | 161 | | 162 | <----CON [MID=2002],T=0xFA, 2.05 Content, S:3/0/64/4 | 163 | | 164 | -------------- ACK [MID=2002] ----------------> | 165 | | 167 Figure 2: Speedy Blockwise GET with Early Negotiation 169 In the following example, the client specifies its SPDYWND as 5, and 170 the server finds out the representation consists of 8 blocks, it will 171 keep the SPDYWND value to 5 in the BlockS option. The server will 172 send a CON message every SPDYWND messages. 174 CLIENT SERVER 175 | | 176 | CON [MID=1234], GET, T=0xFA /status, S:0/0/64/5 ------> | 177 | | 178 | <----ACK [MID=1234],T=0xFA, 2.05 Content, S:0/1/64/5 | 179 | | 180 | <----NON [MID=2000],T=0xFA, 2.05 Content, S:1/1/64/5 | 181 | | 182 | <----NON [MID=2001],T=0xFA, 2.05 Content, S:2/1/64/5 | 183 | | 184 | <----NON [MID=2002],T=0xFA, 2.05 Content, S:3/1/64/5 | 185 | | 186 | <----CON [MID=2003],T=0xFA, 2.05 Content, S:4/1/64/5 | 187 | | 188 | -------------- ACK [MID=2003] ----------------> | 189 | | 190 | <----NON [MID=2004],T=0xFA, 2.05 Content, S:5/1/64/5 | 191 | | 192 | <----NON [MID=2005],T=0xFA, 2.05 Content, S:6/1/64/5 | 193 | | 194 | <----NON [MID=2006],T=0xFA, 2.05 Content, S:7/0/64/5 | 195 | | 196 | -------------- ACK [MID=2006] ----------------> | 197 | | 199 Figure 3: Speedy Blockwise GET with Early Negotiation 201 3.3. Retransmission Considerations 203 There is only one CON message every SPDYWND messages sending by the 204 server. if the NON messages get lost during the communication, the 205 server has no way to know the fact and will not retransmit it. Only 206 after receiving a number of messages from the server, the Client can 207 identify the "hole" due to packet loss. The client can send separate 208 request per the missing sequence number in the whole block. 210 Figure 4 shows an example where the NUM 2 and NUM 6 blocks get lost. 211 The client will send separate requests for block number 2 and 6 after 212 receiving the final block where M=0. 214 CLIENT SERVER 215 | | 216 | CON [MID=1234], GET, T=0xFA /status, S:0/0/64/5 ------> | 217 | | 218 | <----ACK [MID=1234],T=0xFA, 2.05 Content, S:0/1/64/5 | 219 | | 220 | <----NON [MID=2000],T=0xFA, 2.05 Content, S:1/1/64/5 | 221 | | 222 | <----NON [MID=2001],T=0xFA, 2.05 Content, S:2/1/64/5 | **LOST** 223 | | 224 | <----NON [MID=2002],T=0xFA, 2.05 Content, S:3/1/64/5 | 225 | | 226 | <----CON [MID=2003],T=0xFA, 2.05 Content, S:4/1/64/5 | 227 | | 228 | -------------- ACK [MID=2003] ----------------> | 229 | | 230 | | 231 | <----NON [MID=2004],T=0xFA, 2.05 Content, S:5/1/64/5 | 232 | | 233 | <----NON [MID=2005],T=0xFA, 2.05 Content, S:6/1/64/5 | **LOST** 234 | | 235 | <----NON [MID=2006],T=0xFA, 2.05 Content, S:7/0/64/5 | 236 | | 237 | -------------- ACK [MID=2006] ----------------> | 238 | | 239 | CON [MID=2234], GET, T=0xFA /status, S:2/0/64/5 ------> | **retran** 240 | | 241 | <----ACK [MID=2234],T=0xFA, 2.05 Content, S:2/0/64/5 ----| 242 | | 243 | CON [MID=2235], GET, T=0xFA /status, S:6/0/64/5 ------> | **retran** 244 | | 245 | <----ACK [MID=2235],T=0xFA, 2.05 Content, S:6/0/64/5 ----| 247 Figure 4: Retransmission Flow 249 4. Security Considerations 251 TBD 253 5. IANA Considerations 255 This document needs an assignment of the BlockS option value defined 256 in Section.3.1. 258 6. Acknowledgments 260 TBD 262 7. References 264 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 265 Requirement Levels", BCP 14, RFC 2119, 266 DOI 10.17487/RFC2119, March 1997, 267 . 269 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 270 Levkowetz, Ed., "Extensible Authentication Protocol 271 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 272 . 274 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 275 the Constrained Application Protocol (CoAP)", RFC 7959, 276 DOI 10.17487/RFC7959, August 2016, 277 . 279 Authors' Addresses 281 Zhen Cao 282 Huawei 283 Xinxi Rd 3 284 Beijing 100085 285 China 287 Email: zhencao.ietf@gmail.com 289 Ke Jin 290 Huawei 291 Shenzhen 292 China 294 Email: jinke@huawei.com 296 Baicheng Fu 297 Huawei 298 Shenzhen 299 China 301 Email: 290275570@qq.com 302 Dacheng Zhang 303 Huawei 304 Beijing 305 China 307 Email: zhangdacheng@huawei.com