Intermittent full-match latency (100–132 ms) while local path to Steam Datagram Relay remains ~14–16 ms

SUMMARY
I am seeing an intermittent latency issue in Marathon where an entire match can run at a stable ~100–132 ms, while other matches immediately before or after are normal.

The issue appears to be match/session-specific rather than a general connection problem.

I captured both normal and affected matches with Wireshark. In two separate affected captures, Marathon's dominant UDP gameplay flow used the same Valve / Steam Datagram Relay (SDR) endpoint:

162.254.197.52:27060/UDP

During one of those affected matches, while Marathon was showing approximately 100 ms latency, I simultaneously tested the route from my PC to that SDR relay.

RESULT DURING THE AFFECTED MATCH:
- Marathon displayed latency: ~100 ms
- Direct ping to 162.254.197.52:
  - 40 packets sent
  - 40 packets received
  - 0 packets lost
  - Minimum: 14 ms
  - Maximum: 16 ms
  - Average: 14 ms
- Traceroute reached 162.254.197.52 in approximately 15–16 ms

This means the path from my PC/ISP to the Valve SDR relay was healthy and low-latency at the same time Marathon was reporting ~100 ms.

I have intentionally removed my local IP address and ISP/transit hop IPs from this public post. The Valve relay IPs are retained because they are remote infrastructure endpoints relevant to the issue.

----------------------------------------------------------------------
NORMAL MATCH BASELINE
----------------------------------------------------------------------

Wireshark capture: normal match

Dominant UDP gameplay flow:
- Remote endpoint: 155.133.226.84:27044/UDP
- Approximately 35,200 packets
- Approximately 461 seconds of continuous bidirectional traffic

Network test to that relay:
- Ping minimum: 16 ms
- Ping maximum: 17 ms
- Ping average: 16 ms
- Packet loss: 0%
- Traceroute reached destination in approximately 16–20 ms

The match itself had normal in-game latency.

----------------------------------------------------------------------
AFFECTED MATCH #1
----------------------------------------------------------------------

Marathon latency:
- Approximately 100 ms for the match

Dominant UDP gameplay flow:
- Remote endpoint: 162.254.197.52:27060/UDP
- Approximately 7,743 packets
- Approximately 95.8 seconds of dominant continuous traffic

No direct ping/traceroute measurement to this exact relay was taken during this first affected capture.

----------------------------------------------------------------------
AFFECTED MATCH #2
----------------------------------------------------------------------

Marathon latency:
- Approximately 100 ms for the match

Dominant UDP gameplay flow:
- Remote endpoint: 162.254.197.52:27060/UDP
- Approximately 4,433 packets
- Approximately 57 seconds of dominant continuous traffic

This is the same SDR relay observed in affected match #1.

I ran network tests DURING the affected match:

ping -t 162.254.197.52

Result:
- Sent: 40
- Received: 40
- Lost: 0 (0% loss)
- Minimum RTT: 14 ms
- Maximum RTT: 16 ms
- Average RTT: 14 ms

I also ran:

tracert -d 162.254.197.52

The destination was reached at approximately 15–16 ms.

Some intermediate routers did not answer ICMP traceroute probes, but the responding hops and final destination showed no ~100 ms increase.

----------------------------------------------------------------------
ADDITIONAL OBSERVATION
----------------------------------------------------------------------

During the second affected match, I spoke with another player in the same match who stated that they were located in the United States.

I understand that this does NOT by itself prove that the authoritative Marathon game server was hosted in the US. However, it may be relevant when combined with:

- stable ~100 ms in-game latency for the entire match;
- a healthy ~14 ms path from my PC to the local Valve SDR relay;
- two affected captures selecting the same SDR endpoint;
- normal matches using a different SDR endpoint and having normal latency.

----------------------------------------------------------------------
CURRENT INTERPRETATION
----------------------------------------------------------------------

The captures do not appear consistent with ~100 ms of latency being introduced between my PC and the Valve SDR ingress relay.

During the affected match, the SDR relay was reachable at 14–16 ms with 0% ICMP packet loss while Marathon itself was reporting approximately 100 ms.

Because the gameplay traffic is being relayed through Steam Datagram Relay, the actual authoritative game-server address is not directly exposed in the client-side capture.

The current evidence therefore seems more consistent with one of the following:

1. The match was assigned to an authoritative Marathon server in a distant region.
2. The path after the local SDR ingress relay toward the authoritative Marathon server introduced the additional latency.
3. Matchmaking / server-region selection selected a backend that was inappropriate for my network location.

I am not claiming that the game server was definitely in the US; I only have client-side evidence and the statement from another player in that match.

----------------------------------------------------------------------
WHAT I WOULD LIKE SUPPORT / NETWORK ENGINEERING TO CHECK
----------------------------------------------------------------------

Could you please check whether affected sessions can be assigned to a distant authoritative server region even when the player's local SDR ingress is low-latency?

In particular, it would be useful to verify:

- authoritative game-server region selected for affected matches;
- Steam Datagram Relay route / backend path from the ingress relay to the game server;
- whether matchmaking may mix regions in a way that places some players on ~100–132 ms servers;
- whether there are known issues involving the SDR endpoint 162.254.197.52:27060;
- whether there are server-side logs or session identifiers I can collect next time that would allow Bungie to identify the exact game server / region.

----------------------------------------------------------------------
PRIVACY / CAPTURE NOTE
----------------------------------------------------------------------

I am not attaching the raw .pcapng files to a public forum because a full packet capture can contain unrelated network traffic and potentially identifying network information.

I can provide additional sanitized packet statistics, screenshots, exact timestamps, relay IPs/ports, ping output, and traceroute output if needed.