Minutes for ICNRG at IETF-96
minutes-96-icnrg-2

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: <missed>
   * 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?