Minutes for ICNRG at IETF-96
||Minutes for ICNRG at IETF-96
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
* 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:
* 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:
* IN RFC Editor preparation as RFC 7933
* Information-centric Networking: Evaluation and Security Considerations:
CCNx Messages in TLV Format:
* Big change: reorganizing types into an IANA section.
* CCNx Semantics:
* Needs additional review for clarity.
* Individual drafts
* CCNx Content Object Chunking - Marc Mosko (10 min)
* 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)
* 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)
* 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)
* 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?
* 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
* 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
* 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?