Content Preposition feature

[Zhilin Huang]

Hi guys,

I would like to propose a summary on the Content Preposition feature we are working on. Would you please help to review, any comments are welcomed. Thanks in advance.

This Content Preposition feature will support to cache and update a list of contents to selected cache nodes by schedule. When configuring a "Preposition" Delivery Service, operator needs to provide an ingest manifest file url. Then cache servers assigned in this delivery service will download all content items listed in the ingest manifest at a predefined time. When requested from client later on, the content will be served the CDN network, no extra request will be sent to OS.

Considering the cyclone buffer cache in ATS, operator could configure to pin the preposition contents in cache. As the dynamic contents may go around the cyclone buffer, to avoid frequent read rewrite, a dedicate volume could also be configured to store the preposition contents.

An instrument log file will be created on each cache server. And the status of the prefetched contents will be updated to that log file periodically.

The following are the main functions will be included in this feature:

•       Protocol: Only support HTTP(s)

•       Header/Cookie Authentication: When sending request to OS, customized headers and/or cookie could be configured for authentication purpose.

•       Optionally use HTTP Proxy to access Manifest file

•       Policy Based Ingest: Content will be ingested based on ingest manifest file.

–      The ingest file will include the follow items:

•       Explicit List: list of individual files

•       Directory: recursively crawl all files under the directory

•       ABR Manifest: Generate ingest manifest from HLS/HSS/DASH Manifest

–      Content will be evicted if items removed

–      Each item could define a retry time and interval for failure

•       QoS Knobs

–      Scheduled Time of Day

–      Rate Limiting

For details about this feature, you can take a look at the design document at https://docs.google.com/document/d/1ngyi_uCoKVC7VqrudD1poipqCsKvUSr02TlPXgIT29U/edit?usp=sharing

[Steve Malenfant]

Zhilin,

Are we taking in consideration HTTP of the consistent hashing of both Requests Routers (w/dispersion) and also on the Edge to Mid side?

Steve

--
You received this message because you are subscribed to the Google Groups "traffic_control-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to traffic_control-discuss+unsub...@googlegroups.com.
To post to this group, send email to traffic_control-discuss@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/traffic_control-discuss/ddd15527-ae19-406b-949a-f7b237ae151c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Zhilin Huang]

Hi Steve,

We have not taking consideration of consistent hashing to spread the contents. Each contents will be pre-ingested to all Edge caches and/or Mid caches assigned.

The main reason is we do not want the pre-ingested contents affected by the availability or health/load of caches.

The secondary reason is I am sure about the client behaviours for ABR. Will all clients only use the main ABR manifest URL to query Traffic Router, or may some kind of clients also use child ABR manifest or chunk URL to query Traffic Router.

We do have considered to save storage, user could select enable this feature only on Edge or Mid.

Zhilin

在 2016年8月9日星期二 UTC+8下午9:51:22，Steve Malenfant写道：

[Eric Friedrich (efriedri)]

Steve-

  Content affinity for prepositioned content is certainly something we are interested in. Two of the challenges we need solutions for are

a) How to determine which cache content should be prepositioned on, given that prepositioning may occur when the desired cache is offline/overloaded. 

b) How to pin content into the desired cache. Today cache.config is generated by Traffic Ops which has no knowledge of the content affinity consistent hash assignments. Our current pinning strategy is to pin based on Origin Server FQDN only and not per-content regexes. 

There are definitely mechanisms to address the above, but they were all considered more disruptive and kludgy than we wanted to be for the introduction of prepositioning. We may certainly expand later though if we can come up with some easier to implement improvements to the consistent hashing and cache.config generation. 

—Eric

To unsubscribe from this group and stop receiving emails from it, send an email to traffic_control-d...@googlegroups.com.
To post to this group, send email to traffic_con...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/traffic_control-discuss/9934f6ac-fffa-4132-abf2-566920e352c9%40googlegroups.com.

[j...@knutsel.com]

Hi Zilhuan, Eric,

Some random thoughts on this. I'll try to dig in a bit more today, and really review. 

1) Consistent hashing... I don't know... There are cases where you would have very large cache groups (50+ caches), and you would store it on all caches in that cg this way? 

2) Is the pin-in-cache and/or separate volume really needed? We've found that letting ATS "do it's thing" on a large volume is not as bad as a lot of people think it is. 

3) I think CDNi (control/triggers) has a pre-positioning interface, did you look at that for the implementation of the Manifest?

4) I am not sure this should be a delivery service type? (I think we are overloading that term too much, and maybe should make it HTTP/DNS only in the future, and have the rest of the options explicitly called out, not implicit in a DS type)

Like I said, I'll try to review more today.

Rgds,

[Eric Friedrich]

Hey Jan-

  Didn't want to let this one slip through the cracks. 

On Thursday, August 11, 2016 at 9:02:17 AM UTC-4, jvd wrote:

Hi Zilhuan, Eric,

Some random thoughts on this. I'll try to dig in a bit more today, and really review. 

1) Consistent hashing... I don't know... There are cases where you would have very large cache groups (50+ caches), and you would store it on all caches in that cg this way? 

EF> The current approach is definitely not ideal for HTTP(S) delivery services although its exactly what you'd want for a DNS Delivery Service. We want to enable consistent hashing but need some more discussion and more time before we can propose an implementation. 

 

2) Is the pin-in-cache and/or separate volume really needed? We've found that letting ATS "do it's thing" on a large volume is not as bad as a lot of people think it is. 

EF> We've made both of these configurable, and I expect it will vary on a customer by customer basis. Some deployments are very sensitive to cache fill bandwidth while some are extremely sensitive to latency. The performance penalties associated with pin-in-cache are certainly concerning though. 

 

3) I think CDNi (control/triggers) has a pre-positioning interface, did you look at that for the implementation of the Manifest?

EF> No, haven't looked into this but its a good point. We should certainly investigate that format. 

 

4) I am not sure this should be a delivery service type? (I think we are overloading that term too much, and maybe should make it HTTP/DNS only in the future, and have the rest of the options explicitly called out, not implicit in a DS type)

EF>  Thats a good point. Zhilin- is there any reason we can't eliminate the DS type?

[Zhilin Huang]

Hi Eric,

I think we can eliminate the DS type.

Thanks,

Zhilin

在 2016年8月18日星期四 UTC+8下午9:04:52，Eric Friedrich写道：