Today's meeting will focus on transactions
Four RFCs published since the last meeting. Thanks to the authors.
To be completed soon.
Related drafts. Brief presentation of what these are about.
Reflexive forwarding for modeling client-server interactions in which
sizeable parameters need to be passed. RG draft - update coming soon
Flow balance for congestion control addresses the issue that you cannot
simply count Interest packets to estimate how much data is coming back
in Data packets as the latter have a very large dynamic range (few-64K
bytes). (individual draft)
Microservices: currently being discussed how to best handle this. The
specification should go beyond a general architecture doc and look more
into a concrete specification. (individual draft)
Brief introduction by the chair. Overview of evolving shared state. (see
slides for details)
Transactions (with ACID properties) are easier to achieve in traditional
client-server systems.
Different ways to realize transactions: ICN as a network layer vs.
shared data structures.
Today, two ways discussed.
Dirk Kutscher presents.
Original web design vs. today's (commercial) reality.
Data-oriented Web
Which ICN components do we need? Discussing real-time media (cf.
ROBUST), FLIC, and others.
Transactions (ref to reflexive forwarding and to "RESTful
Information-Centric Networking").
Shows how to do transactions with Reflexive Forwarding
Dave: lots of experience on distributed systems has it that transactions
or secure multi-interactions will generally require more than a single
two-way exchange.
Dirk: discussed a bit a NDNcom two weeks. [...]
Lixia: ICN and NDN has authentication carried out when the signed
interest arrives which directly proves authentication.
Dave: I disagree with this. Consider authorization. In chat Dave
commented that forcing a server to do signature verification on initial
request arrival ha been shown in prior systems (e.g. TCP+TLS) to
represent a seroous computational DOS attack risk.
Lixia: authorization is past authentication. So you can in fact do
authentication ahead of time and not in the authorization pahse.
Dirk: Here, the assumption is that you cannot fully rely on
pre-authentication, but you talk to your server and but the server
doesn't need to know ahead of time who you are; insgead you do
authenticatio and authorization as part of an initial exchange.
Application-layer semantics may require an additional step.
Mark: whenever a protocol does authentication. you need to analyze in
the context of specific examples to discuss, cannot only look at an
abstract level.
Lixia: tomorrow presentation at the DINRG meeting on NDN for distributed
"workspaces".
Wrapup: how to realize transactions in information-centric systems?
Next presentation will look at transactions with shared data strutures.
Marc Mosko presenting.
Initial ideas of transaction manifests.
How would DLT-style distributed transaction map to ICNs?
We discuss a data object, the Transaction Manifest, as a concept.
FLIC: how to encode a single object.
TM: input state -> output state
only the input is relevant (and thus part of the transaction)
TMs need a set of bookkeepers
Bookkeeper job
TMs and Repos and Caches
Difference between Repo and Cache concerning TMs
Naming TMs
Distributed TMs
Dave: with multi-bookkeeper systems, you will have to deal with
livelocks and deadlocks. Often, total order is used for resolution. Can
we do this without total order?
Mark: transaction that goes in names the rows something is
preconditioned on. So, maybe? Unclear at this point. Needs to be looked
at.
Dave: multiple uncoordinated databases, maybe, not following this field.
Mark: TM doesn't require a read-ahead lock; TMs are lockless, things can
fail, there is potentially unfairness between nodes that have different
access latencies
Dave: Yes, this can cause Livelock starvation of some requesters. You
may be able to work without a total order if you have some menas to
provide fairness
Mark: not necessarily a desriable property; for a
bookkeeper-to-bookkeeper protocol, you may not want to address the
fairness issue the same way.
Next steps: sketch out protocols, analyze, prototype
Vanadium does distributed access control as presented at the NDNcom
meeting. Thought this would be interesting to introduce here.
What it is? secure, distributed RPC system
Why? Seems interesting for ICN
Quick intro to Vanadium, then discuss
Vanadium has two parts
Dave: would be interesting to do an apples-to-apples comparison to the
NDN trust schema; Vanadium's approach with the ability to create
blessings and caveats on demand seems to be much more granular and
dynamic.
Mark: I suspect you could. SDSI co-signing objects in CCN. but this
never got anywhere.
Dave: mentioned Dan Boneh's work on aggregate signatures. Does this
apply here?
Mark: Signature wrapping more than concurrent signatures.
Mark: Sync base application and a chat application on top. Interesting
to see how to map those to ICN. Interesting to see features to be usable
as takeaway
Mark: No slides prepared for this.
Mark: How do you know that the key you are looking at is the key that
you should be looking at. IPFS totally punts that, pushing to
out-of-band.
Mark: there is a little bit of trust in IPFS bt not much
CCNX: uses public keys scoped names; you can put a public key, publisher
ID, in an interest and say you only wanyt this name if signed with the
associated key.
Dave: autoconfiguring security is an oxymoron. You will need some trust
root established via a leap-of-faith outside the system to start of
with.
Dave: scoped vs non-scoped namespaces. something we did in the past may
be wortwhile looking at again. RPC system for the OSF distributed
computing environment. All namespaces were scoped nd start out as local.
Then you could "attach" a local namespace to a more global namespace via
an explicit graft operation. The key here was that the authoritative
pointers repreenting the namespace graph were from child to parent, as
opposed to parent to child as it is with systems like DNS.
Your local trust root identifier could become a name in a higher layer
space, yielding a trust root higher in the hierarchy tha could be used
instead of or in addition to your local trust root.
Doing this can create progressively more global name spaces out of local
ones
Mark: what their mount tables allow, is doing a relative naming scheme
Dave: in relative naming systems it's often not feasible to compare two
names and ascertain whether these are the the same thing; may be
computationally infeasible or require any comparion to knowa priori
where in the relative namespace each one came from (which then forces
you to have distinguished roots anyway)
Mark + Dave: That's the way that we structured flick manifests. You can
always write a new Root manifest that points to a previous manifest. And
you can give that root a new name. The operation of asking "are these
two things the same" is very simple it's still hierarchical and you're
growing from the top down. The assertion that some sub manifest as part
of this larger manifest is an assertion by the larger manifest. So the
the the in the interesting inversion here that may be worth looking at
through all these years. Is growing things from the bottom up with the
authoritative pointers being the child to parent pointers. Uh-huh.
Right. Right. So orphans have enough state to computationally find their
parent if the system gets disconnected.
ICNP soliciting ICN submissions
Future ICNRG meetings: