How to delay outgoing traffic

How do I delay outgoing traffic with the filter IPv4 GRE, IPv4 ICMP and IPv4 TCP?
I have the simulation to connections matching the filter. When I start the simulation, no traffic gets affected. How do I fix this problem? How do I get these filters that I want to test out to work properly?

It really depends on what you want to include in the filter.
For a simple test:

• Choose Any as the protocol.
• Then, on the main screen, set Direction to Outgoing, and on the Latency tab set a fixed latency of 100 ms.
• Finally, ping a known local IP address, for example your router, and you will see an extra 100 ms added to the response time.

But If I apply simulation to connections only matching the filter and I add delay to outgoing traffic or packet loss and pack reordering and corruption and I put the filter as IPV4 UDP or Any IPV4 or just Any, the traffic will delay or be affected and it will show in the graph chart. Why does traffic delay or becomes affected when using these filters that I just mentioned but not with IPV4 GRE, IPV4 TCP and IPV4 ICMP, IPV4 AH/ESP or IPV4 TCP/UDP? Is there a way to fix this without having to just any protocol, could you look into it for me if by any chance you don't know how?

GRE and AH/ESP are specialised protocols used for traffic tunnelling and encryption respectively, so unless your application specifically uses these, you won't see any effect.

For general application traffic, you would typically use Any IPv4 or Any IPv6, or if you want to target just regular network traffic, IPv4 TCP/UDP or IPv6 TCP/UDP. Note that these filters will allow ICMP (ping) to pass through unaffected.
If you want to affect ping alone, use ICMPv4 or ICMPv6.

It really depends on what exactly you are trying to apply the filter to. What is the application or traffic type you're testing?

The application I am testing is GTA 5 online on PS5, I use a VPN shared with my Ethernet adapter via PS5. When I delay traffic with IPV4 UDP and Any IPV4, the traffic will delay or stop. If I use IPV4 ICMP and GRE and AH/ESP and TCP and TCP/UDP traffic remains unaffected, nothing happens when I start the emulation.

Like I explained above, GRE, AH/ESP and ICMP are specialised network protocols. The first two are used for encryption and tunnelling, while the latter is used for network signalling (ping, delivery issues, etc). None of these are typically used for game traffic.

If IPv4 UDP works for you, just use that — game traffic is almost always UDP-based. I've heard that adding latency may give you an advantage in certain online games, but I'd doubt it actually helps in practice.

Ok Thank You Sir. Do you think that you guys could add correlation to other functions, like packet reordering and packet loss and duplication and perhaps a UDP generator in a future update for the software?

We intentionally support correlation for latency, but not for loss, reordering or corruption, because latency is driven by a fundamentally different kind of process.

Latency is primarily caused by queueing. Queues have memory: when they build up, packets are delayed in a smooth, time-correlated way, and when they drain, delays reduce gradually. Because of this, correlated latency and jitter closely match how real networks behave under load and congestion.

Packet loss, reordering and corruption do not behave in the same way:

Packet loss is usually a threshold or event-driven effect (for example, buffer overflow or AQM decisions). Loss tends to occur when a specific condition is met, not because previous packets were lost. Adding artificial time-based correlation can create unrealistic loss bursts that do not correspond to real congestion behaviour and can obscure the true root cause being tested.

Packet reordering is not a random time-series process. It is typically caused by discrete events such as multipath routing, path changes or wireless retransmissions. Reordering correlates with path selection and topology, not with time alone. Time-correlated reordering would produce patterns that do not reflect how real networks reorder packets.

Packet corruption is a physical-layer phenomenon, driven by link quality, interference or faulty hardware. It correlates with the medium or location, not with previous packets. Correlating corruption over time effectively simulates a failing link rather than normal network conditions.

In short, correlation is appropriate when the underlying mechanism has state or memory. Queueing (latency) does. Drop decisions, path changes and bit errors generally do not. Applying correlation where there is no real underlying memory reduces realism and makes test results harder to interpret.

How many more updated versions do you guys plan to release for the connection emulator?

There is no defined plan for the release of a certain number of versions. For each product a new version is released when new features are added or something is fixed/improved. For feature-complete products like the Connection Emulator a new version is most likely to be prompted by a bugfix. And, obviously, nobody can predict when (or if) a bug will be discovered.