[icnrg] Draft Minutes from Interim Meeting Sunday 2017 July 16

["David Oran" <[e-mail]>]

Many thanks to our two note takes, Ioannis and Christian!

Comments/corrections to DaveO:

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