1 / 10

CDNI Extended Design Team Meeting Virtual Meeting May 29, 2012

Models for adaptive -streaming-aware CDNI - Request Routing and Manifes t Files draft-brandenburg-cdni-has-01 , section 3.3. CDNI Extended Design Team Meeting Virtual Meeting May 29, 2012 Ray van Brandenburg (ray.vanbrandenburg@tno.nl). Request Routing and Manifest Files – General.

alodie
Download Presentation

CDNI Extended Design Team Meeting Virtual Meeting May 29, 2012

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Models for adaptive-streaming-aware CDNI-Request Routing and Manifest Filesdraft-brandenburg-cdni-has-01, section 3.3 CDNI Extended Design Team Meeting Virtual Meeting May 29, 2012 Ray van Brandenburg (ray.vanbrandenburg@tno.nl)

  2. Request Routing and Manifest Files – General • In a sense, Manifest Files can be considered a form of request routing • Recap, three methods for addressing chunks in a manifest • Relative URL (e.g. ‘segments/seg1.ts’) • Absolute URL with Redirection (e.g. ‘http://req_routing.cdn……’) • Absolute URL without Redirection (e.g. ‘http://surrogate2.cdn….’) • Some CDNs might prefer one method above the other • Some CDNs/CPs might NEED one method (e.g. for security, anti-deeplinking, etc.) • [Note: Should this be part of capability exchange?] • In some cases Content Provider might decide on type of URL used (e.g. in the case where the Content Provider delivers the manifest)

  3. Option 3.1: “Do-Nothing” Approach - 1 • Assumes no HAS awareness in uCDN/dCDN and no additions to CDNI Interfaces • Absolute URLs with Redirection: • Work without HAS awareness • manifest directs clients to uCDNRR • uCDN RR redirects clients to dCDN RR • dCDN RR redirects clients to dCDN surrogate • Creates very significant overhead • Full Inter-CDN Request Routing process for each individual chunk • [Question: with small chunks, is it even worthwhile for a uCDN to outsource delivery to a dCDN in this case?]

  4. Option 3.1: “Do-Nothing” Approach - 2 • Relative URLs: • Might or might not work depending on client implementation and dCDN capabilities • If a client uses the IP address instead of the host name as a prefix to the Relative URLs, dCDN is unable to resolve chunk request • Depends on initial manifest request process in dCDN (dCDN RR->dCDN Surrogate) to use IP addresses or hostnames • In all other cases, Relative URLs work • Suffers from brittleness • Absolute URLs without Redirection: • Does not work • Chunk URLs point to specific surrogates in uCDN • Neither uCDN or dCDN is able to adapt manifest

  5. Option 3.1: “Do-Nothing” Approach - 3 Effect on CDNI Interfaces: • None • Advantages/Drawbacks: + Supports Absolute URLs with Redirection + Does not require HAS awareness and/or changes to the CDNI Interfaces - Not possible to use Absolute URLs without Redirection • - Support for Relative URLs suffers from some brittleness. Makes • assumptions on client-side implementation of the HAS client or on • structure of PATH or QUERY • - Creates significant signaling overhead in case Absolute URLs with Redirection are used (inter-CDN request redirection for each chunk)

  6. Option 3.2: Manifest File rewriting by uCDN- 1 • Presents solution to request routing overhead created by the use of Absolute URLs with Redirection • Allows the uCDN to modify manifest so that the URLs in the manifest point to the RR-function of the dCDN • Requires uCDN to be aware of location of dCDN RR • Which it needs anyway for redirection and which it can query through CDNI Request Routing Interface • Two options: • Perform manifest rewriting once (for all future clients) • Perform manifest rewriting for every individual client • Allows uCDN to directly place surrogate location in the manifest file • Exposes (limited) dCDN topology information to uCDN

  7. Option 3.2: Manifest File rewriting by uCDN - 2 Effect on CDNs/CDNI Interfaces: • CDNI Request Routing Interface: Allow uCDN to query dCDN for the location of its request routing function (is this covered by the existing RR interface?) Advantages/Drawbacks: + Possible to significantly decrease signalling overhead when using Absolute URLs. + Minimal changes to CDNI Interfaces (no HAS awareness) + Does not require HAS awareness in dCDN - Requires high level of HAS awareness in uCDN (for modifying manifest files)

  8. Option 3.3: Two-step Manifest File rewriting - 1 • Allows for dCDN to perform further manifest rewriting • uCDN does first round of rewriting (replacing uCDN RR with dCDN RR) • dCDN does second round of rewriting (replacing dCDN RR with dCDN Surrogates) • Requires high-level of HAS awareness in both dCDN and uCDN • Probably useful to add ‘do not change manifest’ field to Metadata Interface • Allows uCDN to signal that the dCDN is not allowed to change the manifest file

  9. Option 3.3: Two-step Manifest File rewriting - 2 Effect on CDNs/CDNI Interfaces: • CDNI Metadata Interface: Add necessary fields for conveying HAS specific information (e.g. the files that make up the Content Collection) to the dCDN Advantages/Drawbacks: + Allows dCDN to use Absolute URLs without Redirection without having to convey sensitive information to the uCDN • Requires high level of HAS awareness in dCDN (for modifying manifest files) • Requires adding HAS-specific information to the CDNI Metadata Interface • Complex

  10. Summary

More Related