--- 1/draft-ietf-core-new-block-10.txt 2021-04-28 04:34:13.743539180 -0700 +++ 2/draft-ietf-core-new-block-11.txt 2021-04-28 04:34:13.843541675 -0700 @@ -1,19 +1,19 @@ CoRE Working Group M. Boucadair Internet-Draft Orange Intended status: Standards Track J. Shallow -Expires: October 16, 2021 April 14, 2021 +Expires: October 30, 2021 April 28, 2021 Constrained Application Protocol (CoAP) Block-Wise Transfer Options for Faster Transmission - draft-ietf-core-new-block-10 + draft-ietf-core-new-block-11 Abstract This document specifies alternative Constrained Application Protocol (CoAP) Block-Wise transfer options: Q-Block1 and Q-Block2 Options. These options are similar to the CoAP Block1 and Block2 Options defined in RFC 7959, not a replacement for them, but do enable faster transmission rates for large amounts of data with less packet interchanges. Also, Q-Block1 and Q-Block2 Options support faster @@ -27,21 +27,21 @@ 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 October 16, 2021. + This Internet-Draft will expire on October 30, 2021. Copyright Notice Copyright (c) 2021 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 @@ -66,29 +66,29 @@ 4.5. Using Observe Option . . . . . . . . . . . . . . . . . . 16 4.6. Using Size1 and Size2 Options . . . . . . . . . . . . . . 16 4.7. Using Q-Block1 and Q-Block2 Options Together . . . . . . 16 4.8. Using Q-Block2 Option With Multicast . . . . . . . . . . 16 5. The Use of 4.08 (Request Entity Incomplete) Response Code . . 16 6. The Use of Tokens . . . . . . . . . . . . . . . . . . . . . . 18 7. Congestion Control for Unreliable Transports . . . . . . . . 18 7.1. Confirmable (CON) . . . . . . . . . . . . . . . . . . . . 18 7.2. Non-confirmable (NON) . . . . . . . . . . . . . . . . . . 19 8. Caching Considerations . . . . . . . . . . . . . . . . . . . 22 - 9. HTTP-Mapping Considerations . . . . . . . . . . . . . . . . . 23 - 10. Examples with Non-confirmable Messages . . . . . . . . . . . 23 + 9. HTTP-Mapping Considerations . . . . . . . . . . . . . . . . . 24 + 10. Examples with Non-confirmable Messages . . . . . . . . . . . 24 10.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . 24 10.1.1. A Simple Example . . . . . . . . . . . . . . . . . . 24 - 10.1.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 24 + 10.1.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 25 10.1.3. Handling MAX_PAYLOADS with Recovery . . . . . . . . 25 - 10.1.4. Handling Recovery with Failure . . . . . . . . . . . 26 + 10.1.4. Handling Recovery with Failure . . . . . . . . . . . 27 10.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . 27 - 10.2.1. A Simple Example . . . . . . . . . . . . . . . . . . 27 + 10.2.1. A Simple Example . . . . . . . . . . . . . . . . . . 28 10.2.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 28 10.2.3. Handling MAX_PAYLOADS with Recovery . . . . . . . . 29 10.2.4. Handling Recovery using M-bit Set . . . . . . . . . 30 10.3. Q-Block1 and Q-Block2 Options . . . . . . . . . . . . . 31 10.3.1. A Simple Example . . . . . . . . . . . . . . . . . . 31 10.3.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 32 10.3.3. Handling Recovery . . . . . . . . . . . . . . . . . 33 11. Security Considerations . . . . . . . . . . . . . . . . . . . 35 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 12.1. CoAP Option Numbers Registry . . . . . . . . . . . . . . 36 @@ -335,25 +335,24 @@ response (i.e., in that message to the payload of which it pertains), it indicates a block-wise transfer and describes how this specific block-wise payload forms part of the entire body being transferred. If it is present in the opposite direction, it provides additional control on how that payload will be formed or was processed. To indicate support for Q-Block2 responses, the CoAP client MUST include the Q-Block2 Option in a GET or similar request (FETCH, for example), the Q-Block2 Option in a PUT or similar request, or the Q-Block1 Option in a PUT or similar request so that the server knows - that the client supports this Q-Block2 functionality should it need - to send back a body that spans multiple payloads. Otherwise, the - server would use the Block2 Option (if supported) to send back a - message body that is too large to fit into a single IP packet - [RFC7959]. + that the client supports this Q-Block functionality should it need to + send back a body that spans multiple payloads. Otherwise, the server + would use the Block2 Option (if supported) to send back a message + body that is too large to fit into a single IP packet [RFC7959]. How a client decides whether it needs to include a Q-Block1 or Q-Block2 Option can be driven by a local configuration knob, triggered by an application (DOTS, for example), etc. Such considerations are out of the scope of the document. Implementation of the Q-Block1 and Q-Block2 Options is intended to be optional. However, when it is present in a CoAP message, it MUST be processed (or the message rejected). Therefore, Q-Block1 and Q-Block2 Options are identified as Critical options. @@ -463,113 +461,114 @@ starting from zero, until the body is complete (subject to any congestion control (Section 7)). Any missing payloads requested by the server must in addition be separately transmitted with increasing block numbers. The following Response Codes are used: 2.01 (Created) This Response Code indicates successful receipt of the entire body - and that the resource was created. The token used MUST be any - token that was received in a request using the same Request-Tag. - However, it is desirable to provide the one used in the last - received request, since that will aid any troubleshooting. The - client should then release all of the tokens used for this body. - Note that the last received payload may not be the one with the - highest block number. + and that the resource was created. The token used MUST be one of + the tokens that were received in a request for this block-wise + exchange. However, it is desirable to provide the one used in the + last received request, since that will aid any troubleshooting. + The client should then release all of the tokens used for this + body. Note that the last received payload may not be the one with + the highest block number. 2.02 (Deleted) This Response Code indicates successful receipt of the entire body and that the resource was deleted when using POST (Section 5.8.2 - [RFC7252]). The token used MUST be any token that was received in - a request using the same Request-Tag. However, it is desirable to - provide the one used in the last received request. The client - should then release all of the tokens used for this body. + [RFC7252]). The token used MUST be one of the tokens that were + received in a request for this block-wise exchange. However, it + is desirable to provide the one used in the last received request. + The client should then release all of the tokens used for this + body. 2.04 (Changed) This Response Code indicates successful receipt of the entire body - and that the resource was updated. The token used MUST be any - token that was received in a request using the same Request-Tag. - However, it is desirable to provide the one used in the last - received request. The client should then release all of the + and that the resource was updated. The token used MUST be one of + the tokens that were received in a request for this block-wise + exchange. However, it is desirable to provide the one used in the + last received request. The client should then release all of the tokens used for this body. 2.05 (Content) This Response Code indicates successful receipt of the entire FETCH request body (Section 2 of [RFC8132]) and that the appropriate representation of the resource is being returned. The - token used MUST be any token that was received in a request using - the same Request-Tag. However, it is desirable to provide the one - used in the last received request. + token used MUST be one of the tokens that were received in a + request for this block-wise exchange. However, it is desirable to + provide the one used in the last received request. If the FETCH request includes the Observe Option, then the server MUST use the same token as used for the initial response for returning any Observe triggered responses so that the client can match them up. The client should then release all of the tokens used for this body unless a resource is being observed. 2.31 (Continue) This Response Code can be used to indicate that all of the blocks up to and including the Q-Block1 Option block NUM (all having the M bit set) have been successfully received. The token used MUST - be any token that was received in a request using the same - Request-Tag. However, it is desirable to provide the one used in - the last received request. + be one of the tokens that were received in a request for this + block-wise exchange. However, it is desirable to provide the one + used in the last received request. A response using this Response Code SHOULD NOT be generated for every received Q-Block1 Option request (Section 7.2). It SHOULD only be generated when all the payload requests are Non- confirmable and a set of MAX_PAYLOADS payloads have been received by the server. More details about the motivations for this optimization are discussed in Section 7.2. - It SHOULD NOT be generated for CON. + This Response Code SHOULD NOT be generated for CON. 4.00 (Bad Request) This Response Code MUST be returned if the request does not - include neither a Request-Tag Option nor a Size1 Option but does - include a Q-Block1 option. + include a Request-Tag Option or a Size1 Option but does include a + Q-Block1 option. 4.02 (Bad Option) - Either this Response Code (in case of Confirmable request) or a - reset message (in case of Non-confirmable request) MUST be - returned if the server does not support the Q-Block Options. + This Response Code MUST be returned for a Confirmable request if + the server does not support the Q-Block Options. Note that a + reset message must be sent in case of Non-confirmable request. 4.08 (Request Entity Incomplete) As a reminder, this Response Code returned without Content-Type "application/missing-blocks+cbor-seq" (Section 12.3) is handled as in Section 2.9.2 [RFC7959]. This Response Code returned with Content-Type "application/ missing-blocks+cbor-seq" indicates that some of the payloads are missing and need to be resent. The client then retransmits the missing payloads using the same Request-Tag, Size1 and Q-Block1 to specify the block NUM, SZX, and M bit as appropriate. The Request-Tag value to use is determined by taking the token in the 4.08 (Request Entity Incomplete) response, locating the matching client request, and then using its Request-Tag. - The token used MUST be any token that was received in a request - using the same Request-Tag. However, it is desirable to provide - the one used in the last received request. See Section 5 for - further information. + The token used MUST be one of the tokens that were received in a + request for this block-wise exchange. However, it is desirable to + provide the one used in the last received request. See Section 5 + for further information. If the server has not received all the blocks of a body, but one or more NON payloads have been received, it SHOULD wait for up to NON_RECEIVE_TIMEOUT (Section 7.2) before sending a 4.08 (Request Entity Incomplete) response. 4.13 (Request Entity Too Large) This Response Code can be returned under similar conditions to those discussed in Section 2.9.3 of [RFC7959]. @@ -647,31 +646,31 @@ Section 4.6 discusses the use of Size2 Option. The client may elect to request any detected missing blocks or just ignore the partial body. This decision is implementation specific. The client SHOULD wait for up to NON_RECEIVE_TIMEOUT (Section 7.2) after the last received payload for NON payloads before issuing a GET, POST, PUT, FETCH, PATCH, or iPATCH request that contains one or more Q-Block2 Options that define the missing blocks with the M bit - unset. It is permissible to set the M bit to request this and later - blocks from this MAX_PAYLOADS set. Further considerations related to - the transmission timing for missing requests are discussed in + unset. The client MAY set the M bit to request this and later blocks + from this MAX_PAYLOADS set. Further considerations related to the + transmission timing for missing requests are discussed in Section 7.2. - The requested missing block numbers MUST have an increasing block - number in each additional Q-Block2 Option with no duplicates. The - server SHOULD respond with a 4.00 (Bad Request) to requests not - adhering to this behavior. Note that the ordering constraint is - meant to force the client to check for duplicates and remove them. - This also helps with troubleshooting. + The missing block numbers requested by the client MUST have an + increasing block number in each additional Q-Block2 Option with no + duplicates. The server SHOULD respond with a 4.00 (Bad Request) to + requests not adhering to this behavior. Note that the ordering + constraint is meant to force the client to check for duplicates and + remove them. This also helps with troubleshooting. For Confirmable responses, the client continues to acknowledge each packet. Typically, the server acknowledges the initial request using an ACK with the payload, and then sends the subsequent payloads as CON responses. The server will detect failure to send a packet, but the client can issue, after a MAX_TRANSMIT_SPAN delay, a separate GET, POST, PUT, FETCH, PATCH, or iPATCH for any missing blocks as needed. If the client receives a duplicate block with the same ETag, it MUST @@ -715,24 +714,26 @@ appropriate, a 4.13 (Request Entity Too Large) is returned without the Size1 Option. 4.5. Using Observe Option For a request that uses Q-Block1, the Observe value [RFC7641] MUST be the same for all the payloads of the same body. This includes any missing payloads that are retransmitted. For a response that uses Q-Block2, the Observe value MUST be the same - for all the payloads of the same body. This includes payloads - transmitted following receipt of the 'Continue' Q-Block2 Option - (Section 4.4) by the server. If a missing payload is requested, then - both the request and response MUST NOT include the Observe Option. + for all the payloads of the same body. This is different from Block2 + usage where the Observe value is only present in the first block + (Section 3.4 of [RFC7959]). This includes payloads transmitted + following receipt of the 'Continue' Q-Block2 Option (Section 4.4) by + the server. If a missing payload is requested by a client, then both + the request and response MUST NOT include the Observe Option. 4.6. Using Size1 and Size2 Options Section 4 of [RFC7959] defines two CoAP options: Size1 for indicating the size of the representation transferred in requests and Size2 for indicating the size of the representation transferred in responses. The Size1 or Size2 option values MUST exactly represent the size of the data on the body so that any missing data can easily be determined. @@ -830,23 +831,24 @@ Implementation Note: By using 8-byte tokens, it is possible to easily minimize the number of tokens that have to be tracked by clients, by keeping the bottom 32 bits the same for the same body and the upper 32 bits containing the current body's request number (incrementing every request, including every re-transmit). This allows the client to be alleviated from keeping all the per- request-state, e.g., in Section 3 of [RFC8974]. 7. Congestion Control for Unreliable Transports - The transmission of the blocks of a body over an unreliable transport - MUST either all be Confirmable or all be Non-confirmable. This is - meant to simplify the congestion control procedure. + The transmission of all the blocks of a single body over an + unreliable transport MUST either all be Confirmable or all be Non- + confirmable. This is meant to simplify the congestion control + procedure. As a reminder, there is no need for CoAP-specific congestion control for reliable transports [RFC8323]. 7.1. Confirmable (CON) Congestion control for CON requests and responses is specified in Section 4.7 of [RFC7252]. For faster transmission rates, NSTART will need to be increased from 1. However, the other CON congestion control parameters will need to be tuned to cover this change. This @@ -968,30 +970,31 @@ For Q-Block1 Option, if the server responds with a 2.31 (Continue) Response Code for the latest payload sent, then the client can continue to send the next set of payloads without any delay. If the server responds with a 4.08 (Request Entity Incomplete) Response Code, then the missing payloads SHOULD be retransmitted before going into another NON_TIMEOUT delay prior to sending the next set of payloads. For the server receiving NON Q-Block1 requests, it SHOULD send back a 2.31 (Continue) Response Code on receipt of all of the MAX_PAYLOADS - payloads to prevent the client unnecessarily delaying. Otherwise the - server SHOULD delay for NON_RECEIVE_TIMEOUT (exponentially scaled - based on the repeat request count for a payload), before sending the - 4.08 (Request Entity Incomplete) Response Code for the missing - payload(s). If this is a repeat for the 2.31 (Continue) response, - the server SHOULD send a 4.08 (Request Entity Incomplete) response - detailing the missing payloads after the block number that would have - been indicated in the 2.31 (Continue). If the repeat request count - for a missing payload exceeds NON_MAX_RETRANSMIT, the server SHOULD - discard the partial body and stop requesting the missing payloads. + payloads to prevent the client unnecessarily delaying. If not all of + the MAX_PAYLOADS payloads were received, the server SHOULD delay for + NON_RECEIVE_TIMEOUT (exponentially scaled based on the repeat request + count for a payload) before sending the 4.08 (Request Entity + Incomplete) Response Code for the missing payload(s). If this is a + repeat for the 2.31 (Continue) response, the server SHOULD send a + 4.08 (Request Entity Incomplete) response detailing the missing + payloads after the block number that would have been indicated in the + 2.31 (Continue). If the repeat request count for a missing payload + exceeds NON_MAX_RETRANSMIT, the server SHOULD discard the partial + body and stop requesting the missing payloads. It is likely that the client will start transmitting the next set of MAX_PAYLOADS payloads before the server times out on waiting for the last of the previous MAX_PAYLOADS payloads. On receipt of the first payload from the new set of MAX_PAYLOADS payloads, the server SHOULD send a 4.08 (Request Entity Incomplete) Response Code indicating any missing payloads from any previous MAX_PAYLOADS payloads. Upon receipt of the 4.08 (Request Entity Incomplete) Response Code, the client SHOULD send the missing payloads before continuing to send the remainder of the MAX_PAYLOADS payloads and then go into another @@ -1987,20 +1990,22 @@ Acknowledgements Thanks to Achim Kraus, Jim Schaad, and Michael Richardson for their comments. Special thanks to Christian Amsuess, Carsten Bormann, and Marco Tiloca for their suggestions and several reviews, which improved this specification significantly. Thanks to Francesca Palombini for the AD review. + Thanks to Pete Resnick for the Gen-ART review. + Some text from [RFC7959] is reused for readers convenience. Authors' Addresses Mohamed Boucadair Orange Rennes 35000 France Email: mohamed.boucadair@orange.com