I've heard before that TCP is a really awful fit for mobile. So shouldn't there be a general replacement for TCP on mobile? Everybody inventing their own custom fix does not sound like the most efficient way to solve this problem.
> So shouldn't there be a general replacement for TCP on mobile?
But what would this magical protocol do differently that would make it work better?
In my opinion, most of TCP's semantics arise not out of the network, but rather the data itself. I can't have packets getting lost in the middle of an SSH session: it just doesn't make sense. My keystrokes are a stream of data that must be in order, and must be delivered: thus TCP.
I commute daily, and use 4G on my commute. Another poster has problems very similar to mine[1]:
> As an aside, these days it's worth noting that a 3G, WLAN or 4G link layer will try very hard not to drop any packets. So when you're doing UDP, watch out for those 40000 millisecond old packets that will burst to your lap once the rain cloud moves away from the cell tower
You can see this just by pinging 8.8.8.8 in the background. The loss of good signal will result in many packets getting dropped, but then when signal resumes, ping will receive the packets that it had presumed lost, and you'll get things like:
64 bytes from 8.8.8.8: icmp_seq=65 ttl=46 time=37324.3 ms
64 bytes from 8.8.8.8: icmp_seq=66 ttl=46 time=36324.3 ms
64 bytes from 8.8.8.8: icmp_seq=67 ttl=46 time=35324.3 ms
64 bytes from 8.8.8.8: icmp_seq=68 ttl=46 time=34324.3 ms
... and so on ...
From which you can tell that they were buffered somewhere, and then when the signal cleared up, basically transmitted quickly and cleanly. But it makes you wonder if TCP connections then receive a flood of duplicate packets (the original + the resends); I've not watched wireshark closely enough to see.
For all the ads make you think speed is the determining factor in who has the better 4G, I'd say simple packet loss or connectivity loss makes much more of a difference to me day-to-day. "Coverage", you might call it, except typically according to the phone there is a signal, it is 4G, but the strength is just so poor as to be unusable. I use an app to get this info (the bars in the corner just aren't fine-grained enough), and it reports things like "Net. type: NSDPA * 7.2 Mbps", and that'd be okay, except: "Net strength: -99 dBm * 7 ASU" — too low for connectivity; in my experience, I require >-80 dBm for actual data to transmit successfully. (Ping packets to round trip, etc.)
> In my opinion, most of TCP's semantics arise not out of the network, but rather the data itself. I can't have packets getting lost in the middle of an SSH session: it just doesn't make sense. My keystrokes are a stream of data that must be in order, and must be delivered: thus TCP.
Mosh[1] is basically (a better) SSH over UDP. It fares a lot better than SSH on mobile connections. It does away with hanging connections and such nonsense.
A big problem for TCP with mobile is that when packets get lost, TCP assumes there's a lack of bandwidth, and throttles the throughput. On mobile, it's more likely it just got lost, and needs to be resent as soon as possible. TCP doesn't do that. It waits. TCP connections deteriorate on mobile.
