One document matched: draft-li-core-coap-patience-option-03.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY COAP PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-core-coap.xml'>
<!ENTITY COAPOBS PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-core-observe.xml'>
<!ENTITY COAPMISC PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bormann-coap-misc.xml'>
]>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<rfc
category="std"
ipr="trust200902"
docName="draft-li-core-coap-patience-option-03">
<front>
<title abbrev="CoAP Patience Option">
CoAP Option Extension: Patience
</title>
<author initials="K." surname="Li" fullname="Kepeng Li">
<organization abbrev="Huawei Technologies">Huawei Technologies</organization>
<address>
<postal>
<street>Huawei Base, Bantian, Longgang District</street>
<city>Shenzhen</city>
<region>Guangdong</region>
<code>518129</code>
<country>P. R. China</country>
</postal>
<email>likepeng@huawei.com</email>
</address>
</author>
<author initials="B." surname="Greevenbosch" fullname="Bert Greevenbosch">
<organization abbrev="Huawei Technologies">Huawei Technologies</organization>
<address>
<postal>
<street>Huawei Base, Bantian, Longgang District</street>
<city>Shenzhen</city>
<region>Guangdong</region>
<code>518129</code>
<country>P. R. China</country>
</postal>
<email>bert.greevenbosch@huawei.com</email>
</address>
</author>
<author initials="E." surname="Dijk" fullname="Esko Dijk">
<organization abbrev="Philips Research">Philips Research</organization>
<address>
<postal>
<street>High Tech Campus 34</street>
<city>Eindhoven</city>
<country>The Netherlands</country>
</postal>
<email>esko.dijk@philips.com</email>
</address>
</author>
<author initials="S." surname="Loreto" fullname="Salvatore Loreto">
<organization abbrev="Ericsson">Ericsson</organization>
<address>
<postal>
<street>Hirsalantie 11</street>
<city>Jorvas 02420</city>
<country>Finland</country>
</postal>
<email>salvatore.loreto@ericsson.com</email>
</address>
</author>
<date day="04" month="December" year="2013" />
<area>Applications</area>
<workgroup>core</workgroup>
<abstract>
<t>
CoAP is a RESTful application protocol for constrained nodes and
networks. This specification provides a simple extension for
CoAP, the Patience option. This option informs a recipient of the preferred time frame for a
request or response depending on usage context. In a unicast request, it indicates the patience
a client has in waiting for a response. The CoAP server tries to return
the response within the specified time frame. In a multicast request,
it indicates the patience a server should have in sending its response.
The recipient would then try to randomly delay its response within the time frame
that the requester indicated or computed by the recipient itself.
In a CoAP observe notification, it indicates the patience an
observer should have in both waiting for a subsequent notification and in
re-establishing an observation relation.
</t>
</abstract>
<note title="Note">
<t>
Discussion and suggestions for improvement are requested, and should
be sent to core@ietf.org.
</t>
</note>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>
This specification adds a new option Patience to CoAP <xref target="I-D.ietf-core-coap" />.
The main purpose is for the requester to inform the recipient of the preferred time frame for a
response. In the unicast request case, it is used to indicate the patience it has in waiting for
a response. It then indicates "a response is most
useful within the specified time frame". In the multicast request case, it
indicates the patience that a server should have in sending a response.
In other words, it indicates "if possible please delay your response
by a randomly chosen time within the specified time frame".
A second purpose is for use by a server when sending CoAP observe <xref target="I-D.ietf-core-observe" />
notifications, to indicate the maximum time an observer should wait (i.e. patience
of the observer) before starting any observation relationship recovery.
</t>
<section anchor="just" title="Justification">
<t>
In the unicast case, it is useful for the requester (client) to indicate that
the response is required to be returned within a certain amount of time.
For example, the requester could require a response within 2 seconds,
otherwise the response is not of interest anymore.
With this indication of the patience for a response,
the requester knows how long it should wait for the response, and it
needs to keep the state of the request only for the indicated
time. After this period, the request will be given up. It can avoid that
the recipient wastes resources by sending a
response which already exceeds the set patience timeout of the requester.
</t>
<t>
In the multicast case, if a server decides to respond to a multicast
request, it should not respond immediately.
Instead, it should pick a
duration for the period of time during which it intends to respond.
The length of this period is called the Leisure,
and defined in <xref target="I-D.ietf-core-coap"/>.
The same document specifies how to compute the a rough lower bound for Leisure,
as well as the DEFAULT_LEISURE.
A Patience option, if present, can be used
as an upper bound for the Leisure,
i.e. the server SHOULD respond before the time frame indicated by Patience has been exceeded.
</t>
<t>
In an observe scenario, it is useful for a server to indicate to an observer that,
after the period of time in the Max-Age option has expired, a new notification will be sent
within the time interval indicated by the Patience option. The server may use this to
send notifications with a dithered delay i.e. randomly chosen within the Patience-specified
time interval, when there are many CoAP clients simultaneously observing a resource on the server,
avoiding network congestion issues. Another use is for the server to delay sending a new
notification because e.g. the resource has not changed. The observer in this case can
assume that the server will do its best to deliver a notification at least before the Patience
time interval runs out.
</t>
<t>
If the Patience option is combined with Observe option in a request,
currently it indicates the maximum time an observer is prepared to wait for an
initial notification.
</t>
</section>
<section anchor="terms" title="Terminology">
<t>
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 <xref target='RFC2119' />.
</t>
</section>
</section>
<section anchor="Patience" title="Patience Option Extension">
<section anchor="Definition" title="Patience Option Definition">
<texttable>
<ttcol align="left">No.</ttcol>
<ttcol align="left">C</ttcol>
<ttcol align="left">U</ttcol>
<ttcol align="left">N</ttcol>
<ttcol align="left">R</ttcol>
<ttcol align="left">Name</ttcol>
<ttcol align="left">Format</ttcol>
<ttcol align="left">Length</ttcol>
<ttcol align="left">Default</ttcol>
<c>28</c>
<c></c>
<c></c>
<c>x</c>
<c></c>
<c>Patience</c>
<c>see below</c>
<c>1 B</c>
<c>(none)</c>
</texttable>
<t>
The value carried in the Patience Option is in a specific format
resembling a pseudo-Floating Point value
(as in <xref target="I-D.bormann-coap-misc"/> Appendix B.2):
<figure>
<artwork>
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| T | TX|
+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</t>
<t>
T = Time
</t>
<t>
TX = Time Exponent
</t>
<t>
where the patience time is calculated as:
</t>
<t>
Patience time = 2^(TX * 4 + 3) * T
</t>
<t>
The value of the Patience option is calculated in milliseconds or
alternatively mibiseconds (1/1024s) if this would ease numerical
operations on above values on constrained platforms.
The minimum non-zero patience time is 8ms, when TX=0, T=1 and a milliseconds
time base is used. The maximum
patience time is then 2064384ms, around 34 minutes, when TX=3 and T=63.
</t>
<t>
The Patience option is "elective". It MUST NOT occur more than once.
</t>
</section>
<section anchor="Usage" title="Using the Patience Option">
<t>
The semantics of the Patience Option depends on its usage context,
as detailed in below sections.
</t>
<section anchor="Unicast" title="Unicast usage">
<t>
In the unicast case, this option is used by a CoAP client to indicate
the maximum time a requester is prepared to wait for a response.
</t>
<t>
The requester adds the Patience option to any request
for which it is prepared to wait for a response.
The requester sets the option to the maximum time that it is
prepared to wait.
</t>
<t>The Patience option applies to both piggy-backed response
and separate response. For a separate response, the patience
applies to the actual response after the ACK. ACK should
be sent immediately upon receipt of the CON message.
</t>
<t>
TBD: In case a requester retransmits a request, the Patience Option value
MAY be decreased by an amount of time equivalent to the time since the
previous transmission attempt. In case a requester did not receive
an ACK to a confirmable request and a time interval of at least the
interval indicated in the Patience Option of the request has passed,
the requester SHOULD give up the request.
</t>
<t>
The recipient interprets this option as the maximum time between receipt
of the complete request and the time that it begins
sending the response.
The requester will observe a longer time interval
between request and response, as network transit and processing by
proxies add delays.
If timing is critical,
the requester SHOULD consider the possible delays and choose the value
for the option accordingly.
</t>
<t>
The recipient MAY apply a lower value to the patience timeout based on
local policy. A recipient MAY choose to take longer to produce
a response, at the risk that the requester is no longer able to use the
response.
</t>
<t>
In case that the CoAP message is transmitted through a proxy,
the Proxy MAY reduce the value of a Patience option
based on a local policy (e.g. to consider the maximum time that
an idle connection is kept open by a local NAT or Firewall).
A Proxy MAY add a Patience
option if none is present. The value in the Patience option
MUST NOT be increased or removed.
</t>
<t>
If the requester does not receive a response
within the indicated response time, the requester SHOULD consider the
request as failed.
If the recipient can't provide a response within the required time, the
recipient SHOULD discard the request.
</t>
</section>
<section anchor="Multicast" title="Multicast usage">
<t>
In the multicast case, Leisure is defined in
<xref target="I-D.ietf-core-coap" /> to work as a duration for
the period of time during which a server intends to respond to a
multicast request. The Patience option in a CoAP request can be
used as an upper bound for the Leisure.
</t>
<t>
How to use Leisure is defined in <xref target="I-D.ietf-core-coap" />.
</t>
</section>
<section anchor="Observer" title="Observe usage">
<t>
In a CoAP observe <xref target="I-D.ietf-core-observe" /> scenario,
the Patience Option MAY be used in a notification
to indicate the maximum time an observer should wait before starting any
observation relationship recovery.
</t>
<t>
The Max-Age Option indicates the maximum time a response (notification) may be cached
before it MUST be considered stale. The Max-Age Option of a notification
is usually set to a value that estimates when the server will send the
next notification. However, in the case the value has not changed,
the server can decide not to send a new notification, possibly confusing the
observer. It is quite difficult for an observer to
discriminate the situation that it has not received a new notification
because the value has not changed from situations where the server
has lost its state, or for some reason has given up on notification delivery.
</t>
<t>
The Patience Option in a notification is used to indicate the maximum
time a server will try to reach the client before giving up. This is
to save the client some effort in re-establishing observation
relationships each time max-age is reached.
This option is also useful to give a server the time to send out
the notifications, in case there are many CoAP clients observing
simultaneously a resource, while avoiding network congestion issues.
</t>
<t>
The server adds the Patience option to any notification related to an
observation relationship from which it wants delay an observation refresh
request made by the observer. The server sets the option to the maximum time that it is prepared
to spend to reach the observer before giving up.
</t>
<t>
The observer interprets this option as the minimum time between the expiration
of a notification (as indicated by its Max-Age Option value) and the moment it
MAY start an observation relationship recovery action with the server.
</t>
<t>
If the observer does not receive a response within the indicated time
interval, the observer SHOULD attempt to re-establish the observation relationship
with the server if it is still interested in observing the particular resource.
</t>
</section>
</section>
<section anchor="Detection" title="Detection of IP unicast or multicast CoAP request">
<t>
A single Patience Option, used to indicate potentially either client
patience (in the IP unicast case) or server patience (in the IP multicast case),
requires that a CoAP server is able to distinguish between IP unicast
and multicast requests. If there exist commonly used IP stacks that
do not offer such functionality [to be checked], requiring servers to
be able to make the unicast/multicast distinction seems unwise and
limits the applicability of the Patience Option.
</t>
<t>
Approaches for a CoAP server to detect unicast versus multicast
requests may include:
</t>
<t>
1) CoAP server application opens a specific socket and sets IP
multicast reception using the POSIX setsockopt function [to be
verified if IP unicast traffic also is received in this case,
or not].
</t>
<t>
2) CoAP server checks the IP destination address of incoming
packets. If this has the FF00::/8 IPv6 prefix, then it's treated
as multicast otherwise unicast [to be verified if IP stack APIs
allow to get IP destination].
</t>
<t>
3) Receiving CoAP multicast requests always occurs on a different
port than the standard CoAP port. For example, similar to
coaps:// that uses a different port than coap://, a scheme
coapm:// on a different port may be defined for multicast requests.
</t>
</section>
</section>
<section anchor="example" title="Example">
<section anchor="UnicastExample" title="Unicast Usage Example">
<t>
This section gives a short example with a message flow that
illustrates the use of the Patience option in a GET request.
</t>
<t>
This example (<xref target="PatienceExample"/>) shows that the
requester wants to get a response within 3200 milliseconds, when
T=25, TX=1.
</t>
<figure title="Patience Option in a unicast request" anchor="PatienceExample">
<artwork> <![CDATA[
requester recipient
| |
| |
+----->| Header: GET (T=CON, Code=1, MID=0x7d38)
| GET | Token: 0x53
| | Patience: 25/1
| | Uri-Path: "temperature"
| |
|<-----+ Header: 2.05 Content (T=ACK, Code=69, MID=0x7d38)
| 2.05 | Token: 0x53
| | Payload: "22.3 C"
| |
]]>
</artwork>
</figure>
</section>
<section anchor="ObserverExample" title="Observe Usage Example">
<t>
This section gives a short example with a message flow that
illustrates the use of the Patience option in an Observe
notification.
</t>
<t>
This example (<xref target="ObserveExample"/>) shows that the
server wants the observer to wait 819 seconds (T=25, TX=3)
before starting any observation relationship recovery, even though
the Max-Age of the temperature value notification is only 120 seconds.
</t>
<figure title="Patience Option in an observe notification" anchor="ObserveExample">
<artwork> <![CDATA[
Observer Server
| |
| |
+----->| Header: GET (T=CON, Code=1, MID=0x7d38)
| GET | Token: 0x53
| | Observe: 0
| | Uri-Path: "temperature"
| |
|<-----+ Header: 2.05 Content (T=ACK, Code=69, MID=0x7d38)
| 2.05 | Token: 0x53
| | Max-Age: 120
| | Patience: 25/3
| | Payload: "22.3 C"
| |
]]>
</artwork>
</figure>
</section>
</section>
<section anchor="security" title="Security Considerations">
<t>
This presents no security considerations beyond those in
section 10 of the base CoAP specification
<xref target="I-D.ietf-core-coap" />.
</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>
The IANA is requested to add the following "CoAP Option Numbers" entry
as per Section 11.2 of <xref target="I-D.ietf-core-coap"/>.
</t>
<texttable>
<ttcol align="left">No.</ttcol>
<ttcol align="left">C</ttcol>
<ttcol align="left">U</ttcol>
<ttcol align="left">N</ttcol>
<ttcol align="left">R</ttcol>
<ttcol align="left">Name</ttcol>
<ttcol align="left">Format</ttcol>
<ttcol align="left">Length</ttcol>
<ttcol align="left">Default</ttcol>
<c>28</c>
<c></c>
<c></c>
<c>x</c>
<c></c>
<c>Patience</c>
<c>(ref to this document)</c>
<c>1 B</c>
<c>(none)</c>
</texttable>
</section>
<section anchor="acknowledgement" title="Acknowledgements">
<t>
The authors of this draft would like to thank the participants of the
email discussion on this issue.
Thanks to Carsten Bormann, Peter Bigot, Barry Leiba, Linyi Tian for
the reviews and discussions.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&COAP;
&COAPOBS;
</references>
<references title="Informative References">
&COAPMISC;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 20:48:48 |