## 6 Implementation and Evaluation
### Performance Evaluation
#### 6.3.2 Congestion Control Optimizations  
An important aspect of group communication is congestion control, especially in LLN where resources are limited. Network congestion can lead to extended response times and significant energy consumption, due to frequent retransmissions of packets. CoAP provides basic congestion control by using the exponential back-off mechanism (Section 2.1) and by limiting the number of open requests from a client to any server to one request by default. Furthermore, CoAP specifies that, when using multicasts, a certain random delay should be inserted before forwarding the request to other nodes. In CoAP terms, this delay is called Leisure. The server could either use a default value for Leisure or compute a value for it. If the server has a group size estimate G, a target data transfer rate R and an estimated response size S, a rough lower bound for Leisure can then be computed as:  
\[Leisure_{lowerbound}=\frac{S*G}{R} \tag{2}\]  
When only taking into account the 1-hop neighbours of the gateway in our test network in Figure 16, G equals 5, S equals approximately 80 bytes, and the target rate can be set to a conservative 8 kbit/s = 1 kB/s. The resulting lower bound for the Leisure is then equal to 0.4 s. However, since CoAP servers will often not be able to compute the Leisure, we elected to use the default Leisure value (5s) in all of our multicast experiments. For a more complete discussion of the Leisure period and its estimation we refer to Section 8.2 of [5]. CoAP does not specify a congestion control mechanism when a single client is communicating with many servers using unicasts as is the case in our group communication solution. However our experience shows that this can quickly lead to congestion. A simple solution for avoiding network congestion when using unicasts is to limit the rate at which requests are sent. In order to examine this, we conducted a series of experiments to query an entity of five members and measure the response time, which is expressed as the time between the moments the client issues the request to the EM until it gets back the response. We repeated the same experiment for different delays between the requests sent from the EM to the members. We repeated the experiment 50 times for each setting and computed the averages. The same set of experiments was repeated when all members were either one or two hops away and while using null-rdc or Xmac. As expected, the experiments revealed that the average response time of an entity can be improved by inserting small delays between the requests for individual entity members (Figure 17). However, the best delay depends on both the topology and the used MAC protocol. This is most obvious in the graph of Xmac for 1-hop communication. Here one observes two peaks at about 100 ms and 400 ms. The first peak is a result of collisions between the forwarded requests from the nodes at the first hop to the nodes at the second hop with the delayed requests for the next member. The second peak is a result of collisions between the replies from the members at the second hop with the delayed requests for the next member. For delays less than 0.5 s the used MAC protocol had more effect on the response time than the delay inserted between the requests. However as the delay between requests grows larger it becomes the dominating factor for the total response time with a linear relationship between the two. In the remaining experiments we used only null-rdc as MAC protocol for two reasons. First, we wanted to avoid measuring the delays in communication as imposed by the use of Xmac. Second, Xmac does not support multicast well, and thus we would not have been able to make a fair comparison between our group communication solution and multicast based solutions. For the star topology which we used in most of our experiments, a delay of about 50 ms provided the best response when null-rdc was used. As a result we have used a 50 ms delay between requests to the members in all other experiments discussed later in this section.