TCP adaptation with network coding and opportunistic data forwarding in multi-hop wireless networks

8 Opportunistic data forwarding significantly increases the throughput in multi-hop wireless mesh networks by utilizing the broadcast nature of wireless transmissions and the fluctuation of link qualities. Network coding strengthens the robustness of data transmissions over unreliable wireless links. However, opportunistic data forwarding and network coding are rarely incorporated with TCP because the frequent occurrences of out-of-order packets in opportunistic data forwarding and long decoding delay in network coding overthrow TCP’s congestion control. In this paper, we propose a solution dubbed TCPFender, which supports opportunistic data forwarding and network coding in TCP. Our solution adds an adaptation layer to mask the packet loss caused by wireless link errors and provides early positive feedbacks to trigger a larger congestion window for TCP. This adaptation layer functions over the network layer and reduces the delay of ACKs for each coded packet. The simulation results show that TCPFender significantly outperforms TCP/IP in terms of the network throughput in different topologies of wireless networks. 9


Opportunistic data forwarding with network coding
Studies show that network coding can reduce the data packet collision and approach the maximum

103
In MORE, the source node divides data packets from the upper layer into batches and generates coded 104 packets of each batch. Similar to ExOR, packets in MORE are also forwarded based on a batch. The 105 destination node can decode these coded packets to original packets after receiving enough independently 106 coded packets in the same batch. The destination receives enough packets when the decoding matrix 107 reaches the full rank, then these original packets will be pushed to the upper layer. MORE coordinates the 108 forwarding of each node using a transmission credit system, which is calculated based on how effective it 109 would be in forwarding coded data packets to downstream nodes. This transmission credit system reduces  which data packets are not required to be divided into multiple batches or to be encoded separately in 130 each batch. In SlideOR, the source node encodes packets in overlapping sliding windows such that coded 131 packets from one window position may be useful towards decoding the packets inside another window 132 position. Once a coded packet is 'seen' by the destination node, the source node only encodes packets 133 after this seen packet. Since it does not need to encode any packet that is already seen at the destination, 134 SlideOR can transmit useful coded packets and achieve a high throughput. between relaying nodes based on bandwidth of wireless links, and they used an intra-flow network coding 153 solution modelled by means of Hidden Markov Processes. However, the schemes above were designed to 154 utilize opportunistic data forwarding and network coding, but none of these was designed to support TCP.

216
To better support TCP with opportunistic data forwarding and network coding, TCPFender inserts the TCP We make two important changes to improve the network coding process of MORE for TCP transmis-240 sions. For a given batch, the source does not need to wait until the last packet of a batch from the TCP 241 before transmitting coded packets. We call this accumulative coding. That is, if k packets (k < β ) have 242 been sent down by TCP at a point of time, a random linear combination of these k packets is created and 243 transmitted. Initially, the coded packets only include information for the first few TCP data segments of 244 the batch, but will include more towards the end of the batch. The reason for this "early release" behaviour 245 is for the TCP receiving side to be able to provide early feedback for the sender to open up the congestion 246 window. On the other hand, we use a deeper pipelining than MORE where we allow multiple batches 247 to flow in the network at the same time. To do that, the sending side does not need to wait for the batch 248 acknowledgement before proceeding with the next batch. In this case, packets of a batch are labeled 249 with a batch index for differentiation, in order for TCP to have a stable, large congestion window size 250 rather than having to reset it to 1 for each new batch. The cost of such pipelining is that all nodes need to 251 maintain packets for multiple batches. The design of the destination adaptation layer is shown on the right of Fig. 1. The network coding 296 module has two functions. First, it will check whether the received TCPFender data segment is innovative 297 or not. In either case, it will notify the ACK signalling to generate a TCPFender ACK. Second, it will 298 deliver original TCP data segments to TCP layer if one or more original TCP data segment are decoded 299 after receiving an innovative coded data packet. This mechanism can significantly reduce the decoding 300 delay of the batch-based network coding. On the other hand, TCPFender has its own congestion control 301 mechanism, so TCP ACK that is generated by the TCP layer will be dropped by the ACK signalling 302 module at the destination.

Forwarder adaptation layer 304
The flow of data at forwarders is shown in the middle of Fig. 1. The ACK is unicast from the destination 305 to the source by IP forwarding, which is standard forwarding mechanism and is not shown in the diagram.

306
The intermediate node receives TCPFender data segment from below and this segment will be distributed 307 into corresponding batches and regenerates a new coded TCPFender data segment. This new TCPFender 308 data segment will be sent to downstream forwarders via hop-by-hop IP broadcasting based on the credit

311
In this section, we investigate the performance of TCPFender through computer simulations using NS-2.

312
The topologies of the simulations are made up of three exemplar network topologies and one specific 313 mesh. These topologies are depicted in Fig. 2 "diamond topology", Fig. 3 "string topology", Fig. 4 "grid 314 topology", and Fig. 5 "mesh topology". The packet delivery rates at the physical layer for the mesh 315 topology are marked in Fig. 5, and the packet delivery rates for other topologies are described in Table. 1.

316
The source node and the destination node are at the opposite ends of the network. One FTP application   by opportunistic data forwarding, and the receiver side releases ACK segments whenever receiving 390 an innovative packet. In current work, we implemented our algorithm to support TCP Reno. In fact,

391
TCPFender can also support other TCP protocols with loss-based congestion control (e.g., TCP-NewReno,

392
TCP-Tahoe). The adaptive modules are designed generally enough to not only support network coding and 393 opportunistic data forwarding, but also any packet forwarding techniques that can cause many dropping 394 packets or out-of-order arrivals. One example will be multi-path routing, where IP packets of the same 395 data flow can follow different paths from the source to the destination. By simulating how TCP receiver 396 will signal the TCP sender, we are able to adapt TCPFender to functioning over such the multi-path 397 routing without having to modify TCP itself.

398
In the simulation results, we compared TCPFender and TCP/IP in four different network topologies.

399
The result shows that TCPFender has a sizeable throughput gain over TCP/IP, and the gain will be very 400 distinct from each other when the link quality is not that good. We also discussed the influence of batch 401 size on the network throughput and end-to-end packet delay. In general, the bath size has a small impact 402 on the network throughput, but it has direct impact on end-to-end packet delay.

403
In future, we will consider TCP protocols with RTT-based congestion control and also analyze how 404 multiple TCP flows interact with each other in a network coded, opportunistic forwarding network layer, 405 or a more generally error-prone network layer. We will refine the redundancy factor and the bandwidth 406 estimation to optimize the congestion control feedback of TCP. Finally, we will propose a theoretical 407 model of TCP with opportunistic forwarding and network coding, which will enable us to study the 408 TCPFender as a function in various communication systems.