draft-ietf-core-new-block-13.txt   draft-ietf-core-new-block-14.txt 
CoRE Working Group M. Boucadair CoRE Working Group M. Boucadair
Internet-Draft Orange Internet-Draft Orange
Intended status: Standards Track J. Shallow Intended status: Standards Track J. Shallow
Expires: November 22, 2021 May 21, 2021 Expires: November 27, 2021 May 26, 2021
Constrained Application Protocol (CoAP) Block-Wise Transfer Options Constrained Application Protocol (CoAP) Block-Wise Transfer Options
Supporting Robust Transmission Supporting Robust Transmission
draft-ietf-core-new-block-13 draft-ietf-core-new-block-14
Abstract Abstract
This document specifies alternative Constrained Application Protocol This document specifies alternative Constrained Application Protocol
(CoAP) Block-Wise transfer options: Q-Block1 and Q-Block2 Options. (CoAP) Block-Wise transfer options: Q-Block1 and Q-Block2 Options.
These options are similar to, but distinct from, the CoAP Block1 and These options are similar to, but distinct from, the CoAP Block1 and
Block2 Options defined in RFC 7959. Q-Block1 and Q-Block2 Options Block2 Options defined in RFC 7959. Q-Block1 and Q-Block2 Options
are not intended to replace Block1 and Block2 Options, but rather are not intended to replace Block1 and Block2 Options, but rather
have the goal of supporting Non-confirmable messages for large have the goal of supporting Non-confirmable messages for large
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 22, 2021. This Internet-Draft will expire on November 27, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 32 skipping to change at page 2, line 32
4.4. Using the Q-Block2 Option . . . . . . . . . . . . . . . . 15 4.4. Using the Q-Block2 Option . . . . . . . . . . . . . . . . 15
4.5. Using Observe Option . . . . . . . . . . . . . . . . . . 17 4.5. Using Observe Option . . . . . . . . . . . . . . . . . . 17
4.6. Using Size1 and Size2 Options . . . . . . . . . . . . . . 17 4.6. Using Size1 and Size2 Options . . . . . . . . . . . . . . 17
4.7. Using Q-Block1 and Q-Block2 Options Together . . . . . . 18 4.7. Using Q-Block1 and Q-Block2 Options Together . . . . . . 18
4.8. Using Q-Block2 Option With Multicast . . . . . . . . . . 18 4.8. Using Q-Block2 Option With Multicast . . . . . . . . . . 18
5. The Use of 4.08 (Request Entity Incomplete) Response Code . . 18 5. The Use of 4.08 (Request Entity Incomplete) Response Code . . 18
6. The Use of Tokens . . . . . . . . . . . . . . . . . . . . . . 19 6. The Use of Tokens . . . . . . . . . . . . . . . . . . . . . . 19
7. Congestion Control for Unreliable Transports . . . . . . . . 20 7. Congestion Control for Unreliable Transports . . . . . . . . 20
7.1. Confirmable (CON) . . . . . . . . . . . . . . . . . . . . 20 7.1. Confirmable (CON) . . . . . . . . . . . . . . . . . . . . 20
7.2. Non-confirmable (NON) . . . . . . . . . . . . . . . . . . 20 7.2. Non-confirmable (NON) . . . . . . . . . . . . . . . . . . 20
8. Caching Considerations . . . . . . . . . . . . . . . . . . . 24 8. Caching Considerations . . . . . . . . . . . . . . . . . . . 25
9. HTTP-Mapping Considerations . . . . . . . . . . . . . . . . . 25 9. HTTP-Mapping Considerations . . . . . . . . . . . . . . . . . 26
10. Examples with Non-confirmable Messages . . . . . . . . . . . 25 10. Examples with Non-confirmable Messages . . . . . . . . . . . 26
10.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . 26 10.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . 27
10.1.1. A Simple Example . . . . . . . . . . . . . . . . . . 26 10.1.1. A Simple Example . . . . . . . . . . . . . . . . . . 27
10.1.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 26 10.1.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 27
10.1.3. Handling MAX_PAYLOADS with Recovery . . . . . . . . 27 10.1.3. Handling MAX_PAYLOADS with Recovery . . . . . . . . 27
10.1.4. Handling Recovery with Failure . . . . . . . . . . . 28 10.1.4. Handling Recovery with Failure . . . . . . . . . . . 29
10.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . 29 10.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . 30
10.2.1. A Simple Example . . . . . . . . . . . . . . . . . . 29 10.2.1. A Simple Example . . . . . . . . . . . . . . . . . . 30
10.2.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 30 10.2.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 31
10.2.3. Handling MAX_PAYLOADS with Recovery . . . . . . . . 31 10.2.3. Handling MAX_PAYLOADS with Recovery . . . . . . . . 32
10.2.4. Handling Recovery using M-bit Set . . . . . . . . . 32 10.2.4. Handling Recovery using M-bit Set . . . . . . . . . 33
10.3. Q-Block1 and Q-Block2 Options . . . . . . . . . . . . . 33 10.3. Q-Block1 and Q-Block2 Options . . . . . . . . . . . . . 34
10.3.1. A Simple Example . . . . . . . . . . . . . . . . . . 33 10.3.1. A Simple Example . . . . . . . . . . . . . . . . . . 34
10.3.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 34 10.3.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 35
10.3.3. Handling Recovery . . . . . . . . . . . . . . . . . 35 10.3.3. Handling Recovery . . . . . . . . . . . . . . . . . 36
11. Security Considerations . . . . . . . . . . . . . . . . . . . 37 11. Security Considerations . . . . . . . . . . . . . . . . . . . 38
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
12.1. CoAP Option Numbers Registry . . . . . . . . . . . . . . 38 12.1. CoAP Option Numbers Registry . . . . . . . . . . . . . . 39
12.2. Media Type Registration . . . . . . . . . . . . . . . . 38 12.2. Media Type Registration . . . . . . . . . . . . . . . . 39
12.3. CoAP Content-Formats Registry . . . . . . . . . . . . . 39 12.3. CoAP Content-Formats Registry . . . . . . . . . . . . . 40
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 41
13.1. Normative References . . . . . . . . . . . . . . . . . . 40 13.1. Normative References . . . . . . . . . . . . . . . . . . 41
13.2. Informative References . . . . . . . . . . . . . . . . . 41 13.2. Informative References . . . . . . . . . . . . . . . . . 42
Appendix A. Examples with Confirmable Messages . . . . . . . . . 42 Appendix A. Examples with Confirmable Messages . . . . . . . . . 43
A.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . . 42 A.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . . 43
A.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . . 44 A.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . . 45
Appendix B. Examples with Reliable Transports . . . . . . . . . 46 Appendix B. Examples with Reliable Transports . . . . . . . . . 47
B.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . . 46 B.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . . 47
B.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . . 46 B.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . . 47
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 47 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48
1. Introduction 1. Introduction
The Constrained Application Protocol (CoAP) [RFC7252], although The Constrained Application Protocol (CoAP) [RFC7252], although
inspired by HTTP, was designed to use UDP instead of TCP. The inspired by HTTP, was designed to use UDP instead of TCP. The
message layer of CoAP over UDP includes support for reliable message layer of CoAP over UDP includes support for reliable
delivery, simple congestion control, and flow control. CoAP supports delivery, simple congestion control, and flow control. CoAP supports
two message types (Section 1.2 of [RFC7252]): Confirmable (CON) and two message types (Section 1.2 of [RFC7252]): Confirmable (CON) and
Non-confirmable (NON) messages. Unlike NON messages, every CON Non-confirmable (NON) messages. Unlike NON messages, every CON
message will elicit an acknowledgement or a reset. message will elicit an acknowledgement or a reset.
skipping to change at page 20, line 42 skipping to change at page 20, line 42
initial Q-Block functionality negotiation. initial Q-Block functionality negotiation.
Following the failure to transmit a packet due to packet loss after Following the failure to transmit a packet due to packet loss after
MAX_TRANSMIT_SPAN time (Section 4.8.2 of [RFC7252]), it is MAX_TRANSMIT_SPAN time (Section 4.8.2 of [RFC7252]), it is
implementation specific as to whether there should be any further implementation specific as to whether there should be any further
requests for missing data. requests for missing data.
7.2. Non-confirmable (NON) 7.2. Non-confirmable (NON)
This document introduces new parameters MAX_PAYLOADS, NON_TIMEOUT, This document introduces new parameters MAX_PAYLOADS, NON_TIMEOUT,
NON_RECEIVE_TIMEOUT, NON_MAX_RETRANSMIT, NON_PROBING_WAIT, and NON_TIMEOUT_RANDOM, NON_RECEIVE_TIMEOUT, NON_MAX_RETRANSMIT,
NON_PARTIAL_TIMEOUT primarily for use with NON (Table 3). NON_PROBING_WAIT, and NON_PARTIAL_TIMEOUT primarily for use with NON
(Table 3).
Note: Randomness may naturally be provided based on the traffic
profile, how PROBING_RATE is computed (as this is an average), and
when the peer responds. Randomness is explicitly added for some
of the congestion control parameters to handle situations where
every thing is in sync when retrying.
MAX_PAYLOADS should be configurable with a default value of 10. Both MAX_PAYLOADS should be configurable with a default value of 10. Both
CoAP endpoints MUST have the same value (otherwise there will be CoAP endpoints MUST have the same value (otherwise there will be
transmission delays in one direction) and the value MAY be negotiated transmission delays in one direction) and the value MAY be negotiated
between the endpoints to a common value by using a higher level between the endpoints to a common value by using a higher level
protocol (out of scope of this document). This is the maximum number protocol (out of scope of this document). This is the maximum number
of payloads that can be transmitted at any one time. of payloads that can be transmitted at any one time.
Note: The default value of 10 is chosen for reasons similar to Note: The default value of 10 is chosen for reasons similar to
those discussed in Section 5 of [RFC6928], especially given the those discussed in Section 5 of [RFC6928], especially given the
target application discussed in Section 3.2. target application discussed in Section 3.2.
NON_TIMEOUT is the period of delay between sending MAX_PAYLOADS_SET NON_TIMEOUT is used to compute the delay between sending
for the same body. By default, NON_TIMEOUT has the same value as MAX_PAYLOADS_SET for the same body. By default, NON_TIMEOUT has the
ACK_TIMEOUT (Section 4.8 of [RFC7252]). same value as ACK_TIMEOUT (Section 4.8 of [RFC7252]).
NON_TIMEOUT_RANDOM is the initial actual delay between sending the
first two MAX_PAYLOADS_SETs of the same body. The same delay is then
used between the subsequent MAX_PAYLOADS_SETs. It is a random
duration (not an integral number of seconds) between NON_TIMEOUT and
(NON_TIMEOUT * ACK_RANDOM_FACTOR). ACK_RANDOM_FACTOR is set to 1.5
as discussed in Section 4.8 of [RFC7252].
NON_RECEIVE_TIMEOUT is the initial time to wait for a missing payload NON_RECEIVE_TIMEOUT is the initial time to wait for a missing payload
before requesting retransmission for the first time. Every time the before requesting retransmission for the first time. Every time the
missing payload is re-requested, the time to wait value doubles. The missing payload is re-requested, the time to wait value doubles. The
time to wait is calculated as: time to wait is calculated as:
Time-to-Wait = NON_RECEIVE_TIMEOUT * (2 ** (Re-Request-Count - 1)) Time-to-Wait = NON_RECEIVE_TIMEOUT * (2 ** (Re-Request-Count - 1))
NON_RECEIVE_TIMEOUT has a default value of twice NON_TIMEOUT. NON_RECEIVE_TIMEOUT has a default value of twice NON_TIMEOUT.
NON_RECEIVE_TIMEOUT MUST always be greater than NON_TIMEOUT by at NON_RECEIVE_TIMEOUT MUST always be greater than NON_TIMEOUT_RANDOM by
least one second so that the sender of the payloads has the at least one second so that the sender of the payloads has the
opportunity to start sending the next MAX_PAYLOADS_SET before the opportunity to start sending the next MAX_PAYLOADS_SET before the
receiver times out. receiver times out.
NON_MAX_RETRANSMIT is the maximum number of times a request for the NON_MAX_RETRANSMIT is the maximum number of times a request for the
retransmission of missing payloads can occur without a response from retransmission of missing payloads can occur without a response from
the remote peer. After this occurs, the local endpoint SHOULD the remote peer. After this occurs, the local endpoint SHOULD
consider the body stale, remove any body, and release Tokens and consider the body stale, remove any body, and release Tokens and
Request-Tag on the client (or the ETag on the server). By default, Request-Tag on the client (or the ETag on the server). By default,
NON_MAX_RETRANSMIT has the same value as MAX_RETRANSMIT (Section 4.8 NON_MAX_RETRANSMIT has the same value as MAX_RETRANSMIT (Section 4.8
of [RFC7252]). of [RFC7252]).
NON_PROBING_WAIT is used to limit the potential wait needed when NON_PROBING_WAIT is used to limit the potential wait needed when
using PROBING_RATE. By default, NON_PROBING_WAIT is computed in the using PROBING_RATE. By default, NON_PROBING_WAIT is computed in a
same way as EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]) but with similar way as EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]) but
ACK_TIMEOUT and MAX_RETRANSMIT substituted with NON_TIMEOUT and with ACK_TIMEOUT, MAX_RETRANSMIT, and PROCESSING_DELAY substituted
NON_MAX_RETRANSMIT, respectively: with NON_TIMEOUT, NON_MAX_RETRANSMIT, and NON_TIMEOUT_RANDOM,
respectively:
NON_PROBING_WAIT = NON_TIMEOUT * ((2 ** NON_MAX_RETRANSMIT) - 1) * NON_PROBING_WAIT = NON_TIMEOUT * ((2 ** NON_MAX_RETRANSMIT) - 1) *
ACK_RANDOM_FACTOR + (2 * MAX_LATENCY) + NON_TIMEOUT ACK_RANDOM_FACTOR + (2 * MAX_LATENCY) + NON_TIMEOUT_RANDOM
NON_PARTIAL_TIMEOUT is used for expiring partially received bodies. NON_PARTIAL_TIMEOUT is used for expiring partially received bodies.
By default, NON_PARTIAL_TIMEOUT is computed in the same way as By default, NON_PARTIAL_TIMEOUT is computed in the same way as
EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]). This default value EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]) but with ACK_TIMEOUT
is calculated in the same way as NON_PROBING_WAIT. and MAX_RETRANSMIT substituted with NON_TIMEOUT and
NON_MAX_RETRANSMIT, respectively:
+---------------------+---------------+ NON_PARTIAL_TIMEOUT = NON_TIMEOUT * ((2 ** NON_MAX_RETRANSMIT) -
| Parameter Name | Default Value | 1) * ACK_RANDOM_FACTOR + (2 * MAX_LATENCY) + NON_TIMEOUT
+=====================+===============+
| MAX_PAYLOADS | 10 |
| NON_MAX_RETRANSMIT | 4 |
| NON_TIMEOUT | 2 s |
| NON_RECEIVE_TIMEOUT | 4 s |
| NON_PROBING_WAIT | 247 s |
| NON_PARTIAL_TIMEOUT | 247 s |
+---------------------+---------------+
Table 3: Congestion Control Parameters +---------------------+-------------------+
| Parameter Name | Default Value |
+=====================+===================+
| MAX_PAYLOADS | 10 |
| NON_MAX_RETRANSMIT | 4 |
| NON_TIMEOUT | 2 s |
| NON_TIMEOUT_RANDOM | between 2-3 s |
| NON_RECEIVE_TIMEOUT | 4 s |
| NON_PROBING_WAIT | between 247-248 s |
| NON_PARTIAL_TIMEOUT | 247 s |
+---------------------+-------------------+
Table 3: Congestion Control Parameters
The PROBING_RATE parameter in CoAP indicates the average data rate The PROBING_RATE parameter in CoAP indicates the average data rate
that must not be exceeded by a CoAP endpoint in sending to a peer that must not be exceeded by a CoAP endpoint in sending to a peer
endpoint that does not respond. A single body will be subjected to endpoint that does not respond. A single body will be subjected to
PROBING_RATE (Section 4.7 of [RFC7252]), not the individual packets. PROBING_RATE (Section 4.7 of [RFC7252]), not the individual packets.
If the wait time between sending bodies that are not being responded If the wait time between sending bodies that are not being responded
to based on PROBING_RATE exceeds NON_PROBING_WAIT, then the wait time to based on PROBING_RATE exceeds NON_PROBING_WAIT, then the wait time
is limited to NON_PROBING_WAIT. is limited to NON_PROBING_WAIT.
Note: For the particular DOTS application, PROBING_RATE and other Note: For the particular DOTS application, PROBING_RATE and other
skipping to change at page 22, line 44 skipping to change at page 23, line 13
values are used without applying any jitter. values are used without applying any jitter.
Each NON 4.08 (Request Entity Incomplete) response is subject to Each NON 4.08 (Request Entity Incomplete) response is subject to
PROBING_RATE. PROBING_RATE.
Each NON GET or FETCH request using a Q-Block2 Option is subject to Each NON GET or FETCH request using a Q-Block2 Option is subject to
PROBING_RATE. PROBING_RATE.
As the sending of many payloads of a single body may itself cause As the sending of many payloads of a single body may itself cause
congestion, after transmission of every MAX_PAYLOADS_SET of a single congestion, after transmission of every MAX_PAYLOADS_SET of a single
body, a delay MUST be introduced of NON_TIMEOUT before sending the body, a delay MUST be introduced of NON_TIMEOUT_RANDOM before sending
next MAX_PAYLOADS_SET unless a 'Continue' is received from the peer the next MAX_PAYLOADS_SET unless a 'Continue' is received from the
for the current MAX_PAYLOADS_SET, in which case the next peer for the current MAX_PAYLOADS_SET, in which case the next
MAX_PAYLOADS_SET MAY start transmission immediately. MAX_PAYLOADS_SET MAY start transmission immediately.
Note: Assuming 1500-byte packets and the MAX_PAYLOADS_SET having Note: Assuming 1500-byte packets and the MAX_PAYLOADS_SET having
10 payloads, this corresponds to 1500 * 10 * 8 = 120 Kbits. With 10 payloads, this corresponds to 1500 * 10 * 8 = 120 Kbits. With
a maximum delay of 2 seconds between MAX_PAYLOADS_SET, this a delay of 2 seconds between MAX_PAYLOADS_SET, this indicates an
indicates an average speed requirement of 60 Kbps for a single average speed requirement of 60 Kbps for a single body should
body should there be no responses. This transmission rate is there be no responses. This transmission rate is further reduced
further reduced by being subject to PROBING_RATE. by being subject to PROBING_RATE.
The sending of a set of missing blocks of a body is restricted to The sending of a set of missing blocks of a body is restricted to
those in a MAX_PAYLOADS_SET at a time. In other words, a NON_TIMEOUT those in a MAX_PAYLOADS_SET at a time. In other words, a
delay is still observed between each MAX_PAYLOAD_SET. NON_TIMEOUT_RANDOM delay is still observed between each
MAX_PAYLOAD_SET.
For Q-Block1 Option, if the server responds with a 2.31 (Continue) For Q-Block1 Option, if the server responds with a 2.31 (Continue)
Response Code for the latest payload sent, then the client can Response Code for the latest payload sent, then the client can
continue to send the next MAX_PAYLOADS_SET without any further delay. continue to send the next MAX_PAYLOADS_SET without any further delay.
If the server responds with a 4.08 (Request Entity Incomplete) If the server responds with a 4.08 (Request Entity Incomplete)
Response Code, then the missing payloads SHOULD be retransmitted Response Code, then the missing payloads SHOULD be retransmitted
before going into another NON_TIMEOUT delay prior to sending the next before going into another NON_TIMEOUT_RANDOM delay prior to sending
set of payloads. the next set of payloads.
For the server receiving NON Q-Block1 requests, it SHOULD send back a For the server receiving NON Q-Block1 requests, it SHOULD send back a
2.31 (Continue) Response Code on receipt of all of the 2.31 (Continue) Response Code on receipt of all of the
MAX_PAYLOADS_SET to prevent the client unnecessarily delaying. If MAX_PAYLOADS_SET to prevent the client unnecessarily delaying. If
not all of the MAX_PAYLOADS_SET were received, the server SHOULD not all of the MAX_PAYLOADS_SET were received, the server SHOULD
delay for NON_RECEIVE_TIMEOUT (exponentially scaled based on the delay for NON_RECEIVE_TIMEOUT (exponentially scaled based on the
repeat request count for a payload) before sending the 4.08 (Request repeat request count for a payload) before sending the 4.08 (Request
Entity Incomplete) Response Code for the missing payload(s). If all Entity Incomplete) Response Code for the missing payload(s). If all
of the MAX_PAYLOADS_SET were received and a 2.31 (Continue) had been of the MAX_PAYLOADS_SET were received and a 2.31 (Continue) had been
sent, but no more payloads were received for NON_RECEIVE_TIMEOUT sent, but no more payloads were received for NON_RECEIVE_TIMEOUT
skipping to change at page 23, line 43 skipping to change at page 24, line 13
body and stop requesting the missing payloads. body and stop requesting the missing payloads.
It is likely that the client will start transmitting the next It is likely that the client will start transmitting the next
MAX_PAYLOADS_SET before the server times out on waiting for the last MAX_PAYLOADS_SET before the server times out on waiting for the last
of the previous MAX_PAYLOADS_SET. On receipt of a payload from the of the previous MAX_PAYLOADS_SET. On receipt of a payload from the
next MAX_PAYLOADS_SET, the server SHOULD send a 4.08 (Request Entity next MAX_PAYLOADS_SET, the server SHOULD send a 4.08 (Request Entity
Incomplete) Response Code indicating any missing payloads from any Incomplete) Response Code indicating any missing payloads from any
previous MAX_PAYLOADS_SET. Upon receipt of the 4.08 (Request Entity previous MAX_PAYLOADS_SET. Upon receipt of the 4.08 (Request Entity
Incomplete) Response Code, the client SHOULD send the missing Incomplete) Response Code, the client SHOULD send the missing
payloads before continuing to send the remainder of the payloads before continuing to send the remainder of the
MAX_PAYLOADS_SET and then go into another NON_TIMEOUT delay prior to MAX_PAYLOADS_SET and then go into another NON_TIMEOUT_RANDOM delay
sending the next MAX_PAYLOADS_SET. prior to sending the next MAX_PAYLOADS_SET.
For the client receiving NON Q-Block2 responses, it SHOULD send a For the client receiving NON Q-Block2 responses, it SHOULD send a
'Continue' Q-Block2 request (Section 4.4) for the next 'Continue' Q-Block2 request (Section 4.4) for the next
MAX_PAYLOADS_SET on receipt of all of the MAX_PAYLOADS_SET, to MAX_PAYLOADS_SET on receipt of all of the MAX_PAYLOADS_SET, to
prevent the server unnecessarily delaying. Otherwise the client prevent the server unnecessarily delaying. Otherwise the client
SHOULD delay for NON_RECEIVE_TIMEOUT (exponentially scaled based on SHOULD delay for NON_RECEIVE_TIMEOUT (exponentially scaled based on
the repeat request count for a payload), before sending the request the repeat request count for a payload), before sending the request
for the missing payload(s). If the repeat request count for a for the missing payload(s). If the repeat request count for a
missing payload exceeds NON_MAX_RETRANSMIT, the client SHOULD discard missing payload exceeds NON_MAX_RETRANSMIT, the client SHOULD discard
the partial body and stop requesting the missing payloads. the partial body and stop requesting the missing payloads.
skipping to change at page 24, line 20 skipping to change at page 24, line 38
(including Observe Option, if appropriate for an unsolicited (including Observe Option, if appropriate for an unsolicited
response) rather than as a request for the remaining missing blocks. response) rather than as a request for the remaining missing blocks.
It is likely that the server will start transmitting the next It is likely that the server will start transmitting the next
MAX_PAYLOADS_SET before the client times out on waiting for the last MAX_PAYLOADS_SET before the client times out on waiting for the last
of the previous MAX_PAYLOADS_SET. Upon receipt of a payload from the of the previous MAX_PAYLOADS_SET. Upon receipt of a payload from the
new MAX_PAYLOADS_SET, the client SHOULD send a request indicating any new MAX_PAYLOADS_SET, the client SHOULD send a request indicating any
missing payloads from any previous MAX_PAYLOADS_SET. Upon receipt of missing payloads from any previous MAX_PAYLOADS_SET. Upon receipt of
such request, the server SHOULD send the missing payloads before such request, the server SHOULD send the missing payloads before
continuing to send the remainder of the MAX_PAYLOADS_SET and then go continuing to send the remainder of the MAX_PAYLOADS_SET and then go
into another NON_TIMEOUT delay prior to sending the next into another NON_TIMEOUT_RANDOM delay prior to sending the next
MAX_PAYLOADS_SET. MAX_PAYLOADS_SET.
The client does not need to acknowledge the receipt of the entire The client does not need to acknowledge the receipt of the entire
body. body.
Note: If there is asymmetric traffic loss causing responses to Note: If there is asymmetric traffic loss causing responses to
never get received, a delay of NON_TIMEOUT after every never get received, a delay of NON_TIMEOUT_RANDOM after every
transmission of MAX_PAYLOADS_SET will be observed. The endpoint transmission of MAX_PAYLOADS_SET will be observed. The endpoint
receiving the body is still likely to receive the entire body. receiving the body is still likely to receive the entire body.
8. Caching Considerations 8. Caching Considerations
Caching block based information is not straight forward in a proxy. Caching block based information is not straight forward in a proxy.
For Q-Block1 and Q-Block2 Options, for simplicity it is expected that For Q-Block1 and Q-Block2 Options, for simplicity it is expected that
the proxy will reassemble the body (using any appropriate recovery the proxy will reassemble the body (using any appropriate recovery
options for packet loss) before passing on the body to the options for packet loss) before passing on the body to the
appropriate CoAP endpoint. This does not preclude an implementation appropriate CoAP endpoint. This does not preclude an implementation
skipping to change at page 27, line 38 skipping to change at page 28, line 15
CoAP CoAP CoAP CoAP
Client Server Client Server
| | | |
+--------->| NON PUT /path M:0x11 T:0xe1 RT=11 QB1:0/1/1024 +--------->| NON PUT /path M:0x11 T:0xe1 RT=11 QB1:0/1/1024
+--->X | NON PUT /path M:0x12 T:0xe2 RT=11 QB1:1/1/1024 +--->X | NON PUT /path M:0x12 T:0xe2 RT=11 QB1:1/1/1024
+--------->| [[Payloads 3 - 8 not detailed]] +--------->| [[Payloads 3 - 8 not detailed]]
+--------->| NON PUT /path M:0x19 T:0xe9 RT=11 QB1:8/1/1024 +--------->| NON PUT /path M:0x19 T:0xe9 RT=11 QB1:8/1/1024
+--->X | NON PUT /path M:0x1a T:0xea RT=11 QB1:9/1/1024 +--->X | NON PUT /path M:0x1a T:0xea RT=11 QB1:9/1/1024
[[Some of MAX_PAYLOADS_SET have been received]] [[Some of MAX_PAYLOADS_SET have been received]]
| ... | | ... |
[[NON_TIMEOUT (client) delay expires]] [[NON_TIMEOUT_RANDOM (client) delay expires]]
| [[Client starts sending next MAX_PAYLOAD_SET]] | [[Client starts sending next MAX_PAYLOAD_SET]]
+--->X | NON PUT /path M:0x1b T:0xeb RT=11 QB1:10/1/1024 +--->X | NON PUT /path M:0x1b T:0xeb RT=11 QB1:10/1/1024
+--------->| NON PUT /path M:0x1c T:0xec RT=11 QB1:11/1/1024 +--------->| NON PUT /path M:0x1c T:0xec RT=11 QB1:11/1/1024
| | | |
Figure 5: Example of MAX_PAYLOADS NON Request with Q-Block1 Option Figure 5: Example of MAX_PAYLOADS NON Request with Q-Block1 Option
(With Loss) (With Loss)
On seeing a payload from the next MAX_PAYLOAD_SET, the server On seeing a payload from the next MAX_PAYLOAD_SET, the server
realizes that some blocks are missing from the previous realizes that some blocks are missing from the previous
skipping to change at page 32, line 15 skipping to change at page 33, line 15
CoAP CoAP CoAP CoAP
Client Server Client Server
| ... | | ... |
| [[Observe triggered]] | [[Observe triggered]]
|<---------+ NON 2.05 M:0xa1 T:0xf0 O:1236 ET=23 QB2:0/1/1024 |<---------+ NON 2.05 M:0xa1 T:0xf0 O:1236 ET=23 QB2:0/1/1024
| X<---+ NON 2.05 M:0xa2 T:0xf0 O:1236 ET=23 QB2:1/1/1024 | X<---+ NON 2.05 M:0xa2 T:0xf0 O:1236 ET=23 QB2:1/1/1024
|<---------+ [[Payloads 3 - 9 not detailed]] |<---------+ [[Payloads 3 - 9 not detailed]]
| X<---+ NON 2.05 M:0xaa T:0xf0 O:1236 ET=23 QB2:9/1/1024 | X<---+ NON 2.05 M:0xaa T:0xf0 O:1236 ET=23 QB2:9/1/1024
[[Some of MAX_PAYLOADS_SET have been received]] [[Some of MAX_PAYLOADS_SET have been received]]
| ... | | ... |
[[NON_TIMEOUT (server) delay expires]] [[NON_TIMEOUT_RANDOM (server) delay expires]]
| [[Server sends next MAX_PAYLOAD_SET]] | [[Server sends next MAX_PAYLOAD_SET]]
|<---------+ NON 2.05 M:0xab T:0xf0 O:1236 ET=23 QB2:10/0/1024 |<---------+ NON 2.05 M:0xab T:0xf0 O:1236 ET=23 QB2:10/0/1024
| [[On seeing a payload from the next MAX_PAYLOAD_SET, | [[On seeing a payload from the next MAX_PAYLOAD_SET,
| Client realizes blocks are missing and asks for the | Client realizes blocks are missing and asks for the
| missing ones in one go]] | missing ones in one go]]
+--------->| NON GET /path M:0x04 T:0xf3 QB2:1/0/1024\ +--------->| NON GET /path M:0x04 T:0xf3 QB2:1/0/1024\
| | QB2:9/0/1024 | | QB2:9/0/1024
| X<---+ NON 2.05 M:0xac T:0xf3 ET=23 QB2:1/1/1024 | X<---+ NON 2.05 M:0xac T:0xf3 ET=23 QB2:1/1/1024
|<---------+ NON 2.05 M:0xad T:0xf3 ET=23 QB2:9/1/1024 |<---------+ NON 2.05 M:0xad T:0xf3 ET=23 QB2:9/1/1024
| ... | | ... |
skipping to change at page 33, line 16 skipping to change at page 34, line 16
Client Server Client Server
| ... | | ... |
| [[Observe triggered]] | [[Observe triggered]]
|<---------+ NON 2.05 M:0xb1 T:0xf0 O:1237 ET=24 QB2:0/1/1024 |<---------+ NON 2.05 M:0xb1 T:0xf0 O:1237 ET=24 QB2:0/1/1024
|<---------+ NON 2.05 M:0xb2 T:0xf0 O:1237 ET=24 QB2:1/1/1024 |<---------+ NON 2.05 M:0xb2 T:0xf0 O:1237 ET=24 QB2:1/1/1024
| X<---+ NON 2.05 M:0xb3 T:0xf0 O:1237 ET=24 QB2:2/1/1024 | X<---+ NON 2.05 M:0xb3 T:0xf0 O:1237 ET=24 QB2:2/1/1024
| X<---+ [[Payloads 4 - 9 not detailed]] | X<---+ [[Payloads 4 - 9 not detailed]]
| X<---+ NON 2.05 M:0xb9 T:0xf0 O:1237 ET=24 QB2:9/1/1024 | X<---+ NON 2.05 M:0xb9 T:0xf0 O:1237 ET=24 QB2:9/1/1024
[[Some of MAX_PAYLOADS_SET have been received]] [[Some of MAX_PAYLOADS_SET have been received]]
| ... | | ... |
[[NON_TIMEOUT (server) delay expires]] [[NON_TIMEOUT_RANDOM (server) delay expires]]
| [[Server sends next MAX_PAYLOAD_SET]] | [[Server sends next MAX_PAYLOAD_SET]]
| X<---+ NON 2.05 M:0xba T:0xf0 O:1237 ET=24 QB2:10/0/1024 | X<---+ NON 2.05 M:0xba T:0xf0 O:1237 ET=24 QB2:10/0/1024
| ... | | ... |
[[NON_RECEIVE_TIMEOUT (client) delay expires]] [[NON_RECEIVE_TIMEOUT (client) delay expires]]
| [[Client realizes blocks are missing and asks for the | [[Client realizes blocks are missing and asks for the
| missing ones in one go by setting the M bit]] | missing ones in one go by setting the M bit]]
+--------->| NON GET /path M:0x06 T:0xf5 QB2:2/1/1024 +--------->| NON GET /path M:0x06 T:0xf5 QB2:2/1/1024
|<---------+ NON 2.05 M:0xbb T:0xf5 ET=24 QB2:2/1/1024 |<---------+ NON 2.05 M:0xbb T:0xf5 ET=24 QB2:2/1/1024
|<---------+ [[Payloads 3 - 9 not detailed]] |<---------+ [[Payloads 3 - 9 not detailed]]
|<---------+ NON 2.05 M:0xc2 T:0xf5 ET=24 QB2:9/1/1024 |<---------+ NON 2.05 M:0xc2 T:0xf5 ET=24 QB2:9/1/1024
skipping to change at page 43, line 36 skipping to change at page 44, line 36
Client Server Client Server
| | | |
+--------->| CON PUT /path M:0x05 T:0xf4 RT=11 QB1:0/1/1024 +--------->| CON PUT /path M:0x05 T:0xf4 RT=11 QB1:0/1/1024
+--->X | CON PUT /path M:0x06 T:0xf5 RT=11 QB1:1/1/1024 +--->X | CON PUT /path M:0x06 T:0xf5 RT=11 QB1:1/1/1024
+--->X | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024 +--->X | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024
[[NSTART(3) limit reached]] [[NSTART(3) limit reached]]
|<---------+ ACK 0.00 M:0x05 |<---------+ ACK 0.00 M:0x05
+--------->| CON PUT /path M:0x08 T:0xf7 RT=11 QB1:3/1/1024 +--------->| CON PUT /path M:0x08 T:0xf7 RT=11 QB1:3/1/1024
|<---------+ ACK 0.00 M:0x08 |<---------+ ACK 0.00 M:0x08
| ... | | ... |
[[ACK_TIMEOUT (client) for M:0x06 delay expires]] [[ACK TIMEOUT (client) for M:0x06 delay expires]]
| [[Client retransmits packet]] | [[Client retransmits packet]]
+--------->| CON PUT /path M:0x06 T:0xf5 RT=11 QB1:1/1/1024 +--------->| CON PUT /path M:0x06 T:0xf5 RT=11 QB1:1/1/1024
[[ACK_TIMEOUT (client) for M:0x07 delay expires]] [[ACK TIMEOUT (client) for M:0x07 delay expires]]
| [[Client retransmits packet]] | [[Client retransmits packet]]
+--->X | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024 +--->X | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024
|<---------+ ACK 0.00 M:0x06 |<---------+ ACK 0.00 M:0x06
| ... | | ... |
[[ACK_TIMEOUT exponential backoff (client) delay expires]] [[ACK TIMEOUT exponential backoff (client) delay expires]]
| [[Client retransmits packet]] | [[Client retransmits packet]]
+--->X | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024 +--->X | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024
| ... | | ... |
[[Either body transmission failure (acknowledge retry timeout) [[Either body transmission failure (acknowledge retry timeout)
or successfully transmitted.]] or successfully transmitted.]]
Figure 18: Example of CON Request with Q-Block1 Option (Blocks Figure 18: Example of CON Request with Q-Block1 Option (Blocks
Recovery) Recovery)
It is up to the implementation as to whether the application process It is up to the implementation as to whether the application process
skipping to change at page 45, line 36 skipping to change at page 46, line 36
| ... | | ... |
| [[Observe triggered]] | [[Observe triggered]]
|<---------+ CON 2.05 M:0xe8 T:0xf0 O:1236 ET=23 QB2:0/1/1024 |<---------+ CON 2.05 M:0xe8 T:0xf0 O:1236 ET=23 QB2:0/1/1024
| X<---+ CON 2.05 M:0xe9 T:0xf0 O:1236 ET=23 QB2:1/1/1024 | X<---+ CON 2.05 M:0xe9 T:0xf0 O:1236 ET=23 QB2:1/1/1024
| X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024 | X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024
[[NSTART(3) limit reached]] [[NSTART(3) limit reached]]
|--------->+ ACK 0.00 M:0xe8 |--------->+ ACK 0.00 M:0xe8
|<---------+ CON 2.05 M:0xeb T:0xf0 O:1236 ET=23 QB2:3/0/1024 |<---------+ CON 2.05 M:0xeb T:0xf0 O:1236 ET=23 QB2:3/0/1024
|--------->+ ACK 0.00 M:0xeb |--------->+ ACK 0.00 M:0xeb
| ... | | ... |
[[ACK_TIMEOUT (server) for M:0xe9 delay expires]] [[ACK TIMEOUT (server) for M:0xe9 delay expires]]
| [[Server retransmits packet]] | [[Server retransmits packet]]
|<---------+ CON 2.05 M:0xe9 T:0xf0 O:1236 ET=23 QB2:1/1/1024 |<---------+ CON 2.05 M:0xe9 T:0xf0 O:1236 ET=23 QB2:1/1/1024
[[ACK_TIMEOUT (server) for M:0xea delay expires]] [[ACK TIMEOUT (server) for M:0xea delay expires]]
| [[Server retransmits packet]] | [[Server retransmits packet]]
| X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024 | X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024
|--------->+ ACK 0.00 M:0xe9 |--------->+ ACK 0.00 M:0xe9
| ... | | ... |
[[ACK_TIMEOUT exponential backoff (server) delay expires]] [[ACK TIMEOUT exponential backoff (server) delay expires]]
| [[Server retransmits packet]] | [[Server retransmits packet]]
| X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024 | X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024
| ... | | ... |
[[Either body transmission failure (acknowledge retry timeout) [[Either body transmission failure (acknowledge retry timeout)
or successfully transmitted.]] or successfully transmitted.]]
Figure 19: Example of CON Notifications with Q-Block2 Option Figure 19: Example of CON Notifications with Q-Block2 Option
It is up to the implementation as to whether the application process It is up to the implementation as to whether the application process
stops trying to send this particular body of data on reaching stops trying to send this particular body of data on reaching
 End of changes. 29 change blocks. 
84 lines changed or deleted 105 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/