►
From YouTube: IPFS Network Measurements and Improvements Opportunities By Yiannis Psaras @ Paris P2P Festival #1
Description
We will introduce a set of measurement methodologies that allow us to uncover the characteristics and interactions in the public IPFS network. After a big measurement campaign, we reveal presence of IPFS peers in more than 2700 Autonomous Systems and 152 countries, the majority of which operate outside large central cloud providers like Amazon or Azure. We further evaluate IPFS performance, showing that both publication and retrieval delays are acceptable for a wide range of use cases.
https://www.p2p.paris/festival
(CC BY-NC-SA 4.0)
Pour soutenir l'indépendance du festival, et sa gratuité :
https://p2p.paris/fr/donate/
_______________________
L’objectif de ce festival gratuit est de proposer 5 jours de rencontres autour de toutes les thématiques liées au Peer-to-Peer. Si la notion technologique du P2P est évidemment importante, elle est également un ensemble de valeurs, qui compose une philosophie.
Les valeurs du Peer-to-Peer peuvent s’appliquer à un très grand nombre de thématiques, comme la sécurité des communications, la protection de la vie privée, le partage de savoirs, mais aussi dans les arts, ou encore les échanges monétaires.
Le Paris P2P Festival se veut une occasion de fédérer et permettre la rencontre des acteurs du Peer-2-Peer sous toutes ses formes.
Toutes organisations portant des projets, tech ou non tech, se reconnaissant de ces valeurs sont donc les bienvenues à se joindre à cet événement pour y organiser leur propre rencontre, y poser un stand, ou organiser un hackathon.
Cet événement est le “prolongement” des rendez-vous mensuels de Paris P2P, tous les premiers mercredi du mois à Ground Control. Il représente l’ouverture d’un réseau de personnes, collectifs, associations, entreprises (…) souhaitant profiter ensemble d’un événement par et pour sa communauté, sans but lucratif.
A
So
I'm
going
to
talk
about
what
we're
building,
which
is
called
the
ipfs
observatory,
and
this
is
what
kind
of
motivates
us
the
fact
that
you
can't
improve.
If
you
don't
measure
stuff
and
then
you
should
measure
what
you
think
you
have
improved
in
a
protocol.
So
unless
you
have
the
methodologies
and
all
the
tool
chain
to
go
and
find
that
you
have
successfully
deployed
an
improvement
to
your
protocol,
you
can
be
sure
that
it's
actually
improving
things.
A
So
we
see
measuring
network
protocols
not
as
an
end
in
itself,
but
rather
as
a
means
to
an
end,
which
is
to
identify
bottlenecks
and
problems
that
you
have
with
your
protocols
quantify
how
much
improvements
can
be
done
with
what
you're
doing
with
the
protocol
that
you're
working
on
and
design
of
course,
protocol.
Optimizations,
this
is
a
huge
space,
I'm
just
going
to
cover
our
first
order
priorities
here
and
then
I'm
going
to
give
examples
of
what
we've
done,
what
we're
looking
to
do
and
how
we
can
work
all
together.
A
A
A
So
what
we
have
seen
is
that
when
you
try
to
actually
get
into
the
details
and
see,
why
does
it
take
so
long?
You
realize
that
it
actually
can
be
completed
in
less
than
one
second,
why
this
happens,
because
when
we
try
to
publish
something
using
on
ipfs
using
lib2p,
of
course,
we
need
to
find
the
right
people
to
go
and
store
something
that
is
called
the
provider
record
and
these
these
people.
Then
these
peers
are
going
to
be
responsible
for
letting
others
know
responding
to
requests
to
say
who
has
got
this
content?
A
You
know
point
them
to
the
right
direction,
so
this
process
takes
time
and
takes
all
these
tens
of
seconds.
What
we
figured
out
through
measurements
is
that
those
people
that
we
eventually
choose,
we
know
them
and
we
find
them
in
the
process
like
in
the
first
one
second
of
the
whole
procedure.
So
there
is
a
big
opportunity
of
like
an
order
of
magnitude
improvement
that
we
have
figured
out
and
we're
currently
working
on.
A
Now
the
the
second
thing,
the
second
opportunity
is
that
we
figured
out
through
measurements,
is
the
following.
We
wanted
to
find
out
what
does
content
routing
look
like
in
the
in
ibfs,
especially
using
the
dht
that
max
went
into
some
detail,
so
we
wanted
to
break
down
things
in
steps
and
figure
out.
How
long
does
it
take?
What's
the
latency
to
go
through
each
of
the
steps
right?
What
we
wanted
to
do,
of
course,
is
a
controlled
experiment,
so
we
we
deployed
ipfs
nodes
in
several
different
geographic
locations
across
the
globe.
A
We
then
created
content
like
cids
and
like
specific
content,
that
only
basically
our
nodes
knew
and
we
started
requesting
that
from
all
around
the
globe
and
we
measured
we
monitored
how
long
did
each
one
of
them
take
so
great.
We
have
a
controlled
experiment,
as
some
of
you
might
be
familiar
with
the
process.
A
What
happens
is
that
ibm
first
uses
bitswap
to
to
ask
all
of
the
immediate
peers,
like
as
a
peer
in
a
peer-to-peer
network,
you're
directly
connected
with
a
number
of
peers,
and
you
ask
them
in
case
they
have
the
content
you're
interested
in.
If,
then,
you
wait
for
some
time,
then,
if
that
doesn't
play
out,
then
you
go
to
the
dht
and
you
ask
there:
you
go
around
the
ring
and
you
try
to
find
the
right
person
and
eventually
you
get
the
content.
A
So
in
our
experiment,
what
we
figured
out
is
we
broke
this
down
so
here
you
can
see
the
overall
retrieval
duration
on
that
figure
down
there.
The
middle
figure
is
how
long
it
takes
to
do
the
dht
walk
and
you
know,
find
out
what
is
the
peer
id
and
who
has
got
the
content
that
you're
looking
for
and
then
finally
fetch
the
content
again
using
bitswap.
A
So
if
you
notice
there
first
of
all,
we
see
that
the
dht,
the
lipid
pdht
nowadays
is
performing
pretty
well
you'll,
see
that
from
several
different
locations
depending
a
little
bit
on
the
location,
you
can
do
the
dht
lookup
in
less
than
one
second
right,
which
is
pretty
good
performance
for
a
peer-to-peer
network
compared
to
pitburn
networks
in
the
past,
ibfs
itself
in
the
past
and
so
on.
So
that's
pretty
good
news.
The
other
thing
we
see,
though,
is
that
if
we
compare
like
these,
two
figures
are
pretty
much
like
similar.
A
If
you
see
down
here,
you
notice
that
everything
starts
a
second
later
in
the
overall
duration,
so
so
this
is
because
the
bit
swap
delay.
You
know
the
initial
step
of
asking
the
immediate
peers
takes
this
one
second,
and
that
can
be
very
useful
for
some
applications
or
some
nodes
in
the
network,
but
not
for
everyone.
A
If
immediately
this
kind
of
begs
the
question
of
you
know,
is
it
worth
waiting
this
one
whole?
Second,
if
the
discovery
rate
of
bitswap
is
not
high
enough,
so
if
you
are
continuously
asking
your
peers,
but
you
know
the
number
of
times
that
you
get
a
response
back
is
one
out
of
one
thousand,
then
perhaps
you're
wasting
one
second
waiting
and
the
chances
of
finding
it
is
very,
are
very
small.
A
So
what
we
want
to,
if
our
hypothesis
is
correct,
which
says
that
you
know
it's
not
going
to
be
very
successful
for
very
many
cases,
then
we
could
apply
simple,
very
simple
protocol
optimizations.
That
would
say,
let's
not
wait,
one
minute,
sorry,
one
second!
Before
we
start
the
dht
lookup,
let's
do
these
two
things
in
parallel
or
let's
shorten
this
one.
A
Second,
because
basically,
you
you're
adding
one
whole
second,
like
a
hundred
percent
of
the
latency
to
resolving
to
looking
up
contents
on
the
network,
which
is
a
lot
hundred
percent,
is
a
hundred
percent
so
yeah.
So
that's
two
kind
of
low
hanging,
fruit
and
opportunities
that
we
have
found
out
recently
and
now
we
we're
opening
up
many
of
those
through
grants
for
the
community
to
come
and
work
with
us.
A
We
have,
if
you
go
to
the
decentralized
grant
management
platform,
dgm.xyz
you're,
going
to
find
many
projects
and
we're
starting
to
put
in
projects
there
for
ipfs
and
p2p
ecosystems.
So
this
one
is
one
of
them.
We
have
a
methodology.
We
want
to
go,
find
out
the
success
rate
of
bitswap
and
come
up
with
what
optimization
is
going
to
be
best
for
every
peer,
every
node
and
every
application
in
the
network.
So
that's
one
way
of
getting
involved
and
working
with
us
now
more
generally.
A
These
are
two
of
the
immediate
studies
that
we're
working
on,
but
we've
got
more.
We
did
a
very
big
measurement
campaign
using
the
famous
by
now
nebula
crawler-
that
I
don't
think
is
part
of
the
program
here,
but
the
author
of
these
dennis
is
around
here,
so
come
and
talk
to
me
or
him
basically
to
him.
A
Ideally,
if
you
want
to
find
out
more,
of
course,
is
open
source
and
we've
been
collecting
data
since
last
summer,
and
we
recently
like
narrowed
down
and
did
an
analysis
on
some
part
of
the
data
so
and
there
are
several
metrics,
I'm
just
going
to
mention
some
of
them.
We've
got
a
technical
report,
I'm
going
to
point
you
to
and
several
other
places
where
you
can
see
what
other
things
we're
finding
out.
A
A
A
No,
no
one.
Okay,
sorry
12
hours
is
mega
wrong,
yeah,
so
yeah,
it's
roughly
one
hour
according
to
this
latest
result,
which
must
be
from
this
week
or
something
we
see
that
it's
two
hours.
So
there
have
been
studies
far
back
like
20
years
ago.
That
talked
about
roughly
these
figures,
one
or
two
hours,
and
it's
still
the
same.
It's
pretty
surprising,
but
things
are
still
the
same,
but
you
can
find
out
other
things
you
can
find
out
generate,
for
example,
by
agent
version.
So
we
see
here
that
this.
A
That
probably
does
not
it's
not
very
clear,
but
this
is
the
0.9.
Release
of
ipfs
is
much
more
stable
than
some
of
the
most
recent
ones,
so
you
can
figure
out.
You
know
if
there
is
some
bug
in
the
release
or
if
some
application
is
causing
things
and
things
are
not
looking
very
good.
You
can
also
see
you
know
what
parts
which
nodes
or
its
inversions
are
churning
more.
So
here
we
figured
out
just
yesterday,
actually
that
the
hydra
nodes
are
something
is
wrong
with
them.
A
The
previous
time
shows
some
weekly
reports
that
we
produce
the
hydro
boosters,
which
is
this
orange
brown
line.
Here
they
used
to
be
something
like
this
here,
because
they're
very
stable
they,
they
they're
maintained
actively
and
so
on.
So
you
can
identify
problems
with
the
infrastructure,
so
it's
very
very
important
to
kind
of
go
and
see
how
dig
deep
into
the
protocol
specifics
in
order
to
see
what's
going
on
in
the
network,
another
one
dependency
on
cloud
infrastructure.
A
Five
percent:
eighty
okay,
wow
wow,
okay,
okay,
strong
opinions;
no,
no,
nothing
like
that!
So
it's
less
than
two
percent.
It's
almost
one
percent
and
that's
that's
also
very
surprising,
yeah,
a
pinch
of
salt,
but
we've
we've
done
this
experiment
again
and
again,
because
we
were
also
surprised,
quick,
disclaimer,
that
this
is
about
big
cloud
infrastructure
that
the
big
cloud
providers
are
making
their
ip
ranges
public
and
available.
A
So
there
are
nodes
that
run
on
smaller
cloud
infrastructures
that
we
just
don't
know
their
ib
addresses,
but
yeah
a
very
encouraging
result
right
as
a
decentralized
network.
You
wouldn't
want
80
of
the
network
running
on
aws.
Probably
I
don't
know
it
would
be
a
little
bit
awkward,
but
it's
not
like
that
right.
A
A
So,
but
there
is
some
concentration
there
as
well,
so
the
top
10
ascs
contain
65
of
the
ip
addresses
that
we
have
found.
So
there
is
some
concentration
there,
but
still
this
does
not
mean
that,
for
example,
in
terms
of
resilience
of
the
network
that
would
present
any
problem
so
yeah.
Maybe
let
me
okay,
let's
be
brave
I'll,
show
you
the
okay
yeah,
so
we're
producing
these
reports
every
day
they
are
in
a
under
an
ugly
link,
but
they
have
some
some
very
interesting
results.
A
If
I
can
scroll
up,
you
know
you
can
see
the
percentage
of
nodes
are
online
offline,
constantly
offline
or
dangling
from
the
point
of
view
of
coming
in
and
out
of
the
network.
What
percentage
of
the
network
is
stably
online?
What
number
of
nodes
or
percentage
of
nodes
we've
seen
as
one-off
and
and
so
on?
A
So
there
is
some
like
the
dialable
peers
by
age
and
there
is
churn
rates.
There
is
also
inter
arrival
times,
which
is
another
very
interesting
metric.
You
know
peers
turn
and
go
out
of
the
network
power,
so
they
come
back
right.
They
don't
leave
and
network
disappears
it's
just
that
someone
leaves,
and
after
an
hour
or
two
or
five,
they
just
come
back
online.
A
A
Okay,
it
worked
so
yeah.
We
also
produced
a
12-page
technical
report
that
I'm
more
than
happy
to
share
with
you.
There
is
a
lot
covered
there
on
the
internals
of
how
the
protocol
works.
Our
measure
measurement
methodologies
and
you
know
all
the
results
that
we
found.
This
is
a
set
of
great
individuals.
We
worked
with
so
much
of
what
I've
talked
about
is
not
obviously
my
work
is
teamwork
with
all
these
communities.
A
So
thank
you
very
much
everyone
and
some
clouds,
so
much
of
what
we're
doing
is
obviously
very
useful
for
lipid2p
and
ipfs,
but
it's
important
to
stress
that
it's
not
only
for
that.
So
many
like,
of
course,
as
people
here
now,
if
we're
building
on
top,
if
a
company
or
individual
is
building
an
application
on
top
of
libitp,
we
need
to
be
able
to
provide
some
glimpse
of
what
things
would
look
like
when
you
go
and
deploy
your
application
and
like
build
your
business
or
whatever.
A
So
it's
very
important
to
you
know
have
these
these
tools
to
be
able
and
support
the
community
and
the
developer
community
around
that.
It's
also
very
important
to
know
that
these
measurement
methodologies
are
not
necessarily
targeted
only
for
lipid2p.
Of
course,
you
know
that
that's
our
first
order
priority
here
and
that's
what
we're
doing,
but
you
can
like
measure
other
systems
from
the
webp
ecosystem,
from
peer-to-peer
networks
and
so
on.
A
A
We
are
working
to
see
what's
the
success
rate,
because
you
know
it
works,
it
has
been
tested
and
so
on,
but
it
has
not
been
tested
in
the
wild
to
see
what
what
is
the
success
rate
that
all
of
us
are
going
to
see
when
using
it
so
we're
working
on
that
gossip
sub
performance.
This
is
another
very
important
protocol
of
the
lip
b2b
library
that
we
need
to
have
a
very
good
idea
of
how
it
performs.
A
You
know
it's
a
pops
up
protocol,
we
publish
a
message:
how
long
does
it
take
to
reach
the
entirety
of
the
network?
We
have
a
rough
idea,
but
we
should
be
much
more
definite
and
confident
about
it,
and
then
there
are
other
projects
such
as
the
dhc
routing
table
health
and
and
several
others
now
ways
to
get
involved.
Is
we
have
all
this
effort
to
measure
the
the
web3
stack
and
ipfs
and
the
b2b
is
called
problab?
It's
that's
how
we
call
it.
A
A
So
currently,
there
are
two
already
open,
but
we
plan
to
put
like
more
than
10
in
the
next
couple
of
weeks
and
then
there
are
going
to
be
others
coming
in
batches
and
so
on
so
get
interested,
get
involved,
yeah
come
and
let's
work
together
to
find
better
methodologies
for
all
of
that.
Yeah
and
a
final
note,
we
are
organizing
a
workshop
alongside
an
academic
conference
in
july.
A
That
is
going
to
be
another
very
good
venue
to
come
and
yeah
discuss
your
work,
see
what
other
things
are
going
to
be
presented.
The
program
is
also
is
almost
out.
You
can
find
it
using
that
link
that
you
cannot
see
there
but
yeah.
I
can
point
you
to
it.
There
are
going
to
be
lippy
tpp
folks,
but
not
only
they're
going
to
be
10
papers.
Three
tutorials,
two
demos
several
invited
talks,
so
we
need
to
figure
out
a
way
to
fit
them
all
in
a
day.
A
B
C
Hi
this
super
interesting
talk.
Thank
you.
So
I
saw
that
when
you
were
running
the
metrics
for
the
retrieval
at
the
very
beginning
for
the
latencies
that
you
had
created
kind
of
like
a
staging
environment
yeah,
have
you
thought
about
trying
to
run
that
experiment,
but
with
like
real
data
or
is?
Is
that
is
there
like
a
technical
struggle?
There.
A
It
is
well
yeah,
it
is
actually
infrastructure
from
the
point
of
view
that
it
is
interfacing
and
connected
to
the
public
network.
We
created
custom
cads
that
have
that
were
used
for
the
experiment.
That
was
done
for
a
reason,
and
the
reason
was
that
we
wanted
to
the
content
to
be
in
a
sense
unpopular.
We
didn't
want
others
to.
A
We
didn't
want
others
to
be
requesting
that,
because
that
then
would
kind
of
we
wouldn't
have
the
the
native
picture
of
what
is
happening.
Of
course,
we
can
get
cads
requested
from
the
network
and
play
around
with
those
we
might
see.
The
only
thing
that
we're
going
to
see
is
faster
performance.
You
know.
If
there
is
a
popular
content,
then
they
provide
the
record
and
the
content
itself
might
be
in
more
peers
and
therefore
we're
going
to
get
our
answer
faster.
A
A
D
I'm
curious
if
the
scale
of
measurement
of
the
measurement
infrastructure
could
be
could
be
very
useful
for
other
kinds
of
things
like,
for
example,
fearing
out
latencies
to
certain
kinds
of
nodes.
A
lot
of
the
people
in
the
falcon
ecosystem
are
trying
to
get
extremely
low,
latency
retrieval
and
one.
D
To
get
to
is
persistent
measurements
of
the
retrievability
of
certain
pieces
of
data
with
sub-second
retrieval
from
various
parts
of
the
world,
and
so
I'm
thinking,
if
like
if
you
could
wave
a
magic
wand
and
get
whatever
you
wanted.
What
would
be
kind
of
like
the
scale
of
the
measurement
infrastructure
like
if
you
could
have
like
tens
of
thousands
of
nodes
or
hundreds
of
thousands
of
nodes,
probing
things
like
what
kind
of
scale
do
you
think
would
be
like
the
top
end
of
what
you
would
want
to
get.
A
Right
so
yeah,
that's
an
interesting
point
and
we
have
had
requests
to
go
and
you
know
retrieve
content
through
gateway
through
go
ipfs
code
through
hydra
nodes
and
so
on,
and
that's
an
experiment
that
we
have
not
done.
We
should
do
now
regarding
the
scale.
I
don't
think
we
would
need
so
many
nodes
to
be
able
to
get
base
results
on
retrievability
and
retrieval
latency
and
so
on.
A
What
we
are
building
with
some
other
of
our
collaborators
which
were
just
discussing
is
if
we
can
get
some
telemetry
data
into
a
big
number
of
nodes
like
yeah.
A
number
was
flying
around
today
about
10
of
the
network.
That
would
give
us
much
better
view
of
what
is
actually
happening
in
a
kind
of
day-to-day
scenario,
so
the
kind
of
problem
there
well,
there
is
no
problem,
but
you
know
people
will
need
to
run
this
extra
plug-in.
It's
not
plug-in
it's
going
to
be
within
a
release
and
yeah
some
peop.
E
B
E
A
I
think
it's
it's
different
nature
of
things
that
we
would
be
able
to
collect,
because
we
cannot,
of
course,
like
running
this
experiment.
We
can
only
go
to
you,
know
our
homes
or
you
know
public
cloud
infrastructure
that
we
can
go
and
deploy
nodes
if
there
was
a
user
base
of
a
thousand
or
five
thousand
or
ten
thousand
nodes
in
every
home
in
random
places
across
the
world.
Obviously,
you'd
get
much
more
accurate
results
on
what
kind
of
real
life
looks
like.
So
I
think
that
would
be
an
issue.
A
F
A
G
Thanks
for
you
guys
just
two
quick
things:
one
as
great
things
have
occurred
once
you've
actually
taken
measurements
and
you
kind
of
explained
the
importance
of
measuring.
So
you
can
then
figure
out
what
to
fix.
I'm
curious,
how
do
you
develop
the
intuition
of
what
to
actually
go
measure,
and
the
second
thing
I
want
to
quickly
ask
is:
where
could
I
hang
out
with
you
this
evening
to
talk
with
more
with
the
team
and
the
ipfs
and
lip
pdp
folks,
yeah.
A
Starting
exactly
yeah,
starting
from
the
last
one,
there
is
going
to
be
lippy
to
be
sponsored
dinner
and
drinks
later
on
from
8
00
p.m.
Roughly
on
that
corner
of
the
venue
there,
so
I
don't
know
pick
a
sticker
and
that's
the
identification.
There
is
a
meetup
event
as
well,
which
you
you
might
have
registered,
that's
where
everyone
is
going
to
be
the
libpetep
team,
ourselves
and
and
and
so
on.
A
A
More
generally,
I
am
following
and
I
would
follow
something
from
the
more
general
from
the
more
high
level
and
dig
from
there.
Wherever
you
see,
you
know
things
that
you
would
not
expect
abnormalities
or
things
that
look
awkward
are
not
intuitive.
That's
where
you
then
go
and
dig
a
little
bit
deeper.
So
you
know
breaking
down
the
whole
life
cycle
of
content
from
publishing
to
to
getting
content.
You
come
up
with
this
initial
graph
of
tens
of
seconds
or
100
seconds
to
provide
content.
So
immediately.