Subject: [icnrg] I-D Action: draft-irtf-icnrg-videostreaming-03.txt

From: Marie-Jose Montpetit <[email-masked]>
Date: Tue, 17 Mar 2015 16:17:17 +0000

Hi all:

I reviewed the draft and here are some comments. I think overall the draft does cover pretty well the "state of the art" in video/telelvision transmission and how ICNs can be included. 

1. The adaptive streaming section is particularly strong and I was thinking that the title indicates that. The rest of the draft is not about "adaptive" - should the title be changed?
2. The IPTV section takes a very traditional view of IPTV: multicast real-time. But one must not forget that a lot of implementations include "trick plays" (FF, pause and rewind) that often transform the multicast into multiple unicast. And of course in network "digital video recorders" where personal content is cached for further viewing that may of may not use multicast but could profit of course from ICNs both in changing and accessing the content. I think mentioning this would enhance that section.
3. The multiple wireless: are we thinking multipath? I think that for that ICN would be nice in providing deployment scenarios that are independent of the actual transmission.
4. While a lot of the document addresses P2P there is little mention of the other "multisource-multidestination" services that are consistent with shared video experience; these raise the issues of media synchronization across multiple networks and devices - a hard problem. Some ICN basic mechanisms (strategy layers?) could be helpful here. The multiple screen experience 
5. The network coding section could be stronger. As regards video (unicast, multicast and P2P) network coding has shown promise in reducing buffering events and improving on caching efficiency. Some of the issues raised in this section have been addressed in the network coding community (timing being one with multiple demos). And network coding is not only multistream but can also be used in-stream as an equivalent of a composable erasure code. Actually the IETF nwcrg while not addressing ICN is looking at architecture and there could be avenues for collaboration.

But again overall a good document!

I will be in Dallas and can discuss some more.

Marie-José

Marie-Jose Montpetit, Ph.D.
[email-masked]
@SocialTVMIT

---

From: Cedric Westphal <[email-masked]>
Date: Tue, 17 Mar 2015 17:36:01 +0000

Hi Marie-Jose,

Thanks for your comment. I'm looking forward to discuss this with you in Dallas, especially the IPTV section. 
Best,

C.

-----Original Message-----
From: icnrg [mailto:[email-masked]] On Behalf Of Marie-Jose Montpetit
Sent: Tuesday, March 17, 2015 9:17 AM
To: icnrg
Cc: Liushucheng (Will); Börje Ohlman; [email-masked]; Dr. Jianping Wang; Dirk Kutscher
Subject: [icnrg] I-D Action: draft-irtf-icnrg-videostreaming-03.txt

Hi all:

1. The adaptive streaming section is particularly strong and I was thinking that the title indicates that. The rest of the draft is not about "adaptive" - should the title be changed?
2. The IPTV section takes a very traditional view of IPTV: multicast real-time. But one must not forget that a lot of implementations include "trick plays" (FF, pause and rewind) that often transform the multicast into multiple unicast. And of course in network "digital video recorders" where personal content is cached for further viewing that may of may not use multicast but could profit of course from ICNs both in changing and accessing the content. I think mentioning this would enhance that section.
3. The multiple wireless: are we thinking multipath? I think that for that ICN would be nice in providing deployment scenarios that are independent of the actual transmission.
4. While a lot of the document addresses P2P there is little mention of the other "multisource-multidestination" services that are consistent with shared video experience; these raise the issues of media synchronization across multiple networks and devices - a hard problem. Some ICN basic mechanisms (strategy layers?) could be helpful here. The multiple screen experience 5. The network coding section could be stronger. As regards video (unicast, multicast and P2P) network coding has shown promise in reducing buffering events and improving on caching efficiency. Some of the issues raised in this section have been addressed in the network coding community (timing being one with multiple demos). And network coding is not only multistream but can also be used in-stream as an equivalent of a composable erasure code. Actually the IETF nwcrg while not addressing ICN is looking at architecture and there could be avenues for collaboration.

Marie-José

---

From: Dirk Kutscher <[email-masked]>
Date: Tue, 17 Mar 2015 22:21:08 +0000

