►
From YouTube: A Brief History of Information-Centric Networks
Description
Yiannis synthesized and presented research to IPFS and libp2p engineers on 3 systems in the wider academic landscape with novel practices that might be of use in evolving the systems to increase performance and scalability.
Speaker:
Yiannis Psaras
Abstract:
In parallel to the great work being produced within the IPFS and libp2p projects, there has been a parallel stream of work mainly driven by the academic and research community to shift the focus from host-based networking to content- or information-centric networking (CCN/ICN). Most of the work has been kicked off around 2006, mainly from Van Jacobson (at Xerox PARC at the time) and in the form of talks - see [1] for a pretty inspiring talk by Van Jacobson. This later materialised in several papers and is today still going on under the umbrella of the Named-Data Networking project (see below).
A number of projects have since emerged (mainly in the US and Europe) to investigate the properties of a content-centric network, where content itself is the addressable and routable primitive and to build a scalable, efficient and secure Future Internet Architecture. The work has (mostly) assumed that this future Internet architecture will build on top of IP and will involve in-network routing and forwarding entities (i.e., network routers), which will be able to “talk” ICN language.
In this workshop, we will start off with a general introduction to the properties and differences of name-based routing and name-resolution-based routing in Information-Centric Networks, as well as the strength of applying application-level semantics into network-layer names. We will go through some of the most prominent architectural proposals, which are also conceptually close to IPFS and libp2p. The purpose of this interactive workshop will be to:
Identify interesting aspects or features of previously proposed architectures that are worth looking into closer.
Identify (both for the short term and for the long term) what are the desired features and the overall architectural structure of IPFS and what does that mean for libp2p.
Assuming those changes take place in the near future in IPFS and libp2p, what are the features gained and what are those lost.
Below is a brief description of the architectures that will be discussed together with pointers to reading material. The overall length of the workshop is estimated to be 2hrs. Each of the sessions (the three below plus the introduction) will be ~20mins each allowing 10mins for discussion and Q&A in each session).
1) Named Data Networking (NDN)
NDN is a US-driven project, which however is attracting attention worldwide. NDN follows a “name-based routing” approach, where names are hierarchical and routers do longest-prefix matching to find the next node to forward the request to. This is the most radical of the ICN architectures, which assumes that routers in the network (or at least some of them) understand the NDN stack and support in-network content caching. Although it comes with several challenges (e.g., scaling the routing table size), its expected benefits are significant, being able to natively support client mobility, in-network caching and multicast.
Material:
Website (includes a ton of material): named-data.net
Original 2009 paper: https://named-data.net/publications/networkingnamedcontent/
Follow up 2014 paper: https://named-data.net/publications/named_data_networking_ccr/
2) DONA: Data-Oriented (and beyond) Network Architecture
DONA is a 2007 ACM SIGCOMM paper, which advocates a hierarchical data resolution structure, where there is at least one “resolution handler” in each ISP domain. Names are structured according to the form P:L, where P is the cryptographic hash of the principal’s (publisher’s) public key and L is a label given by the principal/publisher which needs to ensure that names are unique. Given the hierarchical structure of the architecture, a challenge for DONA is the stress on the top-level resolution-handler (assuming we’re addressing the entire Internet).
Material:
Paper: http://ccr.sigcomm.org/online/files/fp177-koponen1.pdf
3) NetInf: Network of Information
NetInf is the product of an EU project (which ended around 2015 or so) which resembles a lot the IPFS structure. NetInf is building on name-resolution-based routing (through a Name-Resolution System - NRS). The NRS is a multi-level DHT and results have reported that the architecture can scale to several millions of nodes with lookup latencies of less than 100ms.
Material:
Overall Architecture paper: https://www.sciencedirect.com/science/article/pii/S0140366413000364
Measurement/Simulation study: https://www.sciencedirect.com/science/article/pii/S0140366413000418
For more information on IPFS
- visit the project website: https://ipfs.io
- or follow IPFS on Twitter: https://twitter.com/IPFS
A
Thanks
everyone
for
joining,
yes,
George
just
said
it
would
be.
The
purpose
of
these
is
to
make
it
interactive.
So
I've
got
you
guts
in
between
different
sections
of
the
slides
to
to
raise
any
questions
for
us
things
that
you
have
not
understood
in
the
process,
but
yeah
these
things
supposed
to
be
a
brief
history
of
information.
Centric
nipples,
which
I
mean
we
have
discussed
with
most
of
you,
has
been
a
kind
of
a
parallel
research
area
involving
academia,
but
only
big
the
web.
A
There
are
big
industries
involved
there
and
there
has
been
quite
some
work
done
there,
so
it
would
be
I
think
very
beneficial
for
people
are,
you
know,
working
in
on
ipfs
and
BJP
to
just
get
an
idea
of
what
has
been
done
and
then
possibly
dive,
deeper
I'm
gonna
follow
up
wardrobes
or
in-person
meetings
to
see.
If
you
know
there
are
interesting
features
that
we
could
adopt
and
follow
up
on
in
a
PFS
in
the
b2b,
so
yeah,
okay
for
those
that
we
have
not
met.
A
My
name
is
Yummy's
lecturer
at
University,
College,
London
and
I'm
research
labs,
mainly
working
in
areas
related
to
condom
routine.
Dhd
and
things
like
that,
in
fact,
okay
I
have
just
not
that
long
ago,
so
yeah,
probably
we
haven't
interrupted
too
much
with
many
of
you,
so
have
been
working
at
UCL
since
the
beginning
of
2010
and
those
last
all
those
years.
A
The
main
point
of
work
basically
was
information,
centric
networks,
and
we
have
done
quite
a
few
words
from
arranging
the
long
span
from
architectural
from
the
architectural
perspective
from
caching
perspective
from
content,
delivery,
perspective,
mobility
and
pretty
much
all
sorts
of
things.
Lately
we
have
been
working
on,
distribute
them
decentralized,
edge
computing,
where
what
we've
seen
is
that,
instead
of
addressing
static
content,
we
wanted
to
address
computation
itself
and
be
able
to
trigger
basically
confrontation
through
some
addressable
structure.
A
So
there
is
nice
page
there,
which
I
have
recently
put
together
story
together
with
links
to
papers.
It
might
be
an
interesting
read
if
you
want
to
see
what
we
thing
around
here
for
the
future
of
the
network,
so
in
terms
of
the
icin
of
the
ICN
community,
one
place
where
someone
could
find
interesting
information
is
the
IRT
F
group.
So
the
IRT
F
stands
for
internet
research
task
force,
which
is
the
research
branch
of
the
internet,
Engineering
Task
Force,
the
IETF,
where
most
of
the
standards
for
internet
protocols
are
being
developed.
A
A
So
it's
an
important
thing:
it
doesn't
cover
research
like
pure
research
things,
so
it
doesn't
cover
papers
and
things
like
that.
But
the
point,
the
few
interesting
internet
thoughts
and
information
are
RFC's,
that
someone
could
get
a
good
idea
of
where
you
know
where,
where
the
thinking
behind
it
is
heading.
So
the
idea
I
mean
the
OSI
Energy
Group
is
making
together
with
every
you
know,
iedf,
which
is
taking
place
three
times
a
year
and
sometimes
their
interim
meetings
in
between
those
meetings
in
between
the
main
IETF
meetings,
very
interesting
discussion
generally
over
the
years.
A
The
area
also
has
a
conference
which
is
sponsored
by
ACM.
It's
been
don't
know,
it's
been
in
public
since
2011
or
something
he
started
as
a
workshop.
Together
with
a
CMC
compa.
Then
it
became
a
conference.
This
year
is
taking
place
in
Hong
Kong
in
September
they're
going
to
be
quite
a
few
interesting
papers
there.
So
it
might
be
something
to
keep
an
eye
on
those
can
attend,
but
those
that
not
there
are
going
to
be
some
interesting
papers
out.
A
So
what's
an
essay
okay.
So
that's
roughly
the
outline
of
what
I
would
like
to
talk
about.
There
are
three
parts
so
I'm
going
to
give
a
quick
introduction
to
information,
centric
networks,
where
you
know
them
a
little
bit
more
technical
bits
than
what
I
have
just
said.
Then
there
is
the
part
where
I
have
selected
three
representative
projects
such
have
specific
features,
which
I
think
could
be
useful
for
I.
A
It
doesn't
matter,
but
it's
just
roughly
what
it's
going
to
look
like,
and
then
there
is
a
final
part
where
I
have
some
of
my
own
thoughts
and
kind
of
design
proposals
for
for
what
I
think
so
far
having
looked
a
little
bit
deeper
into
idea,
fess
and
leave
it
be
so
it's
actually
worth
mentioning,
that's
terminology
might
be
all
over
the
place
or
you
might
be.
You
might
be
saying
the
same
thing
in
two
different
ways,
using
different
words,
so
just
feel
free
to
interrupt
basically
and
yeah.
A
A
The
motivation-
oh
I,
see
n
has
been
pretty
much
the
same
as
it
is
with,
as
it
has
been
with
ipfs
from
the
beginning
that
the
network
is
basically
content,
agnostic
and
the
content
is
location
dependent.
So
these
makes
makes
it
a
little
bit
steep
and
difficult
to
you
know.
Think
of
the
network
as
a
native
content
distribution
that
so
people
who
have
you
know
have
come
up
with.
You
know
observations
and
measurements
that
is
to
show
that
most
of
what
of
the
applications
that
we
use
today
need
a
native,
very
efficient
content
distribution
network.
A
But
what
we
have
instead
is
pulling
two
point
connections,
and
these
in
the
long
term,
is
not
going
to
be
very
supportive
of
all
the
things
that
we
have
want
to
do
with
the
Internet.
So
by
naming
individual
content
objects,
what
is
happening
is
that
we
can
have
more
security
in
some
cases,
there's
better
support
for
mobility
and
there's
also
making
support
for
multicast
or,
if
not
native,
it
can
be
achieved
much
easier.
A
So
that
has
been
the
starting
point,
which
I
mean
I
have
heard
many
people
from
my
affair
saying
exactly
the
same
thing,
so
I
guess
allowing
them
that
so
people
starting
took
it.
You
know
X.
What
can
we
do
with
on
CNBC's
up
to
the
present
day
and
which
is
not
exactly
the
right
question
to
ask
in
my
opinion,
so
you
know
if
we
can
do
things
in
an
easier
way,
then
that's
already
a
start.
A
You
know
we
can
always
do
things,
but
if
performance
and
where
we
do
this
have
optimal,
then
things
will
eventually
become
prohibitive.
So
some
of
the
problems
with
IEP,
which
I'm
sure
you
know
is
that
you
know
if
we
want
you
to
have
some
content.
If
we
have
some
web
content
or
whatever
file
we
have,
you
know
we
can
either
cash
or
authenticate
we
cannot
do.
We
can
never
do
both
effectively
we're
securing
the
channel
over
which
content
is
transparent
and
is
not
the
content
itself
that
were
securing
and
effectively
users
are
asking
for.
A
What
we
are.
The
network
is
replying
who
has
bought
this
watch,
which
is
I,
mean
he
says
a
misunderstanding.
Is
that
kind
of
miss
much
an
example
like
I'm,
giving
some
buy
used
to
game
actually
back
in
the
day
was
the
warehouse
versus
high
street
retailer
example,
where,
if
we
think
of
content
as
a
material,
oh
good,
what
is
happening
today
is
that
we
always
had
to
go
to
some
back-end
warehouse
outside
some
being
safely
in
order
to
get
what
we
want
and
what
we
should
actually
point
to
achieve.
A
A
So
what
does
a
nice
unit
that
you
look
like,
so
we
have
name
resolution
which
is
a
fundamental
part
of
any
architecture,
and
we
have
to
do
a
name
location
mapping.
So
we
have
a
name
and
we
need
to
map
out
to
some
location
and
then
once
we
have
that
we
need
to
go
and
fetch
the
content
we
want
now,
depending
on
how
early
or
how
late
in
the
resolution
process
in
the
code
in
the
neighbor
solution
process,
this
name,
location,
mapping
or
binding
is
done,
and
we
can
either
achieve
many
of
benefits.
A
I
mentioned
before
security,
multicast
mobility,
support
for
mobility
and
effectively
in
native
content,
distribution
network,
and-
and
you
know
the
later,
you
do-
the
binding
the
binding
between
name
and
location.
The
more
you
can,
the
more
benefits
you
have
now.
There
have
been
mainly
two
approaches,
so
one
is
native
data
plane
approach,
which
is
what
we
can
call
name
based
routing
and,
and
these
main
supports
made
laid
binding.
So
what
is
happening
there
is
that
we
assume
that
a
network
fooders
the
actual
network
coders
are,
can
talk.
A
This
IC
and
language
can
talk,
the
product
understand
the
protocol
stack
and
therefore
they
can
receive
and
do
routing
and
forwarding,
based
on
these
name
directly.
So
there
has
been
one
insulation
that
mainly
supports
that
which
is
their
maintained
to
networking
project
and
I'm
going
to
give
more
details
later.
But
the
important
point
for
here
to
remember
is
that
we
have
network
reuters
that
speak
the
language
and
therefore
the
receiver
request
and
they
can
forward
it
natively.
A
So
you
have
a
kind
of
hope
to
hope
hope
by
hope
resolution,
and
then
we
have
the
name
resolution
base
to
look
up
by
name
approaches
which-
and
there
have
been
several
projects
there,
where
this
is
kind
of
early
binding.
So
at
the
beginning
of
the
name
resolution
process,
the
end
client
is
asking
some
external
entity.
Where
can
I
find
this
content
receives
some
location,
bark
in
terms
of
IP
address
or
similar
or
a
peer
ID
or
whatever,
and
then
goes
and
fetches
the
contract.
A
Now,
depending
on
how
efficient
these
can
be
done,
you
can
achieve
most
of
the
benefits.
But
if
you
neglect-
and
you
just
do
this-
you
know
early
binding
and
then
basically
sorting
you're
missing
many
of
the
benefits.
Now
there
have
been
many
projects
there,
mostly
running
in
the
European,
like
funded
by
the
European
Commission,
and
which
start
from
projects
like.
A
Laser
pointer
Wow,
so
there
have
been
many
projects
starting
from
2000
2009-2010
and
going
up
to
these
last
ICN.
2020
project
is
one
of
the
projects
that
we
had
with
usual
and
many
other
partners
in
Europe
and
Japan,
which
finished
actually
last
month
and,
of
course,
okay.
We've
got
IDF
s
which
is
still
ongoing,
and
not
many
of
those
projects
are
still
ongoing
for
good
or
bad
reasons.
So,
just
a
few,
a
few
pull
into
naming
naming
is
the
kind
of
cornerstone
of
an
ICN
architecture,
and
there
are
many,
it's
a
very
big.
A
It's
a
very
big
topic
area,
but
some
of
the
fundamental
requirements
of
names
is
that
they
should
remain
the
same
after
the
content
news.
Sorry,
if
you,
if
someone
takes
the
content
and
takes
it
different,
is
be,
the
name
should
remain
the
same
in
order
to
be
able
to
to
find
it
again
and
it
should
they
should
allow
for
content.
A
Caching,
so
that's
something
very
important
which
you
can't
really
have
with
you
know:
IP
networking,
because
you
know
all
the
cache
or
the
network
is
seeing,
is
an
IP
address
and
you
don't
know
what
the
content
behind
it
is,
whereas
if
you
have
an
Ange
content
chunk
or
content
object,
this
means
that
you
can
identify,
because
you
request
this
by
name
and
therefore
you
can
retrieve
it
from
anywhere
in
the
network.
Now,
okay,
so
naming
itself
is
not
really
problem,
but
if
we
wanted
to
have
you
know,
a
naming
should
not
be
topology
dependence.
A
That's
the
location,
independence
principle,
ICN
is
building
on
top,
and
the
problem
is
that
route
routing
is
the
Balaji
dependence,
so
in
I
see,
and
if
you
want
to
have
addressing
through
naming
that
this
is.
This
is
something
very
important
to
get
right
and
the
nation
basically
naming
determines
route
now
to
go
a
little
bit
further
back.
There
is
this
famous
world
by
Jakov
rector,
which
sometimes
is
called
director
rule
which
says
addressing
can
follow
the
policy
or
topology
can
follow,
addressing
you
have
to
choose
one
which
makes
perfect
sense
if
you
think
about
it.
A
B
Hello,
Toby
all
right
question
about
like
what,
when
people
say
naming
and
in
this
context
like
what
what
do
they
mean
is
a
name
is
the
name
and
address?
Is
it
something
that
is,
you
know
mutable
versus
immutable?
Is
it
something
that's
human,
readable
versus
machine
readable
like
what
is
meant
by
right.
A
So
good
point
and
pretty
much
all
of
the
things
that
you
said
so
there
are
some
approaches
that
say
that
initially
started
as
saying
you
know,
naming
should
be
human
readable,
but
then
these,
of
course
everyone
realized
that
it
doesn't
need
to
be
like
that.
It
doesn't
need
to
be
human
readable,
the
main
distinction,
the
main
two
properties,
so
the
main
distinction
distinctions
over
the
years
was
whether
a
name
is
flux
or
there
is
some
hierarchical
structure
into
the
name.
A
So
if
you
have
a
hierarchical
structure,
just
like
we
have
in
a
URL,
then
these
can
help
a
lot
with
aggregation
in
network
rooters,
as
you
do
routing
and
forwarding.
So
this
is
something
that
is
a
kind
of
a
positive
feature
of
hierarchical
routing.
Now
what
is
in
the
hierarchy
doesn't
necessarily
need
to
be
human
readable.
It
can
be
anything
basically
and
that's
where
we
come
to
the
flats.
A
Namespace
is
where
you
know
many
have
proposed.
Actually
you
know
hash
based
addressing
where
you
know
it's
more
difficult
for
others
to
understand
what
to
do
you
with
a
piece
of
content,
but
there
needs
to
be.
You
know,
if
you
have
it
a
name
resolution
system,
then
you
can
route
and
forwards
accordingly,
the
main
property
that
all
of
those
need
to
have
is
that
the
name
should
be
unique.
Right,
I,
don't
know
if
this
answers
the
whole
question.
A
B
A
A
A
For
me
thanks:
okay,
okay,
okay,
fine,
so
yeah.
So
let's
move
on
the
seas
with
regard
to
naming
I
just
had
a
small.
You
know
reference
here,
it's
a
it's
a
very
big
topic,
but
as
I
said,
there
are
each
architecture
followed
its
own
name,
naming
scheme
and
naming
structure,
so
we're
going
to
to
come
back
to
naming.
So
so.
A
Okay,
any
other
questions
up
until
this
point
and
we're
going
to
get
to
part
two
now
where
there
are
some
three
projects
that
I
mentioned
the
first
one
is
the
named
data
networking
project
which
this
has
been
initially
designed
and
proposed
back
in
2006,
so
it
was
kind
of
conceived
by
Vaughn
Jacobson
when
he
was
Xerox
PARC
and
so
when
Jeremy's,
the
main
person
that
basically
designing
the
congestion
control
algorithms
off
disappea.
As
you
probably
know,
so
he
was
very
interested
for
a
long
long
time
on.
A
How
can
you
of
course,
okay
on
congestion,
control
and
similar
things,
but
also
how
can
you
achieve
multicast
so
he
gave
the
first
talk.
Google
Tech
Talk
in
2006,
which
is
a
very
interesting
talk,
I
highly
recommend
it
is
a
bit
long,
but
it's
certainly
interesting
and
then
the
first
paper
they
published
in
ACM
connects
with
Gees
brother,
big
and
very
good
conferencing,
the
networking
space
in
2009.
A
So
at
that
point
it
was
mainly
you
know,
a
project
running
within
Xerox
PARC,
then,
for
all
sorts
of
reasons
that
is
out
of
scope
here
and
that
the
project
was
kind
of
renamed
and
moved
from
Xerox
PARC
to
a
bunch
of
academic
universities
in
the
US.
It
was
initially
by
the
NSF
and
led
by
UCLA
and
Alicia
Zhang
as
P
I,
where
they
have
follow-up
paper.
A
Ccr
computer
communication
review
in
2014
and
the
website
is
this:
one
and
they've
got
a
really
big
big
collection
of
material
from
papers,
presentations,
videos,
tutorials-
and
this
is
a
very
active
project.
It's
still
going.
There
is
an
active
testbed
exists
and
people
used
to
experiment
with
it.
So
it's
one
basically
together
with
another
one
that
we're
not
talking
up
going
to
talk
about
today.
That
is
still
active.
So
what
was
proposed
there
was
that
the
thin
waste
of
of
the
protocol
stack
instead
of
being
an
IEP
parka.
A
It
should
become
a
Content
chunk,
so
I'm
pretty
sure,
you're
very
familiar
with
that,
because
I
definitely
be
to
be
tried
to
do
pretty
much.
The
same
thing
now,
where
the
IEP
goes
is
that
it
is
kind
of
pushed
down
and
it's
obviously
not
going
to
disappear.
Initially
was
proposed
as
a
clean
slate
network
architecture.
Where
you
know
the
IP
protocol
is
going
to
be
replaced
or
whatever.
A
A
If
someone
wanted
to
reach
my
web
page
and
and
they've
got
okay,
the
data
packets
in
signs-
and
there
are
some
date
signed
traits,
such
as
freshness
period
and
things
like
that
kind
of
you
know
TT,
Ellen
and
similar
things,
and
the
important
thing
to
note
here
is
that
the
very
effectively
the
interest
market
in
the
data
packets
resemble
what
we
have
today
with
IP
packets
and
acknowledgments
disappeared.
Knowledge
means.
A
So
it's
worth
thinking
a
little
bit
about
it
that
you
know
you
have
an
interest
packet,
which
is
about
30,
bytes
long
or
something
very
small
anyway,
and
it's
asking
there
is
each
request
and
interest
for
some
data
is
going
to
be
sent
back.
The
data
packet
is
not
a
whole
content
object,
but
is
about
one
kilobyte
or
so
right.
So
so
we're
talking
about
some.
You
know
kind
of
pretty
radical
modification
where
you
know
today.
What
you
have
is
that
you
have
an
HTTP,
GET
application
layer
and
then
the
network
layer.
A
What
is
happening
is
that
the
sender
is
pushing
data
towards
the
receiver
is
starting
a
connection
through
TCP
and
after
in
our
various
data
that
is
coming
is
kind
of
pushed
back
by
by
the
disappear
sender.
Now
here
we
have
a
kind
of
and
then
and
then
upon
receiving.
You
know
the
data
packets.
The
receiver
is
sending
back
acknowledgments
to
say
that
they
received
that
now
to
kind
of
get
to
where
Andy
any
Easy's.
A
We
we
need
to
kind
of
turn
this
on
its
head
and
say
that
the
sender
is
sending
first
interest
packets
and
upon
receiving
the
interest
package,
any
sender
is
going
to
reply
back
with
data,
so
it's
kind
of
upside
down
and,
of
course,
yeah.
You
understand
that
these
would
come
together
with
some
congestion
control
algorithm
that
is
directly
applied
on
the
named
interest
pocket
than
the
named
data
packet,
and
so
it
so
names
there
in
this
architecture
are
hierarchical
as
I
just
mentioned.
A
I
think
this
is
one
of
the
architectures
use
hierarchical
names,
the
parts
of
the
name.
They
don't
necessarily
need
to
be
human
readable.
It
could
be
anything
and
but
there
needs
to
be
some
hierarchy
because
Reuters
in
the
middle
of
the
network,
what
they
do
is
that
effectively
they
do
longest,
prefix,
machi
and,
depending
on
you,
know
what
they
know
out
of
all
these
and
where
they
can
reach
they
forward
accordingly.
A
So,
for
example,
if
you
wanted
to
reach
you
know
an
academic
institution
in
the
UK
from
Australia,
you
would
need
to
at
least
be
able
to
know
word
for
word
pockets,
starting
with
UK,
slash
right
and
the
further
the
closer
you
get
people
you
know,
Reuters
might
know
more
more
parts
of
the
name
and
therefore
they
can
make
more
intelligent
decisions.
Now,
if
someone
has
happened
to
download
these
before-
and
there
is
an
extra
request
for
that,
then
the
Reuter
somewhere
in
a
remote
area
far
away
might
might
already
know
the
whole
of
these.
A
So
by
doing
longest,
prefix
matching
it
can
find
that
and
retrieve
it
from
close.
So
it
doesn't
have
to
come
all
the
way
to
where
this
content
is
originally
stalled.
That
could
be
either
end
users
in
and
user
advices,
where
it
could
be
in
there
for
caches
or
whatever.
So
the
more
content
is
becoming
popular,
the
more
that
the
rooters
are
getting
to
know
the
whole
part
of
the
name
and
therefore
they
can
serve
it
naturally,
from
closer
now
to
achieve
that,
there
are
three
tables
in
the
main
Indian
node
architecture.
A
You
know
the
whole
network
perform
more
efficiently.
So
this
is
the
content
store.
Then
there
is
a
pending
interest
table,
which
is
a
table
and
index,
basically
where
every
node
is
storing
their
interests,
that
it
has
just
forwarded
further
and
then,
when
the
data
for
the
interest
that
the
data
is
coming
back
to
consume
the
interest,
and
once
it
says
that
it's
going
to
remove
the
name
from
this
pending
interest
table,
and
then
there
is
the
feed
table
which
is
kind
of
similar
to
the
fib
tables.
A
So
that's
the
the
node
structure
that
every
return
is
supposed
to
have
in
this
in
this
model
and
it's
a
very
interesting
structure.
It
brings
lots
of
challenges
as
I'm
going
to
say
in
a
minute,
but
it
still
is
an
interesting
design.
So
if
we
go
to
a
more
graphical
explanation,
we
have
the
requestor.
Here
we
have
a
bunch
of
frutas
and
the
source
node
down
there.
So
what
is
happening
is
that
the
requester
is
sending
an
interest
bucket,
which
is
going
to
reach
the
first
row
in
the
network.
A
What
these
rotar
does
opponent
getting
an
interest
is
that
they
check
first
the
cache
to
see
if
the
content
is
there
already.
So
if
it
is
a
serve
it
directly
back,
if
it's
not,
then
they
check
the
pending
interest
table,
and
this
is
quite
interesting
because,
as
you
can
understand,
you
know,
as
interests
are
as
are
thought
there.
They
can
enable
native
multicast
so
I'm
going
to
explain
that
in
a
minute,
and
if
nothing
is
in
the
big
table,
then
they
check
their
feet
and
they
for
accordingly
and
the
next
Rooter
does
the
same.
A
They
check
the
cache
the
page,
and
if
nothing
is
there,
a
buffet
band
for
world
fair.
Now
at
some
point
which
the
content,
the
main
content
source
we
who
is
in
a
cache
or
whatever
memory
they
have,
they
get
the
content
and
send
it
back
now.
Every
root
is
caching,
the
content
locally
and
the
content
is
eventually
returned
to
the
requester.
A
Now,
when,
when
another
quest
comes
from
someone
else
for
the
same
content,
obviously
it's
going
to
hit
the
cache
and
get
the
content
back
directly,
which
is
improving
the
efficiency
of
course,
and
what
is
he's
also?
It
can
enable,
as
I
said
time,
shifted
multicast,
because
if
we
have,
if
the
first
requester
is
sending
an
interest
which
is
sorting
the
pending
interest
table,
if
another
requester
is
sent,
the
sense
happens
to
send
an
interest
for
the
same
thing.
This
route
is
not
going
to
forward
the
interest.
A
A
So
so
the
the
native
multicast
issue
is
very
nicely.
It's
very
nicely
covered
here.
Another
thing
that
is
covered
is
that
there
is
support
for
mobility,
so
if
we
assume
that
these
are
not
two
different
requesters,
for
example,
and
you're
sending
a
request,
but
then
you
disconnect
from
whatever
access
point
is
there
Wi-Fi
or
cell
station,
and
you
connect
to
another
one.
You
don't
have
to
tear
down
and
get
a
new
TCP
connection
done.
You
just
send
the
interest
which
you
know
the
interest
that
you
send
this
when
you
were
connecting
here.
A
The
content
has
probably
come
back
and
this
cache
here.
So
even
if
you
lost
this
due
to
bad
connection,
while
you
were
transiting
to
the
next
to
the
next
day
station,
what
is
happening
is
that
you
just
send
the
interest
again
and
you
retrieve
the
content
directly
from
the
last
hope
in
the
network.
So
pretty
pretty
interesting,
knowing
which
okay,
of
course
comes
with
challenges.
There
are
two
key
features
of
this
architecture.
A
Is
that,
apart
from
the
rest,
that
I
mentioned
is
that
there
is
a
connectionless
model,
so
there
is
no
connection
establishment,
basically
users
just
issue
interests,
and
there
is
data
from
data
centers
that
go
back
and
consume
the
interest,
and
there
is
always
a
rather
strict
push
based
model,
so
sorry
pool
based
model,
so
data
is
travelling
in
the
network
only
if
someone
has
requested
it.
So
this
has
got
several
interesting
properties
carrying
in
courage
together
as
I
said:
okay
yeah,
it's
interesting
data
pocket,
which
is
the
TCP
connection,
basically
upside
down.
A
And
of
course
there
are
some
challenges
right,
so
scaling
the
fib
size
is
an
issue
and
it's
not
an
easy
one,
because
we
have
to
assume
that
you
know
you
need
to
keep
track
of
pretty
much
any
namespace
that
exists
in
the
Internet
right.
So,
of
course
you
don't
need
to
keep
track
of
the
whole
of
the
name.
As
I
said,
Reuters
do
longest,
prefix
matching,
but
even
to
keep
you
know
the
first
few,
the
first
few
parts
of
hierarchical
name.
A
It
has
been
shown
that
the
field
is
going
to
explode
and
then
and
then
there
are
patent
cache
poisoning
attacks.
So
the
this
is
not
a
solved
problem
and
one
that
can
I
mean
can
be
a
show.
So
bad,
don't
know
if
it's
right
what
to
say,
but
it's
a
problem
that
is
looking
for
a
solution.
Basically,
because
someone
can
issue
interests
for
contents
that
do
not
exist
for
content.
That
does
not
exist
using
random
lanes,
and
these
goes
and
fills
up.
A
The
pending
interest
table
of
the
Reuters
effectively
launching
a
denial
of
service
attack,
because
you
know
nothing
else
can
be
stored
in
there
and
I.
Think
that's
right!
So
yeah,
that's
the
last
slide,
as
I
said
there
is
a
the
project
is
ongoing.
There
is,
there
is
a
live
deathbed
that
people
are
using
mainly
for
research
biopsies.
A
It's
the
only
proposal,
it's
pretty
radical,
but
really
nice
design.
In
my
opinion,
and
it's
the
only
one-
only
proposal
that
you
know
does
actually
name
based
routing
from
the
sender
to
the
receiver,
or
at
least
that
is
the
main
design
yeah
and
with
ease
of
like
you.
You
take
a
quick
pause
here
and
see
you
know
if
there
any
interesting
features
that
you
think
should
be
considered
further
in
in
the
context
of
this
project
or
more
generally,
oh
whatever,
and
have
a
question
you
have.
D
So
I
would
ask
you
that
name
based
routing
and
name
resolution
like
look
up
my
name
type
and
architectures
are
the
two
different
ways
of
going
about
this
yeah.
How
has
different
architectures,
how
much
overlap
or
similarity
is
there
between
the
two
like?
Are
there?
Are
there
problems
that
come
up
with
nd
M
and
you
would
expect
Ike
yet
to
divest
to
see,
or
are
they
disparate
enough?
That
you'd
only
expect
to
see
it?
If
we
like
to
started
turning
the
course
of
the
ship.
A
Yeah,
that's
actually
very
good
question,
because
one
suggestion
that
I
had
is
that
name
based
routing
one
interesting
feature
or
principle
that
it
brings
with
it
either
it
can
resolve
local
content.
So,
in
my
view,
a
hybrid
approach
between
you
know
having
a
name
based
system
up
to
some
point
and
then
some
resolution
entity
that
is
going
to
try
and
find
what
local
name
basic
routing
cannot
find.
I
think
he
can
hit
the
strike.
A
The
right
balance,
sorry
yeah,
but
up
until
now,
that's
a
very
good
point
that
both
approaches
have
taken
either
one
or
the
other.
And
my
view
is
that's
a
combination
of
these
two
and
both
of
them
have
problems.
Scalability
problems
or
performance
problems.
We're
going
to
see
later,
but
having
hybrid
of
the
two
has
not
really
been
looked
at
and
I
think
it's
a
very
practically
it's
a
very
interesting
direction,
but
someone
should
consider.
A
Yeah
good
point:
yes,
there
is,
it
is
assumed
that
there
is
going
to
be
something
similar
to
the
icon
we
have
today,
but
wherever
you
know
there
should
be
some
central
registry
for
names
or
not
every
name.
Obviously
not
every
document
that
we
produce
and
publish
every
day.
It
needs
to
be
needs
to
be
registered
up
to
some
point
hierarchy
to
get
the
prefix.
It
will
need
to
be
agreed
between
everyone,
yeah.
F
G
F
A
There
are
a
few
issues
here.
You
don't
necessarily
need
to
know
where
exactly
the
server
is,
but
there
needs
to
be
some
bootstrapping,
some
bootstrapping
right,
so
the
because,
initially
so
day,
one
how?
How
do
you
get
actually
the
first
entries
in
the
fib
table,
so
these
would
have
to
be
done
by
some
static
link,
state
routing
protocol
that
would
need
to
run
to
bootstrap.
Basically,
what
he's
putting
the
feed
tables
and
then
yeah
so
I
see
so
that
Steve
and
raised
a
hand.
H
Yes,
as
far
as
I
can
tell
key,
to
presume
this
is
DNS
is
that
with
DNS,
like
I
asked
one
server
for
the
name,
and
they
tell
me
where
to
go
next
and
you
keep
on
doing
this
recursively,
but
this
is
more
like
I
would
ask
one
server
than
they
would
forward
them
at
Ford,
then
forward
and
eventually,
like
some
caches
that
were
hopefully,
or
maybe
the
time
of
the
station
will
forward
back
the
content.
So
it's
more
that
it's
like
I.
It's
a
forwarding
system.
Instead
of
like
a
recursive
lookup
system,
yeah.
I
Right
is
it?
Is
it
my
turn?
I
was
using
the
chat
to
raise
my
head.
That's
the
right
approach,
so
I
have
two
questions
here
for
you.
Yes,
interest
cancellation.
How
does
how
does
a
node
signal
to
the
rest
of
the
network
that
they
have
received
the
chunk
that
they
were
interested
in
so
I'm,
assuming
that
the
chunk
doesn't
travel
backwards
from
the
same
earth
as
it
was
advertised
whenever
I
guess
that
interest
was
appetizer
Network?
This
would
I
don't
know.
Is
that
the
case
case
yeah.
A
A
Because,
as
a
requester
is
sending
some
interest
kind
of
installing
some
state
in
this
PPT
there
and
then
through
the
feeb,
you
know
it
says
that
I
have
received
interest
for
this
lane
where
and
when
it
comes
back.
I
have
to
send
it
down
through
this
interface,
so
it's
not
going
to
send
it
back
through.
Another
interface
got.
I
It
yeah
so
this
effectively
creates
a
single
path
for
this
request.
On
the
network
case,
it
would
be
very
difficult
to
parallel
ice
right
because,
at
the
end
of
the
day
like,
if
you
parallel
eyes,
have
you
take
multiple
paths.
You'll
end
up
flooding
the
network
with
that
demand
in
a
way,
and
with
the
with
the
data
transfer
that
that
demand
generates
right
exactly.
A
Yeah
yeah
yeah
yeah
in
the
in
the
in
the
initial
in
the
base
design,
you
know
single
path
and
symmetric
routing
is
assumed,
but
and
then
you
know,
other
protocols
would
have
to
build
on
top.
If
you
wanted
to
do
some
sort
of
multi
path
and
then
the
knowledge
of
you
know
several
different
paths
along
and.
A
Yes,
so
so
the
main
premise
here
is
that
you
know:
if
so,
it
depends.
If
these
node
goes
down,
then
this
requester
will
have
so.
So
no
sorry,
if
these
nodes
say
goes
down,
then
these
rotar
would
because
they've
got
the
feed
table
that
interconnects.
Basically,
everyone
knows
who
is
around
they.
Can
they
can
forward
the
request
to
someone
else,
so
that
is
not
a
big
problem.
Obviously,
whatever
is
ongoing
is
going
to
be
lost,
but
then
the
network
is
going
resiliency,
something
that
can
be
supported
by
I
got
it
so.
I
A
A
So
there
would
need
to
be
I
mean
hard
limit.
Yes,
it
would
have
to
be.
There
hasn't
been
any
hard
limit
and
I
think
what
they're
currently
using
is
about
four
kilobytes
or
something
it's
this
I
mean
has
not
been
I,
don't
think
it
has
been
agreed
or
standard
unease
at
this
point,
everything
that
is
larger
would
have
to
go
through
fragmentation.
Basically,
as
it
happens
today,
as
well
with
jumbo
frames
and
things
like
that,.
I
Got
it
so,
at
the
end
of
the
day,
it
would
be
kind
of
like
the
file
itself
or
the
chunk
that
makes
sense
to
the
user
to
fetch
in
a
single
unit.
The
one
that's
addressable,
you
wouldn't
make
the
inner
blocks
of
that
larger
blob
addressable
in
themselves.
Right
sorry,
I
didn't
get
that
so
imagine
you
have
a
one
megabyte
file.
A
Yeah
there
is
going
to
be
an
individual
name
for
each
individual
chunk,
so
the
long
name
could
be
so
say
this
one
is
not
an
HTML
file,
but
is
a
huge
PDF
file.
The
huge
video
file
of
one
megabyte
is
going
to
splitting
chunks
of
one
kilobyte
or
four
or
five
or
whatever,
and
okay.
There
should
be
some
naming
convention.
That
would
say
this
would
be
X
dot.
A
A
Based
routing
approach
or
a
small
part
of
that
together
with
some
other
high
bridge,
is
something
I
think
that
could
be
quite
interesting
for
to
consider
in
my
PFS.
So
the
second
part
now
the
second
project
is
project.
Actually
it's
a
paper
called
donor
data
oriented
network
architecture.
It
has
never.
It
has
not
been
a
project,
it
was
a
paper
published
in
2007
or
six
in
ACM
cecum
and
because
so
in
terms
of
timing,
it
was
so
early.
It
was
basically
behind
before
you
know
them
the
Indian
or
CCN
projects
from
Park
and
from
Jacobson.
A
So
that's
why
it
was
very
timely
and
it
created
a
lot
of
interest
around
it
and
some
thousands
of
citations
just
because
it
was
so
timely.
So
the
main
motivation
was
the
same.
You
know,
content
is
what
matters
and
not
exactly
who
is
hosting
the
content.
It
was
supposed
to
be
a
clean
slate
design
of
the
internet
and
with
main
design
goals.
Having
persistence
names
need
to
remain
when
content
moves
to
another
domain
or
another
location
availability,
which
means
access
should
be
reliable
and
fast,
and
then
authenticity,
which
you
know
through
some
mechanics.
A
A
Sorry,
the
content,
publisher
or
someone
who
is
cashing
or
storing
the
contents
and
in
practical
terms,
what
these
pcs,
the
cryptographic
hash
of
public
key
of
the
content,
publisher,
web,
restoring
the
content
and
then
the
Rahzel,
which
is
a
label
which
is
chosen
by
the
principle
and
again,
has
to
be
unique.
So
it
can
be
the
hash
or
something
but
has
to
be
unique
as
compared
to
any
other
content
in
the
internet.
So
it
has
to
somehow
you
know,
be
uniquely
identified
with
some
bits
in
this
object.
A
The
packet
formats
is
of
this
time,
that
is,
the
data
public,
key
and
signature,
and
the
clients
obviously
verify
data
by
comparing
the
hash
of
the
public
key.
What
with
what
the
principle
or
the
content
publisher
has
provided
before
now,
there
is
an
the
other
very
central
thing
in
the
donor
detector
is.
A
The
resolution
handler
is
a
is
a
network
entity
kind
of
thing
which
is
placed
inside
the
network
and
inside
the
ISPs
network
in
order
to
handle
requests
and
redirect
do
the
routing
and
forwarding
basically,
so
the
main
operations
is
a
registered
packets,
so
you
can
think
of
that
as
published.
So
you
have
a
content.
A
A
So
the
register
process
goes
something
like
this,
so
there
is
resolution
handler,
which
is
pretty
much.
You
know
you
assume
that
there
is
at
least
one
in
every
isp
domain,
and
whoever
has
got
we
have.
Some
content
is
needs
to
register
with
the
local
resolution
handler
now.
What
the
resolution
camera
is
doing
is
that
it
is
propagating
upwards
in
the
isp
hierarchy
or
any
peering
domain.
A
They
have
to
say
that
I
have
I
know
how
to
find
these
contents
with
this
with
this
detailed
name-
and
these
goes
all
the
way
up
to
the
top
level
tier
one
is
P
or
top
level
entity
and
therefore-
and
that's
done
in
order
to
be
able
to
actually
then
find
the
content
where,
if
there
is
a
client
that
is
asking
for
this
copy
of
the
content
that
we
just
registered
and
published
from
that
resolution
handler,
what
happens?
Is
that
is
going
to
hit
that
one?
This
guy
doesn't
know
what
finder
is
being
forwarded
upwards.
A
This
guy
has
seen
that
there
has
been
stayed
installed
in
this
resolution
handler
before
so
they're
going
to
forward
down
and
go
and
find
the
copy.
So
this
figure
here
is
not
exactly
accurate,
because
I
think
I'm
pretty
sure
in
the
donor
architecture
the
head
there
have
been
that
were
peering
messages
as
well.
So
these
guy
here
would
register
the
messages
to
this
guy
and
this
guy.
Therefore,
these
could
be
cut
shorter
and
be
forwarded
between
these
two
resolution.
Hundreds
to
go
and
find
the
content,
but
that's
the
general
idea,
so
very
ck.
A
A
But
what
is
happening
there
is
that
effectively
have
requesters
that
are
sending
a
fine
message
and
then
the
resolution
handler
is
going
to
route
towards
where,
if
it
doesn't
know,
if
there
is
nothing
in
the
cache,
then
they're
going
to
forward
it
upwards
in
the
hierarchy
until
it
finds
a
top-level
domain
where
it
needs
to
go
further
down
again
and
find
the
content
so
yeah.
This
is
a
new
entity,
a
new
entity.
There,
the
resolution
handler
it's
an
interesting
architecture,
obviously,
as
you
can
understand,
speci
and
state
that
needs
to
be
kept
up
level
and.
A
Right
so
so
we
did
the
sudden,
so
the
knife
I
was
off
by
the
time.
I
was
saying
that
what
I
was
trying
to
say
is
that,
as
you
understand
that
the
top
level
resolution
handler
is
going
to
experience
a
lot
of
stress
in
terms
of
the
state
that
it
needs
to
keep
right,
because
every
effectively,
every
single
content
piece
of
inter
on
the
internet
needs
to
be
registered
there
right
in
order
to
be
able
to
eventually
go
back
and
find
it.
A
A
You
can
see
here
that
okay
D
start
from
small
ISPs
and
from
subdomains
basically
and
then
for
small
all
ISPs,
but
as
you
as
you
go
along
to
find
the
Tier
one
is
BC
that
they
need
to
keep
all
the
content
in
the
universe
and
that's
pretty
similar,
even
though
the
optimization
for
with
it
in
curling,
where
the
top-level
domains
don't
necessarily
need
to
keep
all
of
the
content.
But
they
need
to
get
most
of
the
content.
The
situation
is
a
little
bit
better
for
large
and
small
ISPs.
A
Now
assuming
10
to
the
power
of
13
information
objects
published
in
the
Internet.
What
these
translates
to
that's
quite
interesting
is
is
the
number
of
servers
that
Tier
one
domains
need
to
keep
in
order
to
have
the
state
storage,
so
this
is
like.
Twenty-Six
thousand
sixteen
gigabyte
ram
servers
in
order
to
be
able
to
store
everything
in
there
in
their
memory
and
be
able
to
do
two
forward
requests
accordingly.
A
Now,
in
summary,
okay
effectively,
what
it
comes
down
to
is
that
you
have
resolution
handlers
and
each
resolution
handler
needs
to
keep
routing
state
for
data
that
is
below
the
most
stress
goes
to
Tier
one
highest
pieces.
We
said
so
the
initial
design
was
claiming
should
be
doing
main
base
routing,
but
these
depends
on
how
many
resolution
handlers
you
actually
have
by
domain.
So
if
you
have
just
one,
then
it's
not
quite
sling
base.
Routing
is
just
a
different
resolution
system.
If
the
more
resolution
handlers
you
have
the
more
you
can
actually
do
effectively.
A
A
Yeah
so
yeah.
That
concludes
that
the
second
part
and
yeah
any
questions
or
interesting
features
for
me,
for
example,
something
that
could
would
be
interesting
to
have
as
a
network
and
in
this
particular
case
the
AFS
network
ROS,
is
to
see
if
there
is,
if
we
could
have
a
notion
of
hierarchy
or
you
know,
domain
or
a
autonomous
system
structure,
and
these
fool
doesn't
need
to
be.
You
know
related
to
the
ISP
itself,
as
is
in
the
Dom
architecture,
but
having
some
sort
of
structure
is
going
to
help
with
scalability,
but
both
with
performance.
A
A
A
B
A
So
the
hierarchy
here
and
does
not
come
in
terms
of
names.
So
this
is
how
the
names
look
like
it's
just
the
PL
structure,
where
the
principle
is
basically
the
Cooper
graphic
hash
off
the
public.
Key
of
the
person
that
is
storing
the
content
or
publishing
the
content
and
and
L
is
something
that
again
has
to
be
so.
I
would
have
thought
that
could
be
the
hash
of
the
content,
basically,
which
is
unique
to
this
specific
content.
Object.
H
In
terms
of
hierarchical
structures,
that
would
actually
I
think
really
sing
for
everyone
concerned.
There
is
a
you
generally
wouldn't
be
had
no
structure,
you
kind
of
implicitly
have
authorities
yeah,
which
is
something
we
tend
to
shy
away
from.
It
is
who
I'd
be
in
essence
a
bit
like
there's
no
authority,
you
just
like
have
your
key
in
you.
Have
your
namespace
okay,.
H
So
you
know
IPS
we
currently
don't
have
hierarchies
primarily
because
that
requires
a
namespace
or
any
authority.
As
far
as
I
know
I,
we
probably
wouldn't
want
it
to
be
a
location-based
as
a
bit
because
then
like
one
of
the
key
goals.
This
feels
like
move
and
still
have
your
content
resolved
yeah.
But
you
can
still
do
hierarchical
adjusts
without
making
it
missing
map
to
geography
by
just
like
updating,
I,
guess
the
next
layer
up
and
saying:
hey,
I,
moved
over
here
and
then.
H
A
Yes,
so
it
makes
sense,
so
they
agree
that
would
think
the
hierarchy
in
the
namespace
can
be
I
mean
it
can
be
useful
and
that's
something
that
could
be
considered.
It
can
be
dangerous
because
so
the
problem
there
is
that
that
the
naming
structure
and
the
topology
of
the
network
are
two
different
things
that
are
kind
of
moving
in
an
evolving
in
parallel
and
they
can
go
into
totally
different
directions.
A
And
then
you
end
up
with
some
structure
that
is
not
following
the
topology
at
all,
which
which
is
kind
of
already
almost
happening
with
IP
before,
but
it's
going
to
be
even
more
so
with
ipv6,
so
it's
kind
of
danger
and
I
agreed
with
that.
On
the
other
hand,
he
said
topological
doesn't
need
to
be.
You
know.
Yes,
sorry.
A
So
topological
doesn't
need
to
doesn't
mean
to
necessarily
mean
that
if
we
say
that
this
content
is
here,
it
cannot
move
elsewhere.
It
does
not
need
I,
don't
think
to
say
to
be
inside
the
name.
If
we
have
any,
you
know
if
there
is
an
index
somewhere
that
says
within
this
area
of
metropolitan
area,
you
can
find
these
contents,
then
this
will
be
much
faster
when
you
try
to
deliver
the
content,
basically
on
the
opposite
direction.
Right,
because
you
know
so
I
think
some
topological
embedding
needs
to
happen.
A
H
Ideally
like
we'd,
have
additional
information
here,
but
like
content
product,
we
can
be
scoped
to
where
you
are
in
that
what
I
think
helps
all
this,
then
you
would
automatically
find
people
nearby
before
t5
you
further
away,
but
in
general,
like
that,
the
problem
is
like
putting
this
in
the
name
or
putting
topper
like
location
based
off
in
the
name
it
so
I.
Just
like
you
have
yeah.
A
A
So
it's
just
if
the
network
like
through
through
some
gateway
or
some
similar
structure,
like
the
resolution
handler,
can
keep
track
of
what
content
is
right
without
inserting
that
in
the
name
structure
could
I
think
resolve
content
locally
and
improve
performance
is
basically
comes
down
to
what
we
said
before.
Whenever
asked
a
hybrid
of
name
based
and
name
resolution
based.
C
L
You
sorry
yeah,
the
these
are
all
interesting
schemes.
There
seems
to
be
a
tension
that
I
haven't
really
heard
talk
about
with
privacy,
so
like
you're
there
utter
you're.
Talking
to
you
knows
everything
that
you're
accessing
on
the
Internet.
What
what?
What?
What
does
the
community
have
solutions
for
right?.
A
So
so
the
good
thing
about
that
is
that
the
rotor
inside
the
network,
if
you
use
some
name
based
routing
the
route
around
the
rotor
in
the
network,
doesn't
know
who,
where
is
this
going
to?
Because
there
is
no
IP
address
you're,
just
following
back
and
you're,
sending
based
basically
named
contents
and
through
the
state
that
is
installed
in
every
route
there
is
going
to
come
back
to
whoever
is
requesting
that
so
in
that
respect
is
better
than
what
it
is
today
now.
A
A
B
A
B
A
Okay,
yes,
and
no
in
this
particular
case
in
the
done'
thing,
it
was
an
index
like
thing,
so
you
didn't
have
to
go
and
run
the
DHT,
but
alternative
approaches.
Yeah
could
have
a
DHT
which
you
you
you
again
have
to
go
around
the
ring
and
find
what
you're
looking
for.
But
assuming
that
this
is
kind
of
topologically
embedded
in
the
same
region,
you
don't
have
to
travel
far
away.
A
A
It's
been
this
project.
What
has
this
has
been
designed?
There
is
very,
very
similar
to
ipfs
only
p2p,
and
it's
very
interesting
that
they
kind
of
both
have
been
designed
around
about
the
same
time,
but
in
completely
independent
paths.
So
so
the
same
project
is
worth
mentioning
that
it
was
quite
big
and
had
a
bunch
of
companies.
If
we
go
the
website
there,
all
the
big
companies
have
been
contributing
or
somehow
been
involved
in
in
the
project.
A
So
if
something
is
cached
because
you'll
get
the
you're
asking
for
something
based
on
the
specific
name
of
the
content,
then
you
can
take
it
from
mid
pack,
the
network
and
or
it
could
be,
that
some
parts
of
the
continent
you're
looking
for
is
in
this
know,
then
some
other
parts
are
down.
The
other
note,
so
you're
going
to
split
the
request
and
try
to
get
data
from
from
many
different
nodes.
A
Now
the
NRF
system,
the
main
thing
that
was
developing
the
netting
project
is
a
DHT
system
and
multi-level
DHT
schemes,
which
I
think
the
minimum
is
three
levels,
but
it
could
be
more
I
think
they
experimented
with
more
at
least
theoretically,
and
if
we
go
a
little
bit
further
down
into
more
detail.
If
we
assume
that
there
is
an
object,
X,
which
is
the
house
of
which
ET
k
then
another
node,
we
have
this
netting
domain
or
it
could
be
an
autonomous
domain
and
the
DHT
associated
with
the
autonomous
system.
A
And
then
you
have
the
pub
level
the
HDS
and
the
request
is
going
through
some
access.
Now
this
ratio
is
reaching
the
DHD
of
this.
The
pop
level
and
it's
going
to
go
further
up
to
the
to
the
high
layer
THD.
If
that
pop
does,
in
fact
it
doesn't
see
where
the
actual
content
is,
is
thought
locally
and
then
he's
going
to
go
down
and
go
and
find
I
mean
it's
pretty
similar
to
what
IPS
is
doing,
but
at
the
multi
level,
and
then
the
content,
of
course,
is
going
to
follow
the
fastest
way
back.
A
It's
worth
mentioning
that
this
access
know
the
access
note
they're
not
doing
something
they're,
not
actually
keeping
any
record
of
what
has
been
stored.
So
I
suspect
that
if
there
is
a
user
here
and
asks
for
exactly
the
same
object
X,
then
you
know
unless
some
node
there
has
a
cache.
The
same
thing
has
to
happen
again,
so
you
know.
One
thing
is
that
if
there
is
a
node
somewhere
here
that
does
some
keeps
an
index
of
things
that
have
been
forwarded
recently
towards
other
users
and
other
hosts.
A
Then
these
will
eventually
you
know
forward
the
request
and
then
the
content
in
in
local
nodes.
So
the
naming
scheme-
I
guess
it
looks
quite
similar
to
what
you
have
seen
before,
so
there
either
and
I.
There
is
an
authority
part
here,
which
is
the
content
publisher,
but
B
this
part
is
optional
and
the
main
is
whether
what
kind
of
digest
algorithm
is
used
and
then
the
value
where
the
value
they
use
the
hash
so
effectively
is
very
similar
to
what
is
being
used
in
IB
FS
or
at
least
that
the
initial
CID
of
versions.
A
Yes,
so
the
interesting
they're.
Actually
they
have
some
papers
where
they
build
a
pretty
simple
simulator.
In
order
to
see
what
is
the
benefit
when
you
have
multi-level
DHT
system,
so
this
goes
like
they.
The
assumptions
there
is
that
okay,
several
millions
of
nodes,
they
assumed
propagation
delays
about
two
hundred
thousand
kilometers
per
second,
and
these
are
the
delays
that
they
assumed
for
those
distances,
which
is,
of
course
a
simulator.
I
mean
it's.
Not
it's
not
quite
the
same.
Isn't
it's
not
quite
like
that?
A
In
the
internet,
there
is,
of
course,
no
nuts
traversing
or
things
that
are
extra
delay.
So
what
we're
going
to
see
in
the
next
slides
is
basically
the
trend
than
what
it
looked
like.
It's
not
really
realistic,
I
mean
I
would
probably
put
these
these
ones
here
multiply
by
two,
or
so
they
may
be
a
little
bit
more
so
yeah.
A
So
so
here
what
we
see
is
on
the
y-axis
is
the
latency
to
retrieve
some
content,
so
two
requests
go
and
find
it
and
send
back
the
object
I'm
asking
for-
and
this
is
the
number
of
nodes
in
the
network
which
it
seems
it
doesn't
make
any
very
big
difference
now
the
different
lines
here.
That's
the
interesting
point:
they're
comparing
a
multi-level
DHT,
which
is
the
mdhd
here
and
skip
net
so
skip
net.
A
Tonight
it's
an
old
paper
which
was
called
can't
remember
what
the
title
was
but
effectively
is
charting
the
namespace
in
order
to
not
go
and
ask
every
node
in
the
network,
but
depending
on
the
charting
that
you
have
done,
you
go
and
ask
those
nodes
only
it's.
It
seems
to
be
pretty
efficient
in
what
is
reporting
here.
But,
as
it
just
said
before,
in
Stephens
comments,
that's
a
little
bit
dangerous
to
do.
A
So,
if
you,
if
you
add
kind
of
topological
things
inside
a
name
and
you
shard
the
namespace,
especially
in
terms
of
cost
based
names,
then
as
the
topology
voles,
these
two
things
could
become
quite
far
away
from
each
other
and
different
what
it
was
supposed
to
be
now.
Okay.
So
let's,
let's
focus
on
the
dashed
lines,
these
one,
this
one
line.
A
There
is
saying
what
happens
if
we
try
to
resolve
content,
if
you
have
one
day
HD
and
as
you
go
up,
you
see
what
happens
if
you
have
three
layers:
five
layer,
seven
layers
and
nine
layers.
Now
you
shown
here
that
the
multi-leveled
HD
is
having
walls
performance
on
the
single
level,
the
level
THD.
But
this
is
for
uniform,
request
distribution.
A
If
we
go
to
the
sides
where
it
is
assumed
that
would
go
a
30
percent
level
probability
or
I
mean
this
effectively
says
that
30
percent
of
requests
can
be
on
a
local
to
some
DHD
to
some
to
the
DHD
self,
which
is
topologically
embedded
into
some
geographic
area.
Then
these
becomes
much
so
that
one
level
is
not
shown
here,
because
it's
supposed
to
be
one
thousand
which
is
somewhere
up
there.
A
But
what
we
can
see
is
that,
with
nine
levels
of
the
HD
you
can
reach
performance
which
is
much
much
below
what
it
was
before.
And
then
you
go
as
you
go
further
up.
You
see.
This
is
for
three
level:
d,
HD,
5
level,
d,
HD,
7
level,
d,
HD
itself,
etc.
So
these
actually
shown
here
a
little
bit
better.
Here
we
have
again
the
latency
in
here
we
have
the
level
probability.
A
So
so,
how
likely
is
it
consecutively
users
they're
going
to
ask
for
something
that
has
been
requested
before
and
it's
within
some
geographical
region?
You
know
the
locality
of
interest
effectively
now.
What
we
see
here
is
that
the
single
level
d
HD
is
up
to
that
point,
and
here
we
have
the
multi-leveled
h
DS,
which
is
starting
from
mine
from
the
9
level.
A
We
see
seven
levels,
five
levels
and
three
levels,
and
we
see
that
up
to
when
we
reach
twenty
percent
off
of
similarity
in
terms
of
content
distribution
in
the
network,
these
can
go,
I
mean
the
more
levels
you
have
the
more
efficient
the
thing
becomes.
Of
course,
it's
never
going
to
be.
You
know
anywhere
close
to
0.8
or
anything,
but
there
has
been
studies
that
show
that
the
zip
exponent
of
as
if
distribution,
can
be
something
between
0.8
and
1.2.
A
So,
okay,
so
a
value
around
this
area,
I
would
say
that
is
reasonable
to
assume,
and
therefore
this
shows
that
the
locality
of
interest
can
bring
massive
benefits
if
we
design
the
system
as
such.
That
is
taking
these
things
into
account
right.
So
the
summary
of
that,
it's
very
it's
a
it's
very,
very
similar
to
what
ifs
ease
today
and
liquid
way.
The
difference
is
that
having
one
DHT
is
becoming.
A
You
know
it's
suboptimal
in
terms
of
where
you
have
to
go
in
order
to
resolve
content,
and
you
know
there
is
no
notion
effectively
of
having
you
know
resolving
getting
content
close.
So
if
someone
else
near
you
habit,
you
know,
okay,
that's
not
exactly
what's
happening
in
ipfs
and
I,
know
they're,
cashing
notes
and
things
like
that.
But
effectively,
you
know
a
more
hierarchical
structure.
Multi-Level
structure
can
bring
more
benefits
so.
M
I'm
curious,
if
there's
been
any
studies
of
like
populations
of
internet
requests
and
how
much
overlap
there
is
in
a
topological
region,
because
that
that
seemingly
makes
a
very
large
difference.
So
it'd
be
interesting
to
analyze.
How
much
overlap
there
actually
tends
to
be
within
a
locality
to
understand
where
current
network
practice
falls
on
that
graph.
Yep.
A
Yeah,
absolutely
there
are
studies,
there
are
old
studies
and
newest
studies,
but
people
have
been
trying
to
find
out.
You
know
how
what
is
a
reasonable
percentage
doxa
to
to
assume
they're
in
order
as
we
build
networks
and
optimize
networks?
What
is
reasonable
to
assume
so
it's
worth
looking
into
those
yet.
B
So
two
questions,
one
is
so.
This
is
all
dealing
with
immutable
content
right,
yep,
the
other
is
from
what
I
remember.
That's
been
a
while
the
like,
even
before,
like
kid
only
and
such
were
published,
there
were
thoughts
like
well
yeah,
let's,
let's
try
and
have
like
embed
the
topology
more
into
the
system
and
kid
Emily
I
was
sort
of
like
this
is
hard.
A
So
there
there
was
a
test
bench:
I,
don't
know
how
global
it
was.
I
can
I
can
find
out,
but
there
is,
there
is
code
that
is
available
and
there
will
see
a
system
that
was
actually
built
and
not
only
simulated
yeah.
Certainly
there
was
go
there.
I,
don't
know
how
much
stress
test.
It
was
a
stress
test
it,
but
yeah
yeah.
B
H
For
colleagues
on
would
be
to
be
bb/d.
F/C
was
supposed
to
originally
have
a
multi-leveled
HD
using
coral
which
just
guesses
the
levels
based
on
latency.
It's
like
most
viewers
would
all
work
together
and
sort
of
like
collaboratively
figure
out.
They
happen
to
be
in
some
low
latency
group,
and
then
there
was
reformed.
This
is
just
the
real
okay.
H
H
Know,
if
is
a
better
sister,
currently
I
I
think
it.
There
may
be
some
room
for
like
a
hybrid
system.
That
uses
like
your
look
like
your
literal.
Local
network
is
like
the
bottom
tier
and
then
maybe
you
can
automatically
configure
certain
IP
range
for
like
the
next
year
or
you
can
use
like
your
local
ISPs
information.
But
then
beyond
that.
Actually
these
are
usually
the
most
correct,
I
guess.
Yeah.
J
D
I
A
A
A
So
that's
one
thing,
and
the
second
is
that,
yes,
there
was
in
all
of
them
the
wreath
involvement
of
the
IASB
to
some
extent,
but,
for
example,
the
resolution
handler
was
supposed
to
be
one
in
every
RESP
I,
don't
know
if
it
would
need
to
have
the
agreement,
but
I
guess
from
a
business
model
perspective.
Someone
would
have
to
get
this
machine
and
go
and
put
it
back
connected
to
everyone.
You
know
so
who
would
kind
of
foot
the
bill
for
that.
A
Therefore,
the
ISPs,
the
most
you
know
straightforward
thing
to
you
approach
and
go
and
put
it
there,
so
yeah
yeah,
so
I
have
seen
there
is
some
discussion
if
we
want
to
take
these
trusts
out
of
the
IASB
or
the
IASB
out
of
the
picture
as
to
how
we
build
a
system,
a
system
where
this
is
not
involved
or
we
do
not
blindly
trust
the
ISP
or
whether
is
the
infrastructure
provider.
Then,
of
course
what
comes
in
is,
in
my
opinion,
the
incentives
and
I
have
been
have
seen
some
discussions
on
it.
A
A
Yeah,
okay
and
then
right
so
I
put
some
resources
here.
Where
some
people
might
you
know
we
might
want
to
look
at
later.
There
is
a
hybrid
ICN
approach,
which
is
also
an
active
project,
and
it
might
be
worth
looking
at
a
sping
currently
developed
at
Cisco.
So
it's
not
a
dead
project.
It
was
not
done
at
some
point.
It's
an
open
source
project
at
Cisco,
where
why
is
happening
there?
What
they're
doing
is
that
they're
assigning
their
dressing,
content,
chunks
or
content
item
and
items
with
an
ipv6
address.
A
A
These
open
sources
of
just
this
link
there
currently
I
think
it's
only
Cisco
people
in
part
place
that
are
developing
this
and
actually
we're
colleagues
where
we're
working
on
the
same
project
together,
but
I
have
they
have
just
released
a
new
version
of
what
they're
doing
and
then
in
in
simulation
tools
on
top
of
what
Molly
suggested
about
measurements,
and
you
know
trying
to
find
out
measurements.
Another
thing
that
I
think
would
be
interesting
is
to
try
and
find
simulation
tools,
so
we
have,
for
example,
data
simulator,
which
is
basically
a
caching
simulator.
A
We
have
real
estate,
I
mean
it's
been
years
and
it
has
got
some
feasibility.
The
main
person
that
developed
that
they,
the
moved
and
I,
know
that
they
have
been
using
the
simulator
within
fastly.
So
it's
been
developed
and
maintained,
and
it
is
something
that
could
you
know,
get
data
as
input
and
project
what?
A
So
there
are
some
yeah
some
thoughts
that
I
mainly
I
mean
mostly
talked
about
those.
But
the
main
thing
is,
you
know
the
me
an
outcome
of
these
discussion
should
be
you
know.
What
could
we
borrow?
Is
there
something
interesting
that
deserves
further
thinking
before
you
know
allocating
resources
like
big
resources,
you
know
I
think
we
should
have
and
could
have.
A
You
know
either
follow-up
online
discussions
or
physical,
a
physical
meeting
where
you
know
we
kind
of
pick
a
few
things
out
of
what
we
discuss
today
and
see
you
know
what
we
could
take
into
account.
So,
in
my
view,
as
I
said,
some
topological
embedding
of
some
structure
or
some
nodes
is
going
to
improve
performance
considerably,
whether
this
is
done
through
the
corral
techniques
or
some
other
technique.
A
I,
don't
know,
but
I
think
the
system
moves,
and
you
know
the
the
delivery
delay
is
going
to
start
becoming
an
issue-
maybe
not
now,
maybe
in
five
years.
But
you
know
if
the
system
is
supposed
to
be
kind
of
content,
delivery
network,
the
CDN
kind
of
approach-
these
guys
have
done
crazy
things
and
in
order
to
get
even
close
to
that
performance,
you
know
some
topological
thing
needs
to
be
in
the
whole
system,
not
missing
the
naming
I'm,
not
not
saying
that
in
the
system.
A
So
these
can
come
in
terms
of
some
name
based
some
name
based
routing,
as
opposed
to
only
name
resolution
based
routing,
so
some
nodes
that
can
keep
track
of
what
is
being
cached
locally
and
redirect
local
nodes
when
something
gets
popular
before
getting
before
hitting
the
DHD
I
think
that
is
also
something
that
can
take
huge
advantage
of
the
kind
of
interests
and
then,
as
we
just
said,
routing
and
trust.
Basically,
so
how
do
you
do
that?
All
oh
they're
both
have
assumed
that
there
is
a
nice
baby.
A
L
So
one
sort
of
low-hanging
thing
I
was
thinking
for
the
name-based
stuff.
Is
we
actually
did
do
some
name
base
stuff
in
IP
NS
right
you
can.
You
can
use
a
DNS
name
and
then
that
gets
resolved
to
an
IP
NS
key,
which
then
is
used
to
look
up
in
the
DHT,
but
like
we're
not
we're
just
sort
of
using
that
in
the
resolution
process
for
DNS
lookup
and
then
throwing
it
away
or
if
we
didn't
throw
that
away.
We
actually
use
that
I'm.
Sure
Dean
has
yeah.
A
I
thought
this
somewhere
and
the
next
thing
I
want
to
look
at
more
closely
into
your
IP
NS,
and
there
is
a
thread
or
of
the
DNS
link
that
takes
the
XD
there,
which
could
stay
for
a
bit
longer
or
could
have
some
other
metadata
information
that
it
can
be
kept
or
helping
some
different
way.
But
yeah
good
point.
L
C
A
A
Then
there
is
a
content
storage
which
is
okay,
five-point
storage
market
and
then
there
needs
to
be
I,
believe
I,
don't
know,
but
eventually
needs
to
be
timely
delivery
as
well,
so
so
content
needs
to
be
provided,
but
with
some
isolation,
some
guarantees
to
keep
cold
or
service
high.
So
in
terms
of
content,
publishing
it's
there
is
something
that
discussed
briefly
with
Steven
at
some
point
last
week
or
the
week
before
which
he
starts.
In
my
opinion,
caching
is
different
storage.
A
So
it's
different
to
say
that
someone
is
storing
something
and
that
is
going
to
be
there
for
longer
time
periods,
and
you
know
it's
going
to
become
unavailable.
You
know
if
Christy
goes
out
and
is
different
you're
having
someone
that
is
caching
and
is
unreliable
unstable
because
they
just
throws
a
lot
up
and
go
so
I
think
this
needs
to
be
reflected
in
some
node
class
kind
of
thing,
where
there
are
some
caching
nodes
which
are
unstable.
A
There
are
some
caching
nodes
which
are
stable
and
then
there
are
that's
actually
store
contents,
and
in
order
to
get
that
you
know,
there
needs
to
be
techniques
that
actually
both
measure
the
participation
of
nodes
in
the
network
and
therefore
kind
of
assign
them
or
build
reputation
of
some
sort.
And
you
know
they
are
allocated
in
one
of
those
categories
and
then
how
do
we
actually
do
the
provide
the
records?
You
know
I
have
this
content
cache
here
is
a
whole
different
thing
and
there
are
interesting
techniques
that
say
you
know
to
estimate
basically
on.
A
When
did
some
node
started
cashing
this
and
how
much
time
has
has
it
been
since
then
try
to
probabilistically
infer
whether
some
piece
of
content
is
still
in
this
can
show
it
has
expired,
and
this
Alice
has
been
pushed
out
of
the
cache.
Therefore,
you
know
we
can
assume
without
having
to
provide
to
send
out,
provide
the
records
all
the
time
we
can.
We
can
probabilistically
know
whether
to
contact
some
node
or
not.
A
Then
it's
content,
storage,
which
you
know
it
has
to
be
reliable
and
available,
and
it
needs
basically
smart
replication.
So
the
content
placement
needs
to
be
intelligent
so
that
you
know
when
I
receive
some
content
here
other
we
need
to
have
a
mechanism
to
to
see
whether
it
makes
sense
to
replicate
this
content
to
other
nodes
that
are
close
by
because
you
know
I
might
disappear
from
the
network,
but
this
content
might
become
popular
all
of
a
sudden.
A
Therefore
it
would
be
good
to
have
it
somewhere
close
by
and
be
able
to
identify
it
as
such
in
order
to
serve
other
content.
Other
users,
you
know
without
having
to
go
after
the
DHD
and
have
to
resolve
the
comb,
then
also
from
start
again
and
then,
of
course,
you
know,
content
delivery,
he's
another
tricky
point,
but
I
guess
that's
on
the
plan.
A
This
is
a
little
bit
further
and
out
towards
the
future,
so
yeah,
so
so
kind
of
a
design
proposal
is
that
which
I'm
sure
I
have
seen
some
of
them
in
github
pages,
I,
just
thought
of
putting
it
in
one
or
two
slides,
a
that's,
not
every
client
should
be,
should
be
providing
routing
information.
There
should
be
one
Gateway,
node
or
entry
node
or,
if
you
I,
don't
know
which
we
trust
first
somehow,
and
then
these
are
sitting
before
the
DHD,
so
that
we
can
resolve
content
that
is
local
and
effectively
through
a
multi.
A
But
if
the
main
point
is
that,
if
you
have
clients
here-
and
you
have
this
local
gate,
where
your
whatever
other
thing
we
want
to
collate,
you
know
if
it
keeps
if
this
gateway
here
is
keeping
an
index
of
what
other
clients
have
been.
A
request
could
be
resolved
locally
without
even
hitting
the
local
DHT,
which
is
there.
Then,
if
something
is
not
there,
obviously
you
need
to
go
to
the
deity
and
that
may
be
different
levels
of
the
HDS,
but
you
know
having
one
node
that
he's
basically
attached
to
several
different
page,
the
Rings.
A
This
makes
you
know
latency
to
be
pointed
to
different
levels
here
or
there
minimum
you
don't
have
to
go
to
the
other
side
of
the
planet
in
order
to
get
a
pointer
to
the
deity
that
you
need
to
go
so
physically.
This
is
one
machine
that
is
just
keeping
index
is
two
different
things
and
down
here.
Is
you
know
it's
not
could
be
he's
keeping
an
index
as
in
the
table
not
before
it
goes
into
the
DHD.
A
So
structure
like
this
I
think,
could
you
know
in
the
long
term
be
something
that
should
be
considered
and,
of
course
he's
the
issue
of
trust
right
so
I'm,
not
forgetting
that
it's
just
yeah
yeah
and,
of
course
the
design
I
think
depends
on
the
desired
outcomes.
You
know
if
it's
a
faster,
if
we
won't
try
professedly
p2p
to
be
a
faster
CDN
Network,
then
you
know
there
needs
to
be
a
lot
of
work.
As
I
said
you
know,
CDN
systems
are
crazy,
sophisticated
if
it's
a
permanent.
You
know
storage
and
backup
network.
A
Then
you
know
with
deity
of
one
or
a
few
of
some
sort.
Then
I
think
the
target
is
there
and
it's
it's
totally
fine
and
yeah.
You
might
have
noticed.
I
have
not
mentioned
the
word
security
and
privacy
too
much,
but
this,
of
course,
is
something
that
needs
to
be
there
and-
and
there
is
related
work
on
that
and
I
know.
Other
people
in
the
collapse
have
been
working
on
that
it's
just
I
decided.
A
You
know
to
keep
it
out
of
that
and
subject
to
a
different
meeting
if
we
want-
and
actually
yes,
if
you
fell
asleep
I,
don't
know
it's
time
to
wake
up
now,
yeah
and
any
other
questions
and
feedback.
There
is
this
feedback
form
that
George
will
send
or
has
sent
already
at
the
moment,
but
yeah
any
any
any
kind
of
feedback
now
or
later
yeah
a
bit.
Yes
thank.
G
G
Awesome
so
I
have
a
bunch
of
thoughts.
The
the
one
that
I
will
choose
to
like
just
bring
up
is
and
like
you
were
kind
of
like
that.
You
need
at
the
end
like
it
seems
to
me
that,
like
in
both
of
these
communities,
either
at
the
fast
fast
we
disappear
I
now
so
their
name
data
networking
or
even
like
the
DHT
research.
G
There
is
kind
of
like
this
belief,
or
this
hope
to
find
a
one
size
fits
all
DHT,
even
if
it's
a
multi
layer
or
like
a
clustering
EHT
doesn't
matter
like
like
it
seems
like
we
are
always
tweeting
like
store
storage
of
data
as
I
can
a
database
problem
when
in
reality
is
like
a
data
access.
So
let's
watch
that
a
publishing
problem
right,
like
I,
see
something
missing
here
and
then
I
was
hoping.
G
Maybe,
like
you
know,
of
some
work
or
maybe
like
I,
it's
already
done
and
I
just
don't
know
about
it,
which
is
like.
How
can
we
tell
like
when
we
create
the
data?
How
can
we
describe
with
the
data
itself
like
how
it
is
supposed
to
be
accessed
so
I
think,
like
a
blog,
maybe
there's
like
a
blog
post
every
week,
so,
like
user
should
not
be
like
resolving
HD
records
every
second,
because
they
they
probably
will
not
get
or
or
as
a
user.
G
A
J
A
Are
you
know
if
it's
a
blog
post,
which
is
updated
every
minute,
then
these
listened
RT
feeds
my
web
page.
There
is
a
data
debris
here,
then
these
decent,
if
it's
even
going
further
and
saying
this-
is
some
piece
of
personal
information
out
of
my
wearable
devices
that
I
want
to
keep
totally
private
and
totally
encrypted
and
give
access
only
to
my
doctor
and
no-one
else,
not
even
my
family
or
whoever,
and
then
these
needs
to
have
totally
different
properties
right,
yeah,
so
so
I
totally
agree
with
you.
A
I
I
am
not
straight
my
hand,
aware
of
an
architecture
that
supports
that,
but
there
have
been
recently
approaches
by
you
know
you
kind
of
attach
metadata
data
and
that's
how
you
can
achieve
a
few
things.
How
scalable
this
is
to
address
the
whole
of
the
internet,
I'm,
not
very
sure,
but
I
agree.
There
is
a
very
nice
direction
for
someone
to
to
look
at
I
really.
G
Wonder
if
this
is
a
problem
that
could
not
only
be
solved
by
like
using
AI
like
ml
and
so
on,
because
like
what
we
are
talking
about
so
many
variables
and
so
many
options
that
you
will
actually
need.
Some
help
like
to
actually
choose
the
right
path
in
which,
like
you,
would
publish
something
or
you
would
access
something:
yeah,
yeah,
cool,
okay,.
G
L
Is
sort
of
a
separate
question,
but
there's
been
a
lot
of
this
research
and
like
and
I've,
been
following
things
like
multicast,
which
have
been
around
since
the
80s
and
they
really
took
off
and
I
feel
like
some
of
these
things.
It's
just
like
the
technologies
are
more
efficient
or
the
ideas
are
more
efficient,
but
they're
incompatible
with
existing
business
models,
like
artists
tend
to
sell
oversubscribed,
they
don't
put
storage
or
squid
caches
in
or
anything
to
improve
the
experience.
L
The
experience
is
improved
by
CD
ends,
which
have
a
separate
business
model
where
the
publisher
pays
or
companies
like
Google,
so
it
this
the
current
environment,
favors
massive
massive
companies
like
Google
and
Amazon,
and
so
there's
not
that
rich
incent
or
there's
no,
not
much
profit
to
be
made.
We're
at
ispeed
levels
to
you
like,
put
put
in
like
more
expensive
Cisco,
routers
I.
A
So
there
has
been
this
thing
with
accountability,
basically,
where
caching
has
been
a
big
thing,
but
it
has
not
taken
off
as
much
as
it
could,
and
then
there
was
a
big
CDN
company
that
came
and
everyone
trusted
them.
That's
why
they
give
the
content
you
to
them
now,
with
with
structures
like
you
know,
permanent
names
and
name
data.
This
is
much
easier
to
do
right
because
you
can.
A
You
can
have
some
proof
that
something
has
been
requested,
then
has
been
forwarded
and
if
someone
is
asking
for
that,
name
is
asking
for
that
name,
and
this
cannot
change
you
know
and
you
don't
need
any
dpi
or
anything
that
you
can
do.
You
know
under
the
hood
basically,
but
it
totally
agrees
a
business
model
issue
and
yeah.
C
A
There
are
many
so
out
of
those
that
I
have
talked
about.
It's
mainly
the
end.
The
end
object
that
is
kind
of
alive
and
there
is
a
deathbed
and
everything
so
that
can
be
used.
It
can
be
compared.
They
can
be
measured
that
they
are
very
open
to
any
new
user
or
any
new
collaboration
or
any
new
testing,
and
so
I
know.
So
it's
on
that
side.
Yes,
everything
good,
so
the
NetBeans
project,
for
example.
It's
not
operational
anymore
I
know
there
was
a
prototype.
A
I
know
there
was
a
test
bed
of
some
sort
and
there
is
open
source
code
available.
Certainly
I,
don't
think
it's
maintained
anymore,
but
the
fact
that
we
can
get
the
code
and
deployed
somewhere
in
tests
that
can
be
done.
I
have
a
notonly,
so
I'm
going
to
to
check
with
them
and
see.
Where
is
the
code
actually
yeah
yeah
and,
as
I
said,
the
donor
thing
was.
The
donor
architecture
was
a
paper,
so
there
might
be
some
coach
with
the
papers,
even
some
github
repository,
but
it
was
never
really.
I
I'd
like
to
I'd
like
to
mention
to
add
to
it
the
beads
thoughts
of
how
much
of
this
can
we
actually
evaluate
we
use.
Potentially,
you
know
I
think
that's
a
fundamental
difference
between
what
these
projects
are
trying
to
address
and
the
kind
of
the
the
lay
of
the
land
that
they're
actually
seeing
that
is
addressable
versus
what
we
are
trying
to
do.
We
are
inherently
peer-to-peer
right,
so
these
projects
are
actually
assuming
that
the
internet
will
be
will
be
reshaped
and
will
require
active
collaboration
by
very
powerful
actors
out
there.
I
I
K
J
B
B
Those
are
like
two
very
different
ways
of
looking
at
it.
In
the
sense,
the
continuous,
like
the
continuously
growing
DHT
is
basically
just
one
system,
whereas
a
multi-level
is
like
you've
intentionally
designed
that
as
multiple
levels,
sort
of
did
does
the
multiple
levels
thing
as
being
like
discrete
like.
What
do
you
think
are
the
advantages
there.
A
So
the
advantages
there
I
think
is
that
we,
basically
when
you
when
you
enter
this
ring
in
order
that
the
next
point
that
you're
pointed
to
might
be
too
far
away.
Apart
from
that
knots
and
things
like
that,
even
these
can
be
very
far
away,
so
the
the
time
to
go
there
and
then
go
to
the
next
and
then
go
to
the
next.
A
Until
you
hit
the
point
where
you
have
the
local
node,
you
know
you
get
the
note
that
knows
where
your
content,
the
content
that
you're
looking
at
is,
can
be
both
long
in
terms
of
the
resolution
like
to
go
around
the
ring
and
then
the
note
that
you're
going
to
induct,
you
might
also
be
too
far
away
and
that's
when
the
contents
delivery
starts
right,
which
has
to
go
through
a
possibly
long.
You
know
long
haul
path
from
a
different
continent.
A
So
if
there
is
a
more
smaller
notion
of
ADHD,
which
is
registering
local
content,
then
you
know
the
locality
of
interest
comes
together
and
it
can
be
exploited.
You
know
by
looking
for
content
within
the
same
metropolitan
area,
rather
than
having
to
go
all
the
way
to
Japan,
to
come
back
and
find
that
the
content
is
here.
B
You
do
that
with
like,
like
far
like
far
jumps
right,
so
there's
like
extensions
on
on
corridor,
instead
of
just
reaching
all
the
way
across
the
network
in
in
key
space.
You
also
reach
to
like
people
that
are
closer
to
you
and
sort
of
you
break
the
network
up
into
halves
and
quarters
and
eighths
yeah.
You
could
do
that
with
latency
and
be
like
well
I'm
gonna
fill
up
most
of
my
table
with
people
nearby
and
I'll
feel
some
with
people
far
away
all.
A
D
I'm
able
to
raise
my
hand,
okay,
but
I,
did
have
a
quick
question.
It
seems
like
caching
and
like
redoing,
a
lot
of
the
network
to
be
more
named
it
and
that
work
who,
like
or
like
information-centric
network,
like
seems
to
violate
the
end,
end
principle
in
some
ways,
then
what
the
which
principle,
the
end-to-end
principle
right
yeah?
How
does
that
conflict
manifest
in
discussions
around
these
projects
and
like
within
the
IETF
or
like
within
big
groups
that
have
a
lot
of
control
over
the
Internet
it
seems
like
this
is
like?
D
Is
this
acknowledge,
just
like
it
could
be
really
interesting,
is
like
a
small
like
as
a
possible
alternative
and
the
way
just
in
future,
but
we're
not
gonna
think
about
it.
Do
people
tend
to
just
just
miss
this
effort,
or
do
people
generally
agree
that,
like
this
would
be
a
good
thing,
but
it
has
to
be
problems.
Yeah.
A
Yeah,
so
there
is,
there
is
discussion
lately
to
say
that
you
know
there
is
enough
consolidation
of
Internet
services
and
that's
not
good,
and
things
have
to
change
there.
Has
there
hasn't
been
any
great
movements?
I
mean
there
are
some
people,
some
people,
that
we
were
talking
about
about
10
years
ago
in
the
IETF
or
in
some
conferences,
but
there
hasn't
been
anything
fundamentally
actually
done
so
yeah.
A
D
Yeah,
and
would
you
say
the
reason
why
that
conversation
is
starting
now,
is
that
they're
like
it
doesn't
seem
like
it's
tied
to
business
type
app
like
who
pays
for
these
sorts
of
things
is
that
the
businesses
were
interested
or
there's
like
a
clear
financial
incentive,
or
is
there
some
other
reason?
I?
Don't.
A
A
You
know
a
secondary
thing
and
people
looking
to
improve
performance
and
this
and
that-
and
you
know
you
end
up
with
solutions
like
VPN
and
you're,
saying:
okay,
I,
don't
care
if
there's
more
delay
on
some
privacy
so
which
throws
away
all
the
performance
things
that
someone
tried
to
do
away
because
I
don't
care.
You
know
like.
H
Don't
say
this
helps
improve
the
antenna
principle
because,
like
currently
in
order
to
have
the
interprets
pole
you'd
like
HTTP
we've
had
to
layer
on
HTTP,
it
just
absolute
prevents
any
and
all
caching
yeah,
but
this
is
effectively
like
the
endpoint
is
actually
like.
The
next
router
and
then
they're
on
point
is
the
next
router.
So
point-to-point
is
still
like.
You
probably
have
encrypted
or
secure
connections,
but,
like
you,
don't
really
care
about
which
I'm
I
guess
it's
the
best
way
of
putting
it
in
terms
of
privacy.
You
can
you
can
get
privacy.
A
Yeah
great
yeah
yeah
and
you
need
those
things
I
mean
be
especially
because,
sometimes
not
sometimes
you
know,
you
know
those
cases.
Names
have
to
be
unique
and
permanent.
These
means
that
you
know
Reuters
or
whoever
he's
the
forwarding
t
knows
exactly
exactly
what
you're
forwarding
right.
So
in
terms
of
network
neutrality
and
all
that
stuff,
you
know.
Basically,
information
is
out
in
the
real.
J
K
Thank
you,
I
think
we're
I'm
so
well.
Thank
you
so
much
yummies.
This
was
really
great
and
thanks
everyone
for
coming
and
again
we
really
care
about
feedback.
So
hope
you
know
if
you
want
to
use
the
next
two
minutes,
it's
a
short
form,
and
this
will
also
help
us
plan
B.
You
know
future
workshops,
the
remotes
are
in
person
and
yeah
I
mean
that's.
It
have
a
great
weekend,
yeah.