Even looking at it like that, it's wrong.

TCP has a lot of tunable parameters where the choices are baked into it, and it assumes that extra round trips are no big deal.

Crypto does not have all that many tradeoffs. You just need expert implementation. It's dangerous and unnecessary to do it yourself.

For something that is low-bandwidth and latency-sensitive, you can take TCP and make minor adjustments and come out with something that is far better suited. Even something as dumb and easy as sending all packets twice could turn an semi-common jitter into an ultra-rare jitter.

If you could open a TCP socket with forward error correction options, and disable head-of-line blocking, then you could probably argue against custom TCP-like protocols. But that's not the world we live in.

I was using "never implement your own crypto" as an example. I think that "never implement your own crypto" is a more important rule to follow than anything regarding TCP. On the other hand, if you don't know much about networking, trying to reimplement TCP over UDP isn't likely to gain you better performance. As with most things, there is no substitute for knowing what are doing.

I know it was an example, but the crypto saying is actually a good rule of thumb, while "don't do TCP" is a pretty bad rule of thumb.

You don't need to know that much about networking to get something that's better than TCP in this specific use case. It may be unoptimized and terrible but your goal is latency. Just pretend that 5% of packets will get lost and do something to compensate, and you beat TCP on imperfect networks, even as a novice.

There's a lot of work besides performance to get right in a transport protocol though. Just getting the retransmission working like you want is a small part of the job.

WebRTC went for UDP-encapsulated SCTP in order to get a transport without HOL blocking. I'd look into that or an existing UDP game net transport (like Enet) first.

I think 'never implement your own crypto' really means, 'this is an area where there is no substitute for knowing what the hell you are doing. Sometimes knowing what you are doing is not hard (changing a tire), sometimes it is (cryto and networking)

Agreed. TCP is a great general purpose communication protocol, but using it in all situations is probably not a good idea. For eg, for a specific case of mobile networks, a custom protocol built over UDP could out perform TCP. details here:

https://packetzoom.com/blog/lessons-learned-tcp-slow-start-d...