[icnrg] Comments on draft-irtf-icnrg-ccninfo-02
"David R. Oran" <daveoran@orandom.net> Fri, 02 August 2019 14:17 UTC
Return-Path: <daveoran@orandom.net>
X-Original-To: icnrg@ietfa.amsl.com
Delivered-To: icnrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75881120153 for <icnrg@ietfa.amsl.com>; Fri, 2 Aug 2019 07:17:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBUJneFosKgE for <icnrg@ietfa.amsl.com>; Fri, 2 Aug 2019 07:17:00 -0700 (PDT)
Received: from spark.crystalorb.net (spark.crystalorb.net [IPv6:2607:fca8:1530::c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E823120140 for <icnrg@irtf.org>; Fri, 2 Aug 2019 07:17:00 -0700 (PDT)
Received: from [192.168.171.1] ([IPv6:2601:184:4081:19c1:5d74:cc89:3503:46cf]) (authenticated bits=0) by spark.crystalorb.net (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id x72EGt81020389 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NO) for <icnrg@irtf.org>; Fri, 2 Aug 2019 07:16:58 -0700
From: "David R. Oran" <daveoran@orandom.net>
To: ICNRG <icnrg@irtf.org>
Date: Fri, 02 Aug 2019 10:16:54 -0400
X-Mailer: MailMate (1.12.5r5643)
Message-ID: <FDD9172E-D6C5-4A4C-B8B1-C7787BCA7D4B@orandom.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_BAE8E6CA-3ADB-4A0C-A6E9-EE37D257D57F_="
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/z3x8lumFkYl7tiog81-zS8mpIQM>
Subject: [icnrg] Comments on draft-irtf-icnrg-ccninfo-02
X-BeenThere: icnrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Information-Centric Networking research group discussion list <icnrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/icnrg>, <mailto:icnrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/icnrg/>
List-Post: <mailto:icnrg@irtf.org>
List-Help: <mailto:icnrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/icnrg>, <mailto:icnrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Aug 2019 14:17:03 -0000
I did a full re-read of the latest CCNInfo draft. These comments are with <Chair Hat off>. I’ll be sending a separate message with my <chair hat on> comments shortly. General comments: - The specification is a lot more complete and easy to understand. It’s already implemented (by the authors), and I suspect another implementer could get pretty close to an interoperable implementation from the material in the current version. - The design seems fundamentally solid. It’s not the design I would have chosen, but given this is for research purposes and heading toward experimental status rather than a standard, I think progressing this approach is fine. We can experiment with it (and other approaches) to learn more about how to instrument and manage networks based on CCNx. There is of course other complementary work in ICNRG (e.g. ping and traceroute) so researchers would be encouraged to do both qualitative and quantitative evaluation of the tradeoffs in the various approaches. There is also work under submission to the ICN’19 conference that takes yet another approach so soon we may have a rich set of things to compare and contrast. - The forwarding model is pretty much separate from the Interest/Data forwarding procedures. I understand the authors’ motivation for this, but it does mean a lot of extra code in all the forwarders in order to have appropriate coverage. It also raises a number of possibly tricky resource allocation issues, since CCNInfo will be competing for both memory (i.e. PIT) and link bandwidth with Interest/Data while having somewhat different dynamic characteristics. For example, the Request messages will be large compared to regular Interests (especially so if they are signed), and the set of state stored in the PIT somewhat different, meaning you either have a separate data structure or a more complex joint PIT data structure. - It was somewhat difficult for me to get a holistic grasp of the security properties of the CCNInfo Request/Reply protocol. For example: - Requests can be signed by the initiator, but the request blocks are not individually signed. This seems to result in a fully transitive trust model upstream toward the FHR (CCNInfo terminology identifying the forwarder directly attached to a producer). Is this a problem? I’m not sure. - Conversely, recording the identity of every upstream forwarder may represent a privacy problem. Again, the tradeoffs are difficult to assess, since there is the ability in the protocol for information hiding, and administrative controls at domain boundaries. However, the anonymity characteristics of Interest handling (the further you are away from the consumer, the harder it is to localize the consumer in the topology, discover the identity, or establish linkability) are compromised. Does this matter? I’m not sure. - On a similar note, it appears the individual reply blocks in Reply messages are not signed so again CCNInfo appears to rely on transitive trust to protect the returned information. Even if they were to be signed, deciding whether the right key was used is not at all clear (this is related to another comment later on the question of how forwarders are named/identified). - Some of the statistics reported in CCNInfo are likely to be expensive to compute, and possibly quite algorithmically difficult to implement efficiently in high-performance implementations that shard the PIT & CS. It isn’t clear whether these ought to be done by CCNInfo or obtained instead by a direct application-layer management protocol talking to the management application in a forwarder node. It may be worth scrubbing these to only return basic information about an individual Data Object in a cache, repo or producer, and only return a return handle to use (via a separate protocol) to obtain the details for groupings like prefixes. - CCNInfo creates a non-CCNx namespace for naming/identifying forwarders. Why? This seems to me both fraught with management complexity (allocation, duplication, security, etc.), at odds with the naming architecture of CCNx (or NDN) and frankly unnecessary. If instead CCNinfo used the existing namespace structure to name forwarders, things would (at least in my opinion) be much better: - name allocation for forwarders is no different from that for any other data producer - by providing these names in CCNInfo Replies to the initiator, you now have a direct and easy coupling to a more comprehensive management protocol driven by regular interest/data exchanges (or for more sophisticated uses, by RICE). - security becomes a lot better integrated, as you can use all the existing trust schema work to decide what to sign, what to encrypt, and using what keys. - It appears flow balance is seriously violated by the discovery form of CCNInfo request/reply exchanges, as a single request can generate multiple replies (in pathological cases, an exponential number of replies since Request aggregation is turned off explicitly). We really need to deal with this. Some possible alternatives: - quarantine relies at intermediate forwarders and combine them; returning only one “aggregate” reply on each downstream link. - Explicitly bound the number of replies as well as their size and communicate this in the protocol so the resource allocators can account for this in congestion management. Here are some more detailed comments on things that I found in reading the specification: - Report blocks can get pretty big. The recommendation is to just give up and not report anything more if your reply would exceed an IPv6 MTU. Why? CCNx supports Data objects as large as 64K and current NDN restricts to 4K. Admittedly this has all sort of “interesting” fragmentation and congestion control implications (which are the subject of a new I.D. I plan to submit soon…but I digress). Given that there is no exclusion capability, nor steering capability it’s not possible to get beyond the “horizon” created by this limitation. I’m not advocating necessarily adding either of these, however the small MTU for replies does seem to be problematic for a network management tool. - In describing the information returned from caches, it wasn’t entirely clear if the these sum all the things in the cache matching a given prefix or something else. If they are in fact prefix-matched, this really needs to be done in the background and not in the forwarding path given the expense of traversing the cache data structures. (Folks will recall we got rid of prefix-match on data in CCNx for exactly this reason, and NDN recently changed to prefer exact match as well). Once you do this it may be appropriate to ask why not just layer these capabilities of CCNInfo as an application (as does the NIST work for NDN) rather than bake it into the basic network layer packet forwarding. I don’t necessarily advocate this; in fact I would prefer to simplify CCNInfo to make it feasible to implement at high performance (see my general comment earlier about only returning simple stuff in CCNInfo and doing the complex stuff on top). - I didn’t see use of the existing T_MTU_TOO_LARGE error when you run out of space (page 11). Did I miss it? - Is 16 bits enough entropy for RequestID (page 12)? it may be ok if you don’t do any aggregation across consumers (which you currently don’t) and lifetimes are bounded very small as you currently do (4 seconds). It still makes me nervous though. - On page 14 you RECOMMEND routers have synchronized clocks. This too strong in my opinion, for three reasons: - you are throwing away the low order 16 bits of the NTP timestamp anyway - loose synchronization is sufficient for the kinds of uses I think you want from CCNInfo. - If you expect CCNInfo to give you accurate per-hop and total RTT estimation using these clocks this isn’t terribly helpful given that the whole protocol runs on a different forwarding model, so you can’t use the CCNInfo RTT measurements to say much of anything about what real Interest/Data exchanges will experience. The alternative Ping and Traceroute proposals should do a much better job of this. - Is the count of “received interests” (page 18) all those received or only those satisfied? - I didn’t see much value in the Reply block information on First/Last Segnum or Elapsed Cache time. For these and some others it might help to given some examples of how one might use this. - in Section 4.2 you say you have to compare the number of report blocks with the hop limit. I think this means you have to remember the received hop limit in the PIT entry for the request, but I didn’t see that in the list of state you have to keep. Minor stuff: - move the actual packet type and TLV allocations to the IANA considerations section, and mark the values as “TBS” rather than picking them (yes…this might force you to change the implementation, but them’s the rules for RFCs…). - page 23 s/the fill discovery request/the full discovery request/ [End of comments] DaveO
- [icnrg] Comments on draft-irtf-icnrg-ccninfo-02 David R. Oran
- Re: [icnrg] Comments on draft-irtf-icnrg-ccninfo-… Hitoshi Asaeda
- Re: [icnrg] Comments on draft-irtf-icnrg-ccninfo-… David R. Oran
- Re: [icnrg] Comments on draft-irtf-icnrg-ccninfo-… Hitoshi Asaeda