Re:UDP Isn't Unreliable, It's a Conertible
by tsimionescu on Thursday October 30, 2025 @03:24PM
(#45764182)
I never really understood this complaint. UDP adds such a tiny and useful header on top of IP that it hardly seems meaningful to reinvent the wheel instead of just using it.
[ Parent
| on HN ]
Re:UDP Isn't Unreliable, It's a Conertible
by throw0101c on Friday October 31, 2025 @08:17AM
(#45771205)
See §Problem Space on what it was thought that UDP lacked that caused the creation of DCCP:
Re:UDP Isn't Unreliable, It's a Conertible
by tsimionescu on Friday October 31, 2025 @10:09AM
(#45772162)
I'm not asking why you'd need a new transport protocol, that much is clear. The question is what is the disadvantage of building this new protocol on top of UDP, especially if you don't expect to work with middlebox developers to add special features for your new protocol.
The only thing I get from that document that answers this question to some extent is the extra overhead of the checksum field in UDP headers. In other places, they generally don't seem to actually discuss the option of building a QUIC-like transport, that is a transport-layer protocol that still exists on top of the UDP skeleton.
Re:UDP Isn't Unreliable, It's a Conertible
by anticensor on Monday November 03, 2025 @08:47AM
(#45798891)
Your box should just treat that unknown protocol as a raw IP traffic, instead of dropping it.
Re:UDP Isn't Unreliable, It's a Conertible
by tsimionescu on Wednesday November 05, 2025 @01:44AM
(#45820021)
Probably, but again: why would you want to send raw IP traffic rather than UDP? What are the disadvantages of building your protocol on top of UDP instead of building it on top of raw IP, for an Internet protocol?