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,
<https://www.rfc-editor.org/info/rfc2119>.
[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,
<https://www.rfc-editor.org/info/rfc3748>.
[RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in
the Constrained Application Protocol (CoAP)", RFC 7959,
DOI 10.17487/RFC7959, August 2016,
<https://www.rfc-editor.org/info/rfc7959>.
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]