Minutes interim-2018-icnrg-01: Sun 09:00

Meeting Minutes Information-Centric Networking (icnrg) RG
Title Minutes interim-2018-icnrg-01: Sun 09:00
State Active
Other versions plain text
Last updated 2018-03-25

Meeting Minutes

   ICNRG Interim meeting London, UK, Sunday March 18, 2018 ¶

Note-takers: Bastiaan Wissingh (morning), Cedric Westphal (afternoon)

9:00 Meeting starts
        •       Welcome, Agenda Bashing, Minutes taker, Bluesheets, Status -
        Chairs (10 min) •       Hybrid ICN (hICN) - Luca Muscariello (25 min +

Dave; These IPv6 addresses you mention, are they intended to be topologically
independant? E.g. treated as anycast addesses?enumeration Luca: Yes, that's the
intention. Lixia: the routing system does not tell whether a prefix is unicast
or anycast Dave: So the matching scheme in this case is CCN Exact matching, not
NDN Longest Prefix matching? Luca: Yes Dave: In regular IPv4, ICMP does flow
hashing. Here it does not make sense to do this flow hashing, right? Luca:
Right Ravi: How is the ICN payload encapsulated here? Luca: There is no ICN
encapsulation, it's called hICN. See slide with packet layout. ??: Do you
consider NACK packets also? Luca: Yes, it implements the concept of ICN, so you
can do that. Dave: the locator part can not be part of the signature? Luca: no,
some fields have to be set to zero before calculating the signature Jan: how
about opensource? Luca: everything is opensource in CICN, except for the hICN
libraries. But they are available for use.

•       Map-Me: Managing Anchor-less Producer Mobility in Content-Centric
Networks ( https://mapme-tnsm17.github.io/) - Giovanna Carofiglio (25 min +

Thomas: do I understand that for every update you flood the whole network?
Giovanna: No, you are following fib entries upstream
Thomas: but then you have to flood all fib entries
Dave: you flood the spanning three
Jan: so what if the producer moves out of the spanning tree?
Thomas: this is an Intra-domain protocol

•       Map-Me implementation in hICN and applications to next generation
mobile networks - Jordan Augé (15 min + questions)
                No questions

•       FD.io/CICN open source project - update on the consumer/producer socket
API and HTTP support - Mauro Sardara (15 min)

Dirk: the way you deal with web traffic over ICN, would be very interesting for
follow-up discussions. Mauro: yes, maybe for next time, when we have done some
live distribution with hICN

•       PyCN-lite (for IoT, running MicroPython?), and PiCN (for NFN) -
Christian Tschudin (15 min)

Dirk: Any measurement data regarding throughput?
Christian: Not yet, we first focus on functionality
Thomas: As a remark on Python, IoT and RIOT. MicroPython is currently not
ported to RIOT, but if it is done, it would rule out certain more limited
boards. Christian: yes I agree with that Dave: anyone tried this in a
unikernel? Christian: not yet Lixia: is the security layer still weakly
implemented? Christian: yes, I think that is still true. Currently implemented
•      “Enabling Dynamic ICN Multicast in Cellular Radio
                 Access” - Ravi Ravindran (15 min)

Dirk: Interesting topic, maybe next meeting focus on key technical issues, and
how ICN can really help there.

•       New draft: (based on Contrace): "CCNinfo: Discovering Content and
Network Information in Content-Centric" :
https://datatracker.ietf.org/doc/draft-asaeda-icnrg-ccninfo/ - Xun Shao (15 min)

Dave: the reason you depend on the timeout rather than the response, is that a
single request can have multiple responses right? Have you thought about how to
allocate the link resources for these things? Dirk: you are ignoring flow
balance here right? Xun: There is no flow balance. Dave: (chairhat off) indeed
merging with traceroute won't work because they are quite different. Technical
comment, since your planning on returning lot of information, channel
allocation is made really difficult. Borje: How far are you planning to
distribute these Interest messages? Xun: There are hop limit and timeout
options Dave: I think we need a way to trade off the resource expanses on the
exploding amount of data that might be returned. Eve: This problem of
'explosion' of returned data is applicable for more use cases, so it would be
very interesting if some one can come up with a solution for it, not only in
the case of CCNinfo, but in a more general way.
•      Demo: "Deployment of ICN stacks and NDN in particular
                 by leveraging NFV" - Guillaume Doyen (20 min) [Demo
                 introduction and demo. The demo will also be shown at the end
                 of the lunch break and at the afternoon coffee break.]

Dirk: for scaling monitoring, are you only monitoring PIT size, or more?
Guillaume: only PIT size for the moment.
Dirk: have you made any measurements to see how the system performs when under
attack? Guillaume: that is something we are working on at the moment, to the
amount of good versus bad content.

12:30-14:00 Lunch

•       New draft: "Requirements for Key Management in CCN/NDN” :
https://datatracker.ietf.org/doc/draft-li-icnrg-km-reqs/ - Ruidong Li (15 min)

Eve: Have you thought about fetching keys when connectivity is intermittent?
Ruidong: We will consider it.
Dirk: From chair's perspective, we avoid "requirements" and suggest
"considerations". Eve: There are requirements for use cases. Borje: This has a
lot of general requirements for all key management. We should focus on
ICN-specific. Dave: We want long-lived content, but short-term keys. We'll want
to iterate this question a lot.

•       New draft: "DABBER: Information-centric Routing for Opportunistic
Wireless Networks" : (
https://datatracker.ietf.org/doc/draft-mendes-icnrg-dabber/) - Paulo Mendes (15
min) (No questions.)

