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 <rawlin.pet...@gmail.com>
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 <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