# Performance of the Transport Layer Security Handshake Over 6 TiSCH
## 4 Insights: The (DTLS Handshake over 6 TiSCH  
### Handshake Reliability  
The results obtained in the previous section show that the retransmission behavior of DTLS is ill-suited for constrained networks. First, both endpoints must be capable of estimating network latency correctly to set an appropriate static value for the retransmission timeout. The default DTLS timeout of 1 s is too aggressive in most scenarios. Estimating network latency in a 6 TiSCH network is tricky because it depends on the number of hops packets need to traverse, the density of the TSCH schedule (bandwidth), and the size of the packet. The 6 TiSCH network fragments large IPv6 packets into multiple 6 LoWPAN frames. The 6 TiSCH devices send each fragment in an available active slot in the TSCH schedule. A network with a depth of multiple hops, combined with a sparse schedule, induces high latency on an end-to-end connection. The constrained endpoint in the 6 TiSCH network should be aware of these factors impacting the RTT. An arbitrary DTLS endpoint on the Internet probably does not know that its messages will travel over a constrained 6 TiSCH network.  
Secondly, the cryptographic computations necessary to complete the handshake often take a long time on low-power devices, especially when they lack hardware acceleration. The RTT can significantly increase when constrained devices are computing the cryptographic functions, see Figure 7(a). Unless the Internet DTLS endpoint has a very conservative initial retransmission value for the DTLS handshake, the network and cryptographic latency will cause many spurious retransmissions. Since DTLS retransmits entire flights--which can easily reach more than 1000 B for flights four and five--this has dire consequences for the operation of the 6 TiSCH network.  
TLS relies on TCP to provide the necessary handshake reliability. TCP segments carry entire or partial TLS records, with each segment having its retransmission timer. Contrary to UDP, TCP uses acknowledgment packets in combination with its retransmission timers. The acknowledgments provide TCP with RTT estimation capability, see Figure 7(b). The  
Figure 8: Computational-intensive computations can cause spurious retransmissions during the DTLS handshake. TCP’s acknowledgments indicate that the TCP segment arrived correctly and no retransmission is necessary, even if a reply is not immediately received.  
retransmission timer is initialized at 1 s upon completion of the TCP handshake and gets updated throughout the connection lifetime. TCP's adaptive RTT estimation provides a significant advantage over the static timeout values of DTLS. However, the estimation happens on a per-segment basis and does not account for possible 6 LoWPAN fragmentation. Smaller TCP segments can traverse the TSCH network quickly since they do not require 6 LoWPAN fragmentation. Larger segments exhibit a much higher RTT due to 6 LoWPAN fragmentation. When multiple small TCP segments are followed by a large segment, the Retransmission Timeout (RTO) value is too aggressive and causes a spurious retransmission of the large segment. We can limit the impact of spurious retransmissions by activating TCP's SACK option [22]. The option is advantageous in a scenario where multiple TCP segments are on the wire, and segments successfully received are interleaved with segments lost. A receiver can then add one or more SACK blocks to its acknowledgment packet to precisely indicate which segments need retransmission.