Re: Traffic Router Enhancement - Default Maxmind Geolocation Override

2018-02-21 Thread Jeff Elsloo
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  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"  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

2018-02-16 Thread Rivas, Jesse
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

2018-02-15 Thread Eric Friedrich (efriedri)
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

2018-02-15 Thread Rivas, Jesse
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

2018-02-15 Thread Eric Friedrich (efriedri)
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

2018-02-14 Thread Nir Sopher
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 Peters 
wrote:

> 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

2018-02-13 Thread Rawlin Peters
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 
> 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

2018-02-13 Thread Rivas, Jesse
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