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?) —Eric > On Feb 23, 2018, at 5:40 PM, Rawlin Peters <rawlin.pet...@gmail.com> wrote: > > 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 your concerns. > > For HTTP_LIVE targets for instance, we'd like edge caches to ideally > retrieve/serve data from an Origin that is close to the client and > fall back to Origins that are farther and farther away. This allows > for increased redundancy while ordering optimal Origins (Delivery > Services) for a client to choose from. > > For example, I have 3 Origins in different locations: Seattle, Denver, > and Boston. I would create an HTTP_LIVE delivery service for each > origin and a CLIENT_STEERING delivery service with those delivery > services as targets. I would then like to have those targets ordered > based upon proximity to the client. So a client in Seattle would get > the list [Seattle, Denver, Boston], while a client in Boston would get > the list [Boston, Denver, Seattle]. > > To make things more complicated, I want to add a redundant origin in > each location and split traffic between them (like STEERING_WEIGHT > today) while taking into account the geo-ordering. I also want to be > able to force an ordering (like STEERING_ORDER today) among co-located > targets. > > In order to accomplish this I propose to: > 1. add two new steering types: GEO_ORDER and GEO_WEIGHT (by adding a > target of type GEO_*, a steering DS would then enable geo-ordering) > 2. associate a Delivery Service Origin with a latitude/longitude, > thereby associating a lat/long to a GEO_* target > > Item 1 is pretty straightforward and will also play nicely with the > current steering types (STEERING_ORDER and STEERING_WEIGHT). I've > completed a POC within Traffic Router that basically provides the > following ordering when mixing all 4 types in a single steering > delivery service: > - Negative STEERING_ORDER targets > - GEO_WEIGHT and GEO_ORDER targets, grouped by proximity to the > client, ordered by geo-order and the consistent-hashing from the > weightings > - STEERING_WEIGHT targets (consistent-hashed) > - Positive STEERING_ORDER targets > > Item 2 is not as straightforward because the simple thing would be to > just add an Origin Lat/Long field to the Delivery Service and call it > a day. However I don't think we should do that, and I'll dive more > into that in a separate thread (coming soon). > > Does anyone have questions/concerns about adding these new GEO_ORDER > and GEO_STEERING target types and geo-sorting them based upon > proximity to the client? Are you okay with the proposed ordering when > all the steering types are mixed together? > > - Rawlin
