Bad lag again with NTT's NA server network

[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.