Minutes ICNRG meeting @ IETF-90 in Toronto


Agenda items


Minutes ICNRG meeting @ IETF-90 in Toronto


Intro and draft updates - ICNRG Chairs (10 min)

Dirk:  Chairs slides. Agenda bash


ICNRG Documents update

Kostas presents status of Scenarios and Evaluation methodology. Call for contributions on the latter draft. No comments on mike


Baseline scenario – Kostas


Video Streaming (draft-irtf-icnrg-videostreaming-00) - Cedric Westphal (10 min)

Cedric presents video draft. Focus on how do you adapt current Internet mechanisms to ICN? Draft updates summarized. Look into use cases: Netflix (DASH), p2p, iptv.

No objection in the room for adopting as an ICNRG draft


ICN-IoT draft -ravi.ravindran@huawei.com (10 min)

Ravi presents ICN arch for IoT draft. Split document to challenges and architecture. Added contributors section, more contributions welcome


Smart transport-smart grid contributions very much welcome.


Dirk: How much interest is it for this in the RG? Please discuss at the mailing list.


Applicability and tradeoffs of ICN for efficient IoT (draft-lindgren-icnrg-efficientiot-00) - Olof Schelén/Anders Lindgren (10 min)

Olov presents applicability and tradeoffs for ICN/IoT.


Jan: challenge: ICN routers consume more power (than IP?) in IoT scenarios. Olov: we want to do some lightweight approach. ICN in concert with existing internet protocols. Not for real-time data. 


Naming: importance of time (for IoT, other). We need push, efficient for real-time (would be interesting for ICN). Retrieving meta-data should be optional.


We're looking for feedback. Do the RG want to do clean slate or extend todays IP network for IoT using ICN mechanism?


Dirk: no constrains on "clean slate" vs. "overlay".

DaveO: how does this relate to error amplification (lack of integrity in the IoT part). Olov: e2e security, we're working on it, we're open.

DaveO: have you considered emulating push (phone home + pull); requires extra messages. Olov: IoT needs alarms (and we need to avoid RTT). 

DaveO: have you considered transmit-only nodes. Olov: no, that's a different mode.

Key concept: only immutable data to avoid problem with cache inconsitensies.

Dirk: next steps: what's the maturity of this work.

Olov: we're experimenting, but we're not there yet

Dirk: we're seeing projects starting working on this, we could allocate more time on this line of work, we could discuss in the next meeting. Let us know if you want to contribute in this area


Updated version of the ICN Management Considerations draft - Daniel Corujo/Cedric? Westphal (10 min)

Cedric: management considerations draft. Presentation prepared by Daniel. Addresses how management relates to ICN (new management possibilities). Significant reworking of the draft. On-going research work presented. Looking for feedback on the scope, and contributions/comments/suggestions.



Jan: presents Pub/Sub support in ICN. Early phase for the actual draft, but we're working on this for some time. Efficiency an issue (see ealrier presentation, timeliness etc.) Plan for a survey draft on pub/sub for ICN. ccnx pub/sub enhancement spec as a draft down the road.

Nacho: the new spec is on PARC's web site

Karen (MIT): group needs to think about why would one put low-level semantics underneath. There's a deeper question to be answered here. There are many other communication mechanisms that we're using that they're not pub/sub etc. 

DaveO: adding features/adaptation is different from this, as the fundamental tradeoffs are different. This is really interesting work and we should see more of it and look deeper into this. But it's not as simple as putting pub/sub in ICN

Joerg Ott: implicit assumption of certain types and ways of implementing ICN. There are some architecture for ICN that inherently use pub/sub at the lower layer. No assumption

Jan: good point, we should include it in the document

Dirk: this needs further exploration

Kostas: it's interesting to come back to how the original approaches with different low-level primitives (psirp/netinf/ccn) do this and why we now go from ccn to pub/sub


New draft on standards necessary for binding RWIs with self-certifying names (draft-seedorf-icn-wot-selfcertifying-00) - Jan.Seedorf@neclab.eu (10 min)

Jan presents self-certifying names draft. Going fast :) PKI vs. WoT. This draft looks into WoT. There are a lot of IETF drafts. Looking for feedback. list of standards considerations. We could write a concrete spec on how you do this.


Kostas: we’re working on a project called Felix that is Federated Infrastructure between EU and Japan, extending Ofelia (using LDAP), now doing certificate-based authentication. Could be relevant. 


Update on ICN-solutions for disaster scenarios (draft-seedorf-icn-disaster-02) - Jan.Seedorf@neclab.eu (10 min)

Jan: ICN for disaster scenarios. Key considerations: energy consumption, comms resources (emergency). 3 use cases. New in this draft version: start looking into solutions.ICN data mules, pririty delivery (DTN-related). Confidentiality and access control important. Decentralized (off-line) message authN (WoT-based). Basically use the ID format to update the ICNRG folks about the developments in the solution space (GreenICN)


