TCP does have retransmission, but it was designed for networks with very low packet loss and where most packet loss is due to congestion, so it does not react quickly to packet loss and when multiple packets are lost it slows down dramatically. TCP typically uses an exponential backoff in re-transmission times to avoid exacerbating congestion.

When dealing directly with UDP, one can implement different application-level logic for dealing with packet loss: "NAK" packets, different backoff strategies, and even forward error correction.

Yes, I had the same confusion. There seems to be a standard for TCP over UDP [1]. But in general, I would assume that it does not help at all WRT any of the packet loss/latency problems posed by satellite links.

TCP is designed for encapsulation in IP, this is why it is called TCP/IP. And UDP is very similar to IP, only difference is that UDP gives you source and destination port numbers and a payload checksum, where IP only gives you a protocol numbers and non-checksummed data. None of these "features" is going to have any effect on how TCP is delivered.

So the only effect that use of TCP over UDP would have here is:

- increase the overhead used for headers, thereby decreasing the MSS (segment size)

- "cloak" the TCP traffic as UDP and thereby prevent any routers and/or middleboxes [2] from applying special treatment to TCP (i.e. traffic shaping, buffering etc.)

Maybe the latter effect is what made a difference for the link in question.

[1] https://tools.ietf.org/id/draft-baset-tsvwg-tcp-over-udp-01....

[2] https://en.wikipedia.org/wiki/Middlebox

edit: formatting

He probably saw benefits from using UDP because he's no longer limited by TCP's congestion control and can flood the pipe with duplicates of his packets.