Hi everyone,
We are a development team identifying a sophisticated networking conflict in Italy between the ISP TIM (AS1267) and Epic’s network infrastructure. This is not a standard latency issue, but a systematic failure of the TCP flow control triggered by ISP-level Deep Packet Inspection (DPI).
The Technical Conflict:
-
Forced Path Optimization: Epic’s infrastructure identifies the connection as healthy and attempts to route traffic via internal accelerators.
-
DPI & Reset Loop: As soon as real game data flows, TIM’s DPI triggers TCP RST (Reset) packets and applies Rotating MTU fragmentation.
-
Buffer Saturation: The mismatch between Epic’s burst delivery and TIM’s rotating MTU leads to critical buffer saturation. The network buffers (both at the OS and router level) fill with out-of-order segments and fragments that cannot be reassembled due to the injected resets.
-
Congestion Collapse: The Windows TCP stack interprets this buffer congestion and the flood of duplicate ACKs as a total network failure. Consequently, the TCP Receive Window Auto-Tuning collapses the effective bandwidth—often to less than 1% of the actual line capacity—while the ping remains deceptively low.
Summary of Observations:
-
ISP: TIM (Telecom Italia) - AS1267.
-
Behavior: Apparent low latency, but near-zero throughput due to TCP window throttling and buffer stalls.
-
Bypass Attempts: Standard VPNs and MTU clamping (1450-1472) are ineffective as the ISP-level DPI tracks the flow signature.
What we are looking for:
We need to escalate this to the Epic Network Engineering team. The traffic signatures of Epic’s Mediterranean accelerators are triggering aggressive traffic-shaping on TIM’s nodes, which “fools” the Windows network stack into a self-throttling state.
Is there a way to force the client to opt-out of these specific accelerators, or is there a known mitigation for ISP-level RST injection that triggers this buffer/autotuning collapse?