Thank you, Marie-Jose, for the review!

Co-authors, can you discuss the points that Marie-Jose raised and prepare a response so that we can discuss next steps in Dallas?

--
Thanks,
Dirk

> On 17 Mar 2015, at 17:17, Marie-Jose Montpetit <[email-masked]> wrote:
> 
> Hi all:
>

---

From: Cedric Westphal <[email-masked]>
Date: Wed, 18 Mar 2015 00:13:27 +0000

Hi Dirk,

I will respond in-line:

-----Original Message-----
From: icnrg [mailto:[email-masked]] On Behalf Of Dirk Kutscher
Sent: Tuesday, March 17, 2015 3:21 PM
To: Marie-Jose Montpetit
Cc: [email-masked]; Börje Ohlman; icnrg; Dr. Jianping Wang; Liushucheng (Will)
Subject: Re: [icnrg] I-D Action: draft-irtf-icnrg-videostreaming-03.txt

--
Thanks,
Dirk

> 1. The adaptive streaming section is particularly strong and I was thinking that the title indicates that. The rest of the draft is not about "adaptive" - should the title be changed?

We can remove the "Adaptive" from the title, so as to be inclusive of other forms of video streaming. 

> 2. The IPTV section takes a very traditional view of IPTV: multicast real-time. But one must not forget that a lot of implementations include "trick plays" (FF, pause and rewind) that often transform the multicast into multiple unicast. And of course in network "digital video recorders" where personal content is cached for further viewing that may of may not use multicast but could profit of course from ICNs both in changing and
accessing the content. I think mentioning this would enhance that section.

This is a valid point. ICN should inherently support the multiple unicast scenario after a pause or a rewind, so it can be mentioned. The in-network DVR scenario has been discussed, but someone raised the issue of what type of guarantees would there be that the content would be there and it seemed it would require an application layer solution rather than a network service. Still, we can add a mention of it. 

> 3. The multiple wireless: are we thinking multipath? I think that for that ICN would be nice in providing deployment scenarios that are independent of the actual transmission.

Any ICN could be multipath, it should be a generic assumption. We can clarify this. 

> 4. While a lot of the document addresses P2P there is little mention of the other "multisource-multidestination" services that are consistent with shared video experience; these raise the issues of…

Is there an interrupted thought here? The multi-source/multi-destination service should be supported by ICN, but not necessarily by the existing solutions considered in the draft. Anyhow, please clarify!

We can add some text that network coding is more than just multistream.

Again, thanks for the comments!

C.

> Marie-Jose Montpetit, Ph.D.

_______________________________________________
icnrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/icnrg

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Wed, 18 Mar 2015 00:25:31 +0000

See below.

> snip/snip

> Is there an interrupted thought here? The multi-source/multi-destination service should be supported by ICN, but not necessarily by the existing solutions considered in the draft. Anyhow, please cl…
Yes it seems the rest of the sentence got away - what is missing is that the multiple screen experience is very well supported by an ICN as each device addresses content not technology.
> Again, thanks for the comments!
Thanks

---

From: Andrea Detti <[email-masked]>
Date: Wed, 18 Mar 2015 08:56:01 +0100

Dear Cedric,

if necessary next week I can have a look at the 
"multisource-multidestination" (multiple screen)  topic and write 
something by revising the literature. Just to start the discussion.

Regards,

Andrea

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Wed, 18 Mar 2015 10:04:01 +0000

Actually there is not a lot in the literature. At least the “academic” stuff. It is mostly implementation.

> On Mar 18, 2015, at 3:56 AM, Andrea Detti <[email-masked]> wrote:
> 
> Dear Cedric,
> 
> if necessary next week I can have a look at the "multisource-multidestination" (multiple screen)  topic and write something by revising the literature. Just to start the discussion.
> 
> 
> Regards,
> 
> Andrea
> 
> 
> 
>> [email-masked] <mailto:[email-masked]>
>> @SocialTVMIT
>> 
>>> snip/snip
>>>> [email-masked] <mailto:[email-masked]>
>>>> @SocialTVMIT
>>>> 
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.irtf.org/mailman/listinfo/icnrg <https://www.irtf.org/mailman/listinfo/icnrg>
>>> 
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.irtf.org/mailman/listinfo/icnrg <https://www.irtf.org/mailman/listinfo/icnrg>
>> 
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.irtf.org/mailman/listinfo/icnrg <https://www.irtf.org/mailman/listinfo/icnrg>
>

