Minutes ICNRG Interim Meeting
March 24 2019
IETF 104 - Prague
Chairs Intro: Agenda Bashing, Minutes taker, Bluesheets, Status (15 min)
- ICN conference in Hong Kong 24-26 September with ICNRG interim a day after so plan to stay an extra day.
- Broader CFP with added ancillary topics e.g. distributed network, metrics, use cases, applications, deployment etc.
- May 3 paper registration, May 10 paper submission.
- Assume papers will be shepherded, but needs confirmation from TPC chairs .
- Double blind reviewing
A keyword-based naming for in-network computing - Onur Ascigil (25 Mins)
Question (DaveO): hashing changes the data
Answer: we do a hash of the data name not hash of the data
Question (ThomasS): authority relation to routing? name does not say anything about routing; names are not location based
Answer: authority allows to send an interest to the right domain
Question/comment (JanS): More names than IP addresses and this adding? Routing scalability?
Answer: That is why we have routing information in the name like a tag-based routing.
Question (MJM with COIN-co-chair hat): Could this be presented at COIN
Answer: Börje can do it
Question (Dave O.): More recent paper? Since 2017.
Answer: No new paper yet
Question (Dave O.): Actuation: is this done via another mechanism independent of the naming?
Answer: Separate function
Question (Dave O.): Output of the function gets signed by a key generated by whom; any work on data provenance?
Answer: No real answer
Question (Puyan): look at TinyDB; why did you decide to put everything in the name; query issues; keywords address the vocabulary?
Answer: Bloom filter (Discussion on tinyDB: https://tinydb.readthedocs.io/en/latest/)
Comment (Dirk): Tag name components not mentioned
Pub-Sub with ICN - Thomas Schmidt (25 mins)
Should Pub-Sub become a RG item?
Question (Jan): You don’t need the control plane anymore?
Answer: The work can be done on layer 2 without concluding on previous discussions that were open ended; layer 3 prefixes broadcasted on layer 2
Comment (DaveO): looks like a local routing protocol over the mesh - layer 2, 3 or mix - layer 2 broadcast with layer 3 embedded information
Discussion (DaveO/Thomas): Mapping protocol on layer 2 may be needed
Comment (Dirk): We plan to sit together and discuss some more activities related to Pub/sub on ICNRG and come back on Friday with concrete proposal (use Wednesday free time?)
Efficient Blockchain access via ICN - Niels van Adrichem (25 min)
Question (MJM): Is this based on Ethereum? How does it address the work done to reduce the complexity of both gossip and consensus in blockchain?
Answer (DaveO): Seems to addresses the gossip protocol aspects of blockchain
Question (DaveO): Why is the byte overhead so high in the original measurements?
Answer: will be shown later
Comment (Dave O): on getting rid of the NDN signature: if you have both thee could be interesting cache poisoning attacks; perhaps use the bitcoin signature as NDN signature using NDN signature agility feature.
Comment (Dirk): gossip is inefficient for all ledger type applications; there will be a presentation Wednesday at dinrg is being discussed and that could show how it would be worthwhile to revisit the protocol
Comment (MJM): Link to IoT since blockchains are moving there - idea for continuing the work.
Comment (Jan): IETF WG ALTO draft using the ALTO protocol with blockchain so that the p2p know the underlying network
Question/comment (Dave O. on behalf of Lixia): Why is not solved with the NDC sync protocol? Lixia would argue it is (maybe it’s not)
—— BREAK ——
Finalizing Disaster Draft - Jan Seedorf (10 mins)
Question (MJM): Who are the customers?
Answer: Traditional operations for the authors not private networks
Comment (Dirk): Manage the comments in a meaningful way - what are the benefits of ICN for disasters,
Comment (Thomas): Points to discussion for IP over ICN.
Answer: It’s the the draft now
Comment (Dirk): ICN over X pointers also?
NRS Documents Update - Jungha Hong (15 mins)
Question (Christian): very centralized solution that the decentralization movement would react negatively to that
Answer: In the Architecture document, section 3 says it’s distributed
Answer (Börje): it’s a “service” not a “server”
Comment (Christian): the text mentions “server’ at points and could be clarified
NDN Tools Overview, Status, and future plans - Jeff Thompson (30 mins)
CCL= common client library
CNL= Common Name Library
Question (Eve): APIs for alternate ICNs?
Answer: NDN and CCN are similar for interests; IPFS is hash based names but is not addressed now
DaveO: Grey area; how do you deal with different mapping?
Answer: Abstractions
Question (Cedric): Can you translate from one wire format to another?
Answer (supported by Dave O): Cannot translate wire formats as it breaks the signatures
Comment from Christian on how you could do this translation: model it as a function execution on the data
Question (Dave O.): Allows cache exploration with prefix matching?
Answer: Not really. (DaveO thinks if you support Interest/Data on with prefix matching no good way to prevent cache exploration)
(Discussion on how to use this with routing)
Question (DaveO): Mandatory type name component of hashes?
Answer: Yes
Comments (DaveO): Bloom Filter tells you what’s different; may have false positive but works beautifully; on missing useful feature missing is horizon to know the oldest update everyone has seen.
Question (Thomas): Broadcast for topology discovery so PSync needs to know the topology? (P is for “partial”)
Answer: May not be the case
Question (DaveO): CNL Integrated to the Schematized trust?
Answer: good questions <missing words> maybe
Comment: why is the latency so long on NDN-RTC?
Answer: Other person’s slide (could Open FEC be the culprit?)
Comment (DaveO): Not do what the telepresence group did: from the users point of view and cartesian instead of polar
Question (Eve): Relationship with NIST and their code repository?
Answer: Fast new code for Sandy project ; NDSIT head of the NDN consortium now
Question (Thomas): CDN-IOT fixed or dynamic memory allocation?
Answer: has been discussed
—— LUNCH Break ——
NFN Update - Christopher Sherb (20 minutes)
Question (Dirk): You do the pre-pending so to forward the information to whom wants the data?
Answer: Yes this is to chose a specific direction towards a specific node
Answer (Christian) You are not limited to one node,
Question (Eve): Where is the computing and pre-pending computing decisions i? It seems hidden from the user.
Answer: In the rewriting. But it done by the network.
Question (DaveO): In the re-writing can you tell difference between recursion and iteration? In centralized there are well known algorithms to tell and suppress loop for iterative computations - in distributed it is much harder.
Comment (Christian): Question has be asked before; can split the credits
Comment (Jeff): A smart contract on Ethereum is a piece of code and brains are applied to make it secure
NAT= Named Address Translation in this context (joke)
Question (Dirk): In the mobility are there any side effects?
Answer: You may need to update the data because of the mobility
Comment (DaveO): Seems that re-writing rules must be reversible so you can unwind the computation (figure is misleading)
(Discussion between Christian, Christopher and David about where the messaging goes)
Question (Eve): Where are you getting the meta information from?
Answer: We have repo that will know the size of the file, n-forwarder know the link and will know how to get a data object
Question (Eve): Danger of assuming the information comes from the forwarder vs. somewhere else? For the next version?
Answer: Even now the plan can be split and distributed in a “planning network”; plans are hop by hop.
Question (DaveO): Plan confined to the forwarders and not seen by the originating nodes? Sharding may force to go back to the originating consumer.
Answer: The structure is such that you do not need that.
Question (Dirk): Caching?
Plans are not exposed everything is cached
Question (Eve): How do you find optimal placement for the execution? How do you deal with multiple metrics (cross-optimization)
Answer: We do not do this for now.
Broadcast-only communication models - Christian Tschudin (30 mins)
Question (Disk): How about sending it to both? Fan out.
You need to invent how to detect when the data stopped.
Question (DaveO): Node failure and partition are non-distinguishable until the partition heals
Answer: If you go to the log you see the difference
Comment (Jeff): AR project problem - cannot convince the network people of the problem.
Question (Eve): What is the problem?
Answer (Jeff): Producer of video, consumer of video. repo keeps the video, pause from the user and sends interest again but the source does not remember and data comes from the repo for a while
Comment (DaveO): Unicast pull in IPTV for fast channel change and fast-forward to realtime from pause - same problem.
Question (Eve): Logs being distributed instead of the data?
Answer: Data
Comments (DaveO): You need routing; you cannot send solitons through a medium that has a un-even density (like networks); the state ate the relays looks a whole lot like this is like Pretty Good Multicast (PGM)
Comment (Thomas): All TV programs are everywhere in the network (DaveO adds that model assumes no sources misbehave)
Question (Eve): Where are the lacks?
Answer: There are no lacks
Question (DaveO): Append-only logs of infinite size?
Answer: For the moment we store everything
Question (DaveO): Soliton does not work with differential delay, things arrive out of order
Answer: Stick to the pure model for now
Comment (DaveO): This is per-source FIFO ordering not causal order. Causal orders are defined across multiple sources
Comment (DaveO): TCP window is for congestion control not replication/log
Comment (Thomas): On CT
Question (DaveO): Fully replicated append-only logs are useful but why is broadcast the right underlying communication primitive to base it on?
Answer: Yes broadcast is better.
Question (DaveO): Why not raising all the way to the CRDT (conflict-free replicated data type)?
Answer: Simpler to deal with the logs only?
Comment (Jeff): In a hackaton: all interest, no data.
Comment (DaveO): In the cited “deforesting L2” paper the scheme is not for broadcast semantics but to do duplicate suppression as the method to prevent loops so you don’t need to track source MAC addresses in the switches. (very cool)
Comment (DaveO): More comments on the need to keep networking and replication at bottleneck resources and congestion control vs. broadcasting separate.
Question (Dirk): ICN lead to sub-optimal solutions - looking at attractive alternatives for higher layer protocols
Answer: Trying out ideas with the group.
—— BREAK ——
Summary of Berkeley CFN workshop - Cedric Westphal (30 mins)
Compute-first relates to NFN.
Question (Eve): Re: Bayware: Anyone else using IPv6 extension headers for micro-service packaging?
Answer (DaveO): Not to my knowledge
Question (Eve): Re: Stratis Ioannidis paper on routing and caching being jointly optimized?
Answer: They don’t have results yet on the full problem
Question (Eve): Big questions. action items?
Answer: Narrow down things that are interesting vs. important.
Question (Christian): Ideal would be with clean slate on CFN.
Answer: Interesting conversation to have around how distributed computing people thinks about computing vs. networking. Need a better agreement on a common understanding of computing. Workshop allowed to get the 2 groups together.
Discussion of management tools (60 mins):
Question (Jeff): Management network?
Answer: Instrumentation, measurements & debugging
Question: NDIST forwarded? Have they thought on management? Worth connecting to their efforts.
Answer: I hope so (discussion on prefix and forwarders, multipath, interest packet steering etc. with Jeff)
—— End ——
Not presented:
PUSHED to Friday