How does the suggested fix know when maxmind is returning a “default location” versus an actual location?
Hopefully the solution is applicable to CDNs which are spread across multiple countries and geographies? —Eric > On Feb 13, 2018, at 1:34 PM, Rawlin Peters <[email protected]> wrote: > > Yeah, this basically solves the problem where MaxMind knows a client > is in the US (or another country) but doesn't know the state, city, > zip, etc., so it's not a "true" miss. In that case MaxMind returns the > geographic center of that country as the client's location, but we > don't want to route those clients to the cache group closest to that > location because it might not be the ideal cachegroup. By using this > parameter we can shift this high volume of "US" traffic that is > essentially being localized to a lake in Kansas to a cachegroup more > capable of handling that load. And we can do this on a per-country > basis because we can create multiple of these parameters (which we > wouldn't be able to do if we just used the Default Miss Lat/Lon of a > DeliveryService). > > -Rawlin > > On Tue, Feb 13, 2018 at 11:10 AM, Rivas, Jesse <[email protected]> > wrote: >> Steve, >> >> Using the miss location for the DS was a potential solution that we talked >> about. However, the miss location is intended for use when the client IP >> falls through MaxMind without any data. Since the default location doesn't >> fit this criteria, it was decided to use a profile parameter to preserve >> granularity. >> >> Jesse >> >> On 2/13/18, 11:06 AM, "Steve Malenfant" <[email protected]> wrote: >> >> Jesse, >> >> I'm not exactly sure how MaxMind return this default value but would there >> be a way to use the MISS location specified in the DS? Seems like that is >> what it was intended for. >> >> Steve >> >> On Tue, Feb 13, 2018 at 12:42 PM, Rivas, Jesse <[email protected]> >> wrote: >> >>> Hi all, >>> >>> >>> >>> At Comcast, we have been seeing a pattern of the same cache group being >>> overloaded nightly as traffic increases on the CDN. The cause was >>> determined to be a default location that the geolocation provider MaxMind >>> returns for client IPs that it does not have additional data for. For the >>> US, MaxMind returns a geolocation with the coordinates: 37.751,-97.822; >>> this is a substantial amount of traffic that is all directed to the nearest >>> cache group. >>> >>> >>> >>> The fix I have introduced is a new profile parameter for CRConfig.json >>> named 'maxmind.default.override' in the format: >>> '<countryCode>;<lat>,<long>'. When MaxMind returns a default location, the >>> code checks for a parameter entry with the same country code. If an entry >>> exists, the default location will be overwritten with the coordinates of >>> the parameter. This allows users to determine where this traffic should be >>> sent rather than using the cache group closest to the MaxMind default >>> location. The new parameter supports multiple entries so that there can be >>> override coordinates for more than one country. >>> >>> >>> >>> Here is the PR: https://github.com/apache/incubator-trafficcontrol/pull/ >>> 1866 >>> >>> >>> >>> Thanks, >>> >>> >>> >>> Jesse >>> >> >>
