On: When TCP sockets refuse to die

[vinay_ys]

What's really weird is that TCP is an endpoint protocol and should have been relatively easier to upgrade/replace/change (relative to say, IP protocol).

But why haven't we moved to something better?

Say, why doesn't Apple use a better suited protocol between Apple devices and Apple servers? Why doesn't google use a better protocol between Google devices and Google servers (oh wait, they do – QUIC..which is something-other-than-TCP over IP).

More people should be doing this, yes? why not?

It is as if the layered architecture of the network isn't being taken advantage of by engineers.

As people build 4G-5G networks that are IP based, shouldn't we insist they build purely IP based and not peek into layers above and make assumptions? thereby enable more of the flow control and reliable transmission protocol experimentations?

[ZWoz → vinay_ys]

Because NAT. Most commonly used as port address translation (One-to-many NAT), so operates with TCP and UDP. That is not only home router issue, mobile netoworks use sometimes Carrier-grade NAT (NAT444). Any new IP protocol has problem with that, so nobody wants to implement something that is going to be broken for most customers.

[vinay_ys → ZWoz]

Yeah, that's the reason for UDP wrapping the custom protocol.

[ronsor → vinay_ys]

1. You don't want to reimplement a quarter of the network stack in userspace.

2. Network infrastructure may drop "unusual" packets.

[Dylan16807 → ronsor]

> 1. You don't want to reimplement a quarter of the network stack in userspace.

That post doesn't say anything about user space. Ideally the new protocol would be in the kernel, triggered with just a flag or even automatically.

[vinay_ys → ronsor]

It's not reimplementing if it is a new protocol with different capabilities. There's no point in having a layered architecture if we cannot evolve the layers, especially the layers designated as endpoint layers.