T-Mobile Home Internet Slow IPv4

Hola,

I still have major problems, this issue is not resolved. I've created another post here:

-Jason

Hola,

Well, updated firmware today from Asus, there seems to be significant improvement in IPv4 latency.

-Jason

Not encrypting DNS... seems like overkill when I am letting the routers forward DNS queries to TMO's v6 servers instead of trying to force external public DNS servers.  Keeping it "in-house" and not reaching across the internet to 3rd party DNS servers... which is how TMO seems to want it to be done.

I only set alt DNS entries up at the bottom of the list on the laptops for when I am not on my home network... but even then, I often use a VPN and lock that down against local LAN access and such anyway.

Seeing as things go sideways when you force the encryption (strict) versus opportunistic (tries, but falls back if unsupported)... sounds like TMO's topology up stream may again be getting in the way because you are continuing to deviate from their program.

Keep in mind that all your packets are going through additional encapsulation to go across TMO's networks... why the base MTU is lowered to 1420 instead of the usual 1500.

Have you tested it with the encryption disabled and running primarily against TMO's DNS as described earlier?

djb14336,

I'm using an Asus router with DoT and if I change it from Strict to Opportunistic, it reduces (but doesn't eliminate) the latency issues to normal levels. It could be a combination of the T-Mobile network + the Asus router with DoT but I'm not quite sure. My particular Asus RT-AX3000 router has been acting up, it hasn't been stable.

If you could test Strict DoT on your Asus router with 9.9.9.9 and 1.1.1.1 that would be great! 

It will look like this:

Then test the DoT here:

1.1.1.1 Connectivity Test

Cloudflare Browser Check | Cloudflare

Please let me know what you discover.

Gracias,

-Jason

Pinged Bing from the TMO diagnostic tool, 70-74ms responses, no losses, multi passes (only pings 3x)

From my Asus router's tools, 65-72ms, no loss.

From my laptop down the hall running over wifi with an online RPG running in the background,  65-117ms no losses.

Something may be off in your local configs or along the upstream route you are getting assigned.  My Asus is using full cone NAT... about the only "tweak" I recall verifying specifically.

Who knows... could have still been some fallout from the flood attacks on MS Azure and all that mess.

Hola all,

Thanks for taking time to research this. I found that if I change my Asus router DoT to Opportunistic, it improves the latency. I also tested connecting directly to the T-Mobile TM-RTL0102 and it seems to be normal. I guess I have to make adjustments to my Asus router setup. 

-Jason

You mentioned you switched to using external DNS, and that it may be related as it coincided with when you started noticing things were getting more laggy.

TMO HI is using only a v6 layer between their modem and the edge networks, which is basically like a CGNAT scheme on the forward facing network segments.  Their is no 1:1 v4 path in or out--so there can be some wonkiness with forced v4 only traffic...  especially for things like DNS queries and ping/trace tests.

The whole system works kind of like a VPN tunnel... more specifically, a sort of v4/v6/v4 tunnel.  One of the more egregious things with this setup is how it monkeys with inbound v4 traffic.  Any unsolicited inbound traffic gets killed at the edge network because the weird sort of VPN scenario going on... without the proper tracking that happens with an outbound request, the system has no way to forward unsolicited traffic to your modem (basically, this is why port forwarding and such is hosed so badly atm).

Our traffic in general is also set at a lower priority... they do this to preserve more time slices for the phones.  And that gets doubled down on when you are running ICMP ECHO requests for testing, as the networks generally place such requests to lower priority as well (if not set to outright ignore them, especially once utilization crosses certain  thresholds).  Couple this with trying to force v4 pathing... and things can get weird.

In short... by trying to force v4 communication, you are opening yourself up to a lot of potential issues.

Take a close look at the Network/Status page of their Askey modem... particularly the v4 and v6 sections.  Notice how we are forced to v6 addresses for everything upstream?

The modem is set to push all data through a v6 gateway.  It's DNS queries are run against V6 servers.  Trying to force v4 only and such is kinda asking for weird things to happen.

Your local network and devices need to be set up in a way so the routers/modems can try to forward it all as they are set to do so natively.  If a v6 path is viable, it will use that, otherwise reverting to v4.  Note that some browsers may misbehave though and may need tweaking for v6 to work more reliably. 

The Askey is mostly configurable and will TRY to function just like any other router (minus an actual bridge mode selection).  You can set your own LAN subnet up, so you are not stuck with the 192.168.x.x address it came with out the box.  Don't even remember their default to be honest.  I changed it to match the subnet my Netgear modem used when I was on Spectrum.  This way everything on my side stayed the same way I had it before, even my shortcuts to my router and the modem. Literally plugged it all up, rebooted my Asus to make sure it synched to the modem properly, and was off to the races. I tinkered with other confiigs, but reverted to my Spectrum model.

Basically, either run your router as an access point or normal mode and double NAT it... but let things configure DNS automatically or otherwise manually forward the first entries to the appropriate gateways so it ultimately gets directed to the TMO v6 DNS servers FIRST.  THEN the external v4 lookups can kick in per client if the initial query fails.  Things just  tended to work more reliably when my Asus configures/forwards DNS automatically versus manually pointing it to the TMO gateway first and then Google secondary.  I have some clients manually configured to look to the Asus as primary DNS, the TMO modem second, then Google and such as additional entries after those two.

