# Performance of the Transport Layer Security Handshake Over 6 TiSCH
## 5 Performance Enhancing Proxy for TLS/TCP  
Even though TCP's adaptive retransmission algorithm is a clear improvement over the static timers used in DTLS (see Figure 7) it is still oblivious of the fragmentation occurring at the 6 LoWPAN layer and the additional RTT this incurs. The latter can cause spurious retransmissions which are particularly expensive in constrained networks. In the experiments presented in Section 3, we solve this issue by dropping the initial _synack_ segment during the TCP handshake. It causes a retransmission of the _synack_ segment but opens the connection with a more conservative fallback RTO value of 3 s instead of 1 s [29]. It ensures that TCP does not start with round-trip time (RTT) estimation that is too aggressive, triggering needless retransmits during the TLS handshake. It is not possible to easily change the initial TCP RTO from user space. Updating this value in the code would require the recompilation of the Linux kernel.  
To solve the problem in a more elegantly, we use a TCP Performance Enhancing Proxy (PEP) [11]. PEPs are a commonly used technique to accelerate TCP connections over satellite links without tampering with the TCP implementation details. It operates as follows:  
1. The PEP intercepts a TCP connection before the segments are sent to the satellite, and it terminates the connection as if the interceptor is the intended destination. It immediately sends an acknowledgment back to the original sender.
2. It forwards the TCP segments further to the actual destination, but it accounts for the specifics of the satellite link, notably a long RTT.
3. In case of segment loss, the PEP takes care of retransmissions.  
For the original TCP endpoints, the TCP PEP remains transparent. In a 6 TiSCH network, the PEP can be cohested with the network gateway (root). The network gateway intercepts the TCP connection and quickly generates acknowledgments for segments originating from the Internet, thereby preventing retransmissions due to fragmentation-induced latency. Since the network gateway is aware of the specifics of the 6 TiSCH network, it can calculate a novel RTT, which takes into account the fragmentation rate and the allocated bandwidth in the 6 TiSCH network. We implement the TCP PEP in OpenVisualizer and assess its performance, see Table 3.  
We notice that the TLS handshake takes one second less to complete compared to Table 2. Since the PEP acknowledges the segments coming from the server, we no longer need to drop the initial _synack_ to force TCP to use a more conservative initial RTO. Surprisingly, the TLS handshake even completes faster than the DTLS handshake, even though it exchanges more bytes in total. However, the initial DoS protection of DTLS immediately triggers 6 LoWPAN fragmentation and adds reassembly delays, while the TCP handshake packets are small and quickly traverse the 6 TiSCH network. DTLS' MTU is also larger--1041 B vs. 864 B--which again causes more delays during fragment reassembly. The TCP acknowledgments are small and do not require fragmentation. It limits their impact on the overall duration of the handshake. We can conclude that DTLS spends a significant  
\begin{table}
\begin{tabular}{l c c c c c c} \hline \hline \multirow{2}{*}{**SSL**} & **Negotiated** & \multirow{2}{*}{**MTU [B]**} & **Latency [s]** & \multicolumn{2}{c}{**Bytes [B]**} & \multirow{2}{*}{**Nagle**} \\  & **MSS** & & \(\mu\) & \(\sigma\) & \(\mu\) & \(\sigma\) \\ \hline \multirow{2}{*}{TLS} & 844 & 864 & 3.323 & 0.125 & 3098 & 2.13 & ✓ \\  & 844 & 864 & 3.209 & 0.083 & 3359 & 1.15 & - \\ \hline \hline \end{tabular}
\end{table}
Table 3: Performance-enhancing proxy and TLS.  
amount of time waiting for all the 6 LoWPAN fragments because of the high fragmentation rate of the UDP datagrams.