Hi Patrick and Mel, Thank you both so much for the incredibly kind words and encouragement! Hearing this from engineers of your background completely made my week. Mel, I’m definitely not an ISP insider, just a web developer who chased this issue for hours because my Counter-Strike matches were lagging and my neighbor's weren't. But I am absolutely tickled! Patrick, your explanation makes perfect sense. It’s a fascinating look at how the infrastructure layer actually operates behind the scenes. I'm going to take your advice and get regional trouble tickets logged with Spectrum to see if we can get the statistical needle moving. Thank you both again for being so welcoming and taking the time to educate a developer who wants to enjoy games with their friends. Also, I am never one to say no to an opportunity to learn something new :-) Best, *Josephina Lacy* On Wed, Oct 28, 2026 at 12:23 PM Mel Beckman <mel@beckman.org> wrote:
,
Patrick,
Of course you are correct, cost is a primary driver. It’s not that I forgot that, it’s just that I thought it was implicit in the ideas that they are load-balancing or grooming and that’s usually done for cost reasons. The primary one being not installing additional circuits :-)
And yes, I meant to congratulate Josephina on her excellent presentation of the situation. She obviously knows her stuff, and gave a very concise, I would call a model, analysis of the latency situation. I suspect she is a Network Engineering professional, perhaps even in the ISP biz :-)
-mel
On Oct 28, 2026, at 9:44 AM, Patrick W. Gilmore via NANOG < nanog@lists.nanog.org> wrote:
Mel: You forgot (because I know you know this) the #1 reason ISPs do traffic engineering: Cost.
For Josephina’s elucidation: Most networks will send traffic over free peering before transit, even if peering is much high latency. In fact, they are unlikely to even know the transit link is lower latency as they will not even check. In their defense, peering is typically equal or even lower latency, but not always.
In the case below, it would not surprise me if Spectrum only has peering out of state while United Fiber has peering in state. Might not even be peering vs. transit. It would also not surprise me if Spectrum has zero external links in MO, so it has to go to Dallas / Chicago / whatever to reach peering or transit. No interconnection, no way to pass traffic.
All that said, I would like to congratulate you Josephina. You have managed to send a clear, polite, professional post with enough relevant info to at least start a diagnosis. There are network engineers on this list with a decade or more of experience that cannot seem to that. 😁 Hopefully someone on this list with an open position is smart enough to offer you a job. I would if I could.
-- TTFN, patrick
On Oct 28, 2026, at 11:34, Mel Beckman via NANOG <nanog@lists.nanog.org> wrote:
I feel your gaming pain. But ISPs don’t necessarily engineer traffic to optimize latency. Sometimes it’s for other reasons, such as load balancing or WDM grooming. That’s proprietary internal information that they’re not obligated to share, and likely won’t.
-mel via cell
On Oct 28, 2026, at 8:23 AM, Josephina Lacy via NANOG < nanog@lists.nanog.org> wrote:
Hi NANOG,
I am a Charter/Spectrum (AS20115) residential subscriber out of the northern Kansas City regional market (specifically Excelsior Springs, MO). I am posting to the list because multiple households across different cities in our area (including Liberty, MO) are experiencing severe routing inefficiencies when targeting Midwest and Southern destinations.
I don't manage BGP topology myself, but looking at our traceroutes, it appears that Charter’s internal backbone is consistently hauling out-of-region Chicago and Dallas traffic to Denver, Western Nebraska before turning it back around. This introduces an unnecessary 30-60ms latency penalty.
To illustrate the contrast, a regional competitor in the exact same neighborhood (United Fiber, AS14371) successfully routes traffic straight from KC to Chicago in 22ms via Arelion, and reaches Dallas in 34ms. Meanwhile, Spectrum subscribers are hitting 55ms-75ms minimum for the exact same endpoints due to internal multi-state detours.
I have compiled our local telemetry below to help any Charter backbone or peering engineers on the list look into why our regional aggregation edge is failing to use local path optimizations.
============== 1. CHICAGO (ORD) DESTINATIONS: SPECTRUM VS. UNITED FIBER ============== Packets targeting Chicago from Spectrum route northwest into Nebraska, encountering a severe 40-45ms latency step-up entirely within Charter's internal transit hops before trailing up through Minnesota to reach Illinois.
[Spectrum User 1 - Excelsior Springs, MO] 7 24 ms 26 ms 24 ms lag-100.mcr01sctsnedc.netops.charter.com 8 67 ms 69 ms 69 ms lag-9.mcr11sctsnedc.netops.charter.com ... 16 56 ms 58 ms 59 ms 162-254-193-71.valve.net
[Spectrum User 2 - Liberty, MO] 8 21 ms 19 ms 21 ms lag-102.mcr01krnynegg.netops.charter.com 9 64 ms 63 ms 61 ms lag-9.crr01gdisne.netops.charter.com ... 17 56 ms 53 ms 54 ms 162-254-193-71.valve.net
[United Fiber Baseline - Excelsior Springs, MO] United Fiber drops locally into a KC hub (MCI), hands off directly to Arelion, and takes a clean line straight east to Chicago in 22ms flat: 4 13 ms 11 ms 10 ms be6661.ccr22.mci01.atlas.cogentco.com 5 13 ms 11 ms 11 ms arelion.mci01.atlas.cogentco.com 6 23 ms 22 ms 22 ms chi-bb2-link.ip.twelve99.net ... 11 25 ms 24 ms 22 ms 162-254-193-71.valve.net
============== 2. DALLAS (DFW) DESTINATIONS: S <https://www.google.com/maps/search/ESTINATIONS:+S?entry=gmail&source=g>PECTRUM VS. UNITED FIBER ============== To reach Dallas (approx. 500 miles directly south of KC), Spectrum routes traffic west to Denver, north through Nebraska and Minnesota, east to Chicago, and back down south.
[Spectrum User 1 - Excelsior Springs, MO] 7 27 ms 25 ms 28 ms lag-100.mcr01sctsnedc.netops.charter.com 8 69 ms 66 ms 66 ms lag-9.mcr11sctsnedc.netops.charter.com ... 18 65 ms 62 ms 66 ms 162-254-194-1.valve.net
[Spectrum User 2 - Liberty, MO] 7 37 ms 32 ms 34 ms lag-100.mcr01sctsnedc.netops.charter.com 8 66 ms 67 ms 68 ms lag-9.mcr11sctsnedc.netops.charter.com ... 18 75 ms 75 ms 69 ms 162-254-194-1.valve.net
[United Fiber Baseline - Excelsior Springs, MO] 4 8 ms 8 ms 8 ms be6661.ccr22.mci01.atlas.cogentco.com 5 14 ms 11 ms 12 ms be5591.ccr32.oma02.atlas.cogentco.com 6 22 ms 20 ms 21 ms be5068.ccr42.ord01.atlas.cogentco.com 7 20 ms 21 ms 20 ms be2766.ccr41.ord03.atlas.cogentco.com ... 14 34 ms 34 ms 34 ms 162-254-194-1.valve.net
============== FULL SPECTRUM TRACEROUTE FOR REFERENCE ============== [User 1 - Excelsior Springs, MO to Valve Chicago] 1 <1 ms <1 ms <1 ms console.gl-inet.com 2 6 ms 8 ms 6 ms vlan-200.ana05kscymogp.netops.charter.com 3 23 ms 19 ms 23 ms lag-46.hcr11kscymogp.netops.charter.com 4 8 ms 6 ms 5 ms lag-20.hcr02kscymogp.netops.charter.com 5 11 ms 10 ms 8 ms lag-28.mcr01ksczksmp.netops.charter.com 6 26 ms 25 ms 24 ms lag-101.mcr01dnvrco26.netops.charter.com 7 24 ms 26 ms 24 ms lag-100.mcr01sctsnedc.netops.charter.com 8 67 ms 69 ms 69 ms lag-9.mcr11sctsnedc.netops.charter.com 9 57 ms 56 ms 56 ms lag-401.crr02gdisne.netops.charter.com 10 57 ms * * lag-808.bbr01stcdmn.netops.charter.com 11 54 ms 54 ms 53 ms lag-1.bbr02chcgil.netops.charter.com 12 55 ms 58 ms 57 ms lag-802.prr01chcgil.netops.charter.com 13 * * * Request timed out. 14 * * * Request timed out. 15 57 ms 53 ms 57 ms 162-254-193-131.valve.net 16 56 ms 58 ms 59 ms 162-254-193-71.valve.net
[User 2 - Liberty, MO to Valve Dallas] 1 1 ms <1 ms <1 ms SAX1V1S.lan 2 13 ms 16 ms 13 ms syn-070-094-032-001.res.spectrum.com 3 31 ms 188 ms 30 ms lag-58.hcr12kscymogp.netops.charter.com 4 18 ms 19 ms 16 ms lag-21.hcr02kscymogp.netops.charter.com 5 13 ms 13 ms 17 ms lag-28.mcr01ksczksmp.netops.charter.com 6 34 ms 35 ms 33 ms lag-101.mcr01dnvrco26.netops.charter.com 7 37 ms 32 ms 34 ms lag-100.mcr01sctsnedc.netops.charter.com 8 66 ms 67 ms 68 ms lag-9.mcr11sctsnedc.netops.charter.com 9 75 ms 72 ms 73 ms lag-401.crr02gdisne.netops.charter.com 10 77 ms * 70 ms lag-808.bbr01stcdmn.netops.charter.com 11 76 ms 72 ms 76 ms lag-1.bbr02chcgil.netops.charter.com 12 88 ms 80 ms 78 ms lag-22.bbr01olvemo.netops.charter.com 13 79 ms 84 ms 78 ms lag-3.bbr01blvlil.netops.charter.com 14 73 ms 68 ms 71 ms lag-805.bbr01dllstx.netops.charter.com 15 75 ms 70 ms 72 ms lag-801.prr01dllstx.netops.charter.com 16 104 ms 69 ms 73 ms 162-254-194-144.valve.net 17 * * * Request timed out 18 75 ms 75 ms 69 ms 162-254-194-1.valve.net
============== FULL UNITED FIBER TRACEROUTE FOR REFERENCE ============== [User 3 - Excelsior Springs, MO to Valve Chicago] 1 1 ms 1 ms 1 ms router.home.local [192.168.1.1] 2 26 ms 16 ms 16 ms 38.148.167.1 3 7 ms 4 ms 4 ms 10.20.0.29 4 13 ms 11 ms 10 ms be6661.ccr22.mci01.atlas.cogentco.com [38.20.20.129] 5 13 ms 11 ms 11 ms arelion.mci01.atlas.cogentco.com [154.54.11.46] 6 23 ms 22 ms 22 ms chi-bb2-link.ip.twelve99.net [62.115.139.124] 7 19 ms * * chi-b24-link.ip.twelve99.net [62.115.137.29] 8 21 ms 22 ms 22 ms valve-ic-392833.ip.twelve99-cust.net [62.115.202.235] 9 * * * Request timed out. 10 24 ms 22 ms 22 ms 162-254-193-130.valve.net [162.254.193.130] 11 25 ms 24 ms 22 ms 162-254-193-71.valve.net [162.254.193.71]
[User 3 - Excelsior Springs, MO to Dallas] 1 1 ms 1 ms 1 ms router.home.local [192.168.1.1] 2 11 ms 15 ms 16 ms 38.148.167.1 3 6 ms 3 ms 4 ms 10.20.0.29 4 8 ms 8 ms 8 ms be6661.ccr22.mci01.atlas.cogentco.com [38.20.20.129] 5 14 ms 11 ms 12 ms be5591.ccr32.oma02.atlas.cogentco.com [154.54.89.2] 6 22 ms 20 ms 21 ms be5068.ccr42.ord01.atlas.cogentco.com [154.54.166.74] 7 20 ms 21 ms 20 ms be2766.ccr41.ord03.atlas.cogentco.com [154.54.46.178] 8 * 23 ms 21 ms ix-bundle-19.qcore1.ct8-chicago.as6453.net [66.110.15.38] 9 35 ms 34 ms * if-bundle-2-2.qcore2.ct8-chicago.as6453.net [66.110.15.37] 10 * 34 ms 33 ms if-bundle-63-2.qcore1.dl8-dallas.as6453.net [66.198.29.35] 11 * * * Request timed out. 12 34 ms 34 ms 34 ms 64.86.132.235 13 * * * Request timed out. 14 34 ms 34 ms 34 ms 162-254-194-1.valve.net [162.254.194.1]
*Any help or insight from the Charter network team would be greatly appreciated. I apologize for any errors. Feel free to ask any questions!*
*Thank you!* *Josephina Lacy* _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/QGL3XY7E... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/WHSURANP...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/PVF37EQF...