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)" <efrie...@cisco.com> wrote:
Sounds great, thanks!
> On Feb 15, 2018, at 10:33 AM, Rivas, Jesse <jesse_ri...@comcast.com>
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)" <efrie...@cisco.com>
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 <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" <smalenf...@gmail.com> 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:
>>>> '<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
>>>>
>>>
>>>
>
>
>
