## 5 IETF ROLL Working Group
### Research Challenges  
Since CoAP is not fully standardized yet, many related aspects remain to be examined before definite conclusions can be drawn. Some of these aspects are currently being researched and have been documented in Section 6.3. Some other aspects have been identified but no solutions were proposed yet. In this section we summarize the main aspects of the CoAP protocol where we think that extensive research is still needed. Although a few suggestions for congestion control were already proposed (see Section 6.3.2. ), we think that this area requires more research attention. The primary reason being that UDP is the main transport mechanism for CoAP. Unlike TCP, UDP does not provide any reliability mechanism or congestion control. CoAP has its own optional light weight reliability mechanism, but virtually no congestion control. Simple mechanisms for congestion control, that are optimized for LLNs and that take into account the limited amount of resources available on constrained devices are still lacking. Another research aspect is related to the MTU size. The IPv6 minimum MTU is 1,280 bytes, whilst the maximum MTU for IEEE 802.15.4 networks is 127 bytes. The 6 LoWPAN adaptation layer provides an efficient fragmentation method to allow the transmission of larger packets. However large packet sizes still sometimes impose a big problem to the receiving party. If the received message does not fit in the input buffer it could cause unpredictable effects on the receiving side, e.g., operating system restarting because of buffer overflow. For this reason, it can be useful to specify during the resource discovery sequence the maximum accepted length of the response message with the resource description [140]. If both parties support the block option, agreeing on the optimal block transfer size in a way that avoids fragmentation and assembly of the packet at the lower layers will possibly have a high positive impact on the overall performance. This is something that needs further research and experimentation. Security of the IoT remains a challenge despite the fact that several proposals have already been made to cover certain aspects of security. Issues such as secure distribution of encryption keys in LLNs still need to be explored. A basic mapping between HTTP and CoAP is well defined in the core CoAP draft. However since CoAP is by design highly extendable and new options are being regularly added, such extensions might impose new challenges to the HTTP/CoAP mapping. The same consideration also applies in general to all intermediaries, that need to be updated if they wish to understand new options as well (some basic information for intermediaries is contained in an option's option number, which allows intermediaries to correctly handle unknown options). Caching intermediaries have an even bigger challenge to find out and implement optimal caching strategies. Group communication in a LLN context still needs more attention as well. The use of multicast satisfies many group communication needs, but not all of them. Multicasts are transported unreliable and since LLNs are lossy by nature, many applications will opt not to use multicast if they want to make sure that their messages are indeed delivered. For example, if multicast is used to turn on all the lights in a room, it wouldn't be acceptable if one light stays off because it did not receive the multicast message. Alternatives to the use of multicasts might be needed for such use cases. Maybe status synchronization of resources can also be used in certain use cases to make sure that the message did indeed get through. The efficiency of such and other approaches need to be examined. Finally, some challenges are related to the fact that resources on constrained devices often need to be accessed by other machines as well as by humans. These two types of \"clients\" have somewhat contradictory requirements. Humans for example prefer easy to remember (and a bit lengthy) resource names, while M2M communication is better served by providing concise names.