Re: [nwcrg] [icnrg] Review of draft-irtf-nwcrg-nwc-ccn-reqs

[Kazuhisa Matsuzono <[e-mail]>]

Dear Vincent,

Sorry for our delay, but we need a bit more time to revise this draft.
We'll post the revised draft as soon as possible. Please wait for a while.

Thank you very much for your coordination.

Regards,
Kazuhisa

On 2020/02/19 1:38, Vincent Roca wrote:
> Dear Kazuhisa et al.,
>
> Could you please update your document, taking into account the 
> comments received so far.
> I need to give a careful look at it too, which should preferably be 
> done once all of this is cleared.
> Thank you.
>
> Cheers,   Vincent
>
>> Le 14 déc. 2019 à 04:12, kazuhisa matsuzono 
>> <kazuhisa=[e-mail] 
>> <mailto:kazuhisa=[e-mail]>> a écrit :
>>
>> Hello, Dave-san,
>>
>> Thank you for your constructive comments.
>> As Marie-José-san said,
>> we'll wait for the further comments by Jan. 15, and then, upload a 
>> corrected version.
>>
>> Thanks,
>> Kazuhisa
>>
>> On 2019/12/07 21:55, David R. Oran wrote:
>>>
>>> With <ICNRG Chair Hat On>
>>> A reminder to ICNRG’ers to please review this document soon, as the 
>>> NWCRG would like to progress to last call in the near future.
>>>
>>> With <ICNRG Chair Hat Off>
>>> Here are my comments as individual on draft-irtf-nwcrg-nwc-ccn-reqs. 
>>> They are divided into general, technical, and editorial/nits.
>>>
>>>
>>>       General Comments
>>>
>>>  *
>>>
>>>     The document contains a lot of thought-provoking material, and
>>>     is technically sound in terms of its discussion of the issues
>>>     and tradeoffs. Therefore, I think it’s appropriate to advance it
>>>     now as it can form the basis to guide future research work and
>>>     experimentation with the combination of ICN and NWC.
>>>
>>>  *
>>>
>>>     While not a pre-condition to advancing this to RG last call in
>>>     NWCRG, the writing does need a fair amount of work on clarity of
>>>     English language exposition, grammar and usage. It would be very
>>>     helpful if this could be done before sending it to IRSG review,
>>>     as IRSG members are neither NWC nor ICN experts, and could very
>>>     easily be left scratching their heads in a number of places.
>>>
>>>  *
>>>
>>>     The introductory tutorial material on ICN is appropriate to
>>>     level-set for the NWC community, but there’s a need for an
>>>     equivalent tutorial section on NWC to level set for the ICN
>>>     community. Concepts like “degrees of freedom”, “innovative
>>>     packets”, “RLNC”, don’t appear in the (terse) terminology list
>>>     in the Definitions section. It might be good to expand this with
>>>     more tutorial text.
>>>
>>>  *
>>>
>>>     There are a number of places where the document confounds
>>>     security with privacy; these need to be clearly separated and
>>>     the considerations articulated.
>>>
>>>  *
>>>
>>>     A pass needs to be done to align the text here with the current
>>>     RFC status of CCNx. I have some specific comments on this in the
>>>     technical comments below, but I may have missed some places so
>>>     an overall scrub ought to be done, either now, or during RG last
>>>     call.
>>>
>>>
>>>       Technical Comments
>>>
>>>  *
>>>
>>>     In the second paragraph on page 8, you discuss the interaction
>>>     of the naming scheme choices with forwarding, but don’t address
>>>     which, if any, of the characteristics would necessitate a change
>>>     to the semantic-free matching currently done by CCNs and NDN,
>>>     and/or the prefix match semantics of NDN versus exact match of
>>>     CCNx. Instead you concentrate on the size of the TLV headers,
>>>     which doesn’t seem to be a first-order problem.
>>>
>>>  *
>>>
>>>     Material touching on in-network recoding is scattered around in
>>>     various places and probably ought to be consolidated or
>>>     alternatively summarized in a section near the end to pull
>>>     things together. One approach you don’t consider (but probably
>>>     ought to) is exploiting multi-signature capability some signing
>>>     schemes that would work with CCNx. This way you can use
>>>     different signing keys for the original and coded packets,
>>>     allowing the entities responsible for coding to be different
>>>     from the authors of the original content. This way in-network
>>>     recoding could be allowed by giving the signing keys for coded
>>>     packets to routers - this would not require them to be trusted
>>>     to maintain the integrity of the original data since they would
>>>     not have the original signing keys.
>>>
>>>  *
>>>
>>>     In section 4.2.2 you bring up video streaming, and seem to have
>>>     an assumption that your network code is systematic rather than
>>>     non-systematic (aside: another thing probably needing some
>>>     material in the introductory section), further asserting that
>>>     sequential delivery is important, and hence there’s some
>>>     disadvantage to fetching coded packets first. I had a somewhat
>>>     hard time following this, and unless I’m misreading your logic,
>>>     I think it’s actually wrong since today’s streaming decoders
>>>     don’t care at all about packet arrival order and need enough
>>>     computing capacity to decode NWC packets within the playout
>>>     deadline in order to work decently anyway.
>>>
>>>  *
>>>
>>>     In the second paragraph of 4.3, you seem to be unaware that CCNx
>>>     has exactly the feature you want for packets you don’t want to
>>>     cache. The producer just sets the RCT (Recommended Cache Time)
>>>     to zero.
>>>
>>>  *
>>>
>>>     The discussion about whether routers need to decode and validate
>>>     coded packets is a bit confused and I think actually wrong in
>>>     some places. There are two issues. First, the text confounds
>>>     cache pollution with cache poisoning; these are separate
>>>     phenomena that need different mitigation/avoidance approaches.
>>>     Second, while you probably ought to discuss both, cache
>>>     poisoning is pretty thoroughly addressed in the current CCNx
>>>     design (less so in NDN) in a way that does /not/ require routers
>>>     to validate signatures on packets, or in the case of NWC, decode
>>>     them.
>>>
>>>  *
>>>
>>>     I didn’t get the use of the term “virtual logical link” when
>>>     talking about fetching content from multiple producer sites.
>>>     None of the transport or congestion control schemes I’m familiar
>>>     with for ICN use this term, and in fact I’m not sure the concept
>>>     is at all useful in the context of multi-path/multi-destination
>>>     forwarding in CCNx o NDN. Instead you might just reference
>>>     existing work on multi-path/multi-destination congestion control
>>>     and transport.
>>>
>>>  *
>>>
>>>     As the first sentence of a security considerations section,
>>>     saying “This document does not impact the security of the
>>>     Internet” is a big red flag in front of a bull. Get rid of it
>>>     (see may editorial suggestion to consolidate all of the security
>>>     and privacy material see rather than a separate section earlier).
>>>
>>>
>>>       Editorial Comments & Nits
>>>
>>>  *
>>>
>>>     Need to do a global replace of CCN with CCNx.
>>>
>>>  *
>>>
>>>     Get rid of the first paragraph of section 2 and the normative
>>>     reference, since this document doesn’t use any of the RFC2119
>>>     terminology.
>>>
>>>  *
>>>
>>>     Everywhere you say “seamless mobility” it needs to say “seamless
>>>     /consumer/ mobility”.
>>>
>>>  *
>>>
>>>     the second paragraph on page 7 (which begins “the CCN/NDN core
>>>     abstraction”) is really hard to follow. There’s also a
>>>     confounding between what NDN cals the “Strategy layer” and
>>>     “specific…transport” since in NDN forwarding strategy does not
>>>     provide what are classically considered to be transport functions.
>>>
>>>  *
>>>
>>>     Section 4 probably should not be called “requirements” since
>>>     (a)this document is not an appropriate vehicle for expressing
>>>     NWC/ICN integration requirements, and (b)it doesn’t really state
>>>     requirements, but rather some general technical considerations.
>>>
>>>  *
>>>
>>>     the first paragraph of section 4.1 is under naming, but talks
>>>     mostly about fragmentation. Some re-organization might help by
>>>     moving the fragmentation issues to the end of 4.1 rather than
>>>     the beginning.
>>>
>>>  *
>>>
>>>     page 8, second paragraph s/not be able to obtain degrees of
>>>     freedom/not be able top obtain sufficient degrees of freedom/
>>>
>>>  *
>>>
>>>     Page 11, Section 4.3 Caching is *not* essential for improving
>>>     throughput and latency. It’s useful, but not essential.
>>>
>>>  *
>>>
>>>     Given the paucity of material in section 4.5 on security and
>>>     privacy, it might be better to just move this (and hopefully
>>>     expand it a bit) to section 6 as a conventional security
>>>     considerations section.
>>>
>>> [End of Comments]
>>>
>>> On 21 Nov 2019, at 0:47, David Oran wrote:
>>>
>>>     This is joint work of NWCRG and ICNRG, managed out of NWCRG. It
>>>     has needed serious review from the ICNRG participants for quite
>>>     some time, and at this point our review is what is holding up
>>>     its last call and progression.
>>>
>>>     You can find the current version at
>>>     https://datatracker.ietf.org/doc/draft-irtf-nwcrg-nwc-ccn-reqs/
>>>
>>>     PLEASE review this and send comments to both the ICNRG and NWCRG
>>>     mailing lists.
>>>
>>>     I would like to set a deadline of three weeks (December 13)
>>>     after which if no comments that need to be addressed prior to
>>>     further advancement are received, I’ll advise the NWCRG chairs
>>>     to proceed with RG Last call in NWCRG.
>>>
>>>     Thanks, and have a good trip home for those of you who joined us
>>>     in Singapore.
>>>
>>>     DaveO (for Dirk and Börje), ICNRG co-chairs.
>>>
>>>
>>>     ___________________________
>>>     iDevice - please excuse typos.
>>>
>>>     _______________________________________________
>>>     icnrg mailing list
>>>     [e-mail]
>>>     https://www.irtf.org/mailman/listinfo/icnrg
>>>
>>> DaveO
>>>
>>>
>>> _______________________________________________
>>> icnrg mailing list
>>> [e-mail]
>>> https://www.irtf.org/mailman/listinfo/icnrg
>>
>> _______________________________________________
>> nwcrg mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.irtf.org/mailman/listinfo/nwcrg
>