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

From: "David Oran" <[email-masked]>
Date: Tue, 18 Jul 2017 14:35:55 +0200

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

---

From: Lixia Zhang <[email-masked]>
Date: Tue, 18 Jul 2017 07:04:57 -0700

> Comments/corrections to DaveO:
seems to me it'd a lot easier to put this in etherpad as we did before, so that people can just make changes directly

> 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 <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 <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 <http://opendl.ifip-tc6.org/db/conf/networking/networking2017/index.html>
> Slides: https://www.ee.ucl.ac.uk/~ipsaras/files/icfc-slides.zip  <https://www.ee.ucl.ac.uk/%7Eipsaras/files/icfc-slides.zip%C2%A0>
> 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)
> 
> 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?
> Christian Tschudin: Will processed data (by third tier partners) also be published, not only the raw data?
> 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.
> 
> 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.
> 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 <http://dl.acm.org/citation.cfm?id=2980141>
> Dave: i.e. same authority of app developing and infrastructure (access points)?
> Dave: ah, I see how this works with WIFI direct. How does my phone learn about your mapping? Coordination among many parties?
> 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?
> 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
> Gareth Tyson: Thick/thin client - also possible to download an app from another device?
> 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
> 
> 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)?
> 
> 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.
> 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.
> 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
> Dave: no, can't revoke data. Need to wait until old data expires, then reuse name.
> Alex: currently in NDN can exclude old data, perhaps better solutions (SYNC) in the future.
> 
> Jan: flow balance leads to different scheduling than IP routers. Were there any papers on this?
> Antonio: Why FB? Shouldn't it be done by the app? Still can generate interests at any rate, flood the net.
> Luca: global network stability can by gained by local enforcement. Sending many interests is not a stationary thing, will go away.
> Dave: Coupled to symmetric forwarding, flow balance only works with this.
> 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.
> 
> ThomasS: Re pushing of data, we should not go away from request/reply schema, see presentation on Wednesday on avoiding pushing.
> Jungha: Agree on pull but in IoT (and only in this env) we need the push.
> 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?
> Akbar: All my comments on the previous version were taken into account, thanks.
> 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.
> 
> 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
> 
> 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
> 
> Marcel Enguehard: role of "assembly node" - does it require a new authority to hand out tags?
> 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.
> Dave: flow class an known discourse, your work seems to assume that somebody did that already. Should be integrated/studied.
> Alex: ICN2017 poster and demo deadline is Jul 20, after the notification. Consider reformulating rejected papers as posters, submit them.
> 
> _______________________________________________
> icnrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg

---

From: "David Oran" <[email-masked]>
Date: Tue, 18 Jul 2017 16:41:02 +0200

> seems to me it'd a lot easier to put this in etherpad as we did before, so that people can just make changes directly
It was in Etherpad, and you could have done that before I extracted it for re-formatting and final publication…

DaveO