[tptacek]

Why would you need another IP protocol besides UDP? Anything you can do directly under an IP header, you can do under a UDP header as well, and the UDP header itself is tiny.

Going back to David Reed, this is specifically why UDP exists: as the extension interface to build more non-TCP transport protocols.

[IgorPartola]

UDP introduced ports. Ports are not always the best abstraction for specifying which application is talking to which other application. They are finite.

I am very aware of what you can do with UDP, I have done some very fun work trying to minimize bandwidth usage on crappy mobile connections by using and abusing it. But I think at the end of the day it is an engineering crutch.

If we insisted on properly supporting a diverse set of L4 protocols years ago we wouldn’t have wound up with NAT and slow adoption of IPv6. Address exhaustion would have been a real pressing issue. Instead you can’t even ping a server behind a NAT and firewalls run out of memory trying to manage stateful connections.

UDP is a pretty elegant design for what it is but it is barely good enough to allow us some room to make things work. Ultimately it did limit us more than it enabled us.

[tptacek]

Ports are just a multiplexing device, the same as the IP protocol number. Besides the tiny number of bytes in the UDP header, what's the practical difference?

[IgorPartola]

Negligible to none as of now. But take a look at this comment below: https://news.ycombinator.com/item?id=45528837

And I agree: it stifled what could have been a much nicer to work with set of protocols and who knows what could have been created had we not just said "well there is always UDP if you want to do your own thing".

[tptacek]

Stifled how? You want SCTP? Allocate a UDP port for it. You still haven't explained what the problem is.

[IgorPartola]

OK let’s put it this way: what is the point of IP being able to carry protocols other than ICMP, TCP, and UDP? For that matter why doN’t TCP and ICMP run on top of UDP?

[tptacek]

There isn't one! TCP running on top of UDP would have been a reasonable design. TCP/IP is full of warts like this. The URG pointer. The conflicting length fields.

The fact of ICMP not being itself a UDP protocol caused major problems for systems programmers, because it meant that OS kernels all "owned" ICMP, provided only a baroque sockopt programming interface to like 5% if it, and required userland programs to hold suser privileges to do any real ICMP work. Awful design. And ICMP is slow-pathed by routers, because it isn't UDP.

UDP literally doesn't do anything but multiplex raw IP. Unless you're actually worried about the 8 bytes the header takes up, there's no reason, none at all, to slide a new IP protocol anywhere but on top of UDP. Again: that's why UDP was designed in the first place. You can go look this up! David Reed still talks about it!

[jcelerier]

> the UDP header itself is tiny.

we're fighting for bits here!!! if you want to be 100% safe you need 576 packet size, UDP header is 1.4% of that

[supertrope]

IPSec originally ran on raw IP. These days it has to be tunneled in UDP due to TCP or UDP only ossification.

PMTUD breaks when ICMP is blocked.

The same argument can be made that everything but HTTP being blocked is not a problem because everything can be transported on top of HTTP.

[toast0]

It's not nice that pmtud breaks when ICMP isn't available, but sensible probing can do pretty well. Of course, barely anybody probes and they may not be sensible if they do.

Imagine at the beginning of a connection, sending a burst of packets, you could send (ignoring tcp timestamps because it makes the math hard, PAWS is a waste of bytes for most flows, and etc) [0,1460); [1400, 2800), ...

If you get an ack of the first packet, great. If not, you resend it as a 1400 byte payload and probe again in a future burst. Maybe even premptively resend the first packet as a 1400 byte segment after a short delay. Anyway, have enough failed large packets and probe smaller. Probe bigger again every so often if the connection stays open for a meaningful amount of time.

[tptacek]

The same argument is made about HTTP. But at least in the HTTP case, you can point to protocol behavior the middle-layer protocol is enforcing on you. You can't do that with UDP; UDP is just IP, with some ports, and a checksum.

[mtoner23]

Because it's an extra header. Making data transfer that much less efficient and working to make sure that clients can decide it properly

[lxgr]

An extra header of 8 bytes. To put that into perspective, IPv6 added 20 bytes to the IP header compared to v4.

[thadt]

Yeah? It's an eight byte header. The OS needs something to tag IP packets to get them delivered to the correct application. So you're thinking maybe a four byte header for 50% savings here?

[lxgr]

Good point on there needing to be some application-level addressing anyway.

On top of that, I believe the UDP checksum can be omitted as well at least on some OSes (and is arguably not necessary for fully encrypted/authenticated payloads) – leaving really just the two bytes for the "length field".

[tptacek]

You can't omit the UDP checksum in IPv6.

[IgorPartola]

So we have a checksum of the IP header, a checksum of the UDP header and a port number, an application level stream ID or message ID or whatever the application transport protocol is using, and finally almost certainly an even higher level message ID such as a URI. And that’s before you introduce encryption into it with all that overhead. A level 4 protocol providing full integrity verification, encryption, multi homing, multiplexing, out of band control, and control over transmission reliability would be amazing. But the only way you can experiment with these things is if you use UDP and ports. We take the concept of ports for granted but if you think of ICMP or some other L4 protocols that isn’t the only way to identify the sending and receiving application.

If we just allowed all L4 protocol numbers through and ditched NAT we could have nice things. Or we could kick it up two layers to use QUIC for what SCTP could have been.

[tptacek]

There's going to be encryption either way in any modern protocol, and then the header manipulation stuff is already all done in hardware. It's probably more efficient in UDP than as a direct IP protocol, because UDP is fast-pathed in ways protocols other than 6 and 17 aren't.

Having a diversity of IP protocols isn't a nice thing. The designers of TCP/IP made a protocol specifically for doing the thing you wanted to see SCTP do: it was called UDP.

[IgorPartola]

Why isn’t it a nice thing? And SCTP and UDP clearly provide different semantics. I am fine with experimenting with new protocols on top of UDP because it is simple to do but ultimately I think things like SCTP and QUIC should run directly on top of IP.

[tptacek]

No. SCTP provides a superset of UDP's semantics. Every IP protocol does, because UDP doesn't do anything except multiplex raw IP.