Re: [nwcrg] [irsg] IRSG ballot closed: <draft-irtf-nwcrg-nwc-ccn-reqs-08.txt> to Informational RFC

[Vincent Roca <[e-mail]>]

Dear Colin, all,

I’m okay with these reviews and how comments have been addressed.
Thanks a lot to everybody, it helped improving the quality of the ID.

Regards,   Vincent as co-chair


> Le 5 mars 2022 à 00:48, Colin Perkins <[e-mail]> a écrit :
> 
> Hi all,
> 
> Thank you for the update. This version looks to address the IRSG review comments, from Mirja, Allison, and Spencer. 
> 
> Chairs, if you could please confirm you’re okay with this moving forward, then I’ll send it to the IESG for conflict review.
> 
> Colin
> 
> 
> 
>> On 28 Feb 2022, at 16:53, Spencer Dawkins at IETF <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> Hi,  Kazuhisa,
>> 
>> Just top-posting to say that the updated draft version looks fine to me. Thanks to you and your co-authors for your quick response!
>> 
>> Best,
>> 
>> Spencer
>> 
>> On Sun, Feb 27, 2022 at 11:01 PM Kazuhisa Matsuzono <[e-mail] <mailto:[e-mail]>> wrote:
>> Dear Colin, Mirja, Allison, Spencer, all,
>> 
>> Thank you so much for the useful comments and your help !
>> We’ve addressed the comments and uploaded the new version.
>> 
>> > The IETF datatracker status page for this draft is:
>> > https://datatracker.ietf.org/doc/draft-irtf-nwcrg-nwc-ccn-reqs/ <https://datatracker.ietf.org/doc/draft-irtf-nwcrg-nwc-ccn-reqs/>
>> 
>> Please see inline for more details.
>> Many Thanks!
>> 
>> Best regards,
>> Kazuhisa (on behalf of all authors)
>> 
>> 
>> > ----------------------------------------------------------------------
>> > COMMENT:
>> > ----------------------------------------------------------------------
>> >
>> > One high level comment (which isn't anything that would prevent
>> > publishing or
>> > would actually need to be addressed before publishing): For me the
>> > motivation
>> > why NC is specifically beneficial for ICN is not clear. It rather
>> > seems to me
>> > that NC would be kind of equally beneficial to any other kind of network
>> > interaction scheme. Section 6 even notes that a base principe in ICN
>> > is that a
>> > "forwarder or producer cannot initiatively inject unrequested data"
>> > which seems
>> > actually to make the application of NC (where N stands for network) quite
>> > complicated. The approaches and consideration presented are fine and make
>> > sense, I'm just saying the synergy of specifically combining these two
>> > techniques is less clear to me.
>> Thanks!
>> We modified some sentences to address the specific relationship between
>> ICN and NC, as follows:
>> 
>> NC allows for recovery of missing packets by encoding the information
>> across several packets.  ICN is synergistic with NC, as it allows for
>> caching of data packets throughout the network. In a typical network
>> that uses NC, the sender must transmit enough packets to retrieve the
>> original data.  ICN offers an opportunity to retrieve network coded
>> packets directly from caches in the network and this makes the
>> combination of ICN and NC particularly effective.  In fact, NC has
>> already been implemented for information/content dissemination [6] [7]
>> [8].  Montpetit, et al., first suggested that NC techniques be exploited
>> to enhance key aspects of system performance in ICN [9]. Although
>> CCNx/NDN excels to exploit the benefits of NC (as described in Section
>> 5), some technical considerations are needed to combine NC and CCNx/NDN
>> owing to the unique features of CCNx/NDN (as described in Section 6).
>> 
>> > One editorial point: For the ICN terminology you refer to RFC8793. For
>> > NC you
>> > have a rather lengthly list with terms which not necessarily are all used.
>> > Wouldn't it make sense to similarly refer to RFC8406 instead?
>> Thanks for the comment.
>> As with the case of ICN terminology, we referred to RFC8406, and
>> explicitly described that we referred RFC8406:
>> "This section provides the terms related to NC used in this document,
>> which are defined in RFC8406 [21] produced by NWCRG."
>> And then, we listed the NC-related terms, as there are several confusing
>> terms (e.g., source packet, repair packet, encoding, re-coding,
>> generation, etc).
>> In addition, as you pointed out, since there were some terms which were
>> not used in main sections, we removed them from the lists.
>> 
>> > Nits:
>> > - sec 7.2: "would be effective, an effective deployment approach" ->
>> > "would be
>> > an effective deployment approach"? - Maybe spell out CS on first
>> > occurrence.
>> Many thanks, we modified the relevant sentences  as follows:
>> 1. "From this perspective, an effective deployment approach (e.g., a
>> forwarder-supported approach that can provide benefits under partial
>> deployment) is required."
>> 2. "in the cache storage called Content Store (CS) (in Sec. 3)"
>> 
>> > ----------------------------------------------------------------------
>> > COMMENT:
>> > ----------------------------------------------------------------------
>> >
>> > I do have some questions for the authors to consider, but nothing
>> > blocking that
>> > I can see. Thanks for the opportunity to review this document.
>> >
>> > This is the kind of silly question one wonders about, but the top of
>> > the first
>> > page says
>> >
>> > Network Coding Research Group
>> >
>> > But the abstract says
>> >
>> > Abstract
>> >
>> > This document is
>> > the product of the Coding for Efficient Network Communications
>> > Research Group (NWCRG) and the Information-Centric Networking
>> > Research Group (ICNRG).
>> >
>> > My understanding is that the Abstract is correct. Perhaps both
>> > research groups
>> > could be named at the top of the first page? In my limited experience,
>> > that’s a
>> > free-form field.
>> Thank you for pointing it out.
>> We added "ICNRG" at the top of the first page.
>> (We already asked ICNRG-chairs whether there's any problem.)
>> > In section 3, could you expand CS on first use?
>> Thanks, we modified as follows: "in the cache storage called Content
>> Store (CS) (in Sec. 3)"
>> >
>> > This text
>> >
>> > In the case of non-
>> > coherent NC, that often comprises the use of Random Linear Coding
>> > (RLC), it is not necessary to know the network topology nor the
>> > intermediate coding operations [33].
>> >
>> > Didn’t parse well for me. Perhaps
>> >
>> > In the case of non-
>> > coherent NC, which often uses Random Linear Coding
>> > (RLC), it is not necessary to know the network topology nor the
>> > intermediate coding operations [33].
>> Many thanks, we changed as you pointed out.
>> 
>> 
>> > I agree with Mirja’s first comment, that if there’s a reason why ICN
>> > is special
>> > and either benefits from NC differently or needs to be handled
>> > differently,
>> > explaining that would be great. I think Section 5 is getting at that,
>> > but maybe
>> > a forward pointer earlier in the document would be helpful.
>> Thanks! As respond to the Mirja's comment, we updated considering the
>> Mirja's and your comment.
>> 
>> > In addition, I’m looking at
>> >
>> > NC combines multiple packets together with parts of the same content,
>> > and may do this at the source or at other nodes in the network.
>> > Network coded packets are not associated with a specific server, as
>> > they may have been combined within the network. As NC is focused on
>> > what information should be encoded in a network packet instead of the
>> > specific host at which it has been generated, it is in line with the
>> > architecture of the CCNx/NDN core networking layer.
>> >
>> > And wondering if NC could happen at a source OR in other nodes in the
>> > network,
>> > what would happen if it happened at a source AND in other nodes in the
>> > network.
>> > Whether both would be OK, or not, it’s probably worth saying something
>> > about
>> > that.
>> Thank you.
>> Because both can be fine, we modified as follows: "content, and may do
>> this at the source and/or at other nodes in the network."
>> 
>> > In Section 6.1,
>> >
>> > Naming content objects is as important for CCNx/NDN as naming hosts
>> > is in the current-day Internet [24]. In this section, two possible
>> > naming schemes are presented.
>> >
>> > I wasn’t sure which naming schemes are being presented (do they have
>> > names?
>> > References? Or are they being described in this document for the first
>> > time?) I
>> > THINK I can tell where one description ends and the other begins, but
>> > if you
>> > could put each in its own subsection (6.1.1 and 6.1.2), that would be
>> > easier
>> > for readers to navigate.
>> Thanks for the comment!
>> We split Sec 6.1 into two sub-sections: 6.1.1 Unique Naming for NC
>> Packets, 6.1.2 Non-Unique Naming for NC Packets
>> 
>> > In Section 6.2,
>> >
>> > This means that forwarder or producer cannot
>> > initiatively inject unrequested data.
>> >
>> > I had to check, but “initiatively” is a perfectly good English word
>> > that I was
>> > not familiar with. I’m understanding the text, the sentence might be
>> > clearer as
>> >
>> > This means that a forwarder or producer cannot
>> > ^
>> > inject unrequested data packets on its own initiative.
>> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> >
>> > Do the right thing, of course.
>> Thanks, we modified it, because the sentence is clearer.
>> 
>> > In Section 6.2.1, I couldn’t parse this text, and I think I know why.
>> >
>> > On the other hand, if interest has a
>> > partial name without any coding vector information or NC packets have
>> > a same name,
>> > ^^^^^^^^^^^
>> >
>> > Is this (I’m guessing)
>> >
>> > On the other hand, if interest has a
>> > partial name without any coding vector information or multiple NC packets
>> > ^^^^^^^^
>> > have the same name,
>> > ^^^
>> > ?
>> Thanks, we modified as pointed out.
>> 
>> > In 6.2.3,
>> >
>> > In another possible case, when receiving interests only for source
>> > packets, the forwarder may attempt to decode and obtain all the
>> > source packets and store them (if the full cache capacity are
>> > available), thus enabling a faster response to the interests.
>> >
>> > I didn’t understand how this works. Is this enabling a faster response to
>> > subsequent interests, which is what I would have guessed because of the
>> > references to storing and to a cache), or to a single interest? And if
>> > this is
>> > obvious, I apologize to the authors.
>> Many thanks!,
>> As you pointed out, the phrase of “subsequent interests” is appropriate
>> and much clearer. We modified the sentence.
>> 
>> > As an aside, 6.2.4 does an EXCELLENT job of saying
>> >
>> > There are multiple strategies,
>> > Here is what the multiple strategies are, and
>> > Here are the advantages and disadvantages of each strategy.
>> >
>> > This is the kind of presentation I was hoping for in my comment on 6.1
>> > above.
>> Thanks, this was actually done by Dave-san's lots of help.
>> We hope that Sec. 6.1 becomes much clear.
>> 
>> > This text in Section 6.2.5 was hard for me to parse, and I think I
>> > know why.
>> >
>> > NC operations should be applied in addition to the regular ICN
>> > behavior. Hence, nodes should be able to not support network coding
>> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> > (not only in forwarding the packets, but also in the caching
>> > mechanism).
>> >
>> > Perhaps something like
>> >
>> > NC operations should be applied in addition to the regular ICN
>> > behavior. Hence, nodes should should not perform network coding
>> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> > (not only in forwarding the packets, but also in the caching
>> > mechanism).
>> >
>> > Would be clearer? Or am I missing the point here?
>> Thanks so much.
>> To make it clearer, we modified as follows:
>> NC operations should be applied in addition to the regular ICN behavior,
>> and should function alongside regular ICN operations. Hence, nodes which
>> do not support NC should still be able to properly handle packets, not
>> only in being able to forward the NC packets, but also to cache these
>> packets.
>> 
>> > In Section 7.2 (“Rate and Congestion Control”), I didn’t understand
>> > how the
>> > first sentence in this paragraph is connected to the second sentence
>> > in the
>> > same paragraph.
>> >
>> > As described in Section 6.4, NC can contribute to seamless consumer
>> > mobility by obtaining innovative packets without receiving duplicated
>> > packets through multipath data retrieval. It can be challenging to
>> > develop an effective rate and congestion control mechanism in order
>> > to achieve seamless consumer mobility while improving the overall
>> > throughput or latency by fully exploiting NC operations.
>> >
>> > Maybe the reference to seamless consumer mobility is confusing me. Is it
>> > correct to say
>> >
>> > As described in Section 6.4, NC can contribute to seamless consumer
>> > mobility by obtaining innovative packets without receiving duplicated
>> > packets through multipath data retrieval, and avoiding duplicated
>> > ^^^^^^^^^^^^^^^^^^^^^^^
>> > packets has congestion control benefits as well. It can be challenging to
>> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> > develop an effective rate and congestion control mechanism in order
>> > to achieve seamless consumer mobility while improving the overall
>> > throughput or latency by fully exploiting NC operations.
>> >
>> > ?
>> Many thanks!
>> We modified as you pointed out.
>> 
>> 
>> ----- Original Message -----
>> > Thanks – and yes, that’s how the review process works.
>> > Colin
>> > 
>> > 
>> > 
>> > > On 8 Feb 2022, at 18:07, Cedric Westphal <[e-mail] <mailto:[e-mail]>> wrote:
>> > > 
>> > > Hi,
>> > >  
>> > > Yes, we’ll need a minor update to address Spencer’s and Mirja’s comments. Hopefully we can get this done soon and run it by Spencer/Mirja and move forward. If there was a way for the update to not reset the review process, just have Spencer/Mirja/you check on it, that would be fantastic. 
>> > > Thanks!
>> > >  
>> > > C. 
>> > >  
>> > > From: Colin Perkins <[e-mail] <mailto:[e-mail]>> 
>> > > Sent: Tuesday, February 08, 2022 8:17 AM
>> > > To: [e-mail] <mailto:[e-mail]>
>> > > Cc: The IRSG <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
>> > > Subject: Re: [irsg] IRSG ballot closed: <draft-irtf-nwcrg-nwc-ccn-reqs-08.txt> to Informational RFC
>> > >  
>> > > The IRSG ballot has closed on this draft, and it has enough positions to proceed towards publication. 
>> > >  
>> > > There are some non-blocking comments from Mirja and Spencer in the datatracker athttps://datatracker.ietf.org/doc/draft-irtf-nwcrg-nwc-ccn-reqs/ballot/irsg/ <http://datatracker.ietf.org/doc/draft-irtf-nwcrg-nwc-ccn-reqs/ballot/irsg/> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-irtf-nwcrg-nwc-ccn-reqs%2Fballot%2Firsg%2F&data=04%7C01%7Ccedric.westphal%40futurewei.com%7Cb3db1a81197144494bf708d9eb1e849d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637799338586905103%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=u9uvWmyRlWpJuySv3VtpEJ6p95pYivnyFmhfxsGrMCg%3D&reserved=0 <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-irtf-nwcrg-nwc-ccn-reqs%2Fballot%2Firsg%2F&data=04%7C01%7Ccedric.westphal%40futurewei.com%7Cb3db1a81197144494bf708d9eb1e849d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637799338586905103%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=u9uvWmyRlWpJuySv3VtpEJ6p95pYivnyFmhfxsGrMCg%3D&reserved=0>>. Authors/chairs can you please review and let me know if an update is needed to address any of these comments?
>> > >  
>> > > Thanks,
>> > > Colin
>> > >  
>> > >  
>> > >  
>> > > 
>> > > 
>> > > On 8 Feb 2022, at 16:07, IESG Secretary <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
>> > >  
>> > > The IRSG ballot for <draft-irtf-nwcrg-nwc-ccn-reqs-08.txt> has been closed.
>> > > The evaluation for this document can be found at
>> > > https://datatracker.ietf.org/doc/draft-irtf-nwcrg-nwc-ccn-reqs/ <https://datatracker.ietf.org/doc/draft-irtf-nwcrg-nwc-ccn-reqs/> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-irtf-nwcrg-nwc-ccn-reqs%2F&data=04%7C01%7Ccedric.westphal%40futurewei.com%7Cb3db1a81197144494bf708d9eb1e849d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637799338587061345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2FVikS4x%2FSsiwmAjwvuh5mBAZdbPi2oUBgXbuUMXBv%2FM%3D&reserved=0 <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-irtf-nwcrg-nwc-ccn-reqs%2F&data=04%7C01%7Ccedric.westphal%40futurewei.com%7Cb3db1a81197144494bf708d9eb1e849d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637799338587061345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2FVikS4x%2FSsiwmAjwvuh5mBAZdbPi2oUBgXbuUMXBv%2FM%3D&reserved=0>>
>> > >  
>> > > 
>> > > 
>> > > -- 
>> > > Colin Perkins
>> > > https://csperkins.org/ <https://csperkins.org/> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcsperkins.org%2F&data=04%7C01%7Ccedric.westphal%40futurewei.com%7Cb3db1a81197144494bf708d9eb1e849d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637799338587061345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=QhDeCgRD9Ja4vpSrMjhUn7Lggt24sunFiFUxYDdmrvg%3D&reserved=0 <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcsperkins.org%2F&data=04%7C01%7Ccedric.westphal%40futurewei.com%7Cb3db1a81197144494bf708d9eb1e849d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637799338587061345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=QhDeCgRD9Ja4vpSrMjhUn7Lggt24sunFiFUxYDdmrvg%3D&reserved=0>>
>> > 
>> > 
>> > -- 
>> > Colin Perkins
>> > https://csperkins.org/ <https://csperkins.org/>
>