It's almost like the 'network engineers' in gaming have never looked at the network architecture of a telecom system. Same problems: well-known standard solutions.
Not even remotely.
The biggest difference is that in commercial telecom, there's no such thing as obsolete data that can be safely dropped. If an audio stream packet doesn't arrive in time, the user will perceive a glitch, which the codec may or may not be able to cover up psychoacoustically. So these users try hard to prioritize reliable delivery whenever possible. Telecom's mission is to emulate a circuit-switched network with packet switching, which, while necessary, is never going to be the right strategy in the general case.
In game networking, on the other hand, a 200-millisecond-old packet is like a week-old newspaper. If it doesn't arrive in a reasonable amount of time, there's no upside to delivering it at all. The client is better off waiting for the next update from the server, relying on local prediction in the meantime. There's an excellent chance that the user will never notice the dropped packet(s).
This fact by itself means that any application-agnostic attempt to implement reliable delivery or packet sequencing is a waste of time from a game developer's perspective. Streaming protocols developed for video and other media may be a better match, but they still won't be ideal for a use case involving interactivity and client-side prediction. (For one thing, any media streaming protocol is likely to be more concerned with bandwidth over latency, and games live and die over the latter.)
People have been trying to come up with "one transport protocol to rule them all" since TCP/IP, and have always failed spectacularly. There's always going to be room for interesting work in this space, and the notion that an entire class of users should "just use XYZ/IP" or whatever is always going to be as misguided as the early recommendations to ignore UDP in favor of TCP were.
You attacked a strawman (a "telecom" engineering that hasn't been taking the concerns of realtime video into account every telecom protocol for the last 20 years.) Video has exactly the semantics you're talking about, and video-typed flows in RTP et al are interactive channels (originally, to enable adaptive streaming) in exactly the way games need for their data.
(The sending of extra information to enable client-side prediction, on the other hand, is something that can be added without altering the transport layer at all. Layering!)
Bytes on the wire are bytes on the wire. It doesn't matter what vertical you're working in; it just matters how the bytes on the wire need to behave. People should forget about the fact that something is "a game" and just look for wire-protocol structural isomorphisms before assuming their case is so unique.
Again, nobody in gamedev cares about "ordered." Knowing what you missed can still be important, of course, but in-order delivery is simply not a helpful role for the transport layer to take on. It has to be handled at a higher level.
There is nothing that XYZ/IP from RFC xxxx can do to make everyone happy in this space, and there's no sense in trying.
I didn't use the word "ordered" anywhere. Neither RTP nor SCTP require you to do anything in order; they're completely unordered at the level of flows, with no flow head-of-line-blocking another flow. Spread things horizontally so you've got one flow per concurrent consumer in the client (e.g. per zone, or per other player, or whatever else) so that messages concerning events that happen in parallel aren't queuing into a single flow. This is already the idiomatic thing to do if you're working with an actor-based engine; each actor gets its own flow.
> there's no sense in trying
Do you mean you see no advantages in trying? Like, say, allowing people to easily program bots for your Second-Life-alike using well-known open protocols? Or allowing partners to write their own game clients for your Minecraft-alike server, rather than porting yours?
Just because you can't make every game ever work perfectly without writing custom code once or twice, doesn't mean that every game requires custom code. Most games in a given genre are, from a networking perspective, the same game. If you don't think telecom protocols work, put out some gaming transport-protocol RFCs, like BitTorrent did with µTP!
Also, in games, most "messages" are a few bytes, and you pack dozens or hundreds into a single UDP packet. Each of the messages will have application specific ordering/reliability/latency trade offs. No existing IETF or ITU or other protocol comes close to the efficiency gotten by designing the stack correctly for the application.
But, why would games go through the trouble to do an RFC? It's not like you're going to have DOOM talk to Overwatch. And, while the router will see those two games as the same, the internals of the packets reflect the internals of each game. Hence, similarity ends approximately at the UDP level -- which is what the internet cares about, anyway!
(In fact, I even tried to get a standard for the most basic cross have entity transfer 10 years ago, with zero uptake.)
I seem to recall it being in there before you edited your post, but that's a tough thing to prove and a weak thing to base an argument on, so, OK. Either way, I don't have time to engage a moving target.
Not even remotely.
The biggest difference is that in commercial telecom, there's no such thing as obsolete data that can be safely dropped. If an audio stream packet doesn't arrive in time, the user will perceive a glitch, which the codec may or may not be able to cover up psychoacoustically. So these users try hard to prioritize reliable delivery whenever possible. Telecom's mission is to emulate a circuit-switched network with packet switching, which, while necessary, is never going to be the right strategy in the general case.
In game networking, on the other hand, a 200-millisecond-old packet is like a week-old newspaper. If it doesn't arrive in a reasonable amount of time, there's no upside to delivering it at all. The client is better off waiting for the next update from the server, relying on local prediction in the meantime. There's an excellent chance that the user will never notice the dropped packet(s).
This fact by itself means that any application-agnostic attempt to implement reliable delivery or packet sequencing is a waste of time from a game developer's perspective. Streaming protocols developed for video and other media may be a better match, but they still won't be ideal for a use case involving interactivity and client-side prediction. (For one thing, any media streaming protocol is likely to be more concerned with bandwidth over latency, and games live and die over the latter.)
People have been trying to come up with "one transport protocol to rule them all" since TCP/IP, and have always failed spectacularly. There's always going to be room for interesting work in this space, and the notion that an entire class of users should "just use XYZ/IP" or whatever is always going to be as misguided as the early recommendations to ignore UDP in favor of TCP were.