Minutes of ICNRG Interim meeting Singapore, Singapore, November 12, 2017 Date: Sunday November 12, 2017 Time: 09:00-17:00 Location: Raffles City Convention Center (IETF meeting venue) Room: Bras Basah Materials: https://datatracker.ietf.org/meeting/interim-2017-icnrg-04/session/icnrg Refreshments for the breaks are kindly provided by Huawei. Note taker: Nacho Solis ---------------------------------------------------------------------- 09:00 Meeting starts Chairs Welcome, Notes takers, Agenda bashing, Bluesheets ===================================== Update on CCNx protocol documents - revision based on IRTF review in process: - Chris Wood --------------------------------------------------------------------------- https://datatracker.ietf.org/doc/draft-irtf-icnrg-ccnxmessages/ >> CCNx protocol docs (no comments) https://datatracker.ietf.org/doc/draft-irtf-icnrg-ccnxsemantics/ FLIC update - Chris Wood >> FLIC - Reviewers requested - Nacho: Discussion about "size pointers" and whether those are the right solution. There will always be the need for uneven data to be supported. So optimizing for equal size does not save work (we always have to implement odd sizes). - Dave: Some work starting on manifests for video streams - Nacho: Video a good example of where end blocks are not necessarily the same size. - Dave: do we need a more flexible encryption mechanism for manifests? We may want intermediate nodes (routers/caches) to be able to access some metadata information. Metadata might be more sensitive than the hashes for the nameless objects - Dave: How will we do a registry for metadata. - Nacho: Does anybody use manifests? (no answers) Status update and discussion on 802.15.4 ICN Adaptation Layer - Thomas Schmidt ----------------------------------------------------------------- >> 802.15.4 ICN Adaptation Layer - Dave: Technically, this is an "over-X" document. - Nacho: should we look at compression as a general topic? - - group: various ways to do compression - - 802.15.4 has some ... peculiarities, so techniques for this may not map to other alternatives - Works for both CCN and NDN - Dave: Should we look at a multi layer solution for compression (given that we have forwarding state at nodes) - No other "over-X" docs - - No over-ethernet doc - - No over-udp doc Status update and discussion on Contrace: - Xun Shao ------------------------------------------- https://tools.ietf.org/html/draft-asaeda-icnrg-contrace-04 >> Contrace (Original author not presenting, the group has doubts, author will be present tomorrow) - Chairs: adoption of draft will wait until merge with ICN-Traceroute Differences between ICN-Traceroute and Contrace: Contrace uses separate TLV, ICN-traceroute uses a separate daemon. - Discussion of differences and the merging process might be good for next meeting Q- Who assigns router name? Discussion - who names routers in general (more than just for traceroute) Is it a hard problem or a easy problem - Does the AS assign the name? - Forwarding entities will publish their own content this means they may have their own "routable prefix" - router "identifier" and prefix for it to publish data are different but could be the same - more work needed. - Trace could be used to discover the routable name of the forwarder Terminology Doc update & process for RG adoption - Bastiaan Wissingh --------------------------------------------------------- >> Terminology No objections to adoption Name resolution and name based routing in ICN ============================== NRS implementation based on CCNx/CICN - Jungha Hong ---------------------------------------------- https://datatracker.ietf.org/doc/draft-hong-icnrg-ccnx-nrs/ - clarification: client sends interest... when router (Content Router, CR) doesn't have an entry (in FIB or PIT, etc) it contacts the NRS by opening a connection to the NRS. - Q: How similar is NRS to DNS, does it have zones? - unclear - Q: Do you require one level per name component? - unclear - Q: why not just use DNS? - unclear - Q: is the notion of "domain" like an AS? - unclear - Maybe we need a comparison to DNS - All internal communication in the prototype is TCP based. - Q: Why is the CCN protocol modified to talk to NRS? - unclear - There is a potential DOS attack by just sending unknown names to the CR - Q: What if the returned name by NRS is not in the FIB? - Comment: potentially divide in 3 components - how to query the NRS, the internal workings of the NRS, and what you do once you get the second name. - Comment: what about the update protocol? - Question: How do you deal with mapping more than one name? for example /mail/mail1/chunk=0 to /mail/mail2/chunk=0? - - A: Currently we only map 2 components (or up to the chunk number) Requirements for Name Resolution Service in ICN - Jungha Hong --------------------------------------------------- https://datatracker.ietf.org/doc/draft-jhong-icnrg-nrs-requirements/ - Comment: Can we capture issues discussed earlier in the requirements - the NRS (earlier) is a possible implementation - Comment: We are not bound by IETF so we don't need a "Requirements" doc. - Comment: One of the purposes of the NRS is to scale routing. We should consider working from the security up, instead of bolting security onto a pre-existing routing system. - Comment: pick a title that reflects what we're actually doing. --Note taker: Greg White > NRS Short discussion (Dave Oran) -Q: How are IP directory service (COAP resource directory, mDNS) WGs handling related problems? -Comment: COAP RD is a local enitiy, not global, so it is easier -A: paper at ACM-ICN used tag-based routing for local context instead of hierarchical name-based Q: What is relationship between Producer-Consumer A: if only consumers call naming service that has trust relationship . Routers may not have trust relationship (root of trust). - router should trust NRS A: router might connect to untrusted NRS in another network - routers should only connect to NRS instances that it is configured to connect to Dave: Google Cafe-Espresso example: applications resolve locations, network doesn't resolve it comment: may not work in a lot of use cases (edge computing, etc) Dave: XIA used flat namespace but embedded routing information in packet, routers don't have FIB ... not saying we should do that in NDN/CCN Dirk: One workaround to not being able to secure the Producer-Consumer trust relationship- trust the network (ISP) >slides-interim-2107-icnrg-04-sessa-nrs-discussion-input-jungha-hong (Jungha Hong) Dave: one thing to consider in the consumer-based vs router-based name resolution debate - congestion control algos commonly use RTT. Introducing hidden delays due to name resolution could confuse congestion control algos. > NRS discussion (the elephant in the room) (Börje) Fundamentally, hierarchical name based routing doesn't provide ID locator separation Comment: routable name doesn't have be the ID. Comment: Forwarding needs to be based on location, human-readable identifier doesn't need to be. Börje: But the whole idea of ICN was that the name of the content identified the content itself, not the location Comment: there is value in a network infrastructure that can provide "micro-services" that can support core network functions like routing scalability, etc Comment: ID has to be meaningful to humans in order to solve the "bus problem" (how does a human know whether to trust a content object unless they can inherently understand (and hence trust) the name of that object?) Comment: Why not just have the client query the NRS, so that all Interests can be routable? Comment: A conclusion we came to for Link objects is that they need two signatures (both entities). I'm not sure that having bi-directional signatures actually solves anything. It does if the target is only routable to based on a link object (i.e. not routable directly) For mobility, application layer approaches aren't sufficient, the network needs to have built-in support (e.g. resolution service) In some cases (high speed trains) movement is predictable tunneling approaches are not scalable to large numbers of users and high speeds local tunneling, a couple of hops, is fine due to physical constraints of movement locator binding (in an NRS or routing table) can be updated on larger movements, local network technologies can support movements within the local scope > Stream processing basics (Nacho Solis) Some parallels to ICN Stream processing = message processing Offset is a unique (monotonically increasing) id for a message within a partition Q: Is Kafka globally distributed? A: No, a cluster assumes that nodes are within a data center. Q: what do you do about time? A: 2 types of time: event time (tagged by sender) & processing time. Q: if event time is arbitrarily accurate, is it sufficient to eliminate mechanisms for FIFO guarantees? Q: how are stream (topic) names chosen? A: there is a single authority to ensure names are unique A stream/message processing system built on ICN could be a great project > ICE-AR (Lixia Zhang) Q: have you discovered any architectural changes that are needed in NDN, or is it perfect? A: can't say it is perfect, but have not needed to make any changes so far. Q: you mentioned caching. How is it utilized in the AR application? A: just like any application, if multiple consumers are requesting the same item, it can be served from cache Q: what is the benefit for ICN in edge computing? A: code is data. it can migrate to edge compute instances close to where the function request originated Q: can you give an example of what you've changed based on a request from an application? A: no changes.