Subject: [icnrg] Manifest and CCNx-KE slides

From: <[email-masked]>
Date: Wed, 4 Nov 2015 22:19:53 +0000

All,

Attached are the slides for today's talks on Manifests and the CCNx-KE protocol.

--
Christopher Wood

---

From: "Christian Timmerer (ITEC)" <[email-masked]>
Date: Fri, 6 Nov 2015 09:03:24 +0100

Dear Christopher, all,
  when reading your slides on the manifest, I was wondering whether it would be worth looking in the DASH MPD (spec online [1] and MPD schema [2]). In previous work we successfully demonstrated the implementation of dynamic adaptive streaming over CCN (DASH over CCN, we called it DASC) [3-4] and maybe it’s a good idea to reuse the MPD (or parts thereof) for ICN. That would allow ICN clients to natively support dynamic adaptive streaming of multimedia content.

Best regards,
 -Christian

[1] http://standards.iso.org/ittf/PubliclyAvailableStandards/c065274_ISO_IEC_23009-1_2014.zip
[2] http://standards.iso.org/ittf/PubliclyAvailableStandards/MPEG-DASH_schema_files/DASH-MPD.xsd
[3] http://www-itec.uni-klu.ac.at/bib/files/ICME_Overhead-Performance-DASHoverCCN.pdf <http://www-itec.uni-klu.ac.at/bib/files/ICME_Overhead-Performance-DASHoverCCN.pdf>
[4] http://www-itec.uni-klu.ac.at/bib/files/ICC2013_Mobile_DASHoverCCN.pdf <http://www-itec.uni-klu.ac.at/bib/files/ICC2013_Mobile_DASHoverCCN.pdf>

---
Priv.-Doz. DI Dr. Christian Timmerer
Assoc.-Prof | Multimedia Communication, Alpen-Adria-Universität Klagenfurt | blog.timmerer.com | dash.itec.aau.at
CIO | Head of Research and Standardization, bitmovin GmbH | www.bitmovin.com | www.dash-player.com | www.bitcodin.com
Geschäftsführer Förderverein Technische Fakultät | ftf.or.at

General chair of ACM Multimedia Systems Conference 2016 | http://www.mmsys.org/

> On 04 Nov 2015, at 23:19, [email-masked] wrote:
> 
> All,
> 
> <ke.pdf><manifestreqs.pdf>_______________________________________________
> icnrg mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.irtf.org/mailman/listinfo/icnrg <https://www.irtf.org/mailman/listinfo/icnrg>

---

From: David Oran <[email-masked]>
Date: Fri, 6 Nov 2015 17:11:56 +0900

> On Nov 6, 2015, at 5:03 PM, Christian Timmerer (ITEC) <[email-masked]> wrote:
> 
> 
> Dear Christopher, all,
There’s a lot of application-specific goop in a DASH Manifest. The idea here is to have something minimalist. The way I’d do something DASH-like is to have a separate type of object with all the required metadata and have that point to the primitive manifest(s) for actually fetching the objects.

> [3] http://www-itec.uni-klu.ac.at/bib/files/ICME_Overhead-Performance-DASHoverCCN.pdf
> [4] http://www-itec.uni-klu.ac.at/bib/files/ICC2013_Mobile_DASHoverCCN.pdf
> 
> ---
>> [email-masked]
>> https://www.irtf.org/mailman/listinfo/icnrg
> 
> _______________________________________________
> icnrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg

---

From: "Christian Timmerer (ITEC)" <[email-masked]>
Date: Fri, 6 Nov 2015 09:18:33 +0100

Dave, yes most likely a subset is sufficient but hope you agree in principle that this would be beneficial. We could even ask MPEG to specific a profile for ICN but that’s something we don’t have to start now...

> On 06 Nov 2015, at 09:11, David Oran <[email-masked]> wrote:
> 
>

---

From: David Oran <[email-masked]>
Date: Fri, 6 Nov 2015 17:25:02 +0900

> On Nov 6, 2015, at 5:18 PM, Christian Timmerer (ITEC) <[email-masked]> wrote:
> 
> 
> Dave, yes most likely a subset is sufficient but hope you agree in principle that this would be beneficial.
I agree that there are some good reasons to take the “H” out of DASH.
I agree that the data formats for describing how to structure and fetch adaptive video streams on an ICN network architecture is likely to look a whole lot like existing DASH Manifests.
I suspect that it will be tricky to figure out what parts of a DASH MPD are there because of the “DAS” and which pieces are there because of the “H”.

> We could even ask MPEG to specific a profile for ICN but that’s something we don’t have to start now…
If we can keep MPEG on task this would of course be quite beneficial. I’ll express skepticism that starting from the constraint that the result be a DASH “profile” will have a good outcome.

DaveO.

---

From: "Christian Timmerer (ITEC)" <[email-masked]>
Date: Fri, 6 Nov 2015 09:44:58 +0100

> On 06 Nov 2015, at 09:25, David Oran <[email-masked]> wrote:
> 
>> 
It’s mainly the fact that segments needs to be identified via HTTP-URLs, that’s it...

> If we can keep MPEG on task this would of course be quite beneficial. I’ll express skepticism that starting from the constraint that the result be a DASH “profile” will have a good outcome.
I don’t see this as a constraint, more like an opportunity but that’s something we don’t have to focus now.