Optimisation of transport layer protocol

The existing works targeting to solve the above-mentioned issues are categorised as follows:

ˆ Fast start up: Tuning the congestion window is a popular approach to speed up the slow start phase. In RFC 3390 [87], the initial cwnd is suggested to increase

from 3 to 10 and such fixed IW can bring at least 10% reduction of web load time when the network RTT is high [86]. Alternatively, more attention has been paid to enlarge the congestion windows dynamically rather than fixing it [88–90]. Zhang et al. proposed a TCP variant named TCP/SPAND which can improve the completion of TCP connection for short-lived flows [88]. It collects the network information to estimate the available resource. Based on these estimations, the TCP sender can determine an optimal cwnd size. On the other hand, the cwnd during the slow start phase can be also continuously adjusted assisted by the network information. For instance, sender can utilise the feedback on the path to detect the network congestion and periodically adjusts its pacing rate [25]. However, as the author pointed out, these traditional network-assistant algorithms always introduces new IP and TCP field to feedback the network parameters or require each router/other end host on the path can support performance detection, which is too complicate to be deployed. Additionally, these approaches only focus on small content (e.g. up to around 250KB [88]), assuming content only experience in slow start phase in a wired scenario [89] or directly set IW as a full rate without concerning its benefit and cost [90]. Such limitations make these techniques become impractical in today’s mobile internetwork, and given the matureness of MEC framework, the pure end-to-end approach has the potential to overcome the above limitations if necessary context-information can be obtained in a real-time manner. Another issue for slow start phase is how to avoid the potential burst and conges- tion when the congestion increases near to the bottleneck. A well-known solution is hybrid-slow-start algorithm [91] which has been widely adopted in today’s TCP versions on many commercial content platforms.

Traditionally, the slow start will terminate once it encounters a loss event which indicates the current congestion window slightly exceeds the existing network bot- tleneck. Hybrid-slow-start algorithm adds RTT variation as another metric. It traces the RTT variation during the content downloading, once it exceeds a pre- defined threshold (e.g. 0.125 of RTT), the slow start phase will elegantly stop without incurring any packet loss. The efficacy of this algorithm has been vali- dated in wired scenario but as figure out in [23], the detection of network bottleneck can be disturbed by the network fluctuation in mobile network. For instance, as mentioned in 2.2.3, the unavoidable RTT fluctuation and random packet loss can

force the TCP connection to prematurely exit the slow start phase. Consequently, this TCP connection will stay at congestion avoidance phase which only allows a more conservative congestion growth rate, leading to bandwidth under-utilisation and an eventual poor content downloading time.

ˆ Handling Head-of-line blocking: As a fundamental limitation of TCP proto- col, the approaches targeting to avoid HOL can be classified to two types: 1) with the assistant of network proxy [64] or 2) Replacing TCP with UDP protocol which does not rely on the in-sequence delivery [29]. Proxy-based approaches always separate the connections in the middle, isolating the loss path from each other. Holding the packets at network edge can shorter the retransmission path and in- telligently control the TCP flow to alleviate the network congestion (e.g. packet pacing), which can effectively minimise the negative effect of network loss. Addi- tionally, once the proxy can be deployed at all network edge, with client and server side connecting each other in parallel connections, the packet can be manipulated with artificial header which can enable the proxy to dynamically reschedule the packets upon a loss event [61]. On the other hand, seeking for the UDP based ap- proach can fundamentally address this issue. QUIC, proposed by Google, adds an acknowledgement mechanism on plain UDP socket with a novel sequence number management scheme. The lost packet will be pushed into current sender buffer with an increased unique sequence number and the transmission of other packets are totally not affected. It inherited the same congestion window algorithm as new RENO and CUBIC, and has been validated to outperform TCP under loss environment.

ˆ Handling Handshake delay: Utilizing the time period consumed during hand- shake to transfer a proper amount of data or eliminating the handshake phase are two directions to improve efficiency during connection establishment. As a typical example of the former, TCP fast open (TFO) [92] adds a TFO cookie in the first SYN packet and according to this newly added field, the server can save it and use it to identify the client. Then if the client wants to establish more connections with the server, both of the server and client can add DATA packet in the SYN and SYN ACK (see in Fig. 2.12). This method utilises bandwidth during the period of 3-way handshakes and on average it can reduce the web load time by 10% [92]. However, its limitation is that the client should be identified by the server before

it can send the DATA along with the control packet. It means if the user just registers on the mobile network and initiates its first connection to a website, this TCP fast open cannot be used. Regarding the latter approach, both QUIC and TLS 1.3 simplified handshake phase by caching the secured session information that can be utilised for a 0-RTT reconnection between client and server. Also, the latency required for first establishment of a connection is also reduced to 1 RTT due to the improved algorithms.