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

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
Etherpad for notes: ​http://etherpad.tools.ietf.org:9000/p/notes-ietf-100-icnrg
Meeting Materials:
https://datatracker.ietf.org/meeting/interim-2017-icnrg-04/session/icnrg
Refreshments for the breaks are kindly provided by Huawei.

Proposed Agenda ¶
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/
​https://datatracker.ietf.org/doc/draft-irtf-icnrg-ccnxsemantics/ FLIC update -
Chris Wood Status update and discussion on 802.15.4 ICN Adaptation Layer -
Thomas Schmidt Status update and discussion on Contrace: - Xun Shao
​https://tools.ietf.org/html/draft-asaeda-icnrg-contrace-04 Terminology Doc
update & process for RG adoption - Bastiaan Wissingh

--- Note taker: Nacho Solis
>> CCNx protocol docs (no comments)

>> 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)

>> 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

>> 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
No objections to adoption

10:30-11:00 Coffee

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/
Requirements for Name Resolution Service in ICN - Jungha Hong
​https://datatracker.ietf.org/doc/draft-jhong-icnrg-nrs-requirements/
Intro to discussion (Dave Oran)
Short discussion starters (5 min/each): Börje Ohlman, Jungha Hong

--- Note taker: Nacho Solis

> NRS implementation

- 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 NRS in ICN
- 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 entity, 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 with producer (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 algorithms commonly use RTT. Introducing
hidden delays due to name resolution could confuse congestion control
algorithms.

> 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.

17:00ish End of meeting

---------------------------------------------------------------------------

Notes from 15 Nov session

1. chair shared agenda

2. Chair shared debiref from Sunday interim meeting. Folloing topics are
discussed - ICN adaption layer on 802.15.4 (com - NRS implementaiton based on
CCNx/CICN (ETRI proof of concepts) - Name resolution in ICN (Architecture
design considerations) - Cisco will be really interested because it has
implication in scalability and security - Kafka stream and ICN (How ICN
improves applicaiton layer messaging and processing) - AR/VR and how ICN can
play any role - IOT and ICN

Presentation

IoT and ICN discussion
IoT Naming - some reflections - Börje Ohlman (15 min)
Questions: What is the objective of the presentation.
Answer:  We want to have concesus and put together draft
Chair comment- Multiple names for same data. what does it mean by same. Is
there any alternative to this. Nacho - self certifying name for same data at
different locations. This hashing can be same fo rsame data. Federation of
applications which can use different set of data by identifying structure of
data. The system should be capable of interperting and processing data by
identifying schema Borje - We need to document the use cases and use this
information in global context.

Status update and discussion on revised Support for Notifications in CCN - Ravi
Ravindran (15 min)
https://datatracker.ietf.org/doc/draft-ravi-icnrg-ccn-notification/ Status
update and discussion on Design Considerations for Applying ICN to IoT draft -
Ravi Ravindran (15 min)
https://datatracker.ietf.org/doc/draft-zhang-icnrg-icniot/ Status update and
discussion on ICN based Architecture for IoT - Ravi Ravindran (15 min)
https://datatracker.ietf.org/doc/draft-zhang-icnrg-icniot-architecture/ Ravi -
Received lot of comments. It is merged into one draft >> design consideration
Update - It uses design consideration rather than requirements. Motivated from
IOT deployments and it provides open API for inter-operability. IChanges in IOT
architecture due to ICN. Scope of security is defined..

Chair asked if can we adopt as RG group. The feedback is YES. The chair will be
confirm on mailer

Enabling ICN in 3GPP's 5G NextGen? Core Architecture - Ravi Ravindran, Prakash
Suthar and GQ Wang (15 min)
https://www.ietf.org/internet-drafts/draft-ravi-icnrg-5gc-icn-00.txt First
draft covering 5G core, network slicing and how ICN can be leveraged to
optimize overall architecture.

Q: ICN will be application which will not require any change in protocol.
A: ICN awareness is required in 5GC  which implies  feature support to
understand ICN based packet

Q: Is this group support standards work or what is the role, compared with
standards bodies. A (chair): Reasearch impacting mobility management. The
audiance for this draft is ICN community and if 3GPP can take it. Will there is
enough hooks in the 5GC to enable ICN like technology

Q: How are we going to map ICN in 5G core. what is view of network slicing.
Does ICN provide technology or ICN use network slicing A: Enable ICN in data
plane whihc impacting control plane

Q: 3GPP provides network slicing for Control plane slicing and not data plane
A: This draft doesn't impact any  control plane

Status update and discussion on revised ICN-LTE document: (15 min)
https://datatracker.ietf.org/doc/draft-suthar-icnrg-icn-lte-4g/ - Prakash Suthar
  Pre-presentation comment/question:
  Dirk: you can say what is the relation of your work with Ravi ?
  Prakash: discussions in cellular networks w.r.t. IP with non-IP; ICN may
  provide solution for non-IP - this draft is  more related to the current
  networks (also co-author of the 5G-ICN draft); [...] -we have a lab in Cisco
  where we actually experimenting work presented here, and we can demo

    Post-presentation:
    Dirk: have you ever had feedback/question on this work in the non ICN
    community Prakash: Yes there is lot of interest in this research.
        - Presented in industry (Linux foundation, Ciscolive, IEEE RAFNET)
        - Presented at Ciscolive with very good feedback from service providers
        - Presented to the Linux Foundation (they are very interested into
        virtualization), there were 5/6  mobile operators - asked about the
        demo - Presented at IEEE Future internet Architecutre (FIA), Torando -
        they did not think it was possible before coming to conference, We have
        showed the demo

    Dirk: who is in favor of adoptiong the draft (show of hands)
    ok, there is some of interest
    Dirk: we need to figure out how to proceed on this document
       (will) ask the question again on the mailiing list,

Status update and discussion on revised ICN deployment Guidelines Document: (15
min) https://datatracker.ietf.org/doc/draft-rahman-icnrg-deployment-guidelines/
- Akbar Rahman Draft revised  twice since last IETF with detailed feedback

Q: Is ICN at edge or there are more use cases
A: ICN can be expanded inside network.

Q: Is this ICN/NDN only overlay over UDP
A: In general yes. Running ICN over WiFi in campus network (ICN as underlay)
and on top is IP.

Network Coding for CCN & NDN - Kazuhisa Matsuzono (15 min)
https://datatracker.ietf.org/doc/draft-matsuzono-nwcrg-nwc-ccn-reqs/
Two presentations in last IETF (Low latency low loss streaming and NDN naming)

Q (Dave Oran): Is recoding inside security envelope
A (Presenter): No, because we need unencrypt

Q: (Alison) IRTF questions, are you working on network coding group, or will be
interesting in this group? A (Presenter): This is just use case for CCN.

Q (Alison): To chair. Do you want to focus on coding
A (Dave and other chair): We do not want to assume that ICN/NDN is immutable.
We want to look at coding fo make it more friendly. Is this to be owned by MCRG
or ICNRG?. WE will cooperate with coding group.

Multi-Service Tag (duanshihui):
https://datatracker.ietf.org/doc/draft-xia-icn-multiservtag/ (15 min)

Q (Dave): if you look at existing ICN architecture naming convention is quite
clear. Knowing name is in sufficinet abouot how content to be stored?. A
(Presenter): We are looking at some aspect how naming to be used for storing
the content

Wrap up - Chairs (5 min)

Future ICNRG meetings
Chair - We are open to have ICNRG interim. If you see any topic to be covered
please let us know Chair (Dave) -  we are looking for voluteer to host meeting

ICNRG @ IETF101, London
Regular?
Sunday Interim?