You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficcontrol.apache.org by Ori Finkelman <or...@qwilt.com> on 2017/05/13 15:07:56 UTC

Delivery Services compliance to SVA Open Caching model (TC-55)

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> | orif@qwilt.com