Re: [icnrg] [nwcrg] I-D Action: draft-irtf-nwcrg-nwc-ccn-reqs-05.txt

[roca <[e-mail]>]

Dear Kazuhisa, authors, everybody,

Thank you for your update of the I-D.
I have been through the modifications and your answers to my comments.
They have been addressed.

Let’s continue the process (more to come on this soon).

Regards,

  Vincent


> Le 23 janv. 2021 à 03:16, Kazuhisa Matsuzono <[e-mail]> a écrit :
> 
> Dear NWCRG and ICNRG members,
> 
> We believe we addressed the comments given during the LC
> for our NWC-for-ICN draft. (Thanks, Vincent)
> We've just submitted the revised draft. 
> It's great if you can have a look.
> 
> Followings are our reply for the given comments.
> 
> Regards,
> 
> 1)
>> I am a bit  surprised by the proposed format:
>>       /CCNx.com/video-A/g-id/1000
>> for naming  as it totally ignores any possibility of
>> having several potential codes, or several signaling formats.
>> Since there  is no NWC identifier nor any version identifier, 
>> it seems to lack the needed flexibility.
>> I'm pretty  sure there are several solutions to bring this type of 
>> flexibility, but I don't see any mention in the ID.
> 
> We modified and added the new explanation of naming example (in 6.1
> Content Naming) as below:
> ----
> As in [10], when the generation ID is "g-id", generation size is 4, and
> coding vector is (1,0,0,0), the name could be /CCNx.com/video-A/g-id/
> 1000. Some other identifiers and/or parameters related to the encoding
> scheme can also be used as the name components. For instance, the
> encoding ID specifying the coding scheme may be used with "enc-id" such
> as /CCNx.com/video-A/enc-id/g-id/1000, as defined in the FEC Framework (
> FECFRAME) [25]. This naming scheme is simple and can support the
> delivery of coded packets with exactly the same operations in the PIT/CS
> as those for the content objects.
> ----
> 
> 2)
>> - section  6.2.1: it is said:
>> "encoding or recoding is performed to generate the coded packet on an 
>> end-to-end coding basis"
>> I don't  understand the meaning of "recoding" if we only perform 
>> end-to-end coding. I guess it's either
>> a  mistake, or the notion of "end" is different.
> 
> We simply removed "end-to-end coding basis" and modified as below:
> ----
> In the latter case, encoding or recoding is performed to generate the
> coded packet at any forwarder that is able to respond to the interest.
> ----
> 
> 3)
>> I'm a bit  surprised by the 2nd paragraph on storing coded packets.
>> I can  understand that these packets, being unpopular, are less 
>> frequently cached, and therefore propagation of
>> a corrupted  coded packet may be particularly efficient>in terms of 
> spreading.
>> Yet I don't  understand what follows:
>>       "routers could check the request frequencies 
>> and store the coded
>>       packets with certain popularity to prevent the attacks."
>> We cannot  prevent the attack. We can try to minimise its impacts by 
> reducing the number of times a corrupted
>> coded  packet will be replicated. But that's totally different.
>> And I find  the process rather strange and unefficient. Why should a 
>> router artificially store less popular packets?
> 
> We removed "prevent" and modified the related sentences to reflect the
> comment (in Sec.8 2nd paragraph), as below:
> ----
> Depending on the adopted caching strategy such as cache replacement
> policies, routers should also take caution when storing and retaining
> the coded packets in the CS as they could be targeted by cache pollution
> attacks. In order to mitigate the cache pollution attacks' impact,
> routers should check the content request frequencies to detect the
> attack and may limit requests by ignoring some of the consecutive
> requests. The routers can then decide to apply or change to the other
> cache replacement mechanism.
> ----
> 
>> -------- Forwarded Message --------
>> Subject: 	[nwcrg] I-D Action: draft-irtf-nwcrg-nwc-ccn-reqs-05.txt
>> Date: 	Fri, 22 Jan 2021 17:52:22 -0800
>> From: 	[e-mail]
>> Reply-To: 	[e-mail]
>> To: 	[e-mail]
>> CC: 	[e-mail]
>> 
>> 
>> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the Coding for efficient NetWork 
>> Communications Research Group RG of the IRTF.
>> 
>> Title : Network Coding for Content-Centric Networking / Named Data 
>> Networking: Considerations and Challenges
>> Authors : Kazuhisa Matsuzono
>> Hitoshi Asaeda
>> Cedric Westphal
>> Filename : draft-irtf-nwcrg-nwc-ccn-reqs-05.txt
>> Pages : 23
>> Date : 2021-01-22
>> 
>> Abstract:
>> This document describes the current research outcomes in Network
>> Coding (NC) for Content-Centric Networking (CCNx) / Named Data
>> Networking (NDN), and clarifies the technical considerations and
>> potential challenges for applying NC in CCNx/NDN. This document is
>> the product of the Coding for Efficient Network Communications
>> Research Group (NWCRG) and the Information-Centric Networking
>> Research Group (ICNRG).
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-irtf-nwcrg-nwc-ccn-reqs/
>> 
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-irtf-nwcrg-nwc-ccn-reqs-05
>> https://datatracker.ietf.org/doc/html/draft-irtf-nwcrg-nwc-ccn-reqs-05
>> 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-irtf-nwcrg-nwc-ccn-reqs-05
>> 
>> 
>> 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/
>> 
>> 
>> _______________________________________________
>> nwcrg mailing list
>> [e-mail]
>> https://www.irtf.org/mailman/listinfo/nwcrg
>> 
> 
> 
> _______________________________________________
> nwcrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/nwcrg