Skip to content

Solution Ideas

Jump to bottom
H.L Praveen Raj edited this page Oct 28, 2018 · 29 revisions

This section summarises our view of the problem and the solution ideas that we have. This page also provides the challenges that we face, doubts and queries that we have on each of the ideas.

IDEAS

IDEA 1: Implement ECN like mechanism in CoAP

Summary of the Idea:

The objective of this idea is to use the ECN notification packages for better calculation of RTT and RTO. The implementation of this mechanism would be in the application layer, unlike the traditional transport layer implementation of ECN. Here the end-point would be setting the ECN bits of the ACK or RST or the response packets, if it is experiencing congestion or is not able to process the packets fast enough or when some other errors and difficulties are experienced. The ECN notifications could also be used as a flow-control mechanism, since CoAP has none.

It is important to note that, unlike ECN notifications which are sent by the intermediate routers, the solution mechanism discussed here mandates the ECN notifications to be sent from by the end-points alone. This is because the routers have access only to the network layer and transport layer information of the packets and not to the application layer information and it is in the Application layer that the ECP bits are set (since CoAP header where they are set, is part of Application layer).

Challenges:

  • Accommodating the 2 ECN bits in the CoAP header is the major difficulty since it is just 4 bytes long and is fit completely. Even though it is true that only few of the bits of Code field in the header are being used today, the others are reserved and are difficult to obtain for our use. We could work around this problem using the Options field.
  • Detection of congestion at the Application layer.
  • Implementation of flow-control at the Application layer.
  • Changing the existing methods of RTT and RTO calculation to use the ECN notifications.
  • When, how and for which type of requests should the ECN notification be sent?

Doubts and queries:

  • Would this mechanism work with the current policies of CoAP for declaring a communication to have failed?
  • Why is there no flow-control mechanism in CoAP?
  • What have been the difficulties in implementing a flow-control mechanism in CoAP?
  • Why is a separate mechanism (the ECN notifications) required at the Application layer for RTT calculation, when we already have ACK and RST packets?
  • To what extent would this mechanism help in congestion control?

IDEA 2: Implement ECN in UDP

Summary of the Idea:

CoAP is an application layer protocol, and traditionally it works with UDP as the transport layer protocol. Since ECN is implemented in the transport layer and the network layer, we think of implementing it in UDP. This would work similar to ECN with TCP and would help in congestion control.

Challenges:

  • UDP has a fully packed 8 byte header, hence it would be impossible to accommodate the 2 bits, that ECN requires, in the UDP header. Hence we would have to look into some other ways to accommodate the 2 bits, for instance, by using hashing or xor or some other type of encoding.
  • Implementation of Congestion control in UDP using ECN notifications.

Doubts and queries:

  • Does our approach require any changes in the routing protocols?
  • Are the 2 extra bits really required?

This section summarises the solution method we came up with for incorporating ECN with CoAP. It portrays the incremental development in the solution.

SOLUTION

Date : October 13

TODO :

Figure out a way to accommodate ECN notification bits in CoAP header

Solution:

The ECN notification bits can be accommodated in the CODE field of the CoAP header. Presently the CODE field values 1.00 to 1.31, 6.00 to 6.31 and 7.00 to 7.31 are reserved and unused.

We did not go with the idea of using the OPTION field bits for this purpose because of the importance it carries and the community's ethic toward it.

TODO :

Figure out which type of messages would have ECN notifications.

Solution :

We think that it is logical to have ECN notifications only for those messages which require reliable transmission. And since the only type of message that provides reliable transmission in CoAP is Confirmable message (CON), only CON messages will have the ECN notifications.

TODO :

Figure out way to let each end point know that the other end point in ECN capable or not

Solution:

Since only every message (from the application) is fragmented and sent as a series of packets, it is safe to assume that each message (from the application) transmitted is fragmented into at least 2 packets at the CoAP level. Hence the first packet of the bunch can carry the information about the ECN capability of Host A to Host B and the ACK to this packet from Host B could carry the ECN capability of Host B and this would be similar to the ECN initialisation. Since CoAP follows Stop and Wait for the CON packets, which implies any other packet of the message (from the application) will be able to use the ECN initialisation data obtained from the first packet transmission, this solution would work.

