Boffins brew TCP tuned to perform on lossy links like Wi-Fi networks 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 …
"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:"
I think I see a problem here... (hint for non-network people: TCP is very strictly point-to-point not broadcast).
In fairness I couldn't find the word broadcast in the original paper, on the story.
It's the radio transport layer that needs the forward error correction applied when the signal gets ropey, sort it locally where there is information about signal strengths and error rates rather than have the TCP stack compensate for a problematic link that could be thousands of miles away.
No. Fixing it at layer 2 (or 3) is much worse than fixing it at layer 4. Actually the successful work at MIT on coded TCP proves this very neatly. If you detect errors at layer 2 (which is by definition hop-by-hop, not end-to-end) then a burst of bit errors followed by layer 2 retransmission (which is very common on a radio link) will result in a dramatic increase in the transfer time for a packet. This is a common problem on WiFi or 4G connections. Vanilla TCP will see a dramatically increased RTT, mistake this for congestion, and slow down as a result. Your performance goes down the tubes. That's why the MIT people figured out how to switch off layer 2 retransmission to get their factor 20 gain in throughput (Google "coded tcp" to find the evidence). The work reported in this story seems to be along the same lines.
Retries are bad, especially if the round trip time is long. Better is to increase the forward error correction to compensate for the radio link quality as it adds a much smaller overhead to both the local radio channel and the long distance fibre links, keeping the retry rates down. WiFi needs more of the redundancy coding goodness developed for LTE.
These studies often only consider their own data throughput, selfishly grabbing bandwidth at the expense of other users sharing the same links. TCP/IP was carefully designed to allow efficient sharing of limited bandwidth, and that is where many of these proposals fail.
That's why the MIT people figured out how to switch off layer 2 retransmission to get their factor 20 gain in throughput (Google "coded tcp" to find the evidence). The work reported in this story seems to be along the same lines.
It is along the same lines - the "TCP/NC" in the graph and article is TCP using Network Coding, which I believe is what you're referring to. This latest paper uses Fountain Coding instead, to reduce the computational complexity of decoding at the receiver, for two reasons: to accommodate receivers that have scarce CPU resources1, and to reduce latency caused by decoding2.
1Whether they need to use the CPU sparingly to reduce power consumption (mobile) or just don't have much of a CPU in the first place (IoT).
2Network Coding decoding involves solving a relatively difficult mathematical problem - Gaussian elimination in a Galois finite field - for each received message. There are various fountain codes, but e.g. Raptor codes (RFCs 5053, 6330) can also be decoded by Gaussian elimination, but less compute-intensive alternatives are available.
"I was thinking the same - why is the wifi base station not able to cache a half second or so of recent packets and re-transmit them as needed as part of a wifi protocol?"
It does. The default is 7 retransmissions of unacknowledged packets. Wifi is a harsh mistress, despite the retransmission mechanism it still has some degree of packet loss, particularly under poor RF conditions.
Wont [sic] work through firewalls or other network security devices
Citation needed.
In fact, from the paper:
The intermediate nodes do not have to be aware of the existence of the coding algorithms at the transport layer and do not have to take part into encoding or decoding.
Their proposal is transparent to intermediate nodes.
I realize actually looking at the paper before posting a vapid comment is above and beyond the call of duty, but it'd save you from looking like a fool.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