Bloom Filter Flat Name Resolution – Jungha Hong

Name assigned to data object; location independent and flat name. 

Bloom-filter-based Name Resolution System. B-NRS

A network of B-NRS servers: peers and parent-child relationships. 

B-NRS server components: name lookup table; 

Key operations: name registration (followed by BF updates), locator update; lookup

Why BF, not DHT? Major benefit of BF: fixed constant time of insertion. Efficient for union of BFs with the same size and set of hash functions; drawback of BF: false positive; no member deletion; complexity: log2(n) for DHT vs logd(n) where d is the degree of B-NRS servers in tree.

Borje: any implementation in planning?

Jungha: we haven’t decided which hardware implementation GPU or TCAM

Borje: any ICN approach to do this?

Jungha: not decided yet, for the next meeting

DaveO: have you compared the routing update overhead of BF data structure compared with routing updates

Jungha: still ongoing, trying to do some analytical model for latency and scalability

DaveO: scalability in lookup and update distribution;

DaveO: 2nd question, there are deterministic false positive as opposed to probabilistic. Attacks in order to get false positive and get traffic to go far away and consume resource?


CCNx 1.0 – Changes from 0.x – Nacho Solis (PARC)

DaveO: where’s the IPR disclosure..

Nacho: no changes

Packet format change: 

Packet encoding form CCNb to TLV format; old format complex, new format easy to parse

Unified packet format for interest and content object;

Name comes first: fast parsing; separate validation from metadata at the end; 

Now: do exact matching, no longer prefix matching

Parsing much faster

Previous way to disambiguate: selectors and time-outs; now just interest. 

Exact matching: you get what you ask for; efficient match: fast forwarding on single match; no rummaging of caches/traffic: better privacy

Now: contentObjectHash = flat name

Loop halting: previously name + nonce; now: hop limit

Nonce = overhead and router processing; takes memory from the PIT; nonces break aggregation; 

Label-based names: segments have a label or a type; indicate if it’s a version, a chunk, an app specific value; remove aliasing

Jan Seedorf: where can I download this?

Nacho: CCNx.org

Other changes: format should work over any L2, supports fragmentation; no need to verify signature necessarily; manifest as core objects; time is now in millisecond (as opposed to “funky time”); no AnswerOriginKind or Scope; new control message; no timers, get responses back; Storage is handled differently; separate protocol for discovery, chunking, versioning; content store is optional; content store has matching requirements; flow control (vs static pipelining)

New C software, now coding style, modular API, etc.

Ravi: previous draft of similarity hash

Nacho: renamed in interest labels; not an update, new way to do label forwarding

Ravi: how about the implementation for PIT, content store?

Nacho: we have a way to implement it internally, that’s implementation specific, one table, list, hashes, etc.

Ravi: strategy layer?

Nacho: it’s a module; says you have to send it to at least one valid route. You can do other stuff, but it’s not required. 

Mark Mosko: clarifying, the forwarding table is not updated per packet. 

Dirk: any plans to make it available?

Nacho: plans to make the sw available. 


CCNx 1.0 Packet Format – Mark Mosko

TLV

Validation algorithms

Jan Seedorf: this is totally incompatible with the old version; how feasible would it be to write a proxy/gateway to translate?

Mark: it would be difficult

DaveO: the semantics are different; you would get the intersection of the capability and union of liability

DaveO: optional meta-data TLV, should be plural?

Mark: container that has all the meta-data TLV inside it, hierarchical

Ravi: security now an optional feature?

Mark: yes, you can use self-certifying names; the manifest gives me the self-certifying name, don’t need ot include more;

Dirk: add some crypto identifier; there is RFC6920 (“naming things with hashes) that is doing exactly this, with an implied verification, have you looked into that?

Mark: yes; our hash names are calculated in network; we are not making the hash part of the name of the object ; I would like to have a movie, and split it and distribute; because CCN has the ability to verify the self-certifying name, we can use the implicit name of the content object.

Dirk: you can use the output of this RFC


Wrap Up – Dirk

ACM ICN conference in Paris in September

Packet event! Planning co-locating ICNRG meeting on Saturday, 9/25.

Let us know if you can host or support the event; Next regular meeting: is there interest for meeting at IETF-91?

DaveO: if you object, let us know, discussion on the mailing list

Hitoshi: I don’t mind interim meeting in any place, but do prefer regular meeting in IETF

Borje: this is an interim before Honolulu; next question: should we meet in Honolulu or interim somewhere else? Pros for Honolulu: those who are not going to IETF meeting are unlikely to go; if we meet in Honolulu, should we do a 2 hour slot or an interim meeting;

Jan: compromise: interim meeting in Paris, and 2 hour meeting in Honolulu.

Borje: probably no final decision until interim meeting in Paris