# A Survey on Congestion Control for RPL-Based Wireless Sensor Networks
## 5 Discussion
mOFQS adapts to the number of instances in the network depending on their criticality level by tuning its parameters accordingly. Performance of OFQS was evaluated using 67 client (M3) nodes and one server on FIT IoT-LAB testbed. OFQS was compared to RPL with MRHOF/ETX for critical traffic and OF0/HC for periodic traffic. Experimental results show that OFQS achieves better end-to-end delay, PDF, network lifetime, and load balancing. Although using multiple RPL instances has not been the most active research topic, it is worth further investigating how to exploit multiple instances in order to meet different QoS requirements of heterogeneous applications while achieving load balancing. In [7], the authors state that to use multiple instances, one needs to consider implementation complexity and resource constraints of embedded nodes, but that it should be changed with modern devices that have more memory. We expect that the aforementioned emergence of powerful embedded nodes will be able to make multiple instances more viable. **Relationship between TCP and RPL. ** In the traditional WSN literature, it was widely accepted that the transport layer protocol must consume resources minimally; therefore, TCP was not considered as a good candidate. However, as IPv6-based LLNs have become prevalent, TCP has been spotlighted. According to the TCP usage guideline in IoT [60], one of the main reasons why TCP is considered for use in constrained node networks is that UDP-based communications may be limited or blocked in existing infrastructures. TCP designed for LLNs has been very limited in several aspects. For instance, BLIP TCP of TinyOS allows sender-side buffering for retransmission, but does not provide receiver-side buffering and sets the receive window to one MSS. [PERSON] et al. investigated mutual influence between TCP and RPL through empirical tests on an IPv6-based LLN testbed [61]. For LLN endpoints, they used BLIP TCP and TinyRPL, which selects a parent based on uplink ETX. They found that TCP performance may degrade if RPL does not consider traffic load balancing. As powerful low-power embedded devices with more processing power and larger memory space have become readily available [55], [PERSON] et al. claim that commodity LLN hardware has crossed a critical resource threshold to run full-scale TCP [62]. To show that a full-scale TCP can fit well within CPU and memory constraints of modern WSN platforms, they implemented a full-scale TCP, called TCPlp [62], leveraging the full-featured TCP in FreeBSD OS. According to their findings, another factor that makes a full-scale TCP viable is that in an LLN, a small window size is sufficient to fill the bandwidth-delay product and to achieve good TCP performance. They also showed that TCPlp achieves high throughput while consuming power comparably to CoAP which is an LLN-specialized protocol. The emergence of a full-scale TCP for LLNs calls for extensive studies on interaction between RPL and TCP. For instance, interoperability of multipath RPL schemes with TCP will likely be an interesting research topic, because out-of-order packets often have a negative impact on TCP goodput due to the fast retransmit mechanism. **Cross-layer based efforts. ** In [7], the authors argue that cross layer interoperability and/or performance optimization are not optional but mandatory to apply RPL in reality, given that RPL is designed for an LLN which is often a standalone network. As discussed in Section 3, several RPL schemes adopt cross-layer based approaches to congestion control and load balancing. Since the RPL schemes are focused on how to improve congestion control in a hop-by-hop manner, most of them interoperate with the lower layers. However, RPL should also interoperate with the transport layer to enhance end-to-end congestion control.