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

[Colin Perkins <[e-mail]>]

Vincent, all,

Thanks – this draft has now been sent for IESG conflict review, prior to publication.
Colin




> On 7 Mar 2022, at 07:25, Vincent Roca <[e-mail]> wrote:
> 
> 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] <mailto:[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/>