[icnrg] Proceedings of ICNRG meeting in Toronto

[Börje Ohlman <[e-mail]>]

The proceedings, including minutes, of ICNRG meeting in Toronto are now available at
http://www.ietf.org/proceedings/90/icnrg.html

A *great* thanks to Kostas and Cedric for taking the minutes!

Comments and/or additions to the minutes can be sent to the mailing list or directly to me.

Börje

———————————————————



Minutes ICNRG meeting @ IETF-90 in Toronto ¶

  *   Time: TUESDAY, July 22, 1640-1840 EDT
  *   Location: Tudor 7/8
  *   Etherpad for notes: https://neclab.titanpad.com/icnrg-ietf90

Agenda items

  *   Intro and draft updates - ICNRG Chairs + Kostas (10 min)
  *   Video Streaming (draft-irtf-icnrg-videostreaming-01<http://tools.ietf.org/html/draft-irtf-icnrg-videostreaming-01>) - Cedric Westphal (10 min)
  *   ICN-IoT draft ( draft-zhang-iot-icn-architecture-00<http://tools.ietf.org/html/draft-zhang-iot-icn-architecture-00>) [e-mail]<mailto:[e-mail]> (10 min)
  *   Applicability and tradeoffs of ICN for efficient IoT (draft-lindgren-icnrg-efficientiot-00<http://tools.ietf.org/html/draft-lindgren-icnrg-efficientiot-00>) - Olof Schelén/Anders? Lindgren (10 min)
  *   Updated version of the ICN Management Considerations draft - Daniel Corujo/Cedric? Westphal (10 min)
  *   New draft on Pub/Sub? CCNx extension (draft-jiachen-icn-pubsub-00<http://tools.ietf.org/html/draft-jiachen-icn-pubsub-00>) - [e-mail]<mailto:[e-mail]>/ [e-mail]<mailto:[e-mail]> (10 min)
  *   New draft on standards necessary for binding RWIs with self-certifying names (draft-seedorf-icn-wot-selfcertifying-00<http://tools.ietf.org/html/draft-seedorf-icn-wot-selfcertifying-00>) - [e-mail]<mailto:[e-mail]> (10 min)
  *   Update on ICN-solutions for disaster scenarios (draft-seedorf-icn-disaster-02<http://tools.ietf.org/html/draft-seedorf-icn-disaster-02>) - [e-mail]<mailto:[e-mail]> (10 min)
  *   Bloom Filter-based Flat Nme resolution (draft-hong-icnrg-bloomfilterbased-name-resolution-00<http://tools.ietf.org/html/draft-hong-icnrg-bloomfilterbased-name-resolution-00>.txt) - [e-mail]<mailto:[e-mail]> (10 min)
  *   Architecture changes from CCN 0.x to CCN 1.x, focused on the major items where it has diverged from both CCN 0.x and NDN - Nacho Solis (15 min)
  *   Update on the packet format and getting an ICNRG draft for the packet format - Marc Mosko (10 min)
  *   Wrap up, next meeting (Interim meeting in Paris in conjunction with the ACM ICN-2014 conference) (5 min)

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

  *   No progress on draft since London; ready for publication; comments welcome; no further contributions or discussion on the mailing list since London; review in IRTF still pending;

  *   If you have comments on the scenario draft, please COMMENT

  *   Evaluation methodology – Kostas

  *   Draft that went through quiet phase; community still publishing and moving forward; new literature to be covered; Kostas involved in FP7 Alien interaction of CCNx (CONET-based) with OpenFlow;

  *   Open Call for Contributions! Send to mailing list

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.

  *   Jan: iTunes case not covered. Cedric: could be added, contributions welcome

  *   Cedric: Adopt as an RG draft?

  *   Juri ? (Intel): what is the benefit for video over icn (?)

  *   Karen Sollins (MIT): 2 use cases (can do better, things that can become possible or better)

  *   Olov Shelen (LTU): naming covered? Cedric: Could be part of the discussion

No objection in the room for adopting as an ICNRG draft

ICN-IoT draft [e-mail]<mailto:[e-mail]> (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.



  *   New  draft on Pub/Sub? CCNx extension (draft-jiachen-icn-pubsub-00) -  [e-mail]<mailto:[e-mail]>/ [e-mail]<mailto:[e-mail]>(10 min)

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) - [e-mail]<mailto:[e-mail]> (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) - [e-mail]<mailto:[e-mail]> (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<http://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