Dear All, *Executive summary:* we would like to promote PR 108 <https://github.com/apache/incubator-trafficcontrol/pull/108> (or similar functionality) described in [image: Improvement] TC-55 Multi Delivery Services With Same Domain Name and Different Path Prefixes <https://issues.apache.org/jira/browse/TC-55>, to be pulled back to master, after review and required adaptations.
>From here on it's the use case description justifying this PR. As presented at the previous meetup, we would like to go forward making TC compatible with the Streaming Video Alliance <https://www.streamingvideoalliance.org/> Open Caching <https://www.streamingvideoalliance.org/technical-work/working-groups/open-caching/> architecture. In very high level, open caching means that another CDN (the typical use case is a commercial CDN) would be able to delegate traffic to open caches at the ISP premises. The full specs for those who are interested can be found on the SVA website, under Open Caching <https://www.streamingvideoalliance.org/technical-work/working-group-output/> . One of the main gaps are the differences in host name and URL structure. In open caching there is no interdependence of host names between the delegating CDN and the surrogate open cache system. In other words, the hostname of the ISP request router and caches is not indicative for the origin service, and all the information needed for service matching is in the URL path. *An example:* CDN *foo *is redirecting traffic of it's content provider customer example.com to ISP *bar*. Client manifest request from *foo *CDN: GET /vod/sports/final-index.m3u8 Host: foo.example.com (note that typically though the CDN is handling the traffic, the domain is of the content provider, example.com in this case). Foo CDN redirect response: HTTP/1.1 302 Found location http://tr.bar.com/*foo.example.com <http://foo.example.com/>*/vod/sports/final-index.m3u8 (note that the hostname is not indicative, the delegating host name is in the first path segment). Client request to traffic router: GET /*foo.example.com <http://foo.example.com/>*/vod/sports/f inal-index.m3u8 Host: tr.bar.com Traffic Router redirect response: HTTP/1.1 302 Found location http://server1.bar.com/ <http://server.bar.com/>*foo.example.com <http://foo.example.com/>*/vod/sports/final-index.m3u8 >From here the client requests the manifest and then the media files directly from the cache server (server1). *What is the reason for this approach ?* Think of it not in Traffic Control context but rather as a general use case of delegating HTTP traffic between different systems. Note that the delivery services are define by the CDN (foo) and are pushed to the ISP caching systems, which means the CDN needs to have the flexibility to define the DS to their own needs. Decoupling the ISP host names (traffic router and cache server) from the delegating host name has the following benefits: 1. No need for DNS changes for each new delivery service. This is even more important when using DNSSEC. 2. No need for certificate updates for each new delivery service. If the ISP hostnames are fixed, or at least fixed per partner CDN, then there is only one cert (per partner CDN). 3. Allows more flexibility when integrating with 3rd party commercial CDNs. *What is missing ?* The main gap is allowing a delivery service to match the service against path regexp, or a combination of host regexp and path regexp. This means that different DSs may have the same host regexp but with different path regexp. This was already suggested several times in the past and specifically in TC- 55 <https://issues.apache.org/jira/browse/TC-55>. We propose to re-visit TC- <https://issues.apache.org/jira/browse/TC-55>55 <https://issues.apache.org/jira/browse/TC-55> ,make any required changes in the original proposal and actual implementation in PR 108. We would highly appreciate any inputs and comments. Many thanks, Ori -- *Ori Finkelman*Qwilt | Work: +972-72-2221647 <072-222-1647> | Mobile: +972-52-3832189 <052-383-2189> | [email protected]
