Bad lag again with NTT's NA server network

[Ryn_Fiaryn]

Yeah, the Discord thing was just because the hotspot couldn't handle running both at the same time on my phone. Lag city. I don't know if there's another way to have them both work.

[Aranthon]

Even though this seems to be a problem that affects AT&T users, I know people on other ISPs who are experiencing lag/packet loss. One of my static mates is on Tmobile and she is having the same issues that we are

[Illyrian94]

Even though this seems to be a problem that affects AT&T users, I know people on other ISPs who are experiencing lag/packet loss. One of my static mates is on Tmobile and she is having the same issues that we are

It's been a hot minute since I've studied networking, but if I'm remembering right it isn't at all uncommon for one ISP to carry traffic for another at certain points. If I had to guess, that's maybe what's happening with cases like this?

[Aranthon]

It's been a hot minute since I've studied networking, but if I'm remembering right it isn't at all uncommon for one ISP to carry traffic for another at certain points. If I had to guess, that's maybe what's happening with cases like this?

I'm still holding NTT to blame, but at this point I'm willing to present this problem to anyone who is willing to listen.

[Ahumaya]

I found another thread with more information about this problem, this is an issue with peering ports on AT&T's side, not square or NTT, only AT&T has control over fixing it so if you've got complaints send them to ATT :/.

What we can see with our own data from testing ourselves and from the many reports in these several hundreds of posts is that the issue occurs entirely once inside of NTTs infrastructure, when they are communicating from an NTT device to an NTT device.

While NTT could in theory claim that issues are caused by an issue from whoever provides their DC interconnect (Could be run by NTT, could be run on the global internet backbone (AT&T, Verizon, Sprint, etc.), could be run via a dedicated inter/intraconnect company for dark fiber or metroconnect), the issue would still be internal. However, if NTT were to claim that the issue were caused by a "peering issue" caused by AT&T, and the issue could be easily located within the NTT network stack, that issue would affect every user who connects to the NTT network via whichever NTT DC is affected.

While AT&T (and Spectrum and other smaller regional ISPs) could in theory all use the same routing to this same bad DC, and every other ISP globally somehow avoids this bad DC, that seems unlikely due to pure numbers, as routing will generally take the "path of least hops" before getting to the "last mile", which is within the NTT network. It wouldn't make sense for a major ISP like Comcast to send your data outside of, say, Texas, when there is an NTT DC in Texas.

All this suffice to say that the issue is still within the NTT stack of infrastructure, and seeing that it is affecting primarily (though not uniquely) a single ISP, it is heavily implied that the issue is caused by faulty equipment (or equipment not up to the task) within NTT's footprint, and which is permanently assigned to a route that connects from the AT&T "in" line to the NTT DC in Dallas. Talking to NTT nodes within Dallas is fine and shows no issues, and it's only when traveling from the Dallas DC to the Los Angeles hop that the issue appears, as we can see in our own data.

Taking this to the AT&T forums will only move an issue that isn't necessarily Square Enix's fault from these forums, to a place where it isn't necessarily AT&Ts fault. This is an issue that is primarily NTTs fault, either in their own equipment, or in equipment which they have purchased or leased from another vendor (possibly AT&T, if they wish to claim so). However, even if that were the case, it would still be NTTs fault that the issue is still present if it is not affecting other major ISPs, as that would imply that there exist multiple inter/intraconnects between their Dallas and Los Angeles DCs, and they continue sending primarily AT&T customers down a known bad line.

In addition, regarding the thread you linked (which comes from a mailing list of no known repute), it alleges that this could be an issue with UDP peering. While there does seem to be some sentiment on the global backbone that UDP isn't a "modern protocol", there is no evidence to support that this could possibly be the issue at hand, as if it was a UDP issue, it
1.) wouldn't affect the ICMP protocol the ping command uses
2.) wouldn't affect the ICMP protocol the traceroute command uses
3.) if the issue was in the NTT network, WOULD affect all users
4.) if the issue was in the AT&T network, would affect ALL UDP traffic

As none of the above statements are true, the issue cannot be a UDP peering issue. As such, and until further information is provided by relevant and involved sources (specifically NTT or AT&T), the only true, factual, sourceable, and testable information we have points the finger squarely and solely at NTTs inter/intraconnect between their Dallas and Los Angeles DCs.

Peace love and happiness. I hope our days are great.

[Illyrian94]

I'm still holding NTT to blame, but at this point I'm willing to present this problem to anyone who is willing to listen.

Oh, absolutely. I wasn't trying to say this wasn't possibly an NTT problem--just a thought as to why some folks on other ISPs are being affected as well. The more places we can raise this issue at this point, the better imo.

[Lahtori]

Taking this to the AT&T forums will only move an issue that isn't necessarily Square Enix's fault from these forums, to a place where it isn't necessarily AT&Ts fault. This is an issue that is primarily NTTs fault, either in their own equipment, or in equipment which they have purchased or leased from another vendor (possibly AT&T, if they wish to claim so). However, even if that were the case, it would still be NTTs fault that the issue is still present if it is not affecting other major ISPs, as that would imply that there exist multiple inter/intraconnects between their Dallas and San Angeles DCs, and they continue sending primarily AT&T customers down a known bad line.

I still stand by the "everyone sucks here" approach. But it definitely doesn't hurt to light a fire on the AT&T forums as well. I'm not saying to abandon this thread or to stop sending reports/tickets to SE, that definitely should still happen.

The blame just keeps getting passed around. As AT&T customers, we can pressure them. As customers of SE, we can pressure them. Where is the issue most likely? NTT. Who can pressure NTT? SE for sure (they pay NTT right?), and probably AT&T as well.

We all want the same thing, to play the game unimpeded by this NTT latency and packet loss, as we had been doing up until last week. (at least for me, I'm aware these issues are far more rampant for others)

[Aranthon]

Is there anyway for us to get in contact with NTT? I know a few posters have gotten in contact with reps from NTT last week.

[Lahtori]

Is there anyway for us to get in contact with NTT? I know a few posters have gotten in contact with reps from NTT last week.

This is very much something that interests me in knowing. Where/How are these folks communicating with them? I'd imagine they wouldn't give light of day to us as we do not compensate them directly. But I'd love to fuel fire with NTT too!

[Merricat]

I paid for the membership then downloaded and installed the app and then created an account and connected to it. The app shows a map with numbered circles and says I am connected to Atlanta. I am playing from South Louisiana on AT&T fiber. I do not know yet if I am able to pick or change any location. I haven't run any duties to see if it is actually working yet.

Interesting. I'm playing from Atlanta (physical location), on AT&T fiber. If you get good results through the VPN connected to Atlanta... LOL. Just shaking my head over here.