How important is UDP packet order?

I've come here to ask this, after a fairly lengthy exchange with technical support.

A small part of my life, is playing the occasional game of CS:GO. Recently, I started to see loss appear in game (on network stats) and it was causing artifacts in game (delay before kill confirmation, juddering movement, this kind of thing).

The loss was really variable. Mostly 0-5%, but jumping as high as 30% at times. So, as a bit of a technical person I thought I would investigate. Enabling packet logging in game allowed me to see, actually there was 0% loss. Not a single packet was actually lost (good news, I would say). But, this percentage I saw were arriving out of order, and the game client had no way to make use of these out of date packets. So, they were as good as lost.

OK. So, still a problem for gaming I guess.

So I performed some tests with iperf, and found a few interesting things.

1: With small packets, (200 payload) out of order packets could be as high as 25%
2: Larger packets (1420 bytes) has less problems generally 3-5%
3: Very predictably packets that were forced to be fragmented had MUCH less out of order issues (consider how that works to understand why)
4: There were zero packets out of order over IPv6 (less load, different routing?)
5: Tests performed over 4g and wifi (vs fully wired VDSL 80/20 connection) had only the occasional bout of OOO packets, and these were clumped together (almost certainly caused by error detection/correction on either of the two unreliable transport mechanisms).

Zen support say, this is essentially tough luck and I must live with this. But, my question is. When other ISPs don't have the problem. When their own IPv6 network doesn't have the problem, and I have less of a problem on a cellular network over wifi... At what point is the problem too big?

So I'm making it an open question. Because, I don't really know if I'm making a mountain out of a molehill here.

I wonder if any other Zen users here are CS:GO players (or other UDP based online games) and are seeing issues. I suppose extremely low latency VoIP could throw up some issues too.

Actually you can safely ignore this. It appears the router (and I mean the hardware, not the software) is at fault here. Although oddly targeting only ipv4 packets. Perhaps an issue with NIC firmware? I don't know. But, at any rate it happens running DD-WRT or stock firmware. But, doesn't happen when I hooked up the PC directly to the modem.

yes, tried different wires etc. Although, again that would have an effect on IPv6 too. So, it's a weird one this.

Hi

UDP packets are not guaranteed to arrive in the order they are sent, in fact they are not guaranteed to arrive at all!

Usually the application using UDP will be written to cope with out of order UDP packets or to cope when they don't arrive.

Typically on a well behaving network (or local LAN) they would arrive in the order they were sent.

When you go over the internet of course networks and routes can be quite complex, with store and forward buffers all over the place which easily means UDP packets get out of order.

Regards

Phil

You are in fact preaching to the choir. It's why the question was, at what point do you consider it a problem? To me, when I'm getting a better result over two wireless technologies each with their own mechanism which could regularly create out of order scenarios while doing their job, I felt that was to me when you recognize a problem.

As it is, as I made clear in the second post, the problem was a very peculiar one with the router itself. Not peculiar that there might be lost or badly sequenced frames. But that it ONLY happened on IPv4 UDP frames. I'm not sure if it's a general problem with the router, or just a faulty unit (what a bizarre fault, how do you RMA that? hehe)

At any rate, I now have a Raspberry pi performing the pppoe and NAT duties, and I don't see the problem at all any more.

To be clear this was a constant and reproducible phenomenon. Not just something that happened "from time to time"