---

From: Andrea Detti <[email-masked]>
Date: Wed, 18 Mar 2015 12:16:28 +0100

Could you suggest some links please?

Andrea

On 03/18/2015 11:04 AM, Marie-Jose Montpetit wrote:
>> On Mar 18, 2015, at 3:56 AM, Andrea Detti <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Dear Cedric,
>>

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Wed, 18 Mar 2015 12:22:32 +0000

There are some reports on multiscreen viewing that you can find. Let's talk next week.

Marie-José Montpetit
[email-masked]<mailto:[email-masked]>
[email-masked]<mailto:[email-masked]>

On Mar 18, 2015, at 07:17, Andrea Detti <[email-masked]<mailto:[email-masked]>> wrote:

Andrea

Marie-Jose Montpetit, Ph.D.
[email-masked]<mailto:[email-masked]>
@SocialTVMIT

On Mar 18, 2015, at 3:56 AM, Andrea Detti <[email-masked]<mailto:[email-masked]>> wrote:

Dear Cedric,

Regards,

Andrea

See below.
Marie-Jose Montpetit, Ph.D.
[email-masked]<mailto:[email-masked]>
@SocialTVMIT

snip/snip

Thanks

C.

Marie-José

Marie-Jose Montpetit, Ph.D.
[email-masked]<mailto:[email-masked]>
@SocialTVMIT

_______________________________________________
icnrg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/icnrg

_______________________________________________
icnrg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/icnrg

_______________________________________________
icnrg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/icnrg

---

From: Niall Murray <[email-masked]>
Date: Thu, 19 Mar 2015 13:30:07 +0000

Hello All,
Some comments on the draft as follows:

pg5: Use Case - mentions QoE - since this document is likely to be read by
a broad audience from different areas I think the definition of QoE (from
Qualinet) should be included to give context (if not, at least referenced).
I also think it would help if this aspect was brought forward to the
introduction. It is referred to throughout the document, the aim of this
document (I imagine) is to support these the various scenarios with
enhanced QoE.