Challenges & Doubts:

  • How to have ECN initilisation when the first packet itself experiences congestion?
  • Is it necessary to solve the issue of "first packet itself experiencing congestion"?

Discovery :

Core CoAP messages must be small enough to fit into their link-layer packets (~ 64 KiB for UDP) but, in any case the RFC states that:

  • it SHOULD fit within a single IP packet to avoid IP fragmentation (MTU of 1280 for IPv6). If nothing is known about the size of the headers, good upper bounds are 1152 bytes for the message size and 1024 bytes for the payload size; or less to avoid adaptation layer fragmentation (60-80 bytes for 6LoWPAN networks);
  • if you need to transfer larger payloads, this IETF draft extends core CoAP with new options for transferring multiple blocks of information from a resource representation in multiple request-response pair (so you can transfer more than 64KiB per message).

Hence the given solution works only for a few CoAP transmissions since most of them are non fragmented messages.

Date : October 19

TODO :

Figure out way to let each end point know that the other end point in ECN capable or not

Solution :

From the "discovery" above, we understand that almost all the messages (from the application) are sent without fragmentation. Hence the solution discussed earlier won't work. We also note that unlike TCP we cannot have 3 way handshake in CoAP. Thus the only way to have ECN in CoAP would be iff the Host A already knew about the ECN capabilities of the Host B.

We also note that, CoAP is a protocol that is mostly implemented in a constrained IOT environment. Generally, each CoAP node communicates with only a few, finite number of, CoAP nodes.

So the solution for this problem would be to store the ECN capabilities of each of the possible destination CoAP nodes in the host. And since the number of destination nodes is very few, the amount of memory required for this is very small. Let the data-structure used for this storage be called ECN capabilities table.

TODO :

Figure out a way to have ECN capable communication using the ECN capability info of each host.

Solution :

The CoAP Header is used for communicating the ECN capability of the host, acknowledgement of the congestion (ECN-Echo) and CWR flag. The IP Header is used for congestion notifications as suggested in RFC 3168.

The steps in each CoAP communication between Host A and Host B would be as follows :

  • Host A receive the message to be sent to Host B, from the application.
  • Host A checks in its ECN capabilities table to see if Host B is ECN capable or not. If Host B is ECN capable then Host A sets the ECN bits in both the IP header and the CoAP header and sends the packet. If the Host B is not ECN capable, then Host A sets the ECN bits only in the CoAP header and not in the IP header and sends the packet.
  • Host B on receiving the message, sends the acknowledgement. In the ACK, Host B sets the ECN bits in the CoAP header to signify its ECN capabilities. If the CON message header said that Host A was ECN capable, Host B sets the ECN bits in IP header of the ACK packet else IP header is not touched. Host B also updates its entry of Host A in the ECN capabilities table, using the info about the ECN capability of Host A in the CON CoAP header.
  • Host A upon receiving the ACK, updates its entry of Host B in the ECN capabilities table, using the info about the ECN capability of Host B in the ACK CoAP header.

The hosts do not set ECN bits in the IP Header for retransmissions even if both the hosts are ECN capable in order to avoid DoS attacks. But the ECN bits of CoAP header are always set to signify the ECN capabilities of the Hosts.

The above mentioned steps for communication is for a Peer-to-Peer architecture. It the architecture were to be a Server-Client architecture, then the Host B (which here is the server), would not need to have an ECN capabilities table since it could just use the info in the CoAP header itself. But the Host A (which here is the client) needs to always have the ECN capabilities table.

Challenges and Doubts :

  • How and when to set the CWR flag?
  • How to communicate and use the CWR flag?
  • How to set and communicate the ECN-Echo (ECE)?

Date : October 22

TODO :

Figure out way to let each end point know that the other end point in ECN capable or not

Solution :

The previously discussed idea involves the usage of a separate data-structure called ECN capabilities table, which would turn out to be memory intensive and won't be a scalable solution as the networks size increases.