•       New draft: "Architectural Considerations of ICN using NRS” :
https://datatracker.ietf.org/doc/draft-hong-icnrg-icnnrs/ - Jungha Hong (15 min)

Q: Is the resolution done by the consumer?
Jungha: It's done in the application layer just like DNS lookup.
Dirk: I think this is a productive way to address NRS, so thank you.

•       Revised draft: "CCNx Extension for Name Resolution Service" :
https://datatracker.ietf.org/doc/draft-hong-icnrg-ccnx-nrs/ - Jungha Hong (10

•       Revised draft: "Requirements for Name Resolution Service in ICN" :
https://datatracker.ietf.org/doc/draft-jhong-icnrg-nrs-requirements/ - Jungha
Hong (10 min)

Dave to the room: Please review the draft. It's been through a number of good

•       ICN control signaling - follow up from the Berlin meeting - Thomas C.
Schmidt (15 min)

Thomas to the room: So, should we introduce a 3rd packet type for control
signaling, not Interest or Data? Christian: With RPC, I avoided introducing a
3rd packet type by allowing manipulating the PIT. Dave: We have to tease apart
types of attacks. You can't necessarily prevent the attack by using a packet
that doesn't keep state. Dave: What's the difference between a new protocol vs.
Interest/Data exchange that only goes one hop? Thomas: I can use an Interest to
trigger someone else to ask for something. Dave: If the trigger is for some
third party to reply, then you could get redirection attacks. But between two
parties I don't see a problem. You may be asking "how to do three-way
information exchange" but it's not limited to control signaling. Lixia: The new
NDN Interest format will have an Interest parameters field. So you should use
use Interest/Data exchange unless it is proven infeasible. Börje to the room:
Do people think that putting extra data in the Interest is a bad idea? Dave: If
a larger Interest causes fragmentation, you should rethink. Also, everything in
the Interest name needs to come back in the Data packet name. There could be
cut and paste attacks. Finally, you want to avoid having to authenticate an
Interest. Dirk: Currently we don't see anything that precludes using
Interest/Data. Maybe there are other use cases.

•       Revised draft: "Publish-Subscribe Deployment Option for NDN in the
Constrained Internet of Things" :
https://datatracker.ietf.org/doc/draft-gundogan-icnrg-pub-iot/ - Cenk Gündoğan
(10 min)

Ravi: Did you consider the case for mission-critical low latency?
Cenk: It's the same as Interest/Data exchange.
Ravi: We've been calling for a push primitive.

•       Revised draft: "Design Considerations for Applying ICN to IoT" :
https://datatracker.ietf.org/doc/draft-irtf-icnrg-icniot/ - Ravi Ravindran (10

(To save time, Ravi will summarize the changes on the mailing list.)

•       Revised draft: "Forwarding Label support in CCN Protocol" :
https://datatracker.ietf.org/doc/draft-ravi-icnrg-ccn-forwarding-label/ - Ravi
Ravindran (10 min)
(No questions.)

•       Revised draft: "File-Like ICN Collection (FLIC)" :
https://datatracker.ietf.org/doc/draft-irtf-icnrg-flic/ - Christopher A. Wood
& Christian Tschudin (10 min)

Dave: We should support some parts encrypted, some not.
Christian: So maybe not encrypt the index table.
Dave: Or different parts encrypted with different keys.
Luca: Is there a way to rebuild the manifest efficiently?
Christian: For me, the manifest exists persistently along with the data. But
tell me if you know a use case to construct a manifest on the fly. Dave: If you
can package the manifest and data in one object, you could make the manifest
obligatory and get everything in one round trip. Dirk: FLIC is a potential core
spec for the group.

•       Revised draft: "Network Coding for Content-Centric Networking / Named
Data Networking: Requirements and Challenges" :
https://datatracker.ietf.org/doc/draft-matsuzono-nwcrg-nwc-ccn-reqs/ - Cedric
Westphal (10 min)

Dirk: Experiments?
Cedric: An implementation based on a student from University of Bern.
(Further questions deferred to the NWCRG meeting.)

17:00 Meeting ends (the latest)