Wireless TCP

This paper essentially addresses the problem of using TCP over lossy wireless networks by comparing the available proposed solutions to this situation and extensions to TCP. These are split into three categories: 1) link-layer solutions, 2) connection-splitting solutions, and 3) E2E solutions. The link layer solutions attempt to do reliability at the link layer. Connection splitting solutions split the connection in to two pieces, allowing the base station to send ACKs upon receiving packets, and then making sure that the base station reliably transmits the data to the wireless nodes. E2E solutions simply modify the TCP behavior at the end nodes.

There are a lot of different methods of improving TCP performance. Among them are: SACKs (selective acknowledgements). Selective acknowledgements let the sender know exactly which packets were received, so as to avoid unnecessarily resending data. There is also explicit loss notification, which (as the name suggests) explicitly notifies the sender when a packet has been lost. This is advantageous because it helps the sender differentiate between losses that occur because of congestion and losses that occur because of noise in the link.

Other methods include retransmitting on the first duplicate ack, which is beneficial for lossy networks, where a loss is most likely to be due to noise rather than congestion. The final method is duplicate ack suppression at base stations, which gives the base station some time to retransmit the packet before it forwards the duplicate acks to the endpoint; this means that the endpoint will not decrease its congestion window when a non-congestion loss occurs, thereby keeping the throughput high.

As it turns out, the best method turns out to be a link-layer method that both suppresses duplicate acks at the base station and uses SMART based selective acknowledgments. This is called a TCP-aware algorithm because it must understand the meaning of the acknowledgements in order to work.

There's not much more to say about this paper other than the fact that there may be some overhead in determining that the connections being created are, in fact, TCP connections. It would be interesting to run the same experiments with both TCP and UDP and to determine how much overhead is involved in examining the packets. It might also be interesting to run some similar experiments with protocols that use NACKs instead of ACKs.