Hence we think of not using the ECN capabilities table at all. The idea is as follows:

  • If a host is ECN capable then it always marks the packets originating from it to indicate that they are part of an ECN capable communication, irrespective of the ECN capabilities of the other end-point.
  • If a host is not ECN capable it never marks its packets, hence they would not be part of ECN capable communication.

The motive behind such bold marking is to help the IOT traffic to compete with the real Internet packets at congested situations, i.e in order to have IOT packets not dropped while competing with the internet traffic.

TODO :

Figure out a the complete steps of communication once ECN is enabled based on the above discussed ECN mechanism.

Solution :

The CoAP Header is used for communicating the ECN capability of the host and acknowledgement of the congestion (ECN-Echo). The IP Header is used for congestion notifications as suggested in RFC 3168.

Here we assume that we have two bits at the CoAP Header dedicated for ECN. Thus different ECN codepoints at the CoAP header would be

+-----+-----+
| ECN FIELD |
+-----+-----+
  ECT   CE        
  0     0         Not-ECN capable   
  1     0         ECN Capable and No Congestion         
  1     1         ECN Capable and Congestion

Here we note that, we do not require the 01 codepoint unlike the ECN at IP because at CoAP layer, there is no risk of corruption of ECN bits in middle-ware devices.

The steps of communication are as follows (here we assume that HOST A and HOST B are the two end-points):

  • When a HOST is not ECN capable:

    • It sets the ECN field at the CoAP header to 00 and sets the ECN field at the IP header to 00 on all its packets.
    • It ignores any ECN notifications from the IP layer.

  • When a HOST is ECN capable:

    • It sets the ECN field at the IP header to 10(ECT-0) on all its response packets(except the ACK).
    • It sets the ECT bit at the CoAP header to 1(signifying that it is ECN capable) and sets CE bit at the CoAP header to 0 on the initial packet(i.e when it has received no congestion notification about the particular path).
    • If it knows that there is congestion in the path, then it sets the CE bit at the CoAP header to 1. It sets CE iff there was a notification from IP on the previous packet of the other HOST.
    • For the very next ACK packet, the ECN bits at IP header are set to 00 and the ECN bits at the CoAP header are set as discussed above.
    • For retransmissions, the ECN bits at IP header are set to 00(as per RFC 3168).
    • It ignores any notifications from the IP for packets with a different sequence number than what is required (i.e for the duplicate packets).

Detailed explanation of different communication scenarios:

  • When a HOST A is not ECN capable:

    • It sets the ECN field at the CoAP header to 00 and sets the ECN field at the IP header to 00 on all its packets.
    • It ignores any ECN notifications from the IP layer.
    • It responds(with either an ACK or a response message) to HOST B by setting ECN field at the CoAP header to 00 and setting the ECN field at the IP header to 00.

  • When HOST A is ECN capable and no congestion notification was received:

    • It sets the ECN field at the IP header to 10(ECT-0) on its response packets(except the ACK).
    • It sets the ECT bit at the CoAP header to 1(signifying that it is ECN capable) and sets CE bit at the CoAP header to 0 on its response packets to HOST B.
    • For the very next ACK packet to HOST B, the ECN bits at IP header are set to 00 and the ECN bits at the CoAP header are set to 10.

  • When HOST A is ECN capable and a congestion notification was received:

    • It sets ECN bits in the IP header to 10 on its response packet to HOST B.
    • Here it is important to note that, the congestion notification can be received only from the IP layer.
    • It sets the ECT bit at the CoAP header to 1 and CE bit at the CoAP header to 1 on its very next response packet to HOST B. It sets CE iff there was a notification from IP on the previous packet of HOST B.
    • For the very next ACK packet to HOST B, the ECN bits at IP header are set to 00 and the ECN bits at the CoAP header are set to 11.

For HOST B too, the communication steps are exactly similar.

Important details and subtleties to note:

  • At a HOST capable of ECN, for the retransmissions, the ECN bits at IP header must be set to 00(as per RFC 3168). This is done in order to prevent attacks that use sequence number spoofing, which would be a major problem at some nodes, if they do honor the IP's ECN notification for undesired-sequence-number packets.
  • At a HOST capable of ECN, the CoAP layer must ignore the ECN bits of CoAP header for packets with undesired-sequence-numbers. This is just a secondary protection mechanism, since RFC 7252 already mandates that duplicate message must be processed exactly once.
  • The HOST should ignore any notifications from the IP, for packets with a different sequence number than what is required or desired (i.e for the duplicate packets).

