CORE WG Z. Cao Internet-Draft K. Jin Intended status: Informational B. Fu Expires: May 11, 2019 D. Zhang Huawei November 7, 2018 Speeding Up CoAP Block-wise Transfer draft-zcao-core-speedy-blocktran-00 Abstract This document specifies a method to speed up block-wise transfer in CoAP. With this, the client can indicate its willingness to be responded with a sequence of blocks without issuing request for each block one by one. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 11, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. 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 Cao, et al. Expires May 11, 2019 [Page 1] Internet-Draft Speedy Block Transfer November 2018 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions used in this document . . . . . . . . . . . . . . 2 3. Speedy Blockwise Transfer . . . . . . . . . . . . . . . . . . 2 3.1. The Speedy Block Option . . . . . . . . . . . . . . . . . 2 3.2. Example Follow-chart . . . . . . . . . . . . . . . . . . 4 3.3. Retransmission Considerations . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction When performing the block-wise CoAP transfer as defined in [RFC7959] , the Client needs to continuously send requests to the Server, using the BLOCK options to specify the exact segment that is expected. As a consequence, the Server can only acknowledge different blocks one by one according to the request. Such a design was a reasonable choice since the server can be implemented to be truly stateless and lightweight. However, there are some cases where the server is capable of keeping necessary states so that the transfer can be performed in a more efficiently and faster way, e.g., the server being a firmware upgrade device without constraints defined for CoAP. This document describes such a proposal that is used to speed up the CoAP block transfer. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Speedy Blockwise Transfer 3.1. The Speedy Block Option We introduce a new option called 'BlockS', the format being specified in Figure 1. The client can include this option in the payload of the request to indicate its willingness to fetch the block content in a speedy way. Cao, et al. Expires May 11, 2019 [Page 2] Internet-Draft Speedy Block Transfer November 2018 +-----+---+---+---+---+--------+--------+--------+---------+ | No. | C | U | N | R | Name | Format | Length | Default | +-----+---+---+---+---+--------+--------+--------+---------+ | TBD | C | U | - | - | BlockS | uint | 0-4 | (none) | +-----+---+---+---+---+--------+--------+--------+---------+ Figure 1: The Speedy Block Option The value of the BlockS option is a variable-size unsigned integer. This integer value encodes these four fields: NUM, M, SIZE, and SPDYWND; NUM, M and SIZE are defined the same as [RFC7959]. NUM: the relative number of the block (NUM) within a sequence of blocks with the given size. (4, 12, 20 bit) M: whether more blocks are following (M) (1-bit); SIZE: the size of the block (SIZX) (3-bit), the actually size in octct equals to (2**(SZX+4)); SPDYWND(8-bit): the allowance of maximum window size used for speed- up, for a total of SPDYWND messages, the Server will solicitate an acknowledgement from the client if the client includes the BlockS option in its request, it indicates it will be willing and capable to receive a bunch of blocks without sending the request one by one. Since the client is fully awared of its capacity, it MUST indicate the SPDYWND value in the BlockS option explicitly. Upon receiving a request with the BlockS option, the Server will check the SPDYWND value in the request. It will calculate how many blocks (according to the SIZE value) the requested content consists of, and if this value being smaller than the SPDYWND, it will send the first block by changing the SPDYWND to the actually size (in block). The first block is piggyback in the Acknowledgement of the client request. for the next (SPDYWND-1) messages, the server will send the content in a NON message. for every SPDYWND responding messages, the server will send a CON message to solicitate an acknowledgement from the client to make sure that the client is still alive. if the Server does not support the BlockS option, it will neglect this message. The client, under this case, needs to implement a timeout mechanism, so that it can switch to other block-wise transfer (Block1 or Block2) as specified in [RFC7959]. Cao, et al. Expires May 11, 2019 [Page 3] Internet-Draft Speedy Block Transfer November 2018 3.2. Example Follow-chart In the following example, the client specifies its SPDYWND as 5, but the server finds out the representation only consists of 4 blocks, it will change the SPDYWND value to 4 in the BlockS option. The client will recognize this as an indication of actually length of the resource, continue to receive the content response until the M(More) bit being unset. CLIENT SERVER | | | CON [MID=1234], GET, T=0xFA /status, S:0/0/64/5 ------> | | | | <----ACK [MID=1234],T=0xFA, 2.05 Content, S:0/1/64/4 | | | | <----NON [MID=2000],T=0xFA, 2.05 Content, S:1/1/64/4 | | | | <----NON [MID=2001],T=0xFA, 2.05 Content, S:2/1/64/4 | | | | <----CON [MID=2002],T=0xFA, 2.05 Content, S:3/0/64/4 | | | | -------------- ACK [MID=2002] ----------------> | | | Figure 2: Speedy Blockwise GET with Early Negotiation In the following example, the client specifies its SPDYWND as 5, and the server finds out the representation consists of 8 blocks, it will keep the SPDYWND value to 5 in the BlockS option. The server will send a CON message every SPDYWND messages. Cao, et al. Expires May 11, 2019 [Page 4] Internet-Draft Speedy Block Transfer November 2018 CLIENT SERVER | | | CON [MID=1234], GET, T=0xFA /status, S:0/0/64/5 ------> | | | | <----ACK [MID=1234],T=0xFA, 2.05 Content, S:0/1/64/5 | | | | <----NON [MID=2000],T=0xFA, 2.05 Content, S:1/1/64/5 | | | | <----NON [MID=2001],T=0xFA, 2.05 Content, S:2/1/64/5 | | | | <----NON [MID=2002],T=0xFA, 2.05 Content, S:3/1/64/5 | | | | <----CON [MID=2003],T=0xFA, 2.05 Content, S:4/1/64/5 | | | | -------------- ACK [MID=2003] ----------------> | | | | <----NON [MID=2004],T=0xFA, 2.05 Content, S:5/1/64/5 | | | | <----NON [MID=2005],T=0xFA, 2.05 Content, S:6/1/64/5 | | | | <----NON [MID=2006],T=0xFA, 2.05 Content, S:7/0/64/5 | | | | -------------- ACK [MID=2006] ----------------> | | | Figure 3: Speedy Blockwise GET with Early Negotiation 3.3. Retransmission Considerations There is only one CON message every SPDYWND messages sending by the server. if the NON messages get lost during the communication, the server has no way to know the fact and will not retransmit it. Only after receiving a number of messages from the server, the Client can identify the "hole" due to packet loss. The client can send separate request per the missing sequence number in the whole block. Figure 4 shows an example where the NUM 2 and NUM 6 blocks get lost. The client will send separate requests for block number 2 and 6 after receiving the final block where M=0. Cao, et al. Expires May 11, 2019 [Page 5] Internet-Draft Speedy Block Transfer November 2018 CLIENT SERVER | | | CON [MID=1234], GET, T=0xFA /status, S:0/0/64/5 ------> | | | | <----ACK [MID=1234],T=0xFA, 2.05 Content, S:0/1/64/5 | | | | <----NON [MID=2000],T=0xFA, 2.05 Content, S:1/1/64/5 | | | | <----NON [MID=2001],T=0xFA, 2.05 Content, S:2/1/64/5 | **LOST** | | | <----NON [MID=2002],T=0xFA, 2.05 Content, S:3/1/64/5 | | | | <----CON [MID=2003],T=0xFA, 2.05 Content, S:4/1/64/5 | | | | -------------- ACK [MID=2003] ----------------> | | | | | | <----NON [MID=2004],T=0xFA, 2.05 Content, S:5/1/64/5 | | | | <----NON [MID=2005],T=0xFA, 2.05 Content, S:6/1/64/5 | **LOST** | | | <----NON [MID=2006],T=0xFA, 2.05 Content, S:7/0/64/5 | | | | -------------- ACK [MID=2006] ----------------> | | | | CON [MID=2234], GET, T=0xFA /status, S:2/0/64/5 ------> | **retran** | | | <----ACK [MID=2234],T=0xFA, 2.05 Content, S:2/0/64/5 ----| | | | CON [MID=2235], GET, T=0xFA /status, S:6/0/64/5 ------> | **retran** | | | <----ACK [MID=2235],T=0xFA, 2.05 Content, S:6/0/64/5 ----| Figure 4: Retransmission Flow 4. Security Considerations TBD 5. IANA Considerations This document needs an assignment of the BlockS option value defined in Section.3.1. Cao, et al. Expires May 11, 2019 [Page 6] Internet-Draft Speedy Block Transfer November 2018 6. Acknowledgments TBD 7. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, . [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in the Constrained Application Protocol (CoAP)", RFC 7959, DOI 10.17487/RFC7959, August 2016, . Authors' Addresses Zhen Cao Huawei Xinxi Rd 3 Beijing 100085 China Email: zhencao.ietf@gmail.com Ke Jin Huawei Shenzhen China Email: jinke@huawei.com Baicheng Fu Huawei Shenzhen China Email: 290275570@qq.com Cao, et al. Expires May 11, 2019 [Page 7] Internet-Draft Speedy Block Transfer November 2018 Dacheng Zhang Huawei Beijing China Email: zhangdacheng@huawei.com Cao, et al. Expires May 11, 2019 [Page 8]