-
Notifications
You must be signed in to change notification settings - Fork 0
Week 1 Synopsis
Here we summarise the papers we have listed to be read as a part of the Week 1 checklist.
The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. One of the main design goals of CoAP was to keep message overhead small thus limiting the need for message fragmentation. CoAP which easily translates to HTTP for integration with the existing Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments and M2M applications.
Some of the key features of CoAP include:
- UDP binding with optional reliability supporting unicast and multicast requests.
- Asynchronous message exchanges.
- Low header(header size 4 bytes) overhead and parsing complexity
- URI and Content-type support.
- Simple proxy and caching capabilities.
- A stateless HTTP mapping.
- Can provide security when used with Datagram Transport Layer Security(DTLS).
A CoAP request is equivalent to that of HTTP and is sent by a client to request an action (using a Method Code) on a resource (identified by a URI) on a server. CoAP defines four types of messages: Confirmable, Non-confirmable, Acknowledgement, Reset.
Reliability is provided by marking a message as Confirmable (CON). A Confirmable message is re-transmitted using a default timeout and exponential back-off between re-transmissions until the recipient sends an Acknowledgement message (ACK) with the same Message ID. When a recipient is not at all able to process a Conformable message, it replies with a Reset message (RST).
A message that does not require reliable transmission can be sent as a Non-confirmable message (NON). When a recipient is not able to process a Non-confirmable message, it may reply with a Reset message (RST). CoAP also supports Piggybacking. Whenever the response is available immediately, it is sent along with the ACK. Otherwise, the response is sent separately. It is important to note that, a NON request is always responded with a NON response.
CoAP makes use of GET, PUT, POST, and DELETE methods in a similar manner to HTTP.
The CoAP message format starts with a fixed-size 4-byte header. This is followed by a variable-length Token value, which can be between 0 and 8 bytes long. Following the Token value comes a sequence of zero or more CoAP Options in Type-Length-Value (TLV) format, optionally followed by a payload that takes up the rest of the datagram. A CoAP message looks like:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver| T | TKL | Code | Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token (if any, TKL bytes) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1| Payload (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Here the 8 bit code talks about the class of message. A message could be either of the classes, request (0), a success response (2), a client error response (4), or a server error response (5). Code 0.00 indicates an Empty message. All Code values are assigned by sub-registries according to the following ranges (as described in section 12.1):
- 0.00 :- Indicates an Empty message.
- 0.01-0.31 :- Indicates a request. Values in this range are assigned by the "CoAP Method Codes" sub-registry.
- 1.00-1.31 :- Reserved.
- 2.00-5.31 :- Indicates a response. Values in this range are assigned by the "CoAP Response Codes" sub-registry.
- 6.00-7.31 :- Reserved.
Message ID is a 16-bit field used to identify the message and hence provide reliability and duplicate detection.
CoAP messages are exchanged asynchronously between CoAP endpoints. CoAP messages may arrive out of order, appear duplicated, or go missing without notice. It has the following features to ensure reliability:
- Simple stop-and-wait re-transmission reliability with exponential back-off for Confirmable messages.
- Duplicate detection for both Confirmable and Non-confirmable messages.
Re-transmission is controlled by two things that a CoAP endpoint MUST keep track of for each Confirmable message it sends while waiting for an acknowledgement (or reset): a timeout and a re-transmission counter. And, recipients of Acknowledgement and Reset messages must not respond with either Acknowledgement or Reset messages. If the re-transmission counter reaches MAX_RETRANSMIT on a timeout, or if the endpoint receives a Reset message, then the attempt to transmit the message is cancelled and the application process informed of the failure.
A CoAP endpoint that sent a Confirmable message may give up in attempting to obtain an ACK even before the MAX_RETRANSMIT counter value is reached. For example, the application has cancelled the request as it no longer needs a response, or there is some other indication that the CON message did arrive. Another reason for giving up re-transmission may be the receipt of ICMP errors.
An Acknowledgement or Reset message is related to a Confirmable message or Non-confirmable message by means of a Message ID along with additional address information of the corresponding endpoint.
CoAP also mandates that the recipient should acknowledge each duplicate copy of a Confirmable message using the same Acknowledgement or Reset message but should process any request or response in the message only once.
CoAP provides a basic Congestion Control mechanism by using Exponential Back-off time for re-transmissions. In order not to cause congestion, clients (including proxies) must strictly limit the number of simultaneous outstanding interactions that they maintain to a given server (including proxies) to NSTART. An outstanding interaction is either a CON for which an ACK has not yet been received but is still expected (message layer) or a request for which neither a response nor an Acknowledgment message has yet been received but is still expected. After EXCHANGE_LIFETIME, a client stops expecting a response to a Confirmable request for which no acknowledgement message was received. CoAP places the onus of congestion control mostly on the clients.
The advantages of the CoAP over MQTT have been well explained here.
Annotated CoAP RFC [RFC7252] can be found here.
(Source - https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=7509394)
-
The traffic patterns for IoT networks is different from that of conventional networks, because:
- Every IoT device sends a small amount of data periodically to notify the server. Congestion could be caused due to a large number of sensors.
- All the sensors could be triggered to send notifications simultaneously due to the occurrence of a special event.
-
Why not default CoAP Congestion: CoAP's default Congestion Control is not suitable for the dynamic networks like IoT. CoCoA uses the Network Status info which is already available to CoAP and provides better RTO(Retransmission Timeout) estimations. Every CON is retransmitted 4 times before declared as a failed transmission. Initially, a random value in [2, 3] is chosen. Then, Binary Exponential Backoff(BEB) is applied. Some reasons why this idea is not suitable for IoT networks:
- The RTO is not based on any estimate of RTT(Round Trip Time). So, if RTO < RTT, then spurious retransmissions are possible.
- CoAP is used in lossy networks(Bit Error Rate is high). So, very low values of RTO will lead to a lot of idle time.
-
Performance(CoCoA) >= Performance(Base CoAP), for all traffic scenarios
-
CoCoA comprises of - Adaptive RTO, RTO Aging, variable backoff factor (VBF)
-
Adaptive RTO: Uses exponentially weighted moving average(EWMA) of RTTs. In conventional networks, packet losses are only attributed due to network congestion, but in IoT networks packet losses also happen due to high BER.
- Strong RTT: RTT for a message that received an ACK before the sender went for retransmissions.
- Weak RTT: Messages that required atmost two retransmissions. These are necessary because there are a lot of packet losses.
Strong and Weak RTO is defined in a corresponding manner. They have a distinct set of constants used in EWMA. Reference for EWMA - RFC 6298
The tunable constants in the Weak RTO calculation are chosen such that a new weak-RTO value will not influence the Overall-Weak-RTO by a large margin. This is inorder to avoid over-estimation of the RTO due to a few extreme datapoints.
Weak RTO contributes 25% to the overall RTO. The information provided by Strong RTO is more reliable than weak RTO. Initial values of RTO is chosen within the interval of [RTOOverall, 1.5 * RTOOverall].
Variable Backoff Factor (VBF): What's the issue with having one factor of multiplication?? - If the initial value of RTO is small, then the exponentiation does not provide enough time for the network to recuperate. Instead, the network will be flooded with packets due to the small values of RTO and causes spurious retransmissions. - If the initial value of RTO is large, then multiplying it by a large number causes a lot of idle time and wastage of network resources.
These values were obtained empirically.
Initial RTO < 1 ===========> VBF = 3
Initial RTO > 3 ===========> VBF = 1.5
1 < Initial RTO < 3 =======> VBF = 2
RTO Aging: RTO values become stale, if not calculated for a long time. This is because network conditions change very rapidly. If RTO is very small( < 1 sec) or large ( > 3 sec), and if not new RTT measurements have been made for 16(for a small RTT) or 4(for a large RTT) times the current RTT respectively, then the RTT is reset to the initial default value.
-
CoCoA restricts 1 NON message for every RTO. But the base CoAP doesn't place any limit on the number of NON messages. More on this issue - A. Betzler, C. Gomez, and I. Demirkol, “Evaluation of Advanced Congestion Control Mechanisms for Unreliable CoAP Communications,” Proc. 12th ACM Symp. Performance Evaluation of Wireless Ad Hoc, Sensor, & Ubiquitous Networks, Cancun, Mexico, Nov. 2–6, 2015, pp. 63–70.
-
Memory Footprint: CoCoA needs an order of magnitude higher memory per CoAP client. But this increase is much less than the memory used by components of CoAP like Datagram Transport Layer Security(DTLS).
tl, dr; In comparison to default CoAP, CoCoA increases throughput and reduces the time it takes for a network to process traffic bursts, while not sacrificing fairness. CoCoA consistently delivers a performance which is better than, or at least similar to, that of default CoAP
- In the base-CoAP congestion control, pipelined messages can never be sent, because the max number of outstanding interactions is restricted to 1. Is this modified in CoCoA ?? Are pipelined exchanges important for IoT networks for improving throughput??
(The document can be found here: https://tools.ietf.org/html/rfc8323)
CoAP (Constrained Application Protocol) is originally designed to be used over UDP. This document discusses the changes required to use CoAP over TCP.
Advantages of using CoAP over TCP instead of UDP are:
- Blocking of UDP packets by some of the networks, especially in the enterprise networks.
- Different NAT traversal behaviour between TCP and UDP. For example, the NAT binding timeout for UDP connections is usually smaller (160 seconds by default) than the timeout for TCP connections (386 minutes).
- Better flow control and congestion control mechanisms in TCP than in CoAP over UDP.
Larger packet sizes, more memory requirements and more round trips in TCP restrict the use of CoAP over TCP to only those regions where the network doesn't support UDP packets.
The request/response model interaction model of CoAP over TCP is the same as CoAP over UDP. The major difference lies in the message framing. Since UDP is a non-reliable protocol, CoAP had to introduce optional reliability by defining CON, NON, ACK and RST, along with Message ID to identify duplicate messages (refer to the above paper for more information).
CoAP over TCP modifies the framing mechanism to now utilise the byte stream provided by the TCP/TLS, which was previously on datagram transports provided by the UDP/DTLS. Also, since TCP is a reliable protocol, CoAP no longer has to support Acknowledgement messages or to detect duplicate messages.
CoAP Client CoAP Server CoAP Client CoAP Server
| | | |
| CON [0xbc90] | | (-------) [------] |
| GET /temperature | | GET /temperature |
| (Token 0x71) | | (Token 0x71) |
+-------------------------->| +--------------------------->|
| | | |
| ACK [0xbc90] | | (-------) [------] |
| 2.05 Content | | 2.05 Content |
| (Token 0x71) | | (Token 0x71) |
| "22.5 C" | | "22.5 C" |
|<--------------------------+ |<---------------------------+
| | | |
CoAP over UDP CoAP over reliable
transports
The format of the message in CoAP over TCP is similar to the format specified for CoAP over UDP. The differences are:
- The Type and the Message ID fields are removed from the CoAP message header.
- The Version field is removed as well. Currently, CoAP is defined with version number 1 [RFC 7252] and there is no known reason to introduce other version numbers.
- Since TCP is stream-oriented, we need to have a form of message delimitation. The Length field with variable size is introduced for this purpose.
The message field, after the suggested modifications, looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Len | TKL | Extended Length (if any, as chosen by Len) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Token (if any, TKL bytes) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1| Payload (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message field for CoAP over TCP
Len is a 4-bit unsigned integer. A value between 0 to 12 indicates the length of the message in bytes (starting from the Options field) while the last 3 values are reserved for special constructs. The encoding of the Len field is present as Length Options field in the CoAP Options.
Third basic kind of messages, signal messages, are introduced only for CoAP over reliable protocols. This is for the peers to:
- Learn related characteristics, such as maximum message size for the connection.
- Shut down the connection in an orderly fashion.
- Provide diagnostic information when terminating a connection in response to a serious error condition.
Signalling messages share a common structure with the existing CoAP messages. There are a code, a Token, options, and an optional payload.
-
Signaling Codes and Options: A code in the 7.00-7.31 range indicates a Signaling message. Option Numbers for Signaling messages are specific to the message code.
-
Capabilities and Settings Messages (CSMs): One CSM MUST be sent by each endpoint at the start of the Transport Connection. They are used for two purposes:
- Each capability option indicates one capability of the sender to the recipient.
- Each setting option indicates a setting that will be applied by the sender.
Common CSM options are:
- Max-Message-Size Capability Option: Used by the sender to indicate the maximum size of a message in bytes that it can receive
- Block-Wise-Transfer Capability Option: Used by the sender to indicate that it supports the block-wise transfer protocol [RFC7959].
-
Ping and Pong Messages: Generally used as a keepalive function. Upon receipt of a Ping message, the receiver MUST return a Pong message with an identical Token in response as soon as possible.
- Custody Option: When responding to a Ping message, the receiver can include the Custody Option in the Pong message which indicates that the application has processed all the request/response messages received prior to the Ping message
-
Release Message: A Release message indicates that the sender does not want to continue maintaining the Transport Connection and opts for an orderly shutdown, but wants to leave it to the peer to actually start closing the connection. The peer responding to the Release message should delay the closing of the connection until it has responded to all requests received by it before the Release message.
-
Abort Message: An Abort message indicates that the sender is unable to continue maintaining the Transport Connection and cannot even wait for an orderly release. The sender shuts down the connection immediately after the Abort message. Abort messages can indicate one or more reasons using the CoAP Options.
Implementation: In the TKL field, if the value is of the form 0xe(y) (where y is in range 1 to 5) it is a Signaling message of the code 7.0(y).
+------+---------+-----------+
| Code | Name | Reference |
+------+---------+-----------+
| 7.01 | CSM | RFC 8323 |
| | | |
| 7.02 | Ping | RFC 8323 |
| | | |
| 7.03 | Pong | RFC 8323 |
| | | |
| 7.04 | Release | RFC 8323 |
| | | |
| 7.05 | Abort | RFC 8323 |
+------+---------+-----------+
CoAP Signaling Codes
TLS Binding for CoAP over TCP: The TLS guidelines for Internet of Things [RFC 7925] applies here, including the guidance about cipher suites in that document that are derived from the mandatory-to-implement cipher suites defined in [RFC 7252].