Subject: [CDNi] Notes from May 29 Extended Design Team Meeting on "Adaptive Streaming"

From: Francois Le Faucheur <[email-masked]>
Date: Thu, 31 May 2012 15:27:02 +0200

Folks,

Here are draft notes from the May 29 extended design team meeting. Let us know if you have comments.

=========================================================================

Extended Design Team Meeting of CDNI on "Adaptive Streaming"
Date: Tuesday, May 29, 2012
Start Time: 07:00 PDT (e.g San Francisco, USA) = 10:00 EDT (e.g Boston, USA) = 16:00 CET (e.g Paris, France) = 22:00 CST (e.g. Beijing, China)
Finish Time: 10:00 PDT (e.g San Francisco, USA) = 13:00 EDT (e.g Boston, USA) = 19:00 CET (e.g Paris, France) = 01:00 CST (e.g. Beijing, China)

The webex recording for the meeting (missing the first 5-10 minutes of the discussion) is available at:
https://cisco.webex.com/ciscosales/lsr.php?AT=pb&SP=MC&rID=61050812&rKey=a34577e4e4e8ec5a 

SInce the full details of the discussion is accessible through the webex recording, the notes below focus on the Action Items and conclusions of the discussions.
(by merge of notes from Scott Wainner and Francois):

intro on Extended Design Team Meeting: Francois & Rich
==========================================
* This meeting is not a formal Interim Meeting of WG, it is an extended design team meeting.
* Let's remember that we have a strong motivation to develop first what is REQUIRED to make HAS work. We need to focus on fundamentals to make HAS work vs how to use CDN-I to make things work better.

Intro to the new version of draft-brandenburg-cdni-has + recap on key HAS terminology: Ray
===================================================================
See slides.
Action Items:
	* add to cdni-has a discussion on handling of VoD vs Live when discussing Manifest Files: Ray
	* add to cdni-has a discussion on other conceptual differences across HAS schemes: Ray, with input provided by Kevin
	* add to cdni-has a discussion on the fact that different chunks of the same "HAS session" may be coming from different origin servers and may be following different CDN paths. Include the example of Ad insertion possibly locally sourced: Ray, possibly with input from Kevin
	* add to cdni-has the distinction between DNS redirection and HTTP redirection in all sections/discussions (e.g. pros & cons discussions) where it is relevant (e.g. when discussing impact of per-chunk request routing, the impact is different for DNS and HTTP): Ray
	* add to cdni-has a clarification that, in some situations, the manifest file follows the same delivery path as the corresponding chunks (and therefore may be visible to CDNs on the chunk delivery path) and that in some situations the manifest file follows a different delivery path (e.g. delivery directly by CSP or uCDN to client) and therefore is not visible to dCDN. Indicate CDNI must support both situations.: Ray

File Management and Content Collections (prezo + discussion): Ray
==================================================
See slides. They present two options (1.1 and 1.2)

Action Items:
	* add to cdni-has a discussion of a 3rd intermediary option (1.1bis) where:   (Ray)
		o an "Access Correlation Hint" is distributed in CDNI Metadata for all chunks of a Content Collection to indicate those are likely to be requested in a short time window. This can help dCDN Surrogate to implement local File Storage optimization for VoD items (e.g. bundle all files with same Access Correlation Hint value in a single bundle/file), therefore reducing number of stored files while minimizing bundling/unbundling overhead. In pros & cons discussion indicate that impact on CDNI interfaces is very small (since the new  "Access Correlation Hint" doe snot include any HAS-scheme awareness) but expected benefit is small too.
	* add to cdni-has a recommendation sub-section under 3.1 indicating that:    (Ray)
		o recommended approach is 1.1
		o approach 1.bis does not seem to bring something significant (Really no file management optimization … only file storage benefit), and single CDNs already do local optimization today without this. It is the responsibility of dCDN to do scaleable file management, not of CDNI.
		o approach 1.2 would bring benefits but requires full HAS awareness and significant CDNI extension that would significantly impact our milestones, so we don't recommend to include in current work. Good candidate for rechartering when initial solution is done.

Content Acquisition of Content Collections (prezo + discussion): Ray
==================================================
See slides. They present two options (2.1 and 2.2)

Action Items:
	* add to cdni-has a recommendation sub-section under 3.2 indicating that:   (Ray)
		o recommended approach is 2.1. It is definitely sufficient to "make HAS work".
		o approach 2.2 would bring benefits but requires full HAS awareness and significant CDNI extension that would significantly impact our milestones, so we don't want to include in current work. Good candidate for rechartering when initial solution is done.
	* in cdni-has, update the discussion on content acquisition to distinguish between Dynamic Acquisition of HAS content and Prepositioning of HAS content. With Dynamic Acquisition, triggered acquisition of subsequent chunks probably has an extra benefit of avoiding acquisition latency on cache-miss. With Prepositioning, there may be specific ways to enhance those (e.g. a single CDNI Control prepositioning request lists all chucks to be acquired). (Ray)

Request Routing of HAS content (prezo + discussion): Ray
============================================
See slides. They present three options (3.1, 3.2 and 3.3) -( there is a typo in the slides so sometimes they show up as 6.x).

Action Items:
	* in cdni-has add statement that client behaviors not always in line with relative/absolute URIs expected behavior - and therefore needs to be taken into account when discussing Manifest Manipulation. mention that the issue with Relative-URL is not specific to HAS; it is also relevant for Web. Pages have relative-URLs that reference media on the same page which may actually be 'delegated'. (Ray, possibly with input from Ben and Matt)
	* in cdni-has, in section discussing option 3.1 and Relative URIs, clarify the exact situation resulting in breaking Relative URIs. Discuss whether this already exists in single CDN: Ray (possibly with input from Ben).
	* in cdni-has, in section discussing option 3.1 and Absolute URIs WIth Redirection, expand discussion to describe load impact separately for HTTP and DNS:  Ray 
	* in cdni-has, in section discussing option 3.2, clarify that this is somewhat transparent to CDNI (i.e. it happens in uCDN before CDNI plays) but that it is worth explicitly discussing (in particular in the framework) _if we want to allow it_ because it affects how the uCDN will make use of the CDNI interfaces when using a dCDN. Clarify that, in recursive mode, the case involving redirection directly to the Surrogate doe snot need the dCDN to "advertise" topology information, all it requires is the dCDN to indicate the Surrogate in the CDN Request Routing/Redirection response : Ray

	* add to cdni-has a recommendation sub-section under 3.3 indicating that:   (Ray)
		o options 3.1 must be supported
		o option 3.2 might be optionally allowed in uCDN (without any specific extensions to CDNI interfaces). We need a little more discussion as to whether it shoudl actually be allowed or not.
		o option 3.2 would significantly impact our milestones and raises a number of questions on potential brittleness so we don't recommend to include in current work. 
	* Do the existing HAS schemes allow combination of use of Relative URLs for normal access to content + use of Absolute URLs with Redirection for backup access to content (in case normal access fails)?

Next steps:
========
	* continuation virtual meeting of extended design team on HAS on 7 June 2012
	* Ray & co-authors to rev up cdni-has
	* run another virtual meeting of extended design team in 2nd half of June.