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

Hi Dirk,

I will respond in-line:

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

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 <mariejo@mit.edu> wrote:
> 
> 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?

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 media synchronization across multiple networks and devices - a hard problem. Some ICN basic mechanisms (strategy layers?) could be helpful here. The multiple screen experience 
>

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!

 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.

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

Again, thanks for the comments!

C.

> 
> But again overall a good document!
> 
> 
> I will be in Dallas and can discuss some more.
> 
> 
> Marie-José
> 
> Marie-Jose Montpetit, Ph.D.
> mariejo@mit.edu
> @SocialTVMIT
> 

_______________________________________________
icnrg mailing list
icnrg@irtf.org
https://www.irtf.org/mailman/listinfo/icnrg