Re: [icnrg] Comments on draft-azgin-icnrg-ni-01

Ravi Ravindran <ravi.ravindran@huawei.com> Thu, 01 June 2017 16:56 UTC

Return-Path: <ravi.ravindran@huawei.com>
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 5B71012EAF8 for <icnrg@ietfa.amsl.com>; Thu, 1 Jun 2017 09:56:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 5_ikJDwZzzIF for <icnrg@ietfa.amsl.com>; Thu, 1 Jun 2017 09:56:32 -0700 (PDT)
Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AABF012EB0C for <icnrg@irtf.org>; Thu, 1 Jun 2017 09:56:31 -0700 (PDT)
Received: from 172.18.9.243 (EHLO dfweml702-cah.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CEN80182; Thu, 01 Jun 2017 11:56:30 -0500 (CDT)
Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by dfweml702-cah.china.huawei.com (10.193.5.176) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 1 Jun 2017 09:56:30 -0700
Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.117]) by SJCEML703-CHM.china.huawei.com ([169.254.5.229]) with mapi id 14.03.0235.001; Thu, 1 Jun 2017 09:56:28 -0700
From: Ravi Ravindran <ravi.ravindran@huawei.com>
To: David Oran <daveoran@orandom.net>, icnrg <icnrg@irtf.org>
Thread-Topic: [icnrg] Comments on draft-azgin-icnrg-ni-01
Thread-Index: AQHS2uI5rAWcsIMKqUWQr2tPLp4DL6IQOdIQ
Date: Thu, 01 Jun 2017 16:56:27 +0000
Message-ID: <D96E28F4A22C864DBC6C871B5B1C4CC3229B0794@SJCEML702-CHM.china.huawei.com>
References: <FB1F6628-9AF2-40A3-B34B-86DAC7F3225D@orandom.net>
In-Reply-To: <FB1F6628-9AF2-40A3-B34B-86DAC7F3225D@orandom.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.213.49.142]
Content-Type: multipart/alternative; boundary="_000_D96E28F4A22C864DBC6C871B5B1C4CC3229B0794SJCEML702CHMchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/06rJ-LHzcGjCTPDubIjEsvhISJg>
Subject: Re: [icnrg] Comments on draft-azgin-icnrg-ni-01
X-BeenThere: icnrg@irtf.org
X-Mailman-Version: 2.1.22
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: Thu, 01 Jun 2017 16:56:35 -0000

Thanks for your comments Dave, we will revise the draft to address your comments and bring it to discussion in the next meeting.

Regards,
Ravi

From: icnrg [mailto:icnrg-bounces@irtf.org] On Behalf Of David Oran
Sent: Thursday, June 01, 2017 7:20 AM
To: icnrg <icnrg@irtf.org>
Subject: [icnrg] Comments on draft-azgin-icnrg-ni-01


I spent some time going over “Enabling Network Identifier (NI) in Information Centric Networks to Support Optimized Forwarding” ( draft-azgin-icnrg-ni-01).

Here are my comments, with <Chair Hat Off>

General Comments

This is a potentially useful position paper. It takes the position that ICN would benefit from having a separate routing-friendly identifier in order to scale global routing, and that the application-assigned names cannot be directly used in many cases to achieve feasible global routing capability. This is an attractive idea in many ways, but is not universally subscribed to in the ICN community. In order to have the separate “Network Identifier” (NI) from the “Application Identifier” (AI), some way to carry the NI in packets, derive it from the AI, and forward based on it are needed. The main material in the document addresses these questions.

This reviewer is not among the set of people convinced by the arguments in this paper; nonetheless it has a lot of good material, and a good set of references. I would advocate that after more work to address these (and hopefully other ICNRG participant) comments, it would be a useful addition to the literature and hence publishable as an individual contribution RFC. I am less enthusiastic about adopting this as an ICNRG draft, unless one or more people with differing/opposing views add material to the document to make it a more balanced discussion of the the ways naming interact with ICN routing/forwarding scalability and security. In particular, security gets very little attention in this position paper. Security considerations around AI/NI mapping, trust in routing directives, and tradeoffs in control by consumers/publishers versus network operators needs to get significantly more attention.

Detailed comments
Abstract

The abstract already argues that a network-based name resolution service is mandatory. This is not entirely obvious and it is certainly not obvious that the NRS needs to be “network based”. It could be designed as an ICN application, and not even be “global” in the sense that single NRS serves all of the global namespace.

1 Introduction

  *   As I’ve commented elsewhere, the term “location” is introduced informally, and this makes for confusion right off the bat. In this paragraph, you don’t need to wade into the “location swamp” as in this context you could just as easily say “contents, services, and services become disentangled from particular hosts…”

2 Application Identifier (AI) vs. Network Identifier (NI)

