The world is awash with proposals to improve the venerable TCP/IP protocol. The latest, from researchers at the University of Cincinnati, addresses shortcomings in the protocol's behaviour on wireless networks.
Since wireless, rather than a coloured Ethernet cable, is the default connection for most devices, how WiFi handles TCP/IP is a key component of network performance. However, as the researchers from the University of Cincinnati's Centre of Distributed and Mobile Computing write, the combination of a lossy physical layer and TCP/IP's congestion control algorithms can hamper performance.
The proposal put forward by the university's Yang Chi and Dharma Agrawal is dubbed TCP-Forward.
As an example of how TCP congestion control can get in the way of network performance, the paper cites a broadcast of two packets to multiple receivers: if one of the receivers misses a packet, the whole sequence will be retransmitted to everyone. Network coding algorithms (such as random linear network coding) have been put forward to solve this, but they put a decoding load on the receiver, which is fine if the receiver has both the processing and battery power to handle it, but is less optimal in the world of mobile phones or low-power Internet of Things devices.
TCP-Forward is built on the prior work done in a protocol called TCP-Vegas, which uses the round trip time (RTT) to help decide whether a network is experiencing congestion or packet loss.
TCP-Forward maintains throughput as packet loss rises
To TCP-Vegas, TCP-Forward adds Fountain Codes, which are already present in protocol stacks such as IEEE 802.11n, CDMA2000, EV-DO, 3GPP and 10GBase-T Ethernet. The paper explains: “instead of using a feedback channel to notify the source if the sent data successfully arrives at the destination, redundancy is introduced to make sure the destination node can get the original data even if the transmission channel is lossy.”
TCP-Forward, they write, is also useful in multi-hop wireless networks, because only the receiver (and not intermediate nodes) needs to worry about packet decoding:
“Redundancy is introduced at the sender to provide reliability, but explicit acknowledgements are still sent by the receiver. However, different from regular TCP congestion control algorithms, this acknowledgement is only used to move the coding window, which in turn slides the TCP congestion window. Duplicate acknowledgements will not incur TCP to reduce its transmission rate, nor will it change any parameters used in the congestion avoidance algorithms in TCP.”
The result, they say, is a protocol that can maintain better throughput than protocols like TCP-Reno or TCP/NC (network coding) in the presence of packet loss, while at the same time maintaining far better latency than TCP/NC solutions because of its lower processing overhead (particularly in handling larger packets). ®