Minutes interim-2017-icnrg-02: Sun 09:00
minutes-interim-2017-icnrg-02-201707160900-00

ICNRG Sunday Jul 16, 2017 meeting notes
"yet another centric-centric meeting (YACCM)":
  - application-centric, data-centric, information-centric
Morning (notetaker: Ioannis Psaras)
---------------------------------------
a) Welcome

b) Dirk Kutscher looks back to the IFIP Workshop on Information-Centric Fog
Computing (ICFC) in Stockholm, June 2017

Workshop
Website: http://networking.ifip.org/2017/index.php/workshops/workshop-on-information-centric-fog-computing-icfc

Workshop
Programme: http://networking.ifip.org/2017/index.php/workshops/workshop-on-information-centric-fog-computing-icfc/icfc-technical-program

Link to
papers: http://opendl.ifip-tc6.org/db/conf/networking/networking2017/index.html

Slides: https://www.ee.ucl.ac.uk/~ipsaras/files/icfc-slides.zip

c) Eve Schooler update on the NSF-Intel partnership on ICN-WEN (Wireless Edge
Networks), "NSF 16-586"

Jeff Thompson: Is third project (LSN) using existing protocols, or building new
ones Eve: yes, and no, not necessarily using MobilityFirst, but looking into
various alternatives. Target is to get these projects involved in the
standardisation (ICNRG)

d) Edmund Yeh on SANDIE: NDN for Data-Intensive Science

Jan Seedorf: lots of power needed to store and transmit this data
Edmund Yeh: project will likely not look into this

Jeff Thompson: Is there going to be a cut-off point to choose a different
protocol for this kinds of environments? Edmund Yeh: Looking to increase
efficiency and avoid breaking the system. If we show that and provide more
systematic solution, then it's a good proposal to be adopted

Dave Oran: the access patterns are different in those environments and will
affect naming - is the project going to look into this? Edmund: yes, certainly,
this is part of the project plan

Christian Tschudin: Will processed data (by third tier partners) also be
published, not only the raw data? Edmund: not on the map yet, may come later

Dirk Kutscher: there are application-level environments and applications for
this kinds of data: how are you going to make the case for a network-level
platform to support this? Edmund: It's a matter of efficiency. If you show
efficiency in content distribution that should be enough.

e) Cedric Westphal on "ICN & Network Coding"
"Seamless Mobility Support" and "Network coded ICN" (NCICN)

Dave Oran: One of the benefits of network coding is that you can do re-coding
in the middle of the network. In this case, the resulting data would have a
different name. How does the consumer know the new name? Is that looked at?
Cedric Westphal: The name has different components. The client should have the
right prefix, not necessarily the right name. Can't work natively (in pure CCN
with exact match), we have a shim name component, needs more attention/work.

f) Lixia Zhang on the ICN-WEN project "NDN-Enabled Secure Edge Networking with
Augmented Reality"

Dave Oran: in previous architectures, naming was transparent to the
applications. Applications didn't know whether communication is local or
global. Lixia Zhang: applications should have their own "desire" to either
operate locally or globally.

Christos Papadopoulos: you need to be able to have the ability to specify
whether application is local or global. Dave Oran: I would like to unlock the
door for a guest from the other end of the world. You have no usable definition
of what local is. Lixia Zhang:

Christian Tschudin: local/global is a concept from the old world - data always
has context. so you derive data through their context. Dave Oran: is context at
the network layer or above? (lot of nodding: above network layer) Lixia Zhang:
IP gives you a more or less flat space and you can talk to anyone. But the
space is not flat.

Dirk Kutscher: dynamic function execution in FPGA: what's the abstraction for
that? NFN. Lixia: NFN is a concept. we do utilise that. The realisation might
be different.

Ravi Ravidran: VR, AR?

g) Ioannis Psaras on "Keyword based mobile application sharing" (KEBAPP)
MobiArch '16, paper link: http://dl.acm.org/citation.cfm?id=2980141

Dave Oran: How to decide binding between SSID and prefix?
Ioannis: It's up to the app developer.
Dave: i.e. same authority of app developing and infrastructure (access points)?
Ioannis: SSID comes out of your device
Dave: ah, I see how this works with WIFI direct. How does my phone learn about
your mapping? Coordination among many parties? Ioannis: graphical user
interface Dave: ah, same table across all devices. Ioannis: yes Jeff Thompson:
Is this supposed to work only in same local network, or remotely? FIB across
the world need to be updated? Or across neighboring LANs? Trust among these
routers? Ioannis: right now it's only local. Integration with WiFi AP is work
in progress. Börje : How would that work with different broadcast domains? Why
restrict to one WiFi? Ioannis: we could consider this. Marc Mosko: See our work
on custodian, use a name resolution system including MAC addresses NN: How much
energy costs of advertising (and running) apps? It's my battery. Ref to Bitcoin
Ioannis: Aware of this incentive discourse. We did not measure. Gareth Tyson:
Thick/thin client - also possible to download an app from another device?
Ioannis: Yes, could be an applet, can get thin client.

h) Luca Muscariello - Update on CICN Community Open Source work

ICN demo "WiFi w/o WLDR":

Dave Oran: what player is used
Luca: developed a player for this

Dave Oran: have a manifest for content, pointing at metadata object to capture
policies (e.g. prefetching), use regexp (similar to schematized trust) to have
an automaton map content fetching with policies

DirkK: FLIC manifests are very basic. Do you plan to extend
Luca: certainly something to look at.

