Re: Traffic Router Enhancement - Default Maxmind Geolocation Override
Unless there are objections, I will be merging this PR (#1866) in the near future. Please speak up now if you have any concerns. -- Thanks, Jeff On Mon, Feb 19, 2018 at 10:24 AM, Rivas, Jessewrote: > Nir, > > I'm not familiar with the behavior of other geo DBs concerning default > locations, but as long as there are distinct conditions where we can > determine that a response is a default, we can expand this enhancement in the > future to work with other DBs as well. > > -Jesse > > On 2/19/18, 7:11 AM, "Nir Sopher" wrote: > > Are you familiar with the behavior of other ip to geo DBs? > Anyway +1 from me. > I would also be happy to review and merge. > Nir > > On Feb 16, 2018 18:22, "Rivas, Jesse" wrote: > > > If there are no objections to the proposed enhancement for a MaxMind > > override location on a per country, per CDN basis, then I will move > forward > > with the changes and work with a committer to get the PR merged. > > > > -Jesse > > > > On 2/15/18, 8:37 AM, "Eric Friedrich (efriedri)" > > wrote: > > > > Sounds great, thanks! > > > > > On Feb 15, 2018, at 10:33 AM, Rivas, Jesse > > > wrote: > > > > > > Eric, > > > > > > We can determine a response from MaxMind is a default location > when > > the following conditions are met: the country code is populated, the > city > > is null, the postal code is null, and the subdivisions list is empty. If > > these conditions are met, we check for an instance of > > maxmind.default.override with the same country code. This allows users > to > > have one MaxMind override per country, per CDN. > > > > > > -Jesse > > > > > > On 2/15/18, 6:04 AM, "Eric Friedrich (efriedri)" > > > wrote: > > > > > >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 > > > 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 < > > jesse_ri...@comcast.com> 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" > > 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 < > > jesse_ri...@comcast.com> > > >>> 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 > >
Re: Traffic Router Enhancement - Default Maxmind Geolocation Override
If there are no objections to the proposed enhancement for a MaxMind override location on a per country, per CDN basis, then I will move forward with the changes and work with a committer to get the PR merged. -Jesse On 2/15/18, 8:37 AM, "Eric Friedrich (efriedri)"wrote: Sounds great, thanks! > On Feb 15, 2018, at 10:33 AM, Rivas, Jesse wrote: > > Eric, > > We can determine a response from MaxMind is a default location when the following conditions are met: the country code is populated, the city is null, the postal code is null, and the subdivisions list is empty. If these conditions are met, we check for an instance of maxmind.default.override with the same country code. This allows users to have one MaxMind override per country, per CDN. > > -Jesse > > On 2/15/18, 6:04 AM, "Eric Friedrich (efriedri)" wrote: > >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 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 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" 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 >>> 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: ';,'. 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 >>> >>> > > >
Re: Traffic Router Enhancement - Default Maxmind Geolocation Override
Sounds great, thanks! > On Feb 15, 2018, at 10:33 AM, Rivas, Jessewrote: > > Eric, > > We can determine a response from MaxMind is a default location when the > following conditions are met: the country code is populated, the city is > null, the postal code is null, and the subdivisions list is empty. If these > conditions are met, we check for an instance of maxmind.default.override with > the same country code. This allows users to have one MaxMind override per > country, per CDN. > > -Jesse > > On 2/15/18, 6:04 AM, "Eric Friedrich (efriedri)" wrote: > >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 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 >> 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" 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 >>> 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: ';,'. 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 >>> >>> > > >
Re: Traffic Router Enhancement - Default Maxmind Geolocation Override
Eric, We can determine a response from MaxMind is a default location when the following conditions are met: the country code is populated, the city is null, the postal code is null, and the subdivisions list is empty. If these conditions are met, we check for an instance of maxmind.default.override with the same country code. This allows users to have one MaxMind override per country, per CDN. -Jesse On 2/15/18, 6:04 AM, "Eric Friedrich (efriedri)"wrote: 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 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 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" 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 >>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: >>> ';,'. 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 >>> >> >>
Re: Traffic Router Enhancement - Default Maxmind Geolocation Override
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 Peterswrote: > > 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 > 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" 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 >>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: >>> ';,'. 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 >>> >> >>
Re: Traffic Router Enhancement - Default Maxmind Geolocation Override
I need to get better understanding of the DNS infra-structure to be able to verify this assumption. I assumed TR localization feature already solved the problem of getting to the right router, and from there it is in our hands ... Nir On Tue, Feb 13, 2018 at 11:39 PM, Rawlin Peterswrote: > Nir, > > You bring up a good point. If we can make the assumption that requests > coming to a specific Traffic Router are actually somewhat local to > that Traffic Router, we might be able to localize those > "country-localized" clients to a cachegroup close to that particular > Traffic Router. That would have the effect of spreading load around a > country a bit better if the Traffic Routers were geographically > distributed well. Maybe that could be Phase 2 of this effort, but how > much can we rely on that assumption? > > -Rawlin > > On Tue, Feb 13, 2018 at 1:27 PM, Rivas, Jesse > wrote: > > Nir, > > > > This solution does not support that level of granularity. > > > > Jesse > > > > On 2/13/18, 11:43 AM, "Nir Sopher" wrote: > > > > Hi, > > > > Can this solution support different value in different routers? > > Taking TR localization into account, it might give better > granularity. > > > > Nir > > > > On Tue, Feb 13, 2018 at 8:34 PM, Rawlin Peters < > rawlin.pet...@gmail.com> > > 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 < > jesse_ri...@comcast.com> > > > 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" > 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 < > > > jesse_ri...@comcast.com> > > > > 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: > > > > > ';,'. 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
Re: Traffic Router Enhancement - Default Maxmind Geolocation Override
Nir, You bring up a good point. If we can make the assumption that requests coming to a specific Traffic Router are actually somewhat local to that Traffic Router, we might be able to localize those "country-localized" clients to a cachegroup close to that particular Traffic Router. That would have the effect of spreading load around a country a bit better if the Traffic Routers were geographically distributed well. Maybe that could be Phase 2 of this effort, but how much can we rely on that assumption? -Rawlin On Tue, Feb 13, 2018 at 1:27 PM, Rivas, Jessewrote: > Nir, > > This solution does not support that level of granularity. > > Jesse > > On 2/13/18, 11:43 AM, "Nir Sopher" wrote: > > Hi, > > Can this solution support different value in different routers? > Taking TR localization into account, it might give better granularity. > > Nir > > On Tue, Feb 13, 2018 at 8:34 PM, Rawlin Peters > 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 > > 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" 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 < > > jesse_ri...@comcast.com> > > > 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: > > > > ';,'. 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/incu > > bator-trafficcontrol/pull/ > > > > 1866 > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > Jesse > > > > > > > > > > > > > >
Re: Traffic Router Enhancement - Default Maxmind Geolocation Override
Above I mentioned that the parameter 'maxmind.default.override' supports multiple entries so that there can be override coordinates for more than one country. To be more specific, the user can add multiple parameters using the same key to create multiple entries. Jesse On 2/13/18, 10:51 AM, "Rivas, Jesse"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: ';,'. 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