So I've done some more thinking about client-steering geo-ordering,
and I think the geo-sorting part should be summarized as follows:
Sort the geo-steering targets ascending by the total distance from
[client -> edge -> origin]. For targets where the total distance is
equal, prefer the target with
No problem, Eric. I appreciate a good brainstorming. Really the
Seattle-Denver-Boston example I gave was just to illustrate the idea
of the feature; I'm not sure we'd actually go with a Geo Steering DS
architecture that dispersed.
Steering DSes aren't actually assignable to specific cachegroups,
b
Thanks Rawlin-
Thanks for bearing with me. I’m thinking through this and wanted to
brainstorm a little.
What’s the benefit of going to the Boston edge cache to get the Seattle or
Denver DeliveryServices?
- If you already have redundant origins in Boston, you’re protected against
failure of
Hey Eric,
In this example I'd think that all the target DSes would need to be
assigned to all 3 Cache Groups. That way the client could possibly use
any of the target DSes from the cachegroup they're routed to. But I
suppose that could change on a case-by-case basis where maybe the
target DSes are
Makes perfect sense. thanks for the clarification.
On Tue, Feb 27, 2018 at 11:32 AM, Rawlin Peters
wrote:
> Hey Jeremy,
>
> With a redundant origin in each location, there would be a total of 6
> HTTP_LIVE DSes. Then you'd create a steering DS with each of those 6
> HTTP_LIVE DSes as targets. Th
Hey Jeremy,
With a redundant origin in each location, there would be a total of 6
HTTP_LIVE DSes. Then you'd create a steering DS with each of those 6
HTTP_LIVE DSes as targets. The type of each target would either be
GEO_ORDER or GEO_WEIGHT, depending on if we want a forced ordering or
something
In this example, what would be the assignments of delivery services to edge
Cache Groups? Are all 3DS’ assigned to all 3 Cache Groups?
I’ll also assume that the content on the origins, while interchangeable from a
clients perspective, is not identical? (i.e. might contain regionalized
content?)
So, back to the Seattle, Denver, Boston example...
To accomplish the geo ordering and redundant origin use case, you'd create
3 HTTP_LIVE delivery services? One with an origin in seattle. One with an
origin in denver. One with an origin in boston. (or would you create 6 ds's
so you have 2 in each
Hey folks,
At Comcast we have a need to augment CLIENT_STEERING (also regular
STEERING while we're at it) to allow targets to be ordered/sorted
based upon the client's proximity to the origin of the target delivery
services. I'd like to get your feedback on my proposed design and
address any of yo