An example run down with a router in normal mode (will Double-NAT locally):

Router automatically sets up the WAN uplink against the Askey LAN1 or LAN2 port via DHCP on the Askey.  You can leave the Askey with it's default LAN subnet, or configure your own like I did (192.168.100.1 root, just like it was when I was on Spectrum).  Run DHCP on your router for your LAN just like normal, be that it's default or again a custom one like I already had set (I used the 10.10.x.x space).  This will allow you to keep your static bindings and such as you had before.  Your devices should be looking to your router for gateway, DHCP, and primary DNS, with your router forwarding DNS to the TMO modem/router just like it would by default with your prior ISP.  Then the TMO device runs as your router's gateway, and forwards all the DNS queries to it's v6 DNS on the other side.  Only the necessary v6/v4 translations will happen by design without any of the extra wonkiness that can creep in when you try to force things to run differently.   

Should note that you can set up v6 passthrough on your router if you want.  Trying to setup a v6 delegation may appear to work, but tends to break shortly after.  Setting v6 passthrough on your router and enabling v6 on your devices will kinda sorta work.  It wasn't the greatest, but at least the phones seemed to like it... somewhat.  V6 is always a bit screwy when it comes to Windoze.  The PS4 tries v6 if it is active on the LAN, but Sony never did implement v6 right, so it misbehaves and falls back to v4.

Well, it turns out it could be the Asus router. I've connected directly to the T-Mobile TM-RTL0102 and the latency is normal. 

Thanks for take a moment to read this and trying to help!

>ping bing.com -4

Pinging bing.com [13.107.21.200] with 32 bytes of data:
Request timed out.
Reply from 13.107.21.200: bytes=32 time=348ms TTL=118
Reply from 13.107.21.200: bytes=32 time=179ms TTL=118
Reply from 13.107.21.200: bytes=32 time=227ms TTL=118

Ping statistics for 13.107.21.200:
    Packets: Sent = 4, Received = 3, Lost = 1 (25% loss),
Approximate round trip times in milli-seconds:
    Minimum = 179ms, Maximum = 348ms, Average = 251ms

>ping 13.107.21.200 (#1)

Pinging 13.107.21.200 with 32 bytes of data:
Reply from 13.107.21.200: bytes=32 time=143ms TTL=118
Reply from 13.107.21.200: bytes=32 time=216ms TTL=118
Reply from 13.107.21.200: bytes=32 time=505ms TTL=118
Reply from 13.107.21.200: bytes=32 time=195ms TTL=118

Ping statistics for 13.107.21.200:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 143ms, Maximum = 505ms, Average = 264ms

>ping 13.107.21.200 (#2)

Pinging 13.107.21.200 with 32 bytes of data:
Reply from 13.107.21.200: bytes=32 time=630ms TTL=118
Reply from 13.107.21.200: bytes=32 time=159ms TTL=118
Request timed out.
Request timed out.

Ping statistics for 13.107.21.200:
    Packets: Sent = 4, Received = 2, Lost = 2 (50% loss),
Approximate round trip times in milli-seconds:
    Minimum = 159ms, Maximum = 630ms, Average = 394ms

djb14336,

I'm not exactly sure what you mean by "let everything ultimately use their DNS as primary" but I think you mean don't use any third-party DNS provider. I'm not sure why this would affect latency other than a NS lookup. In my case, Bing.com, which was already resolved has a high latency
I don't understand the rest of the paragraph. 

"Queries to an external v4 DNS will have to go through their funky 464xlat/CGN tunnel crud to get there and back"

Again, bing.com was already resolved to an IP address. 

"you can change the private address space if you want, so if you are doing a double-nat set up (personal router in NAT mode not as an access point), you can set them up with more unique IP ranges."

I'm not sure what that has to do with anything, there's double-nat many places and the latency is sub 5 ms. 

" The Askey forwards it over it's v4 private LAN subnet, and if you are using your own router in native mode, that will have to forward again to it's private LAN subnet.  This will inject a little extra lag, but should be considerably less than what you are getting trying to force google/cloudflare/others as the primary DNS.  For the clients you configure manually, would want to point to the router(s) first, then any external provider you want to hit.  Por ejemplo:
10.10.x.x (personal router in NAT mode), 192.168.x.x (TMO Askey)
(Put the local gateway with better response time first, then you can list external providers as you see fit), 8.8.8.8. , 1.1.1.1 "

Not sure what you mean by all that, and again, the double-nat does not account for that IPv4 latency it that translation is sub 5 ms, it is negligible. 

" Forget where I got referred to it, may have been speedguide.net.  But there is a DNS Benchmark tool you can download for free that you can use to test responsiveness of your DNS setup.  May want to Google for it, just make sure it is coming coming from reputable source and all.
EDIT:  found it…
https://www.grc.com/dns/benchmark.htm
Hoping they start shipping the new 5g hardware soon so we can get a feel for how they hold up.  The bands have been available in our market for quite a while now... but we are all still on the Askey LTE boxes. "

Again, it's continuous data latency, even after a DNS server resolves the name to IP address. It is the entire IPv4 experience from a simple ping to bing.com to loading a simple website. Even worse than the latency is the dropping of packets. It gets so bad, TCP does not account for it. It becomes an unreliable connection worse than dial-up. 

Jason