Date : October 27

TODO :

Figure out a way to accommodate ECN notification bits in CoAP header.

Solution :

The previous discussed idea of incorporating the ECN bits in the CODE field of the CoAP header would not work in the case of "separate response" messages because the response message itself would have a CODE and there can only be one CODE value sent at a time.

We have come to a conclusion that only 1 bit (specifically the CN bit) of information at the CoAP header is sufficient to send the congestion notification. This is because, an end-point does not need to know the ECN capabilities of the other end-point, since it marks all the packets ECN capable irrespective of the capabilities of the other end-point.

Since we have concluded that, we require only 1 bit of information, we will be sending this one bit in the TOKEN field in the following way:

  • We plan on using the TOKEN field for carrying the CN bit's information.
  • The current mechanism requires the response message to have the same TOKEN as the request, but our new mechanism would want the response message TOKEN to be either the same or the 1's compliment of that in the request message.
  • Case 1: If the CN bit need to be set (i.e. CN = 1), we will be responding with a TOKEN which is the 1's complement of that received in the request message.
  • Case 2: If the CN bit needs to be not set (i.e. CN = 0), we will be responding with a TOKEN which is exactly the same as that received in the request message.

Why should this work?

  • RFC 7252 mandates that every message must have a TOKEN value. Hence we can be sure to receive the CN information.
  • If the RESPONDING HOST is not ECN capable, then he would respond with the same TOKEN as that in the request message. The REQUESTING HOST would interpret it as no congestion experienced (CN=0), which is exactly what we intended.
  • If the RESPONDING HOST is ECN capable and there was congestion notification from IP, then he would respond with the a TOKEN that is 1's complement of that in the request message. The REQUESTING HOST would interpret it as congestion experienced (CN=1), which is exactly what we intended.
  • Hence, if the REQUESTING HOST receives a response with the same TOKEN as that in its request message, it would imply that, either the RESPONDING HOST is ECN not capable or that there was no congestion experienced.

How would this effect the current CoAP mechanisms?

  • This mechanism will not affect the current message send-receive mechanisms in any way. The current mechanism requires the response message to have the same TOKEN as the request, but our new mechanism would want the response message TOKEN to be either the same or the 1's compliment of that in the request message.
  • Assume that a ECN not capable host (REQUESTING HOST) is communicating with a ECN capable host (RESPONDING HOST) and there was congestion in the channel. Here even though the RESPONDING HOST is ECN capable, it won't complement the TOKEN bits because it will never get congestion notification from IP since the REQUESTING HOST would have marked the packet ECN incapable (i.e ECT=0 and CE=0 at the IP header). Hence REQUESTING HOST will receive a response just like before (TOKEN is the same as request).
  • RFC 7252 says that TOKEN is used as a protection against spoofing. Our mechanism is at least as safe as that in the RFC, since there is no indication at the CoAP header that tells that the packet is ECN capable transmission or not, implying that, any host who looks at this packet sees the TOKEN field just as a random string of bits, as in the mechanism in RFC. Only the end-point hosts understand the meaning of the TOKEN field and no one else does.

What is the disadvantage?

  • RFC 7252 says that TOKEN is used to distinguish between the responses of the concurrent requests (which were destined to the same host).
  • It also mandates that, the REQUESTING HOST must generate TOKEN in such a that, it does not match TOKEN of any other message already in the channel which is destined to the same host.
  • Since we use the TOKEN value and its 1's complement value in the response, a ECN capable REQUESTING HOST must generate TOKEN in such a that, it does not match either the TOKEN or the 1's complement of any other message already in the channel which is destined to the same host.
  • This implies that the maximum number of concurrent messages, in one RTT, reduces by half.
  • Since the TOKEN field is 8 bytes long, and since it is highly improbable that there would be 2^64 concurrent messages to the same host in one RTT, we think that our mechanism is a fairly good one. Moreover, 2^63 (the resulting, max number of concurrent requests) is still an extremely huge number.

