Models for adaptive-streaming-aware CDNI - File Management and Content Collections...

6
Models for adaptive-streaming-aware CDNI - File Management and Content Collections draft-brandenburg-cdni-has-01, section 3.1 CDNI Extended Design Team Meeting Virtual Meeting May 29, 2012 Ray van Brandenburg ([email protected])

Transcript of Models for adaptive-streaming-aware CDNI - File Management and Content Collections...

Page 1: Models for adaptive-streaming-aware CDNI - File Management and Content Collections draft-brandenburg-cdni-has-01, section 3.1 CDNI Extended Design Team.

Models for adaptive-streaming-aware CDNI

-File Management and Content Collections

draft-brandenburg-cdni-has-01, section 3.1

CDNI Extended Design Team MeetingVirtual MeetingMay 29, 2012

Ray van Brandenburg ([email protected])

Page 2: Models for adaptive-streaming-aware CDNI - File Management and Content Collections draft-brandenburg-cdni-has-01, section 3.1 CDNI Extended Design Team.

Key Considerations regarding File Management

• Content Collection may consists of very large number of files (e.g. 100s to 1000s)

• Large numbers of files increases file management overhead in CDN

• Fragments are allowed to be stored as individual files or as part of a single file (e.g. Fragmented MP4)– Some CDNs might prefer one method, while others prefer the other

Page 3: Models for adaptive-streaming-aware CDNI - File Management and Content Collections draft-brandenburg-cdni-has-01, section 3.1 CDNI Extended Design Team.

Option 1.1: “Do-Nothing” Approach - 1

• Assumes no HAS awareness in uCDN/dCDN and no additions to CDNI Interfaces

• Result: dCDN is not explicitely made aware of the relationship between chunks (unaware of which files make up Content Collection)

• Means that dCDN will have to store individual files and can’t ‘bundle’ files in any way– (Possible exception: in case content is fragmented and manifest file

contains byte range requests)

Page 4: Models for adaptive-streaming-aware CDNI - File Management and Content Collections draft-brandenburg-cdni-has-01, section 3.1 CDNI Extended Design Team.

Option 1.1: “Do-Nothing” Approach - 2

Effect on CDNI Interfaces: – None

Advantages/Drawbacks:+ No changes to CDNI Interfaces necessary- dCDN is forced to store all chunks as individual files

Page 5: Models for adaptive-streaming-aware CDNI - File Management and Content Collections draft-brandenburg-cdni-has-01, section 3.1 CDNI Extended Design Team.

Option 1.2: “Allow single file storage of fragmented content” - 1

• dCDN might prefer to store fragmented content as single file on surrogates – Reduces file management overhead

• Two options:– Acquire content as part of single file (see section on Content Acquisition)– Merge the different chunks together and place them in the same

container (e.g. fragmented MP4)

• Requires dCDN to be fully HAS aware– Type of HAS used– Name and type of manifest file etc.

Page 6: Models for adaptive-streaming-aware CDNI - File Management and Content Collections draft-brandenburg-cdni-has-01, section 3.1 CDNI Extended Design Team.

Option 1.2: “Allow single file storage of fragmented content” - 2

Effect on CDNI Interfaces: – CDNI Metadata Interface: Add fields for indicating the particular type

of HAS (e.g. MPEG DASH or HLS) that is used and whether segments or fragments are used

– CDNI Metadata Interface: Add field for indicating the name and type of the manifest file(s)

Advantages/Drawbacks:+ Allows dCDN to store fragmented content as a single file, reducing file management overhead- Complex operation, requiring dCDN to be fully HAS aware