ICNRG meeting @ IETF 96, Berlin, Germany, July, 2016 * Date: Thursday, July 21 2016 * Time: 10:00-12:30 * Location: Berlin, InterContinental Hotel * Room: Potsdam III * Etherpad for notes: ​https://neclab.titanpad.com/ICNRG-Berlin-Thursday Agenda * Welcome, Agenda Bashing, Minutes taker, Bluesheets, Status - Chairs (15 min) * Report from Berlin Interim meeting * RIOT summary/reflection * The RIOT folks made their slides available on the website: https://summit.riot-os.org/ * Dagstuhl Seminar summary * Terminology document Status * ICN conference accepted papers * There will be a workshop on ICN and 5G on the day before the ICN conference - http://conferences2.sigcomm.org/acm-icn/2016/ic5g.php * RG documents status (20 min) * ICN Research Challenges: ​https://datatracker.ietf.org/doc/draft-irtf-icnrg-challenges/ * Adaptive Video Streaming over ICN: ​https://datatracker.ietf.org/doc/draft-irtf-icnrg-videostreaming/ * IN RFC Editor preparation as RFC 7933 * Information-centric Networking: Evaluation and Security Considerations: ​https://datatracker.ietf.org/doc/draft-irtf-icnrg-evaluation-methodology/ * CCNx Messages in TLV Format: ​https://datatracker.ietf.org/doc/draft-irtf-icnrg-ccnxmessages/ * Big change: reorganizing types into an IANA section. * CCNx Semantics: ​https://datatracker.ietf.org/doc/draft-irtf-icnrg-ccnxsemantics/ * Needs additional review for clarity. * Individual drafts * CCNx Content Object Chunking - Marc Mosko (10 min) * ​https://datatracker.ietf.org/doc/draft-mosko-icnrg-ccnxchunking/ * Overview: * Goal: how to chunk and then fetch a large piece of content * Specify how to use the T_CHUNK number for names * Simplified due to being superseded by FLIC manifests * DaveO: most application data will be larger than a single packet, so the chunking protocol is fundamental (i.e., can't build an app without it) * Yes, and Manifests help too. * Chunking would be one of the drafts that would move to experimental RFC status (if that happens) since it's so fundamental. * The CCNx URI Scheme - Marc Mosko (10 min) * ​https://datatracker.ietf.org/doc/draft-mosko-icnrg-ccnxurischeme/ * Goal: represent names in URI syntax * Draft purpose is to reserve and specify URI syntax for CCNx names * Name segments without a type are assumed to be T_NAME * Addressed the name of zero-length problem * ccnx:/ => name with no segments * not the same as a name with a zero-length segment * first segment cannot be a segment of length 0 * Part of the core -- manifests are still work in progress * File-Like ICN Collection (FLIC) - Chris Wood (10 min) * ​https://datatracker.ietf.org/doc/draft-tschudin-icnrg-flic/ * Network level manifest rather than an application level manifest as used by MPEG DASH * Nacho: wanted to remind everyone that it doesn't have to be a tree' * Kevin: Asked what the relationship is to FLUTE FTD? * Dirk: * Dave: ICN might need something like erasure coding for data at rest, not only for data in flight * Chris: That is something that is not considered in the current design. * Nacho: Others have been working on FEC with respect to ICN (e.g., in wireless network design) * Dave: For ICN data in flight network coding might be better than FEC. * FLUTE defined by IETF to distribute content with FEC * How to reconcile this with FEC based chunk distribution? * Dirk says that FLUTE was designed with different requirements; here there may be different requirements * Here there may be a need for access a specific item in the tree * Mark says they did some internal work on error correction * Dave says that there is a difference between objects at rest and in transit. * Loss of data at rest and in transmission are different. * If we need to do these, we need to determine the requirements. * Said with chair hat on * Nacho says work has been done on this elsewhere * Dave with chair hat off says that ICN transmission might need something that isn't FEC * Dirk says this work has been around for some time; so he would like to assess group's feelings about making it a group document giving the group change control * only a few hands shown for having read the document * Discussion to continue on mailing list * Draft seems to be stable, and work is progressed on phone calls hosted by PARC but open to all; bi weekly meetings announced on ICNRG list * Kostas: Is there info on the wiki? someone is getting the meeting announcements late * Chairs agree to add announcements and meeting minutes in the wiki * Borje suggests a separate wiki page which Chris will maintain * Summarize of the changes to the merged ICN-IoT requirements draft based on the feedback on the mailing list - Ravi Ravindran (10 min) * ​https://tools.ietf.org/html/draft-zhang-icnrg-icniot-requirements-01 * DaveO: will you produce another iteration? * We can, yes * DaveO: we'll start another conversation on the mailing about the level of interest and the future status * ICN for IoT on challenged wireless links like LoRa - David Lake (20 min) * Q: Comments on narrow-band IoT? * Follows EPC type of environment * Question: how to virtualize this and "bring it down to the edge"? * Can support non-IP traffic, how do we use it? * Q: is there open source for incorporating NB-IoT into LTE? * Yes -- en route * Ravi: what do you use for names in the NDN part of the network? Identities are host identities, not content identities? * Right -- they're names of sensors. * Is there a naming convention that we should apply across sensors? * Ravi: what about supporting PUSH? That's essential for IoT * Left LoRa in place since that uses the pull system * Freshness allows us to understand the utility of data * Need to revisit this and see how we can do pull * Dirk: Any other naming questions? * No * Q: Can you elaborate on the interface between the two systems? Air interfaces are designed to allow PUSH traffic (async triggered information that causes a PUSH). Costly to be listening/pulling for this data. Backend has pull-model for consumer. Could be done at app layer where changes are saved in DB and then consumers pull from the DB * Pull could work well where the sensor is sending regular, periodic communication * Need to get to a place where, if a device has multiple air interfaces, each one understands the context of data for each interface and how it should be sent/received * This requires some coordination between air interface and data * Brings us back to naming conventions * (at least) 39 different air interfaces in IoT -- can we determine which type of model is appropriate for each interface * Q: will ccn-lite run on bare metal? or will it run on RIOT? * Some of this predates RIOT, so this work was done with ccn-lite compiled on bare metal for each device * In the future we could be using RIOT * Next stage: move to pure CCN/NDN devices where we use RIOT * Great work for ICNRG -- we welcome related experimental work * NDN Protocol Stack for RIOT-OS - Alex Afanasyev (20 min) * Q: what size of cache do you have for the numbers presented? * configured at compile time, should be ~25K now (need to double check) * DaveO: not better than IP? * if caching is removed, roughly the same as IP (based on RTT measurements) * Lixia: let’s not compare orange with apple. In one RTT, NDN gets a named data piece in response readily useable by apps (in contrast, IP would return a packet that needs to up a few layers to become usable) * Ralph: would not expect RTT differences no matter what -- I would compare the number of messages for an application, the size of the two stacks, the amount of background control traffic, etc. Does background traffic (i.e., due to management protocols) reduce with the NDN solution? * have not measured -- that's the next step * Emiliano: check ACM ICN 2014 paper on NDN/IoT to get numbers for the stack size, number/size of messages, etc. * Oleg: there is an NDN/IoT testbed with >3000 nodes -- maybe consider it for IoT experiments. * Oleg: usually in IoT you only have one network interface - what's the role of the face mapping table? * Maybe can be removed. Talk later. * ICN BOF discussion (30 min) * Proposal for setting up a design team for Harmonizing CCN and NDN protocols * Kostas: time from draft to RFC can be quick in the IETF, but this appears to be a very heavy process. Can we create multiple WGs? (Unlike the DTN route.) * Further clarification from Kostas after the meeting: The pointer I (admittedly implicitly) made at the mic was re: this article http://www.ietfjournal.org/working-group-update-l3sm/. My point was more about the perceived difficulty in setting up a WG, which in this case was all about a single RFC with a YANG module standardized in a 1.5 years. I think I also mentioned that other WGs (dmm comes to mind) rechartered a couple years ago with the first milestones being "requirements" and "gap analysis" for dmm, and then moving on to "deployment models" and so on. Probably I didn't explain myself well, but my point was more about WG creation rather than the draft-to-RFC cycle. * DaveO (hat off): IETF tries to drive towards standardization of a single solution for a given set of problems. The ICNRG is open to n>1 ways "to do ICN." If there is consensus in the ICNRG, then that's good, but a WG does not mean that multiple solutions cannot be explored in the ICNRG. * Kostas: there is more than one way to do tunneling -- if ICN is analogous, there may be more than one way. * DaveO: Multiple IETF solutions is a consequence of reality -- it's not generally a goal * Dirk: part of consensus work was to identify "mechanical" vs "semantic" differences * Ralph: Imagined there are lot of facets to ICN -- we have not identified each layer (transport, routing, etc.). A first WG would take one piece of this and work on it. * Kostas: Longevity of the RG is an indication that it's heavy weight. There are significant people in the audience -- why lose the momentum? * Cedric: clarification on 2 options -- will the BOF merge NDN/CCN, or will it focus on "hashing out the differences" or actually developing a single protocol. * Do not know what the scope of the WG would be. * Finding out the scope is a necessary precursor to the WG. * Borje: These are only two different ways. * DaveO (hat on): the people who propose the BOF are the people who decide what is in the proposal. Keeping the difference discussion in the ICNRG seems like a good idea. The output of that could inform the creation of a BOF. (Chairs preference: not move the process of evaluating the architectures to a BOF.) * Q: BOF was not rejected because of lack of consensus -- what about the other issues? IPR is a huge issue. * Dirk: rejection was more about a lack of support behind the proposal (as a community). Regarding IPR: have not discussed this at all yet. Needs to be kept in mind. Not useful to rathole on IPR issues today. But that needs to happen at some point. * Borje: some rejection comments were about lack of communication, and people at the IESG didn't have the latest information about IPR status. And the security elements were underrepresented in the BOF proposal. * Ralph (IAB hat on): * (1) absolutely right about lack of communication r.e. security and IPR issues. Minutes from the BOF selection meeting are available. These would need to be documented better if there is to be another BOF proposal. Minutes can be found at https://www.ietf.org/iesg/minutes/2016/bof-minutes-ietf-96.txt. * (2) about maturity and levels of consensus, those are indirectly explained by two different designs (NDN and CCN). One of the concerns is whether there is serious interest in moving technology forward if we're still at the point where we have two different approaches. Other WGs that have done this have less success -- a single approach/design has better luck. * Anecdote: had to flip a coin in a past WG. * Reconciliation work needs to happen. * A lot of overlap between ICNRG and 5gandip -- cross participation would help * Personal suggestion: keep work in the ICNRG -- join 5gandip in WG formation * Jan: focusing on the semantics and not the syntax is useful and what we should do in ICNRG * Both designs are evolving -- the comparison is hard to do well since everything is changing * If designs were finished and finite they would be easier to compare * Dirk(in "DaveO mode"): idea was to do the comparison in a very fast mode, i.e., not drawn out over time * Borje: comparison is intended to be a consolidating effort. The goal is that this is done before the Kyoto meeting in September. * Kostas: this is simple version control -- just compare two versions of the specific architecture * [Vince, interested bystander] Request for harmonization: these seem like similar protocols trying to address similar issues. Hope we can identify key differences and determine if these differences can be incorporated into a consolidated version (with options). If you could get the two communities together there would be a lot more participation. * Jari: not a rejection because of reasons, but because we need more ground work done. We need a clear picture of what we're doing and why. Also, ICN is huge. When we get to the point where we're ready to proceed, we need better articulation of why we're ready and how the approaches can help something. * Marc: we can make productive progress w.r.t. semantic differences, even with evolving versions. * Ravi: it would help if NDN had drafts so we could compare apples and apples. The only writeup for NDN is on the site (there is no spec document). * Dirk (hat off): Yes, that would help. We need a pragmatic approach -- don't want to get stuck in formalism. * Marc: don't think that we need a comparable NDN spec to have discussions. Participants and contributors just need to be knowledgable about the designs. * DaveO: any person on the comparison team should be familiar with both designs -- they should not need to go to a different site to get info. They should know it. * Dirk: the whole point of having this discussion is to make the community aware of the endeavor * Nacho: CCNx drafts are versioned. NDN has the specs online just the same. Protocols are similar in that they're based in CCNx 0.x. (CCNx 1.0 needs a better name.) NDN has not submitted work in ICNRG so it's hard to have the comparison discussion. PARC IP is available under FRAND. NDN would have the same IPR statement (?). * Lixia: (1) *all* NDN documentation (code included) is available online (everyone can go online and look), (2) yes, NDN has not been brought to the ICNRG yet, but if and when it is brought to the ICNRG it will not have the same patent statements as what Nacho said. It would follow the patent statements in the NDN proposal submission to the NSF back in 2010, i.e. royalty-free for all. * Nacho: current patents are owned by PARC * Marc: in the BOF review, it wasn't known what the IPR statement was, not that there was a problem with the IPR statement * Paul: there is strong motivation for going through this convergence effort, and that comes from outside the community (i.e., those in the industry who have interest but are confused that there's two options). If we can help outside decisions then we will do everyone a service. * Eve: Can we have someone with legal expertise come in and help figure out the IPR problems? * Dave: Not sure we can do that. IETF takes no position on interpreting IPR at all. People just state it's there and it's up to external "things" to assess the validity, coverage, etc. * Eve: done for new documents * Jari: Confirming Dave's comment * Wrap up, Next meetings - Chairs (5 min) * Interim in Japan in conjunction with ACM ICN-2016 conference * Interim in Seoul?