TODO :

Provide a clear description of the steps of communication once ECN is enabled based on the above discussed ECN mechanism.

Solution :

The TOKEN field in the CoAP Header is going to used for communicating the acknowledgement of the congestion (ECN-Echo). The IP Header is used for congestion notifications as suggested in RFC 3168.

Here assume the presence of a virtual bit in the CoAP Header dedicated for ECN. Thus different ECN codepoints at the CoAP header would be:

+-----+-----+-------+
| ECN VIRTUAL FIELD |
+-----+-----+-------+
        CN        
        0      No Congestion experienced        
        1      Congestion experienced

Note:

In the following discussion,

  • REQUEST MESSAGES is used to signify requests and declarative message.
  • RESPONSE MESSAGES is used to signify responses, ACK and reset messages.
  • the expression "CN bit is 1" would mean that the TOKEN in the RESPONSE MESSAGE is the 1's compliment of that of the REQUEST MESSAGE; and
  • the expression "CN bit is 0" would mean that the TOKEN in the RESPONSE MESSAGE is same as that of the REQUEST MESSAGE.
  • if the expression "CN bit is 0" is used in the context of REQUEST MESSAGE, it means that a new TOKEN, satisfying the conditions discussed above, is set for the message.

The steps of communication are as follows (here we assume that HOST A and HOST B are the two end-points and that HOST A is the requester and HOST B is the responder):

  • When HOST is not ECN capable:

    • It sets the CN field at the CoAP header to 0 and sets the ECN field at the IP header to 00 on all its messages.
    • It ignores any congestion notifications from the IP layer.

  • When HOST is ECN capable:

    • It sets ECN field in the IP Header to 10 (ECT-0) on all its messages, except the ACK response message. for ACK messages, ECN field at the IP Header is 00 (RFC 3168).
    • It sets CN field in CoAP header to 0 on all its REQUEST MESSAGES (this happens in case HOST A).
    • It sets CN field in CoAP header to 1 on its RESPONSE MESSAGES (this happens in case HOST B), iff it received a congestion notification for the message it is responding to.
    • For retransmissions, the ECN bits at IP header are set to 00(as per RFC 3168).
    • It ignores any notifications from the IP for packets with a different sequence number than what is required (i.e for the duplicate packets).

Detailed description of different communication scenarios when HOST A is ECN capable.

  • Scenario 1: HOST A and HOST B are ECN capable and there was congestion experienced by the REQUEST MESSAGE sent by HOST A:
    • HOST B receives a congestion notification from the IP layer.
    • HOST B sets CN = 1 (in CoAP header) in the RESPONSE MESSAGE.

A pictorial representation of scenario 1

  • Scenario 2: HOST A and HOST B are ECN capable and there was no congestion experienced by the REQUEST MESSAGE sent by HOST A:
    • HOST B receives no congestion notification from the IP layer.
    • HOST B sets CN = 0 (in CoAP header) in the RESPONSE MESSAGE.

A pictorial representation of scenario 2

  • Scenario 3: HOST A is ECN capable and HOST B is not ECN capable and there congestion experienced by the REQUEST MESSAGE sent by HOST B:
    • HOST B receives a congestion notification from the IP layer, but does not understand what the notification means.
    • HOST B sets CN = 0 (in CoAP header) in the RESPONSE MESSAGE.

A pictorial representation of scenario 3

Important details and subtleties to note:

  • At a HOST capable of ECN, for the retransmissions, the ECN bits at IP header must be set to 00(as per RFC 3168). This is done in order to prevent attacks that use sequence number spoofing, which would be a major problem at some nodes, if they do honour the IP's ECN notification for undesired-sequence-number packets.
  • At a HOST capable of ECN, the CoAP layer must ignore the ECN bits of CoAP header for packets with undesired-sequence-numbers. This is just a secondary protection mechanism, since RFC 7252 already mandates that duplicate message must be processed exactly once.
  • The HOST should ignore any notifications from the IP, for packets with a different sequence number than what is required or desired (i.e for the duplicate packets).
Clone this wiki locally