Models for adaptive-streaming-aware CDNI - File

Document Sample
Models for adaptive-streaming-aware CDNI - File Powered By Docstoc
					          Models for
adaptive-streaming-aware CDNI
               -
 Request Routing and Manifest 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)
                                                  1
        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)



                                                                                         2
                          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
      1.    manifest directs clients to uCDN RR
      2.    uCDN RR redirects clients to dCDN RR
      3.    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?]



                                                                                         3
                           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



                                                                                                4
                                 Option 3.1:
                           “Do-Nothing” Approach - 3
                           Relative URL             Absolute URL with        Absolute URL without
                                                    Redirection              Redirection
Option 6.1                 Works, with some         OK, with significant     Does not work
                           brittleness              overhead


      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)


                                                                                                    5
                          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


                                                                                 6
                        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)

                                                                         7
                      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


                                                                           8
                      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


                                                                       9
                                          Summary
                       Relative URL       Absolute URL with      Absolute URL without   Impact on CDNI
                                          Redirection            Redirection            Interfaces
Option 6.1: No         Works, with some   OK, with significant   Does not work          None
optimizations          brittleness        overhead
Option 6.2: uCDN       Works, with some   Works                  Works, but requires    Very limited
manifest rewriting     brittleness                               dCDN to share
                                                                 surrogate location
Option 6.3: two-step   Works, with some   Works                  Works                  Significant
manifest rewriting     brittleness




                                                                                                         10

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:1
posted:6/11/2014
language:English
pages:10