in the first paragraph you say “a flat identifier offers a fixed predictable overhead and variable security properties within a given context” I get the first property, but I have no idea what “variable security properties within a given context” means.

Some real difficulties start in the second paragraph. Among my doubts/questions/complaints are:

  *   you say the NI provides a binding for the AI to the network at a location. Why only one? Why not a set?
  *   you say the NI is “managed by the network provider to name the routers, point of attachments, servers and end devices” This is orthogonal to the point of the paper, since all of those things are owned by the network operator and he can name them any way he wants. In fact, he can assign AI’s to these things since he knows how to route to them on his own infrastructure and not need an NI at all.
  *   you say “NI could assume names of the underlay network as well, such as IP or Ethernet addresses” I don’t see how this helps/works since in those cases you need an underlay running those protocols anyway, so you already have a map/encap happening without inserting an NI at the ICN layer.
  *   while you say the growth of NI can be much smaller than the growth of AI, your argument for why doesn’t hold water. If AI grows via more objects under routable prefixes that grow no faster than the growth rate of infrastructure, the scaling for routing will be similar. There’s a true point here about high-level name authorities growing faster than infrastructure providers, but you don’t make it.
  *   you say “it is desirable to route requests on NIs, with the mapping between AI and NI is achieved in a scalable manner using a network based name resolution system.” That is one possibility; however there are others, such as the CCN approach of alternative equivalent names with Manifests.

Further on, starting on page 4,

  *   you say “names or identifiers …typically managed by applications, thereby of persistent nature” - what does persistence have to do with this? some names, particularly in the context of real time multimedia, may have little persistence - a few RTTs or so.
  *   You say “Overloading an identifier as a locator can lead to unstable routing control”. First I don’t think using an identifier for routing and matching against named content constitutes “overloading”. Second, what do you mean by “unstable routing control”? Just because something has a high update rate (you mention mobility), or multiple feasible destinations (you mention replication) does not necessarily mean there’s any instability. Further, the problem of high state mutation rates is inherent to mobility (in the absence of cheap broadcast), and whether it is routing state changing fast, or AI/NI binding state changing fast at first order makes no difference. In fact it’s quite likely that routing state update could be considerably more efficient than binding state update.
  *   Why do you say that “name aggregation does not help with scaling the routing and forwarding as originally imagined” I doubt anybody with even minimal technical clue imagined that name aggregation would lead to routing scaling in ICN.

The next paragraph starts by presuming that NIs and routing are inherently needed together, which you have argued but hardly proved. Might be better to s/Routing scalability is typically achieved by designing NIs with aggregate-able property/Routing scalability is typically achieved by designing routing state with aggregate-able property/. The fact that provider-independent addressing in IP is not common has many causes, one of which is non-aggregatability, but there are others, such as the economics of BGP route advertisements (the creator of state is not the one who pays the cost of distributing the state), and the ownership properties of IP address blocks.

  *   I also don’t follow the argument that avoiding NIs somehow leads to “relinquishing the persistency of names”.
  *   Nor the argument that it relinquishes the security bindings such as trust - trust is established by how you bind keys to names, not how persistent the names are.

3 NI based ICN forwarding

In addition to the cases you cite at the beginning of this section, an important additional use case is infrastructure-less configurations that do not need to scale globally.

In the next paragraph, I was trying to follow your argument of where NI becomes important. Why is there necessarily a correspondence between domain boundaries and whether routing state exists in both domains sufficient to route on AIs? I also don’t follow why necessarily domain entry triggers the usage of an NI. I could argue just the opposite- when you enter a domain with relatively complete routing state, the domain can route directly rather than having to do any kind of NI mapping.

A bit further along, you make a pretty strong claim: “However, as significant amount of user traffic fetches resources outside the requesting host's local domain, it becomes crucial to provide architectural support for NI in an ICN protocol.” What is crucial is to be able to route globally, however you do it. Architecturally mandated NIs are one way. Tunneling is another, Source routing is another. Multiple published names with Manifests is another. There are many ways to skin this cat. You do say up front that NI is optional, not mandatory, but is this optional to implement? Optional to use? Is there one mandated format? Globally agreed semantics for the trust assertions in the bindings between AIs and NIs?

