Minutes IETF110: icnrg
minutes-110-icnrg-00

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.