i) Marcel Enguehard (Cisco) on "An introduction to vICN"

Dirk Kutscher: right now you can deploy static code/config: what about dynamic
settings (new wireless node showing up)? Marcel: there is a Python API using
which you can do similar stuff to mininet.

Eve Schooler: modularity of code is very good. are different architectures
going to be integrated? Marcel: it's not restrictive to anything. You can
modify it to do CCN/NDN/ICN or even non-ICN stuff

Dave Oran: All this is done over IP. Closure property: use  IP to
run/deploy/measure IP. Do you have a view of how long it would take to do the
same for ICN natively (run/deploy/measure ICN)?

Morning session ends at 12:45
Afternoon session will start at 14:15

Afternoon (notetaker: Christian Tschudin)
----------------------------------------------

a) Alex Afanasyev on "NDN/CCNx 1.0 Harmonization Effort"

b) Alex Afanasyev on "NDN Protocol Design Principles"

Dave points out the importance of the discussion on (in)dependence on absolute
time clock synchronization. Bad clocks have to be fixed with another protocol
(as an answer to Bengt). And he doesn't like relative time, absolute time makes
things easier with expiration, for example. Lixia: NDN should not break
regarding choice of clock synchronization. Dirk: DTN came also to the
conclusions to not depend on accurate time.

Dave: Immutability good in general, but the binding? More useful for apps is to
expire data and reuse the name after the data has expired. JeffT: points out
that this matches Dave's view on absolute time. Alex: NDN discovery allows to
work around this, e.g. using incomplete names. Dave: Zombie-attack keeping old
data around, apps need a way to ascertain that it has not expired Jan: Dave, is
this data revocation? What about replacing? Dave: no, can't revoke data. Need
to wait until old data expires, then reuse name. Jan: new version is used in
NDN. This is a kind of revocation. Dave: stale data is the problem. Alex:
currently in NDN can exclude old data, perhaps better solutions (SYNC) in the
future.

Dirk on security: What do you mean by "uniquely named"?
Alex: App should not use same name for different content.
Börje: points out that this topic appears on the security slide.

Dave: Fan of flow balance, distinguishing trait.
Jan: flow balance leads to different scheduling than IP routers. Were there any
papers on this? Dirk: This is priced-in into many ICN papers. Antonio: Why FB?
Shouldn't it be done by the app? Still can generate interests at any rate,
flood the net. Alex: every router can decide to honor an interest or not Luca:
global network stability can by gained by local enforcement. Sending many
interests is not a stationary thing, will go away. Antonio: Isn't this like IP
traffic? Dave: Coupled to symmetric forwarding, flow balance only works with
this. Alex: Congestion collapse cannot happen with FB. Lixia: Problem from
multicast times: congestion control could not be solved. Dirk: I worked with
Bengt on "invariants" but ... are these NDN principles really core invariants?
E.g. hierarchical naming, really essential? Can the set of principles be
reduced? Alex: Architecture HAS to allow hierarchical names for demultiplexing,
do not want to introduce port numbers. This is also used in security related
questions, we need more than two levels of name hierarchy.

c) Jungha Hong on "Intelligent IoE Information Platform"

ThomasS: Re pushing of data, we should not go away from request/reply schema,
see presentation on Wednesday on avoiding pushing. Lixia: Pull model important.
Other point: I missed the word security? Jungha: Agree on pull but in IoT (and
only in this env) we need the push. Marcel Enguehard: re security - Should not
allow pushing arbitrary data. Dave: Client sends request to NRS, returns
another name - how does an app (or stack) distinguish among a plain name and
one that has to go to NRS? Jungha: .. moved to offline

d) Bastiaan Wissingh on "ICNRG Terminology v02" draft

Akbar: All my comments on the previous version were taken into account, thanks.
Dave: I suggest to adopt it as a RG draft, forces people to react.
Börje: It's more NDN/CCN terminology, needs to be changed before adoption.

15:20 - 20 minutes break

e) Ravi Ravindran on "Enabling Network Identifier in ICN to support optimized
forwarding" draft

Dave: "Domain can accept or reject the NI" - does reject mean "ignore" or
"remove"? Ravi: depends on what your forwarding state is based on. If reached
edge and you don't need it anymore, can remove.

Dirk: implementations of forwarding labels?
Ravi: our demos are based on it, similar to Luca's demo. Centralized routing.
Dave: with NI?

f) Jungha Hong on "Requirements for Name Resolution Service in ICN" draft

Dirk: how was feedback integrated?
Jungha: one comment from the distribution list, we tried to address all the
points Dirk: how many readers of this document? (Three hands go up) Too few,
please do the pending integration

g) Rachel Huang on an intro to "Multi-service tag in ICN" draft

Marcel Enguehard: role of "assembly node" - does it require a new authority to
hand out tags? Rachel: scope only inside the ICN, not the Internet. Dave: Looks
like a symmetric model, but ICN is asymmetric: Independence of service
importance related to data vs service importance related to request. No single
service class. Rachel: will think it over. Dave: flow class an known discourse,
your work seems to assume that somebody did that already. Should be
integrated/studied. Dirk: Was that specific to some NDN or ICN protocol?
Rachel: no, not looked into it yet.

h) Wrap up

Alex: ICN2017 poster and demo deadline is Jul 20, after the notification.
Consider reformulating rejected papers as posters, submit them.

Dirk: regarding IoT - T2TRG and RIOT meeting are co-located with ICN2017

See you at the regular ICNRG meeting this Wednesday.

Meeting closes at 16:35