Minutes interim-2017-icnrg-04: Sun 09:00
minutes-interim-2017-icnrg-04-201711120900-01

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.