3.1 Label based ICN forwarding

  *   why are security bindings considered optional? forwarding labels would seem to be a devil’s playground, especially if they survive domain crossing. If they don’t we wind up with a feature that is much less useful than it might be as we’ve seen with DSCPs.
  *   you say forwarding labels can guide interests toward a cache (in addition to producers or repositories). This is an interesting capability, similar to what can be done with cache steering for cache clusters. This probably deserves a separate discussion, rather than being buried here.
  *   I think the question of whether label-based forwarding treats labels as always having precedence is kind of an independent property from the other properties of forwarding labels. What is the thinking behind the static precedence requirement? I don’t see how this helps compared to leaving it as a local forwarder decision, other than perhaps removing some cases where there could otherwise be loops. Similarly, I don’t get why it can’t be treated as a hint to be used when there’s no route in the FIB for the AI, as you talk about for link objects.
  *   Why only one forwarding label per interest packet? I can envision a system where there are multiple, at different granularities, and the forwarder picks the “best” one (e.g. the one for which it has the best LPM FIB entry).
  *   You talk a bit about forwarding labels allowing non-ICN names and instead using transport addresses. This seems quite problematic especially when combined with tunneling. You could put in a forwarding label that could result in an upstream forwarder blindly tunneling an ICN packet to anywhere.

The next paragraph, starting “Forwarding label consists”, needs a bunch of language fix up. Also:

  *   you say “if the namespace supports the use of an NI to reach a specific destination” This is the first mention of NI usage being bound to a namespace. If you actually meant to say this, it could be an interesting idea, but raises a ton of questions, like how that binding is made and checked. Why would you do this? Are there certain namespaces that are known a priori to need NI in order to have its objects be reachable? (The next paragraph further mentions this possibility by starting “Forwarding label support for a namespace can be offered at a global…”)
  *   a bit later you say NIs can be mutated “depending on the feedback from the name resolution system” ignoring for the moment whether an NRS provides feedback or only answers questions, there might easily be other reasons to swap NIs like having local IGP information - segment routing in IP can do this.

Parts of the paragraph starting “Forwarding label support” are pretty hard to follow and tend to wander into separate issues, like QoS. I also wonder whether you want to characterize mobility as a “service”, since it’s so baked into ICN as a native feature.

3.2 Link-object based ICN forwarding

  *   Why do you think using link objects constitutes “Map-and-encap”?

3.3 Link Object vs. Forwarding Label

This section reads more like an argument in favor of forwarding labels that a list of differences. It needs a more balanced presentation. For example, the first paragraph attributes certain “network based management” advantages to forwarding labels, which, by implication, you think link objects do not have. However, they might, especially if counter-signed by the network operator and ignored or generating a NAK otherwise.

·         As an example of things that might argue for link objects, here’s some possible text: “Conversely, the link object constrains a network operator from overriding a consumer’s intent, for example where the consumer knows that a certain triangle routing path will outperform native service provider paths”.

·         Another example is where you say that the optionality of the the security binding for the forwarding label is a feature since it contextualizes the trust relationship. A counter view is perhaps “The former puts all trust assessment in the producers and consumers; the latter relieves users of this burden but opens the system to route hijacking similar to what we see with BGP”.

·         For the paragraph about forwarding efficiency, you make the claim that NI-based forwarding labels are more flexible operation in routing. This is arguable, as the router could always put the equivalent FIB entry in based on the same mapping data that created the NI binding. Putting forwarding state in the packet sometimes wins; putting it in the FIB sometimes wins. If putting it in the packet wins sufficiently frequently, the forwarding-labels may be desirable, however there are other ways to skin the cat using path switching or tunneling.

·         The next paragraph says “Forwarding label, on the other hand, can be enabled as part of a service, which limits the use of forwarding label to the supported namespaces, while at the same time requiring its use whenever/wherever supported.” I think this needs a lot more explanation, with example “services” and how forwarding label enables these when a link object or other techniques do not. (Aside: In doing so take care to not declare as “services” obnoxious middleboxes than screw up consumers’ intents as has occurred too much in the IP world. This is a particularly sensitive topic, as I’ve heard occasional arguments in favor of ICN from service providers that it restores their ability to re-insert themselves in application interactions as IP becomes more transparent through e2e encryption ).

·         You say “Even though this selection is shared between consecutive hosts, it is not enforced, thereby potentially leading to non-optimal forwarding paths.” What does “shared between consecutive hosts” mean? Do you mean hosts or routers? A bit further you say “Hence, forwarding label presents the network with the ability to consistently forward packets over optimal paths towards a content source.” I’m not sure this is true, and perhaps only true if the IGP is itself optimal.

4 Name Resolution System Considerations

I didn’t spend much time on this section, as it might be more easily cut down or eliminated once there is a mature NRS document to point to. The material is very general, and doesn’t really get into what kind of NRS is a good match for which style of forwarding. Most limiting, however, is the lack of any discussion of security. Not so much of the NRS itself (which belongs in an NRS specification) but of the tricky issues of who attests to what in the creation, maintenance, and usage of the AI/NI bindings (I think link objects already cover this aspect quite extensively). That is needed in this document, independent of the nature of any NRS that stores and regurgitates them.

David R. Oran
Network Systems Research & Design
4 Shady Hill Square
Cambridge, MA 02138 USA