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 <jesse_ri...@comcast.com> wrote:
> Nir,
>
> This solution does not support that level of granularity.
>
> Jesse
>
> ´╗┐On 2/13/18, 11:43 AM, "Nir Sopher" <n...@qwilt.com> 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" <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/incu
>     > bator-trafficcontrol/pull/
>     > >     > 1866
>     > >     >
>     > >     >
>     > >     >
>     > >     > Thanks,
>     > >     >
>     > >     >
>     > >     >
>     > >     > Jesse
>     > >     >
>     > >
>     > >
>     >
>
>

Reply via email to