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