A basic assumption of TCP is that retransmission only happens due to congestion. It fundamentally assumes a perfect channel, which is why wireless connectivity doesn't play well with it. There have been many attempts to fix this but they require changes in both the AP and the client, so I don't think anyone has really bothered to implement in common hardware yet.
A large part of the wifi stack is in software and these things have in fact been implemented already, at least on linux, it is just that deployment is lacking.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
This is a not a basic assumption of TCP. TCP's inability to differentiate between problems due to congestion vs problems due to noisy or lossy channels is based on the assumption that the link-layer protocol operates independently of higher-layer protocols IP, TCP, etc.
Wireless generally handles the retransmissions on a lower layer (802.11 and cellular data connections both do it), so TCP doesn't see lost packets.
(Of coursee with bad wireless connections you get complete cut outs completely so that even link layer retransmissions won't work)
If there was a lot of room for improvement in TCP here, other protocols would have done them and probably modern TCP would have incorporated them in turn.
> A basic assumption of TCP is that retransmission only happens due to congestion.
From the perspective of a single computer, what's the difference between an error caused by congestion and an error caused by a noisy channel? Can you tell the difference? Isn't a transmission error just a transmission error?
In the case of wireless comms though, that may just increase lag, as the packet may have been lost just because of physical issues and a swift re-trnasmit could be the best option.
This really falls down not to TCP but IP and the protocols below it. TCP if for when a packet get’s lost somewhere along the line not for transmission errors over a wireless channel.
There is a SACK (selective acknowledgement) TCP extension which allows a receiver to say in more detail which packets have been received, to handle reordering more efficiently. But even so, network engineers try hard to avoid anything that can cause reordering: for instance, ECMP (equal cost multipath) balances traffic load across multiple links using a hash of the TCP quadruple to ensure that each flow follows a consistent path.