Update from the chairs: Cenk Gündoğan - finalizing the review on ICNLoPan. Dependencies on other document. Referenced Time TLV instead. Document back to Colin. Colin: will get to it soon Chairs think the document is ready. CCNinfo: Discovering Content and Network Information in Content-Centric Networks presented by Hitoshi Asaeda Questions: Dirk Kutscher: status for this would be experimental, right? A: yes Chairs: also think it's ready, will follow up on mailing list re: last call Colin: I have not read existing version. If it's experimental, make clear what sort of experiment this is helping support. Dave: given that it is a management and experiment tool, would it be ok to say that it is the tool you use for the experiment Colin: yeah, you have to tie it up to what is the experiment and why it is useful to have this tool. Dirk: it's on the level of ping or tracerout Colin: in that case, that's what it should say Hitoshi: this requires some registration, is there any relation between experimental vs informational for IANA types? if this informational, is it ok to request new type value for CNNx from the IANA registry? Dave: these are protocol elements that are being defined. Hitoshi: this is operational tool. It may be better to keep as an experimental document. Dirk: Dave and I will work with Hitoshi offline to find a good formulation for the experiment. Colin: to be clear, it's not significant changes. It's a paragraph at most, if it isn't in there already Dave: my proposal is to start a last call now Dirk: everybody please take a look and let us know what you think Decentralised Data Delivery Markets (3DMs) - Yiannis Psaras Build a decentralise CDN using P2P networks Questions: Dirk: any questions to clarify? Dirk: on the fundamental motivations, challenges to do this. Considering CDN are widely deployed and economics well understood. You could argue that there are issues (multicast), but what is the fundamental problem? Why would people need this? Yiannis: starting from the economics is different, there is no single entity on top of this. Y: why people need this, you can think of it as a dropbox thing, doing it in a permission-less, privacy preserving, robust manner. Dirk: security and trust architecture. what is the assumptions on trust? Y: with all different applications that could be applicable on top of this, there's no one-size-fits-all. You could get some username, some identity with a public key. In terms of data, it could be hashing through the content itself, and using that as the name itself and people can later verify that the data they receive is what they asked for. There are more trust models. Dave: I have some questions in the chat window that are related. You seem to be advocating something that is between the fully distributed blockchain rabbit hole and the centralized model. Dave: one extreme is everything is anonymous, the system has no idea of what's going on outside of doing proof of work. The other extreme is you have an identity, there is some central point that keeps track of who does what. You seem in between these two. Y: differente applications would have different applicability. Some applications would benefit from blockchain, but I don't think this would be sustainable for all content requests. There are more trust-based entities, but I would put them on the side of building application. If you are Netflix, you need an identity on your system. This build on top of the base network set-up. Several different models should co-exist. The network itself, and someone wanted to be part of this, - you can start an ISP today- those who are transporting the bits in the overlay should be able to get their gear up and start doing stuff. Both models should be able to interact. Dave: you dance around the problem of how private is the information. Is it expected that the storage nodes don't know who is asking? Y: ideally yes. The system should provide that level of privacy. Dave: you are aware of the cost of full P.I.R.? (Private Information Retrieval) that can be 500x the cost of simple retrieval. Y: when you're trying to design this, you should try to take this into account. TOR has performance damage, but many people use it. Privacy at the ideal level incurs a performance cost. Georgia Fragkouli: Maybe you can look at the Proof-of-Personhood construct (https://ieeexplore.ieee.org/document/7966966), "a mechanism that binds physical entities to virtual identities in a way that enables accountability while preserving anonymity". Y: I will take a look. Dirk: there are two schools of thinking approaching content distribution in ICN ways. One school is to provide some approximation of what CDN does today. Leveraging ICN principle. Your approach is from the other direction: there is a P2P-like network in the first place, then you sort out the economics, then you try to plug in some content centric/addressing network concept to solve the transport. Y: it's very much along the lines of the CDN paper (in the paper review for this work). I'm not sure there is a P2P system. You can assume at t0, there is an incentive to put an infrastructure in the network. The network will start forming in different locations.... [connection interrupted] Y: there isn't an assumption that a p2p network exists already. It's theoretical work at the moment. At some point, once things are sorted out, people would decide to participate in the network, and some user/server/overlay nodes would start popping out. This study and literature review wasn't done with an existing topology. Dirk: it seems that earlier ICN systems like NetInf thought about similar issues. It seems there are two school of thoughts. Y: in the graph forming topic, that's what I meant when I talked about tipping point. The network level ICN approach can give you a nice name-based forwarding scheme that gives you the benefits of information centricity. If you say it works as an overlay, doing named-based forwarding at overlay nodes will increase the traffic at these nodes, as they're not on the path of a sender/receiver. For unpopular content, resolution-based approach like NetInf would be more performance efficient. But for popular content, the popularity would make it so that name-based forwarding is more efficient. Dirk: what's happening in CDN today, more and more moving to the edge. One of the challenge is marrying CDN overlay with multicast-like distribution. Overlay approach may be inefficient. Y: there isn't any approach, it's more of a wish-list at the moment. If there were solutions to the problem areas I talked about, this would be a great use case. Questions from the chat (addressed edge-wise during conversation above): - Dave Oran: do you need to disentangle the economics of storage versus the economics of delivery? If so, how? - Dave Oran: when you say who is requesting what - is this just third parties or the stronger property that the storage nodes can't tell who is requesting the data - Dave Oran: how much of the old P2P stuff do we drag in - e.g. tit-for-tat, do you have to serve storage to use it, - Dirk Kutscher: what is the underlying trust architecture? You mentioned "self-certified names" -- who is certifying them? - David Oran: is there a role for in-network caches all ICN routers? Do they participate in the storage economics or are they separate? - Dave Oran: how can this be "permissionless" and still provide strong identity to base trust and authenticity on? Do you go all the way down the blockchain rabbit hole? Is it the weaker property that you don't depend on connecting authentication to a RWI (real world identity)? Without that, how do the economics work? - Dave Oran: what additional attack vectors do PITs introduce that aren't already in the FIB? Or in logs like netflow? - Dave Oran: what about resilience as an objective function as opposed just to latency? Dave Oran: do you think Rivest's https://people.csail.mit.edu/rivest/Chaffing.txt has a role here? - Ken Calvert: Could you say how this relates to the models in SAIL_DA7 and SAIL_DA8? They looked at the possible relationships (value flow) among CPs, CDNs, access providers, transit providers. - Georgia Fragkouli: Maybe you can look at the Proof-of-Personhood construct (https://ieeexplore.ieee.org/document/7966966), "a mechanism that binds physical entities to virtual identities in a way that enables accountability while preserving anonymity". AN OLD IDEA BECOMING NEW: ICN FOR IOT - Marie-José Montpetit Dave: do we need to solve provenance to make this edge computation/orchestration/data-fusion work? MJ: we need a lot of decision making locally. You can think of autonomous cars (the worst case, generating a lot of data). But even other systems, a lot of the information is not interesting. You are only interested when something happens. Dave: why do you categorize filtering and computation separately? I don't see a difference. MJ: the features of this architecture are intelligent controllers, and this is data driven. You want the data when it's happenening, and not all the time. You want to go from image to decision. Dave: I'm not getting it - you think there's a difference between throwing data away before computing on it as opposed to after? And isn't throwing data away a computation? MJ: yes, throwing data is a computation. But I'm focused on/thinking about image applications, where you can process an image afterwards or discard it. The computation refers to that later processing of the image. MJ: time to re-think some of the earlier work in IoT and ICN. IoT systems are getting more powerful and more data driven. Dave: if you take a computation-centric view of the world. The fundamental objects are computations. If you take a data-centric view of the world, data is the first order, and computation happens on the data. We have to do a bunch of computation to know what data to throw away. What happens close to sensor in detector is very different from two stages back, three stages back. It has to do with what computation happens where. The computation is going to be where the data is. Industrial process control, etc. You don't need to discover the data, because you know where the data is, you designed the system. MJ: you know where the data is, but you don't know what data is going to be relevant. I look at it from a different point of view. I look at it as existing pub-sub in IoT. Existing pub-sub is about asking a simple question and getting a simple answer. But if your Nest thermostat, or you ask Alexa to play a song, it's fine, it works. If you are an industrial system, you'll measure the temperature, the amount of chemicals, whatever. Dave: i think it's a simple question to ask: did I just see a Higgs boson? But that's the result of tremendous amount of computation. It's not what data is where, but how does the computation obtain what it needs to do its job? MJ: and are we doing this with MPTP or COAP? Dave: why not? MJ: maybe the boson is not the generic application (not an IoT system...) Right now, what is available if you do an industrial IoT system, there is no processing where the information is. You have needs, due to connectivity issues, to accumulate the data. You don't want to download the whole database to access one piece of information. You may want to have a way to do data reduction/set of querries to create a more rich dataset than what you would get by asking a simple queries. MJ: my question to the group is if it wanted to revisit ICN-IoT. Dave: if we think of computation as first class object, as opposed to only data as first class object. MJ: I agree with you. What I'm saying is that the original way that IoT pub/sub was to get data. More and more, what you ask of these systems is to do some processing, filtering/processing/learning on that data, and then reply to it. In your query, you want more than just "data X", but "i want data X if data Y has some condition." You need a richer set of query with processing at the edge than is currently offered. Luca Muscariello: Dont you thinkg that the discovery problem is valid beyond IoT. Host automatic configuration in general looks also relevant MJ: it is beyond IoT. If you look at COIN, all the discovery draft, they are looking at a whole bunch of other ways of doing it. There is work at Ericsson in Sweden on how discovery is made based on semantics. Dave : can i publish a computation? MJ: yes If so, then is the sub a request to execute the computation? And how does that differ in any deep way from an acuator? MJ: actuators are very simple processors. I'm thinking at more complex processors, including video processing. Dirk: you can conceive IoT system and one way is: you need to find data and find ways to access it. Or you can think of data stream, like fling, they are told which input data to subscribe to. You would not discover things, but you would benefits from the ability of putting functions in conventient places and letting the system handle connectivity itself. MJ: what you're saying is interesting. Francois Ortolan: Would be great to have IoT use-case examples of what could be achieved with ICN compared to existing standardized high-level APIs (such as oneM2M) MJ: I'm currently working on a use-case, and it's my plan of showing how a current system is limited to what could be much more interesting. Dirk: let's follow up on this. It would be good to talk about specific scenarios. I still think there is a new perspective.