Makes perfect sense. thanks for the clarification. On Tue, Feb 27, 2018 at 11:32 AM, Rawlin Peters <[email protected]> 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. The type of each target would either be > GEO_ORDER or GEO_WEIGHT, depending on if we want a forced ordering or > something like a 50/50 split, respectively. > > Say I have the following targets in my Steering DS: > > Seattle1 (S1): > GEO_ORDER: 1 > > Seattle2 (S2): > GEO_ORDER: 2 > > Denver1 (D1): > GEO_WEIGHT: 50 > > Denver2 (D2): > GEO_WEIGHT: 50 > > Boston1 (B1): > GEO_ORDER: 1 > > Boston2 (B2): > GEO_ORDER: 2 > > For a client in Seattle requesting /foo, they would get the list [S1, > S2, D2, D1, B1, B2], where D1 and D2 are consistent hashed based upon > the requested URL and given weight. So if they request /bar maybe D1 > and D2 are switched so they get [S1, S2, D1, D2, B1, B2]. > > - Rawlin > > On Mon, Feb 26, 2018 at 8:18 PM, Jeremy Mitchell <[email protected]> > wrote: > > 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 location?) > > > > Then you'd create a steering delivery service with 3 targets (the > HTTP_LIVE > > ds's you just created.) Each target would have type = GEO_ORDER and > value = > > ? > > > > I'm getting confused with that above scenario. How many targets would you > > have? What would the type of each target be and what would the value of > > each target be? > > > > Jeremy > > > > > > On Fri, Feb 23, 2018 at 3:40 PM, Rawlin Peters <[email protected]> > > 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 > >> >