My key point is wrt synchronization - intra - inter - and inter
destination. This was touched on by another reviewer but based on the
scenarios outlined, how is synchronized delivery maintained across the
various scenarios- this issue is intimated in a number of places throughout
the document e.g. pg 9 "the support for potentially multiple sources", pg
11 "synch of multiple content streams" (I think this should be clarified to
include intra - for layers of the same video or audio stream and also inter
- synch between audio - audio. Based on evolving ICN structure this problem
will become more complex than for existing end-to-end system. In addition
an additional issue for video conferencing in the form of inter destination
synch exists, not to mention the nice mass-media distribution scenario.

To conclude, I would like to see an additional Future steps for ICN
(section 9) to include synchronization (the requirements of which will be
different based on application or scenario). Maybe the authors feel that
this aspect demands an ID itself and hence the reason for its omission? If
this is the case, I think this should be stated.

There are a number of typos in the document but I guess these can be
addressed in a later version.

Some other comments on network coding etc are discussed already.

I think the document is nicely structured and the flow makes sense to me.
Its presentation is very timely.

Kind Rgs
Niall Murra

On 25 February 2015 at 20:38, <[email-masked]> wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>  This draft is a work item of the Information-Centric Networking Working
> Group of the IETF.
>
>         Title           : Adaptive Video Streaming over ICN
>         Authors         : Stefan Lederer
>                           Cedric Westphal
>                           Christopher Mueller
>                           Andrea Detti
>                           Daniel Corujo
>                           Christian Timmerer
>                           Daniel Posch
>                           Aytac Azgin
>                           Sucheng Liu
>         Filename        : draft-irtf-icnrg-videostreaming-03.txt
>         Pages           : 37
>         Date            : 2015-02-25
>
> Abstract:
>    This document considers the consequences of moving the underlying
>    network architecture to an Information-Centric Network (ICN)
>    architecture on video distribution. As most of the traffic in future
>    networks is expected to be video, we consider how to modify the
>    existing video streaming mechanisms. Several important topics
>    related to video distribution over ICN are presented, covering a
>    wide range of scenarios: we look at how to evolve DASH to work over
>    ICN, and leverage the recent ISO/IEC MPEG Dynamic Adaptive Streaming
>    over HTTP (DASH) standard; we consider layered encoding over ICN;
>    P2P mechanisms introduce distinct requirements for video and we look
>    at how to adapt PPSP for ICN; IPTV adds delay constraints, and this
>    will create more stringent requirements over ICN as well. As part of
>    the discussion on video, we discuss DRMs in ICN. Finally, in
>    addition to consider how existing mechanisms would be impacted by
>    ICN, this document lists some research issues to design ICN specific
>    video streaming mechanisms.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-irtf-icnrg-videostreaming/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-irtf-icnrg-videostreaming-03
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-irtf-icnrg-videostreaming-03
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>

---

From: Cedric Westphal <[email-masked]>
Date: Thu, 19 Mar 2015 17:34:11 +0000

Thanks Niall for reading the draft. Response in-line below…
BR,

C.

From: icnrg [mailto:[email-masked]] On Behalf Of Niall Murray
Sent: Thursday, March 19, 2015 6:30 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [icnrg] I-D Action: draft-irtf-icnrg-videostreaming-03.txt

Hello All,

pg5: Use Case - mentions QoE - since this document is likely to be read by a broad audience from different areas I think the definition of QoE (from Qualinet) should be included to give context (if not, at least referenced). I also think it would help if this aspect was brought forward to the introduction. It is referred to throughout the document, the aim of this document (I imagine) is to support these the various scenarios with enhanced QoE.

CW: Very good point. I’ll add a citation to the Qualinet white paper and bring this aspect forward into the introduction.

My key point is wrt synchronization - intra - inter - and inter destination. This was touched on by another reviewer but based on the scenarios outlined, how is synchronized delivery maintained across the various scenarios- this issue is intimated in a number of places throughout the document e.g. pg 9 "the support for potentially multiple sources", pg 11 "synch of multiple content streams" (I think this should be clarified to include intra - for layers of the same video or audio stream and also inter - synch between audio - audio. Based on evolving ICN structure this problem will become more complex than for existing end-to-end system. In addition an additional issue for video conferencing in the form of inter destination synch exists, not to mention the nice mass-media distribution scenario.

CW: agree that synchronization issues will vary depending of what is synchronized and who needs to synchronize, and that clarifying this would be helpful. As you point out, there is the issue of synchronize multiple streams into the same consumer (audio and video streams); synchronize a single stream from multiple sources (making sure packets are received in a way that can be re-ordered);  and making sure multiple consumers of the same stream (say, a live stream or video conferencing) are somewhat in sync. I will try to clarify.

To conclude, I would like to see an additional Future steps for ICN (section 9) to include synchronization (the requirements of which will be different based on application or scenario). Maybe the authors feel that this aspect demands an ID itself and hence the reason for its omission? If this is the case, I think this should be stated.

CW: Good point. There are a lot of sync issues not currently address that should naturally arise in ICNs and adding this in Section 9 would be helpful. Future Steps can be listed, and don’t have to be entered in too much detail, so I don’t see an problem with adding it. There was no specific reason for omission other than oversight!

There are a number of typos in the document but I guess these can be addressed in a later version.

CW: do you have an annotated version you could share with these typos? It’d be helpful.

I think the document is nicely structured and the flow makes sense to me. Its presentation is very timely.

CW: thanks so much!

Kind Rgs
Niall Murra

On 25 February 2015 at 20:38, <[email-masked]<mailto:[email-masked]>> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Information-Centric Networking Working Group of the IETF.

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.