[nwcrg] Spencer Dawkins' No Objection on draft-irtf-nwcrg-nwc-ccn-reqs-08: (with COMMENT)
Spencer Dawkins via Datatracker <noreply@ietf.org> Mon, 07 February 2022 18:00 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: nwcrg@irtf.org
Delivered-To: nwcrg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ABE23A1039; Mon, 7 Feb 2022 10:00:58 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Spencer Dawkins via Datatracker <noreply@ietf.org>
To: The IRSG <irsg@irtf.org>
Cc: draft-irtf-nwcrg-nwc-ccn-reqs@ietf.org, nwcrg-chairs@ietf.org, nwcrg@irtf.org, Marie-Jose Montpetit <marie@mjmontpetit.com>, marie@mjmontpetit.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.44.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Spencer Dawkins <spencerdawkins.ietf@gmail.com>
Message-ID: <164425685843.5245.479850094133167811@ietfa.amsl.com>
Date: Mon, 07 Feb 2022 10:00:58 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/nwcrg/bLGC3-Xhosa14_R_93ttHs8YsUU>
Subject: [nwcrg] Spencer Dawkins' No Objection on draft-irtf-nwcrg-nwc-ccn-reqs-08: (with COMMENT)
X-BeenThere: nwcrg@irtf.org
X-Mailman-Version: 2.1.29
List-Id: IRTF Network Coding Research Group discussion list <nwcrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/nwcrg>, <mailto:nwcrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nwcrg/>
List-Post: <mailto:nwcrg@irtf.org>
List-Help: <mailto:nwcrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/nwcrg>, <mailto:nwcrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Feb 2022 18:00:59 -0000
Spencer Dawkins has entered the following ballot position for draft-irtf-nwcrg-nwc-ccn-reqs-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-irtf-nwcrg-nwc-ccn-reqs/ ---------------------------------------------------------------------- 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. ?
- [nwcrg] Spencer Dawkins' No Objection on draft-ir… Spencer Dawkins via Datatracker