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" <n...@qwilt.com> 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" <jesse_ri...@comcast.com> 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)" <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
    >     >>>>
    >     >>>
    >     >>>
    >     >
    >     >
    >     >
    >
    >
    >
    >
    

Reply via email to