Network Coding for Content-Centric Networking / Named Data Networking: Considerations and Challenges
draft-irtf-nwcrg-nwc-ccn-reqs-09
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2022-08-10
|
09 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2022-07-19
|
09 | (System) | RFC Editor state changed to AUTH48 |
2022-07-13
|
09 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2022-06-06
|
09 | (System) | IANA Action state changed to No IANA Actions from In Progress |
2022-06-06
|
09 | (System) | RFC Editor state changed to EDIT |
2022-06-06
|
09 | (System) | IANA Action state changed to In Progress |
2022-06-06
|
09 | Colin Perkins | IRTF state changed to Sent to the RFC Editor from In IESG Review |
2022-06-06
|
09 | Colin Perkins | Sent request for publication to the RFC Editor |
2022-03-08
|
09 | Amanda Baber | IANA Review state changed to IANA OK - No Actions Needed |
2022-03-08
|
09 | Amanda Baber | (Via drafts-eval@iana.org): IESG/Authors/ISE: The IANA Functions Operator has reviewed draft-irtf-nwcrg-nwc-ccn-reqs-09 and has the following comments: We understand that this document doesn't require any registry … (Via drafts-eval@iana.org): IESG/Authors/ISE: The IANA Functions Operator has reviewed draft-irtf-nwcrg-nwc-ccn-reqs-09 and has the following comments: We understand that this document doesn't require any registry actions. While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object. If this assessment is not accurate, please respond as soon as possible. Thank you, Amanda Baber IANA Operations Manager |
2022-03-07
|
09 | Colin Perkins | IRTF state changed to In IESG Review from In IRSG Poll |
2022-03-07
|
09 | Colin Perkins | IETF conflict review initiated - see conflict-review-irtf-nwcrg-nwc-ccn-reqs |
2022-02-27
|
09 | (System) | Revised ID Needed tag cleared |
2022-02-27
|
09 | Kazuhisa Matsuzono | New version available: draft-irtf-nwcrg-nwc-ccn-reqs-09.txt |
2022-02-27
|
09 | (System) | New version approved |
2022-02-27
|
09 | (System) | Request for posting confirmation emailed to previous authors: Cedric Westphal , Hitoshi Asaeda , Kazuhisa Matsuzono |
2022-02-27
|
09 | Kazuhisa Matsuzono | Uploaded new revision |
2022-02-08
|
08 | Colin Perkins | IRSG final poll comments in datatracker; potentially need a revision to address. |
2022-02-08
|
08 | Colin Perkins | Tag Revised I-D Needed set. |
2022-02-08
|
08 | Colin Perkins | Closed "IRSG Approve" ballot |
2022-02-07
|
08 | Spencer Dawkins | [Ballot comment] I do have some questions for the authors to consider, but nothing blocking that I can see. Thanks for the opportunity to review … [Ballot 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. In section 3, could you expand CS on first use? 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]. 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. 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. 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. 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. 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, ^^^ ? 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. 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. 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? 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. ? |
2022-02-07
|
08 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2022-01-29
|
08 | Allison Mankin | [Ballot comment] I enjoyed reading this well-written and interesting draft. It provides important information; it is clear on the promising areas of integrations and also … [Ballot comment] I enjoyed reading this well-written and interesting draft. It provides important information; it is clear on the promising areas of integrations and also provides clear guidance on open or less tractable areas (e.g. it is clear that it can focus only on block codes and convolutional would need more design). Ready to be an IRTF RFC. |
2022-01-29
|
08 | Allison Mankin | Ballot comment text updated for Allison Mankin |
2022-01-29
|
08 | Allison Mankin | [Ballot comment] This is a solid document - it is clear on the promising areas of integrations it covers and also provides a roadmap to … [Ballot comment] This is a solid document - it is clear on the promising areas of integrations it covers and also provides a roadmap to areas not yet well understood or tractable. |
2022-01-29
|
08 | Allison Mankin | [Ballot Position Update] New position, Yes, has been recorded for Allison Mankin |
2022-01-12
|
08 | Mirja Kühlewind | [Ballot 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 … [Ballot 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. 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? Nits: - sec 7.2: "would be effective, an effective deployment approach" -> "would be an effective deployment approach"? - Maybe spell out CS on first occurrence. |
2022-01-12
|
08 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2021-12-07
|
08 | David Oran | [Ballot Position Update] New position, Yes, has been recorded for David Oran |
2021-12-06
|
08 | Colin Perkins | [Ballot Position Update] New position, No Objection, has been recorded for Colin Perkins |
2021-12-06
|
08 | Colin Perkins | IRTF state changed to In IRSG Poll from IRSG Review |
2021-12-06
|
08 | Colin Perkins | Created IRSG Ballot |
2021-11-22
|
08 | Colin Perkins | Waiting confirmation from Melinda Shore that -08 addresses her review comments |
2021-11-17
|
08 | (System) | Revised ID Needed tag cleared |
2021-11-17
|
08 | Kazuhisa Matsuzono | New version available: draft-irtf-nwcrg-nwc-ccn-reqs-08.txt |
2021-11-17
|
08 | (System) | New version approved |
2021-11-17
|
08 | (System) | Request for posting confirmation emailed to previous authors: Cedric Westphal , Hitoshi Asaeda , Kazuhisa Matsuzono |
2021-11-17
|
08 | Kazuhisa Matsuzono | Uploaded new revision |
2021-11-01
|
07 | Colin Perkins | Revised draft needed to address IRSG review from Melinda Shore. |
2021-11-01
|
07 | Colin Perkins | Tag Revised I-D Needed set. |
2021-10-24
|
07 | (System) | Revised ID Needed tag cleared |
2021-10-24
|
07 | Kazuhisa Matsuzono | New version available: draft-irtf-nwcrg-nwc-ccn-reqs-07.txt |
2021-10-24
|
07 | (System) | New version approved |
2021-10-24
|
07 | (System) | Request for posting confirmation emailed to previous authors: Cedric Westphal , Hitoshi Asaeda , Kazuhisa Matsuzono |
2021-10-24
|
07 | Kazuhisa Matsuzono | Uploaded new revision |
2021-08-18
|
06 | Colin Perkins | Dave Oran reviewed for IRSG; update needed to address comments. Additional IRSG review solicited. |
2021-08-18
|
06 | Colin Perkins | Tag Revised I-D Needed set. |
2021-08-18
|
06 | Colin Perkins | IRTF state changed to IRSG Review from Awaiting IRSG Reviews |
2021-08-04
|
06 | Colin Perkins | IRTF state changed to Awaiting IRSG Reviews from Waiting for IRTF Chair |
2021-08-04
|
06 | Colin Perkins | Changed consensus to Yes from Unknown |
2021-07-27
|
06 | Kazuhisa Matsuzono | New version available: draft-irtf-nwcrg-nwc-ccn-reqs-06.txt |
2021-07-27
|
06 | (System) | New version approved |
2021-07-27
|
06 | (System) | Request for posting confirmation emailed to previous authors: Cedric Westphal , Hitoshi Asaeda , Kazuhisa Matsuzono , irtf-chair@irtf.org, nwcrg-chairs@ietf.org |
2021-07-27
|
06 | Kazuhisa Matsuzono | Uploaded new revision |
2021-07-26
|
05 | (System) | Document has expired |
2021-03-11
|
05 | Vincent Roca | IRTF state changed to Waiting for IRTF Chair from Waiting for Document Shepherd |
2021-03-11
|
05 | Vincent Roca | This document is the product and represents the consensus of the Coding for Efficient Network Communications Research Group (NWCRG). It discusses the use of network … This document is the product and represents the consensus of the Coding for Efficient Network Communications Research Group (NWCRG). It discusses the use of network coding techniques for Content-Centric Networking (CCNx) and Named Data Networking (NDN), focussing on technical considerations, challenges, and research outputs. After an adoption as RG Item document in Sept. 2018, the document went through regular updates and presentations during NWCRG meetings, as well as a RG Last Call (Sept. 2020), cross posted to the NWCRG and ICNRG mailing lists. It has also been carefully reviewed by the RG Chairs. I believe this document is now ready for IRSG review. Vincent Roca, on behalf of Marie-Jose Montpetit |
2021-03-11
|
05 | Vincent Roca | This document is the product and represents the consensus of the Coding for Efficient Network Communications Research Group (NWCRG). It discusses the use of network … This document is the product and represents the consensus of the Coding for Efficient Network Communications Research Group (NWCRG). It discusses the use of network coding techniques for Content-Centric Networking (CCNx) and Named Data Networking (NDN), focussing on technical considerations, challenges, and research outputs. After an adoption as RG Item document in Sept. 2018, the document went through regular updates and presentations during NWCRG meetings, as well as a RG Last Call (Sept. 2020), cross posted to the NWCRG and ICNRG mailing lists. It has also been carefully reviewed by the RG Chairs. I believe this document is now ready for IRSG review. |
2021-02-17
|
05 | Vincent Roca | IRTF state changed to Waiting for Document Shepherd from In RG Last Call |
2021-01-22
|
05 | Kazuhisa Matsuzono | New version available: draft-irtf-nwcrg-nwc-ccn-reqs-05.txt |
2021-01-22
|
05 | (System) | New version approved |
2021-01-22
|
05 | (System) | Request for posting confirmation emailed to previous authors: Cedric Westphal , Hitoshi Asaeda , Kazuhisa Matsuzono |
2021-01-22
|
05 | Kazuhisa Matsuzono | Uploaded new revision |
2020-09-07
|
04 | Vincent Roca | De: Vincent Roca Objet: RG Last Call for "Network Coding for Content-Centric Networking / Named Data Networking: Considerations and Challenges" Date: 7 septembre 2020 à … De: Vincent Roca Objet: RG Last Call for "Network Coding for Content-Centric Networking / Named Data Networking: Considerations and Challenges" Date: 7 septembre 2020 à 16:16:16 UTC+2 À: nwcrg@irtf.org, icnrg@irtf.org Cc: Vincent Roca , Marie-Jose Montpetit Dear all, We would like to officially start a RG Last Call for the following I-D: "Network Coding for Content-Centric Networking / Named Data Networking: Considerations and Challenges » https://datatracker.ietf.org/doc/draft-irtf-nwcrg-nwc-ccn-reqs/ This Last Call is managed by NWCRG but is copied to the ICNRG group as well. The call will end on Monday Sept. 28th (3 weeks). Please read it and provide feedback to the authors (note that it already went through several reviews). Thanks in advance. Regards, Marie-Jose and Vincent |
2020-09-07
|
04 | Vincent Roca | IRTF state changed to In RG Last Call |
2020-09-07
|
04 | Vincent Roca | Intended Status changed to Informational from None |
2020-09-02
|
04 | Kazuhisa Matsuzono | New version available: draft-irtf-nwcrg-nwc-ccn-reqs-04.txt |
2020-09-02
|
04 | (System) | New version approved |
2020-09-02
|
04 | (System) | Request for posting confirmation emailed to previous authors: Cedric Westphal , Hitoshi Asaeda , Kazuhisa Matsuzono |
2020-09-02
|
04 | Kazuhisa Matsuzono | Uploaded new revision |
2020-09-02
|
03 | (System) | Document has expired |
2020-03-01
|
03 | Kazuhisa Matsuzono | New version available: draft-irtf-nwcrg-nwc-ccn-reqs-03.txt |
2020-03-01
|
03 | (System) | New version approved |
2020-03-01
|
03 | (System) | Request for posting confirmation emailed to previous authors: Kazuhisa Matsuzono , Hitoshi Asaeda , Cedric Westphal |
2020-03-01
|
03 | Kazuhisa Matsuzono | Uploaded new revision |
2019-09-20
|
02 | Kazuhisa Matsuzono | New version available: draft-irtf-nwcrg-nwc-ccn-reqs-02.txt |
2019-09-20
|
02 | (System) | New version approved |
2019-09-20
|
02 | (System) | Request for posting confirmation emailed to previous authors: Cedric Westphal , Hitoshi Asaeda , Kazuhisa Matsuzono |
2019-09-20
|
02 | Kazuhisa Matsuzono | Uploaded new revision |
2019-09-12
|
01 | (System) | Document has expired |
2019-05-13
|
01 | Vincent Roca | Notification list changed to Marie-Jose Montpetit <marie@mjmontpetit.com> |
2019-05-13
|
01 | Vincent Roca | Document shepherd changed to Marie-Jose Montpetit |
2019-03-11
|
01 | Kazuhisa Matsuzono | New version available: draft-irtf-nwcrg-nwc-ccn-reqs-01.txt |
2019-03-11
|
01 | (System) | New version approved |
2019-03-11
|
01 | (System) | Request for posting confirmation emailed to previous authors: Cedric Westphal , Hitoshi Asaeda , Kazuhisa Matsuzono |
2019-03-11
|
01 | Kazuhisa Matsuzono | Uploaded new revision |
2018-09-11
|
00 | Vincent Roca | This document now replaces draft-matsuzono-nwcrg-nwc-ccn-reqs instead of None |
2018-09-11
|
00 | Hitoshi Asaeda | New version available: draft-irtf-nwcrg-nwc-ccn-reqs-00.txt |
2018-09-11
|
00 | (System) | WG -00 approved |
2018-09-11
|
00 | Hitoshi Asaeda | Set submitter to "Hitoshi Asaeda ", replaces to (none) and sent approval email to group chairs: nwcrg-chairs@ietf.org |
2018-09-11
|
00 | Hitoshi Asaeda | Uploaded new revision |