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, Jesse <jesse_ri...@comcast.com> wrote: > 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 > > >>>> > > >>> > > >>> > > > > > > > > > > > > > > > > > > >
