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

[Spencer Dawkins at IETF <[e-mail]>]

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]>
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/
>
> 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]> 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]>
> > > Sent: Tuesday, February 08, 2022 8:17 AM
> > > To: [e-mail]
> > > Cc: The IRSG <[e-mail]>; [e-mail]; [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/ <
> 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]>> 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://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://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/
> >
> >
> >
> >
> >
>