I did not say a Chicago server didn’t exist, I was using an exercise in logic to illustrate how this issue has absolutely nothing to do with our routing. If tomorrow NTT condensed to one server in Korea (just a vivid example), we would not have any routing change whatsoever to do to find their server. This is not how internet traffic works. Yet, despite absolutely no change on our end (because there is no applicable change), you would still reach the destination. All routing inside the destination network, including the initial server, is something that the destination ISP has to change. I would wager that you are referring to a game that you are trying to use with a server in California (if not, feel free to substitute “website” or other appropriate noun for “game”). This trace route would indicate that the game is using NTT as their internet provider. As a content delivery network, NTT sets up how it’s peering works with other ISPs, they would be in direct control over which server they are listening for traffic or “peering” on. The issue in this scenario would then be that NTT either has an unfortunate server assigned for traffic from us,
or perhaps that the game which is paying NTT to be a content delivery network is not paying for sufficient peering service to support their customer traffic, leading to an inability to accept your request in Chicago, and so you simply go to the nearest available server (or perhaps the only server they actually have as part of their specific CDN service). Neither of these issues are something that we can assist with altering (or even see which hypothetical is the problem), nor are they issues that you should expect compensation from us for as they are not issues with our service.