►
From YouTube: IETF-ICNRG-20211210-1600
Description
ICNRG meeting session at IETF
2021/12/10 1600
https://datatracker.ietf.org/meeting//proceedings/
A
A
A
D
E
D
D
B
A
D
A
A
C
A
End
of
this
week
to
another
icn
rg
meeting,
unfortunately
still
online,
but
I
think
everybody
understands
why
yeah
so
I'm
dirk
kosher
and
my
coach
is
dave
orren
and
just
a
second
before
we
start,
I
just
have
to
point
you
to
some
housekeeping
items
so,
namely
the
irtf
notewell
statement,
so
this
basically
pertains
to
to
ipr.
So
if
you
submit
anything
to
our
group
that
has
ipr
associated
you're
expecting
to
let
us
know,
if
you
have
any
question
on
this,
just
talk
to
dave
and
me.
A
A
A
And
yeah
to
those
of
you
who
are
attending
ic
energy
or
irtf
meetings
for
the
first
time,
so
the
irtf
is
what
is
called
a
sister
organization
of
the
ietf,
so
the
ietf
is
setting
standards
for
the
global
internet,
the
irtf,
so
the
research
task
force
conducts
research.
So
what
we
are
doing
here
is
not
standards
development,
so
we
may
be
producing
specifications
and
so
on,
but
and
then
also
publish
those
rcs.
A
But
this
is
just
to
enable
experimentation
and
yeah
just
write
down
specifications
that
people
can
use
for
conducting
research
and,
of
course
the
hope
is
that,
eventually
you
know
some
insights
generated
that
may
yeah
guide.
Future
sonization
work
in
the
itf
check
out
this
rsc
7418
for
an
irtf
primer.
A
A
A
So
we'll
just
give
you
a
status
update
after
this,
and
then
we
have
three
really
cool
research
presentations,
so
one
by
carlos
on
xeno,
one
by
red
and
femi.
I
hope
that's
correctly,
pronounced
on
gt
systems,
span,
network
architecture
and
then
one
by
she
on
his
thoughts
and
his
work
on
ndn
ts
and
an
api
design
for
that
platform.
A
You
probably
know
that
these
documents
have
been
developed
over
quite
some
time
and
have
seen
quite
a
few
iterations.
So
rc
9138
describes
design
considerations
for
name
resolution
services
in
icn,
so
yeah
what
what
role
name
evolution
could
possibly
play
and
what
you
would
have
to
consider
for
that
and
rc
9139
describes
an
adaptation
of
ccnx
to
low
power
wireless
personal
area
networks.
A
So
this
is
equivalent
to
the
ietf
work
in
like
six
slope
and
so
ipv6
over
these
low
power
pens
and
well.
This
is
actually
has
quite
some
potential,
for
you
know
enabling
further
usage
of
icn
in
construct,
networks,
iot
and
and
so
on.
So
it's
not
necessarily
restricted
to
personal
area
networks,
but
so
this
technology
could
be
used
in
all
kinds
of
networks
where
the
other
kind
of
resource
constrained
and
where
you
need
a
really
compact
representation
and
so
on.
A
A
Exactly
so,
we
have
one
other,
like
specification
type
document
on
a
technology
called
ccn
info,
so
something
that,
like
a
tool
that
allows
you
to
collect
information
about
elements
on
a
path
in
a
ccn
network-
and
we
last
called
this
document
earlier
in
the
year
and
got
some
minor
comments
that
were
addressed
by
the
authors
some
weeks
ago,
and
so
we
think
this
document
is
now
ready.
So
there
haven't
been
any
technical
changes,
and
so
we
would
dave
has
just
notified
colin
that
we
want
to
submit
this
for
our
irsg
review.
A
A
A
E
E
E
A
A
All
future
and
yeah,
then.
Lastly,
we
have
a
couple
of
other
documents
that
still
need
a
bit
of
work
and
but
probably
also
benefit
from
like
feedback
from
the
group
so
path.
Steering,
if
you
remember
that
is,
I
think,
quite
elegant
way-
to
make
icn
communication
stick
to
some
past
with
a
like
soft
state
approach,
which
is
beneficial
in
many
scenarios.
A
So
we
are
still
planning
some
updates
on
that
one,
but
eventually
so
hopefully
this
could
also
be
finished
next
year,
maybe
early
next
year
time,
tl
we
yeah
was.
This
is
a
new
tlv
structure
for
recording
time
that
we
really
wanted
to
reuse
for
the
low
pan
specification.
But
then
lopen
got
finished,
say
earlier,
and
so,
but
we
still
want
to
publish
this
as
a
standalone
rc.
A
And
so
that's
like
quick
summary
of
where
we
currently
are
and,
of
course
it's
also
very
good
time
to
think
about
what
could
be.
You
know
useful
or
interesting,
upcoming
work
and
so
in
the
area
of
iot.
So
we
now
have
this
say:
efficient
encoding
for
low
pen
networks,
we
earlier
talked
about,
say
icn,
lora,
so
low
power,
long
range
radio
systems.
I
think
that
there's
quite
some
potential
there.
A
A
Then
yeah
we
have
been
talking
a
bit
about
distributed
computing.
Also,
it's
an
ic
energy,
but
also
in
the
coin
competing
in
the
network
group
and
yeah.
Many
of
us
think
that
icn
is
a
really
useful
enabler
for
yeah,
also
rethinking
how
computing
is
done
in
the
network,
and
so
the
the
rise
work
or
the
cfn
work
that
we
published
earlier
are
just
two
examples,
but
people
may
have
many
other
ideas
as
well,
so
that
could
be
a
general
good
topic
for
us
and
quality
of
service.
A
If
you
remember,
we
earlier
published
an
rsc
1964,
that
talked
about,
say
the
potential,
so
qs
considerations
in
icn
and
I
think,
was
a
really
nice
description
of
what
could
be
say
qualitatively
much
better
in
icn
compared
to
ip,
when
you
want
to
do
qs,
and
so
the
question
is
okay.
What
what
follows
from
that?
So
do
we
want
to
you
know,
leverage
these
ideas,
maybe
specify
some
mechanisms,
so
there
has
been
some
other
discussion.
Other
work
in
ic
energy
before
maybe
now
is
a
good
time
to
kind
of
yeah.
D
A
A
B
A
E
B
E
B
B
B
B
So
the
first
thing
that
happens
is
that
data
gets
produced
by
the
most
variety
of
entities.
They
can
be
robots,
satellites,
sensors
and
so
on,
and
then
this
data
is
distributed
and
perhaps
just
inside
the
same
physical
nodes
or
within
the
same
vocal
variant
network
or
eventually
across
different
geographic
locations,
and
this
distribution
of
data
happens
because
either
we
want
some
computations
to
be
applied
over
this
data
or
just
because
we
want
it
to
be
stored.
B
And
finally,
we
also
have
the
case
that
we
can
store
data
because
sooner
or
later
we
we
plan
to
retrieve
it
again,
just
for
the
fact
that
we
don't
store
data
just
because
yes,
so
we
can
say
that
in
this
journey,
data
goes
over
a
series
of
alternations
between
the
data
being
in
move,
the
data
being
addressed
and
the
data
being
in
use,
and
traditionally
there
are
different
communication
patterns
that
are
used
for
each
one
of
of
these
cases.
So
for
that
we
move.
B
Traditionally,
we
can
see
push
patterns
like
website
being
the
more
predominant
ones
while
for
that
at
rest,
the
pull
patterns
are
the
most
common
approach
and
what
is
the
catch?
The
cut
the
catch
is
that,
while
data
goes
on
this
journey
every
time,
we
need
to
move
across
that
in
motion
and
that
interest
or
that
ingress
to
that.
In
in
in
motion,
we
clash
against
technology
barrier,
meaning
that
these
two
technologies,
ecosystems,
are
really
fragmented.
B
So
on
one
side
we
have
the
techno
technology
to
push
data
and
on
the
other
side,
we
have
the
technology
to
store
and
to
retrieve
data,
and
the
problem
becomes
even
worse.
If
we
look
at
the
way
the
current
systems
are
being
designed
just
because
we
are
moving
away
from
these
monovitic
systems,
where
everything
runs
either
locally
or
in
the
clouds,
and
we
are
witnessing
a
decentralization
and
distribution
of
the
the
different
functions
that
compose
these
same
systems.
B
B
So
in
a
nutshell,
zeno
tries
to
unify
that
emotion
that
the
news
that
addressed
computations
by
blending
together,
perfect
and
distributed
queries
while
providing
built-in
support
for
geo-distributed,
storage
and
computations.
To
some
extent,
we
can
say
that
zeno
is
a
kind
of
data-centric
solution.
Okay,
that
has
that
oriented
solution,
and
it
achieves
it
by
not
only
defining
its
own
network
protocol
that
can
operate
over
different
network
technologies
at
different
stack
layers,
but
also
by
providing
a
set
of
high-level
apis.
B
B
Then,
in
the
middle,
the
zeno
zeno
defines
the
set
of
data
transportation,
primitives
that
provide
support
for
publish,
subscribe
and
for
query
replies,
communications
and
note
that
here
this
layer
is
content,
agnostic
and
then
on.
The
top
zeno
defines
a
set
of
data-oriented
abstractions,
which
is
our
api.
That
allows
more
complex
semantics
on
top
of
the
real
content
in
order
to
support,
for
example,
distributed
storages,
filtering
transcoding
of
data
and
even
remote
computations.
B
And
then,
when
we
deploy
several
xenons
together,
we
might
come
up
with
a
zenon
network
overlay,
just
like
the
one
we
have
in
this
slide,
and
here
note
that
zeno
can
either
run
in
the
devices
where
the
user
application
is
being
executed.
But
it
can
also
run
as
a
network
node
and
for
that
zeno
defines
three
different
types
of
entities
or
entities.
B
And
then
we
have
the
routers,
which
consists
on
some
software
nodes
that
can
route
messages
between
the
clients
and
the
peers,
and
these
three
roles
allow
us
to
implement
not
only
peer-to-peer
communications
over
any
type
of
connected
graph.
Topologies
allow
us
to
have
brokered
communications,
and
this
is
special
useful
for
constrained
devices
like
microcontrollers,
because
they
they
are
not
so
powerful
and
they
cannot
run
all
the
capabilities
that
are
required,
for
example,
to
do
routing,
and
we
also
have
routers
that
are
capable
of
forwarding
data
to
and
from
other
peers
and
clients.
B
For
example,
we
have
the
star
operator
that
is
used
to
replace
a
single
name
segment
in
the
key,
just
like
the
first
example
in
the
bottom,
or
we
have
a
double
star
operator,
which
is
used
to
replace
zero
or
more
name
segments
in
the
key.
So
in
this
case
the
bottom.
The
second
example
in
the
bottom.
B
Temperature,
I'm
getting
all
the
temperature
sensors
or
the
valves
from
all
the
temperature
sensors
that
exist
in
a
in
a
home.
Okay,
no
matter
what
is
the
room?
This
key
expression
will
match
it,
so
I
can
get
the
temperature
for
my
kitchen,
but
also
the
temperature
of
the
waiting
room
and
so
on
and
so
forth.
B
B
And,
at
the
same
time,
then,
we
can
also
so
it's
also
possible
to
fine
grain,
the
selected
data
at
the
declaration
time
by
defining
some
predicates
project
projections
and
the
set
of
properties.
Okay.
However,
I
would
like
to
highlight
that
the
key
expressions
are
used
throughout,
so
just
the
part
that
we
I
showed
in
the
previous
slide,
but
these
predicate
and
projecting
projections
and
properties
are
only
executed
in
the
node
that
executes
the
query
or
publishes
the
content.
B
So
we
can
have
resources
which
represents
a
name
data
that
is
represented
by
a
key
and
by
its
corresponding
value.
We
can
have
publishers
which
represent
the
spring
of
values
that
match
a
given
key
expression.
So
in
other
words,
it
represents
the
entity
that
produces
data
we
have
subscribers,
which
represents
a
think
of
values
that
match
a
given
key
expression.
So
in
other
words
the
entity
that
consumes
data,
and
we
have
variables
and
a
queryable
here-
represents
a
well
of
values
for
a
given
key
expression.
B
So
a
variable
is
also
a
produced
producer
of
data,
but
the
difference
is
that
it
needs
to
be
explicitly
requested
by
a
query:
okay
and
then
how
can
these
entities
make
use
of
zeno?
So
for
that
we
have
a
set
of
operations
that
are
listed
here
in
this
slide,
so
just
for
me
to
go
very
quickly
from
on
them.
So
we
have
scout
that.
Basically,
acts
as
discovery
mechanisms
to
see
who
is
around
which
entities
are
around,
and
this
is
very
similar
to
the
bonjour
protocol.
B
The
the
thing
here
is
that
a
zeno
session
is
not
end
to
end,
but
is
established
between
adjacent
nodes,
so
between
every
op
we
have
a
zeno
session,
then
we
have
primitives
to
declare
and
undeclare
the
different
kinds
of
entities
from
these
declarations.
Only
the
declarations
for
subscribers
and
queries
are
actually
mandatory.
For
example,.
B
So
other
declarations
for
publishers
and
resources
are
optional
and
basically
serve
to
optimize
specific
mechanisms
within
xeno.
So,
for
example,
we
can
use
a
resource
declaration
in
order
to
map
a
key
or
part
of
the
key
to
an
integer,
and
by
doing
it
we
can
save
some
bytes
in
the
wire
every
time
we
need
to
send
data.
B
Then
one
particular
thing
about
the
way
zeno
implements
queries
are
its
consolidation
strategies
and
also,
I
believe
we
will
not
have
the
time
to
dig
in
on
on
these
details.
Let's
just
consider
that
we
have
a
distributed
database
and
therefore
several
nodes
can
reply
to
a
given
query
in
this
case,
because
databases
might
not
be
aligned.
We,
so
the
queryer
might
get
different
replies
from
the
different
databases
and
to
mitigate
such
cases.
B
We
have
the
wages
strategy
where
only
replies
that
are
more
recent
than
the
previous
sent
are
forwarded,
and
we
have
the
full,
where
only
the
most
recent
replies
for
each
resource
are
sent
back
to
the
courier
and
these
consolidation
strategies
are
applied
in
three
different
stages
while
delivering
the
query
reply
in
the
first
router
in
the
last
router
and
in
the
reception
in
the
reception
node,
and
if
we
look
here
at
the
default
values
that
are
applied
in
these
different
stages,
so
lazy
lazy.
Full.
B
Now
going
a
bit
lower
in
the
network
stack,
so
zeno
is
transparent
from
the
underlying
network
topology
and
it
can.
It
has
been
tested
over
a
different
diversity
of
protocols
at
different
network
stack
layers,
so
we
have
successfully
tested
it
over
udp,
tcp,
tls,
quick
and
then
in
microcontrollers
over
the
threat,
protocol,
bluetooth
and
also
on
top
of
ethernet,
and
we
are
planning
to
test
and
to
make
and
provide
the
support
for
for
more
more
pro
to
for
xeno
to
run
on
top
of
more
protocols.
B
So
if
you,
if
we
look
here
at
the
example
in
this
slide,
so
we
have
a
physical
network
that
is
composed
by
ipv4
ipv6,
bluetooth,
ethernet,
and
this
xeno
overlay
is
able
to
abstract
all
these
heterogeneity
of
protocols
and
technologies
at
the
physical
network
and
to
expose
in
in
a
very
simple
way
as
an
overlay
that
only
needs
to
handle
or
only
needs
to
care.
If
the
transport
is
unicast
or
if
the
transport
is
multicast,.
B
B
B
B
So
yes,
so
we
have
also
an
eval
function
and
these
evolve
functions
could
be
used,
for
example,
to
run
additional
analytics
on
top
of
the
data,
and
the
results
of
these
computations
can
be
retrieved
by
means
of
queries,
okay,
yeah.
So
whenever
the
data
is
produced
and
what
happens
is
that
zeno
will
make
sure
that
this
data
gets
where
it
needs
to
be
delivered
depending
on
the
subscribers
and
the
storages
that
are
known
at
the
moment?
B
So
here
we
have
a
sensor
that
is
publishing
on
that
key
expression,
so
slash
move,
1,
42
sensor
temperature
and
all
the
subscribers
that
declare
their
interests
on
such
content
are
going
to
receive
it.
Okay,
so
the
one
on
the
bottom
explicitly
have
explicitly
requested
for
this
data,
while
the
one
a
bit
to
the
right
asked
for
all
values
that
are
all
temperature
values
that
are
published,
no
matter
the
floor
and
the
room,
and
on
the
top
we
have
the
the
storage
that
is
getting
all
the
information
for
the
first
floor.
B
So
here
the
ones
represent
the
the
distribution
path
and
then
suppose
that
we
have
a
second
sensor,
so
the
one
on
the
second
floor.
That
is
also
publishing
data.
Okay.
So
in
this
case
the
data
will
flow
to
the
other
storage
and
not
to
the
first
one,
just
because
they
are,
they
require
their
interest
on
these
data
with
different
key
expressions
and
then
also
notice
that
on
the
bottom,
we
have
a
subscriber
that
he
is
a
pull
subscriber.
B
B
And
now,
let's
assume
that
we
want
to
know-
or
we
have
a
query
that
wants
to
know
across
all
fours
what
is
the
temperature
in
room
42,
and
this
becomes
pretty
simple
to
do
in
zeno.
As
the
query,
the
query
only
needs
to
issue
a
query
which
will
hit
the
will
have
a
hit
from
the
multiple
storages
and
here
note
that
the
query
doesn't
need
to
know
the
location
of
this
data.
It
just
asks
for
this
information
and
the
network
is
responsible
for
forwarding
it
to
all
the
nodes
that
are
able
to
provide
this
information.
B
So
where
do
we
see
zeno
or
where
we
see
the
main
applications
domains
for
zeno?
So
basically
any
application
or
use
cases
that
requires
the
distribution
of
data
either
via
publish
subscribe
mechanisms,
query
based
mechanisms-
and
this
includes
smart
farming,
robotics,
smart
cities,
transportations
energy,
aerospace,
and
so
on
so
forth.
We
have
some
use
cases
already
done
in
some
of
these
application
domains.
I
have
a
couple
of
examples
to
show
just
before,
just
after
so
yeah,
let's
move
to
them,
because
they
are
very
interesting
so
here.
B
B
And
here
we
have
a
short
demo,
where
we
have
zeno
running
on
a
microcontroller
in
the
network
and
in
a
bridge
between
zeno
and
dds,
and
zeno
is
being
used
to
send
to
send
the
values
from
to
send
the
values
that
are
published
by
a
gyroscope.
And
then
they
are
translated
and
sent
as
comments
to
the
robot.
B
So
now
some
final
thoughts
before
finishing
this
presentation,
so
some
highlights
that
we
think
are
worth
mentioning
about
zeno.
So,
as
far
as
we
know
is
the
most
wire
power
and
memory
efficient
protocol
in
the
market,
we
can
support
the
whole
cloud.
Two
things
continue:
meaning
devices
that
can
range
from
cloud
servers
down
to
microcontrollers.
B
B
B
B
We
also
have
in
our
github
repository
some
demos,
so
yep
you,
you
can
find
this
in
well,
our
homepage
in
github
or
in
guitar,
where
we
can
have
other
discussions
or
if
you
have
just
thoughts
on
how
to
use
demo-
and
this
is
it.
Thank
you
very
much
for
your
attention
and
if
you
have
questions
or
comments,
I
would
be
happy
to
discuss
them.
E
F
B
F
B
F
So
those
are,
are
your
systems.
You
haven't
worked
with
industrial
systems
that
are
already
installed.
No
okay.
So
that's
my
that's
exactly.
The
crux
of
my
point
is
that
if
I
had
access
to
my
own
controllers,
I
would
be
really
happy,
but
right
now
I
think
a
lot
of
the
pain
points
and
the
use
cases
that
you're
you
are
presenting
is
that
we're
dealing
with
existing
industrial
systems
that
expose
only
their
data
through
really
weird
means
to
be.
F
That's,
that's
my
nice,
my
nice
way
of
describing
it
weird,
so
I
would
say,
maybe
for
your
next
generation
it
would
be
great,
and-
and
you
know
you
can
contact
me
and
I-
and
I
could
give
you
some
examples
on
this,
because
I
think
what
you're
doing
is
very
important
for
what
I'm
doing,
except,
except
that
I
don't
know
how
to
communicate
with
it.
So
I'm
taking
all
the
time
here
and
I'm
going
to
stop,
but
we
can
communicate
offline.
B
D
B
If,
if
you
need
to
make
to
ensure
the
integrity
integrity
of
your
content,
you
should
do
it
on
your
application.
Okay,
here
we
are
not
aiming
as
nbn
was.
I
mean
I
stopped
following
ndn
and
ccn
for
a
couple
of
years
before
joining
adwink,
but
we
are
not
aiming
as
ndn
and
ccn
were
in
providing
already
the
integrity
of
the
content
or
to
make
it
part
of
their
design.
G
B
Well,
not
really,
because
I
mean
we
are
targeting
the
same
type
of
functionalities
as
ndn,
ccn
and
others
are
trying
to
do
so,
and
since
we
we,
we
intend
to
have
a
very
low
wire
over
it
by
the
points
and
on
top
of
an
ndn,
we
would
already
have
a
big
overhead
just
with
all
the
the
layers
that
would
that
would
be
under
bible
zeno.
Let's
say
like
like
that.
G
D
B
A
B
A
A
His
presentation
material,
you
also
see
an
appendix
where
he
has
provided
additional
content,
also
code,
examples
and
so
on.
So
please
check
that
out.
That's
really
interesting
again,
thanks
a
lot
for
for
bringing
your
work
twice
and
yeah.
It
seems
really
interesting,
and
I
think
that
we
could
discuss
this
for
for
a
longer
time.
But
maybe
this
is
not
the
end.
So
I'm
looking
forward
to
probably.
B
A
C
C
D
A
A
C
C
A
C
C
C
C
I
still
can't
change
the
page,
so
that's
right
I'll,
just
I'll
go
to
the
presentation
and
and
assume
that
I
look
half
decent
for
you
guys.
I
think,
okay,
all
right,
so
we
we
we
done
carlos.
Some
of
the
things
you
said
were
very
similar
to
the
things
that
we
say.
I
think
with
one
fundamental
difference,
which
is
that
you're
working
at
a
transport
layer
over
different
network
layers
and-
and
we
came
to
this
from
a
slightly
different
perspective.
So
let
me
just
leap
into
that
and
it'll
become.
C
You
know
the
internet
ran
at
the
time,
which
was
a
lot
more
crazy
back
then
than
it
is
now
trust
me.
So
we
we
sort
of
borrowed
from
some
work
that
we
did
with
csiro
and
peer
assist
where
they
had
had
done
something
very
similar
to
a
bittorrent
patent
application
where
they
combined
peer-to-peer
with
super
with
super
servers
for
another
better
word,
and
they
got
some
very
encouraging
results.
And
particularly
the
very
important
thing
to
bear
in
mind
is
that
we've
always
been
application.
Driven
in
this.
C
We
were
driven
by
video
because
we're
in
the
manufacturing
demand
of
cd
cities.
Before
this,
we
then
had
a
customer
who
wanted
to
do
video
wanted
to
do
movies
online,
and
so
we
were
driven
by
basically
building
a
beta
streaming
system,
and
this
was
this
was
before
netflix
existed
by
the
way
or
sorry.
Netflix
was
still
mailing
dvds.
When
we
started
this
and
and
so
we
did
what
everyone
did,
we
stood
on
the
shoulders
of
giants
and
bittorrent
and
github,
etc,
etc,
and
and
sort
of
thought
about
and
said.
C
C
Like
name
domain
networking
content,
centric
networking
sometime
later
and
then,
but
then
one
of
the
fundamental
ideas
we
had
was
to
route
on
those
tagged,
slices
or
packets
and
and
then
to
do
that
intelligently
with
optimization-
and
you
know,
as
I
said
to
someone
the
other
day,
the
at
the
eye
inai
for
networks.
Isn't
that
eye.
C
You
don't
have
to
be
that
smart
to
make
massive
improvements
on
this,
and
then
we
came
up
the
you
know
the
the
same
idea
as
originally
sauron,
bittorrent
etc,
which
was
peer-to-peer
with
super
pops,
but
but
we
left
the
door
open
for
and
then
for
everything
to
be
appear
and
for
it
to
be
a
mesh
network
and
a
distributing
factor
distributed
storage
network
in
a
distributed
computing
network.
So
that's
kind
of
was
the
starting
point
back
in
we
started
the
r
d.
C
We
did
the
work
with
sarah
in
early
2000s
and
then
we
did
mod
for
a
while,
and
then
we
did
the
and
then
we
that
we
did
the
work
with
the
customer
and
came
up
with
this
bit.
We
we
then
discovered
a
thing
called
like
ipfs
and
protocol
labs.
You
know
interplanetary
file
system,
what
a
great
name
and
and
of
course
that
was
an
implementation
of
our
idea,
which
was
the
file
system.
I'd
been
running
around
looking
for
and
saying
you
know
we
need,
we
need
this,
but
it
it
really
was.
C
It
was
a
great
idea
when
we
found
it,
but,
as
time
went
on,
it
became
clear
to
us
that
there
were
some
problems
associated
with
that,
which
was
that
you
know
it
didn't
scale
for
distribution.
It
was
great
for
storage
but
didn't
scale
for
distribution,
and
in
particular
we
became
aware
of
that
when
they
published
some
rfps
early
last
year,
I
think
to
for
some
r
d
work
to
basically
to
help
them
scale.
C
C
Yeah
and
so
we
formed
this
project
team
with
a
bunch
of
other,
really
smart,
guys
and
and
sort
of
merged,
all
the
work
together
to
respond
to
protocol
labs
sort
of
call
for
help.
But
but
you
know,
given
that
we
both
really
like
their
distributed
storage
system-
and
you
know
and
really
a
lot
of
it-
was
merging
the
work
that
haymi
had
done
in
modeling
and
optimization
at
the
labs,
with
the
work
that
we've
done.
C
You
know
around
content,
distribution
and
peer-to-peer
and
and
and
sort
of
our
version
of
that
and
and
in
the
end
we
kind
of
came
up
with
a
solution.
We
first
of
all,
we
had
to
learn
how
it
all
worked,
and
then
we
discovered
the
limitations.
And
you
know
there
were
some
very
strong
points
to
you
know
as
haymi
says,
to
the
to
the
storage
side
of
product
of
ipfs,
but
but
but
it
had
some
limitations
in
distribution
which
we'd
addressed
from
the
beginning
in
in
distributing
video.
C
And
then
there
was
a
a
paper
and
I
I
was
trying
to
remember.
Whilst
I
was
listening
at
who
wrote
the
paper,
but
I
think
it
was
someone
in
either
ccna
or
icn
or
indian
had
written
a
paper
that
said,
it
might
be
really
interesting
to
smash
together,
ipfs
with
name
domain,
networking
or
content-centric
networking.
I
think
they
said
content-centric
networking
and
we're
like.
What's
this
concentric
networking
thing,
I'm
ashamed
to
say
you
know,
and
we
we
then
you
know
we
dived
into
that
whole
thing
and
we
went
wow.
This
is
nirvana.
C
C
And-
and
so
we
ended
up
with
a
thing.
We.
We
call
this
hybrid
adaptive,
routing
system
which
does
both
name
resolution
and
name
based
routing
and
and
and
when
I
say
routing
it's,
it's
an
ndn
concept
of
routing.
So
we're
essentially
allowed
to
protocol,
but
with
you
know
the
bits,
the
indian
bits
to
stop,
you
know
to
do
stop
feedback
and
load
balancing,
etc
or
loops.
C
Is
that
we
kind
of
said
you
know
we
didn't
even
consciously
say
ip
has
reached
its
limits,
but
that
was
kind
of
the
outcome
of
what
we
were
doing.
And
so
you
add
all
this
other.
Then
you
get
all
the
other.
These
other
benefits
of
you
know,
location
based
and
multicast,
and
it's
fully
distributed,
and
then
we
combine
hamey's
work
around
electricity
and
elasticity
and
virtualization
and
and
then
we
came
up-
and
I
remember
when
jamie-
I
don't
know
if
you
remember
when
we
when
we
first
spoke
the
very
first
time
ever.
C
You
asked
me
one
question,
you
said:
do
you
have
a
global
optimizing
system
as
well
as
a
local
optimizing
system?
And
I
said
yes
and
you
said
good,
that's
the
only
thing
that
works
and-
and
I
guess
when
we
when
we
make
our
claims
here
saying
you
know
this
stuff
works
and
it's
very
efficient.
It's
haymi's,
the
guy
who's
kind
of
proved
that
for
us
he's
he's
been
modeling
this
stuff
for
a
very
long
time,
and
we
might
get
him
to
talk
about
that
in
a
second.
C
So,
in
fact,
we
might
do
that
very
soon.
But
but
in
essence,
you
know-
and
this
only
kind
of
dawned
on
us
over
time
is
that
what
was
happening
is
that
that
the
network
is
becoming
the
cloud.
You
know
when
you
take
this
fundamentally
different
approach
and
sort
of
smash.
The
two
things
together,
then,
then
the
network
becomes
the
cloud
and
and
therefore
the
computer,
so
we're
talking
really
about
distributed
cloud
and
and
distributed
computing.
C
So
this
is
what
we
do.
I
won't
go
into
too
much
detail
about
that,
except
it
turns
out
having
modeled
used
jamie's
very
sophisticated
models
that
doing
it.
This
way
is
incredibly
cheaper
and
incredibly
more
efficient
and-
and
when
I
say
incredibly,
I
mean
you
know
up
to
50
but
we'll
get
to
those
numbers
in
a
second
and
and
it
you
push
things
out
to
the
edge
and
of
course
you
improve
latency
significantly
as.
C
Your
back
all
costs,
etc,
etc.
So
it's
very
secure
I
mean
we
were
working
with
hollywood.
We
won't,
even
we
don't
even
say
bittorrent
in
the
presence
of
hollywood.
We
call
it
the
other
protocol,
and
so
we
we
were
secure
from
day
one
and
and
it
just
got
more
secure
with
the
things
that
have
come
along
since
so
so
fundamentally
that
high
value
content
is
encrypted
at
ingest
and
that's
that's
what
makes
it
secure
using
hollywood
approved,
algorithms,
drm,
etc,
but
also
that
you
know
the
name
domain.
C
D
C
H
H
Everything
is
getting
distributed
and
we
have
compute
storage
in
the
network
and-
and
we
need
to
understand
first,
if
you
know,
what's
the
optimal
use
of
available
resources
at
core
edge
and
peer
levels.
So
the
first
work
we
did
is
just
modeling
different
applications
running
over
this
network
and
seeing
really
if
it
makes
sense
where
those
functions
end
up
being
running.
What
is
the
optimal
place
where
they
run?
What
is
the
optimal
place
where
data
gets
stored?
H
So
when
we
start
modeling
these
these
networks,
we
see
that
you
know
if
we
end
up
allowing
you
know
unlimited
if
we
unconstrain
the
use
of
storage
and
computers
at
different
layers.
Where
do
these
applications
and
data
end
up
moving
and
how
much
cost
reduction
reduction
we
can
get
so
the
first
stage
was
just
looking
at
that
and
saying
that
you
know
as
we
move
towards
more
low
latency
obligations
and
even
for
just
content
distribution.
H
Of
course
we
get
a
lot
of
bandwidth
cost
reductions
and
you
start
moving
both
data
and
functions
to
the
edge
so
and
just
for
on
demand
previous
streaming
and
live
video
streaming.
We
end
up
getting
numbers
on
on
around
40
for
network
cost
reduction
that
we,
we
think
is
even
it
can
go
even
greater
when
we
really
go
for
industrial
automation
and
augmented
experience
services
where
we,
you
really
have
that
low
latency
requirement.
H
H
Idea,
of
course,
is
to
exploit
programmability
and
virtualization.
So
as
you,
you
use
virtual
machines
and
you
can
program
the
network
in
between
you.
You
get
additional
cost
reductions
essentially
from
over
provisioning,
so
you
reduce
over
provisioning
because
you're
using
you,
you
have
a
network
that
is
more
elastic
now.
H
Data
and
functions
live
in
the
network,
but
they
consume
virtual
resources,
so
you
can
scale
up
and
down
the
use
of
resources
whenever
you
need
them,
so
you
get
an
extra
20
in
the
simulations
that
we
run
when
you
add
that
elasticity
to
the
optimization
and
then
finally,
we
have
a
stage
where
we
say:
okay,
you
know
if
applications
and
data
really
live
in
the
network.
The
first
thing
you
want
to
do
is
you
have
to
optimize
the
use
of
resources.
H
The
second
thing
is
to
make
sure
that
that
use
is
elastic
and
is
dynamic.
The
next
thing
is
change
and
use
more
efficient
networking
protocols.
So
the
idea
of
the
final
stage
is
using
these
integration
of
name,
resolution,
routing
and
name-based
routing,
so
using
name
resolution
routing
for
distributed
storage
for
persistent
available,
distributed
storage
and
using
name
the
name
based
routing
for
fast
access
and
delivery,
and
we
think
that
integrating
both
system
is
really
the
best
way
to
to
use
the
benefits
of
of
both
worlds.
H
Right
I
mean
they
do
have
limitations
on
their
own
with
name
resolution
routing.
You
know
it's
an
overlay
solution.
You
have
it's
a
slow
system
for
resolution,
but
it's
really
great
for
persistence,
distributed,
storage
and
name-based.
Routing
is
great
for
efficient
delivery,
but
it
has
also
some
limitations
and
the
amount
of
forwarding
state
that
you
can
keep
so
putting
them
together.
We
think
it's
it's
a
great
solution,
so
I
think
that
functionality
and
then
and
then
the
last
aspect-
is
adding
an
element
of
ai.
H
No
still
on
that
same
slide,
which
is
just
in
this
case,
it's
a
modeling
exercise,
but
we
think
that
when
things
get
so
complicated,
when
data
really
leaves
in
the
network-
and
you
have
so
many
options
to
access
data
and
to
run
functions
and
computations,
an
element
of
ai
that
combines
global
optimization
with
local
ai
agents
can
help
just
optimizing.
Both
the
resource
allocation
and
the
routing
and
caching
decisions
in
a
better
way
and
then
yeah,
maybe
red.
Maybe
then.
C
You
join
it
all
up
yeah.
So
so
then,
if
you
once
you
get
to
that
level,
then
then
you
say:
okay!
Well,
if
we
do
that,
you
know
how
does
that
have
to
work,
and
we
very
quickly
got
to
the
point.
Another
colleague
of
ours,
matt,
moran,
who's
very,
very
experienced
at
ott
and
networking
stuff,
and
he
said
you
know
no
one's
going
to
trust
us,
because
if
you
have
a
an
optimizing
ai,
then
you
know
someone
has
to
run
it
and
and
of
course,
that
that's
not
that's
not
going
to
work.
C
C
But
there
isn't
just
one,
you
know
there's
multiples
of
these
and
then
you
have
to
join
them
up
at
a
couple
of
levels
which
we'll
have
some
slides
on
in
a
minute.
In
order
to
to
really
to
to
have
an
ai
api.
I
guess
for
one
of
a
better
word
where
your
your
your
you
know:
sending
stateful
information
in
between
sub
networks
and
and
it
joins
up
into
a
into
a
universal
content
distribution
network,
which
is
this
concept
that
we
have.
C
So
these
guys
were
open
to
that
possibility.
And
when
we
came
along,
you
know,
as
they
said,
you
know,
we're
the
big
fat
pipes
and
you're
the
guys
who
fill
the
pipes
and
we
kind
of
realized.
We
needed
to
do
that.
But
we
didn't
quite
know
how,
and
so
it's
it's
turning
out
to
be
sort
of
a
bit
of
a
marriage
made
in
heaven
and
it
could
get
quite
interesting
in
the
next
very
short
space
of
time.
C
So
that's
a
system
block
diagram
of
merging
the
two
things
together,
which
talks
a
bit
more
about
that.
We
won't
go
into
too
much
detail
about
the
rollout.
It's
global,
we're
doing
africa
first,
we'll,
hopefully
do
australia
very
soon
we're
working
with
these
guys.
So
this
is
a
really
interesting
thing.
C
You
know
these
are
the
people
who
are
building
existing
networks
or
maybe
building
future
networks
in
the
case
of
nvidia,
and
so
we,
I
think,
that's
the
system
block
diagram
out
of
the
patents
which
is
similar
but
different
to
some
of
the
earlier
ones
which
are
more
involved.
This
is
the
one
I
wanted
to
get
to.
You
know
you
say:
okay!
Well,
how
are
we
going
to
do
this
and
it
it
ends
up
being
reasonably
simple.
C
C
You
know,
but
but
at
the
moment
they're
focusing
that
on
corporates-
and
you
know
guys
like
bmw,
you
know
so
that
they
can
have
the
cad
systems
that
design
the
cars
talk
to
the
cad
systems,
that
design
the
factories.
But
we've
talked
to
them
and
said:
have
you
thought
about
pushing
that
out
of
the
network
and
they
said
well
no,
but
that
seems
like
a
pretty
good
idea.
So
we're
having
those
discussions
and
of
course
you
know,
the
essence
of
the
metaverse
is-
is
perfectly
suited
to
this.
C
This
thing
needs
to
be
standardized.
Obviously
you
know
that's
a
huge
thing,
and
these,
as
we
say,
are
the
areas
that
there's
a
nice
set
of
rules
from
tony
parisi,
which
you
know
there's
one
metaverse
it's
open.
It's
in
brackets
are
our
editions.
It's
enabled
by
a
network
that
network
is
the
internet,
and
this
is
how
these
things
roll
out
some
things.
Some
thoughts
for
the
future
you
know
is,
as
I
talked
about,
we
perhaps
need
some
new
funding
and
operational
models
that
sort
of
combine
the
best
of
everything.
C
Clearly,
quantum
computer
is
a
huge
thing
transport,
but
I
don't
know
much
about
this,
but
it
seems
that
lasers
might
be
kind
of
good
for
that.
They're,
certainly
good
for
quantum
key
distribution,
which
the
network
we're
working
with
does
and
then,
of
course
distributed
artificial
intelligence
where
you're
doing
local
training,
perhaps
and
machine
learning
the
concepts
of
plato,
urn
tatrino,
like
you
would
train
at
tamagotchi,
you
you'll
train
an
ai
agent
and
then,
of
course,
the
the
golden
fleece
of
general
artificial
intelligence.
So
these
are
so.
C
These
are
the
guys
who
we're
kind
of
working
with-
and
this
is
this
is
our
claim-
and
this
is
this-
is
my
favorite
saying
at
the
moment.
One
one
day
you
go
to
sleep
and
you're,
the
czar
of
the
whole
of
russia
and
you
wake
up
in
the
morning
and
you're.
Not
so.
Thank
you
very
much
for
the
opportunity
to
talk
and
sorry,
I
think
we're
going
to
fraction
over
time,
but
I'll
kind
of
open
it
up
to
questions.
A
So
this
is
really
quite
intriguing,
so
you,
I
think,
raised
many
interesting
aspects.
There's
also
some
thoughts
that
have
been
discussed
in
this
community
and
also
the
computing
in
the
network
community
a
lot
yeah.
So
we
don't
have
that
much
time.
So
I
think
what
I
would
like
to
do
is
just
ask
people
who
have
questions
to
reach
out
to
you
if
that's
okay,
yep,
because
I
think
there
would
be
many
like
quite
detailed
technical
questions
next,
but
I
think
it
probably
takes
a
long
time
to
answer
those.
A
D
C
A
F
C
D
I
Go
hi,
my
name
is,
I
am
a
classic
researcher
at
the
nist,
but
on
the
nts
this
is
my
personal
project,
so
this
will
reflect
personal
opinions
today,
I'm
talking
about
under
nts
api
design
and
the
nts
is
a
set
of
alien
libraries
for
the
modern
web.
It
is
modern,
javascript
libraries.
It
can
be
used
in
both
typescript
and
javascript
projects.
I
It
works
in
node.js
and
the
browsers
has
more
than
90
percent
of
test
coverage
with
automated
and
manual
browser
testing
on
desktop
android
ios.
It
works
standalone
without
a
forward
or
it
can
connect
to
forwarders
such
as
nfd
and
dnd
pdk.
The
project
is
so
far
actively
maintained.
New
features
are
added
regularly
and
it
supports
the
latest
indian
specification.
I
I
So,
let's
first
get
into
the
low-level
api.
Many
people
would
say
low
level.
Api
is
boring,
and
this
is
probably
true
because
the
indian
team
official
position
is,
we
encourage
application
developers
to
use
high-level
api,
such
as
data
center
toolkit
and
the
common
name
library,
because
those
high-level
api
can
abstract
and
the
uncomplexity
away
from
the
application
developers.
I
However,
my
my
belief
is
interacting
with
low-level
api
is
unavoidable,
because
if
you
try
to
build
a
high
level
api
as
a
library
developer
would
have
to
deal
with
low
level
api
and
also
high
level.
Api
are
unlikely
to
cover
all
possible
apk
needs,
so
sometimes
applications
still
need
to
interact
with
low-level
api.
Therefore,
I
believe
it's
still
important
to
design
a
good
low-level
api
and
the
nts
has
some
unique
opportunities,
because
first
and
dmts
is
not
the
first
library.
I
am
really
the
first
to
implemented
a
particular
feature
in.
I
Instead,
my
preference
is
to
write
some
applications
with
existing
libraries
and
look
at
how
other
developers
are
using
the
library
to
make
applications
as
results.
I
can
feel
the
pain
points
of
existing
library,
especially
which
api
are
cuba,
some
to
use
and
which
code
snippet
have
been
copy
pasted
in
multiple
places
in
the
application,
because
it's
missing
in
the
library
and
then
I
can
improve
those
areas
in
the
nts.
I
The
other
opportunity
is
that
ndnts
is
a
personal
project,
so
I
can
have
the
freedom.
I
don't
need
to
promise
backwards
compatibility.
I
can
take
my
time
to
refactor
the
code
without
worrying
about
the
deadlines,
and
I
can
ask
invited
people
to
watch
my
push
up.
Videos
that
are
delivered
over
the
indian
textbook
then
collect
the
video
playback
metrics
to
improve
my
conjection
control
implementation,
but
back
to
the
apis.
The
first
one
I
mentioned
is
trv
decoding,
but
it's
with
trv
availability
considerations.
I
I
will.
I
will
do
an
example.
The
example
is
the
indian
links,
data
routing,
daemon,
rss
lsa
info
structure.
Is
a
structure?
Look
like
this?
It
has
a
trv
type
number,
a
trv
lens.
It
contains
a
name,
a
sequence
number
and
the
expiration
time
field
sources.
Three
are
sub
t
of
the
elements,
but
it
looks
simple.
Then
we
look
at
the
endian
specifications.
There
is
a
section
called
the
considerations
for
availability
of
trv-based
encoding.
I
That
section
dictates
that
if
the
decoder
encounters
unrecognized
out
of
order
70
of
the
element,
there
is
a
specific
behavior
to
follow,
based
on
the
trv
type
number.
If
the
pov
type
number
is
less
than
32
or
is
all
the
number
the
decoder
must
abort
decoding
and
the
reporter
error.
If
the
trv
type
number
is
even
numbers
and
the
decoder
should
ignore
that
trv
element
and
continue
decoding.
I
So
how
to
write
the
decode
in
the
libraries
and
the
nts
adopts
a
semi-decorative
structure.
So
the
code
looks
like
this:
we,
I
have
a
thing
called
the
ev
decoder
or
evolvability,
aware
trv
decoder
to
use
that
decoder.
You
can
declare
each
sub
trv.
Using
this
add
function,
I
can
add,
with
the
trv
type
and
a
small
lambda
function
of
how
to
handle
the
trb
value
or
how
to
handle
that
sub
trv.
I
The
lambda
function
can
include
actual
logic,
such
as
savings
under
portion
boundary,
which
is
useful
when
I
decode
the
data,
packets
or
decoder
certificate.
But
it's
not
here,
and
here
it's
very
simple
and
then
is
the
evolvability
consideration.
I
mentioned
earlier.
It's
handled
automatically
by
the
ev
decoder
with
ndncxx.
I
I
It
can
be
added,
but
then
it
will
make
make
the
code
even
more
complicated
python.
Dr
so
far
is
a
short
history,
because
it's
using
a
reflection
based
decoder
that
is
purely
decorative
but
python
and
the
answer
decoding
function.
It
is
less
flexible
because
earlier
I
said
that
there
there
could
be
actual
logic
such
as
the
standard
protein
boundary
and
the
python.
I
Ndn
can
also
do
that
either
you
have
to
add
extra
code
and
there's
also
python
dms
decoder
forces
is
a
class
structure
to
follow
the
trv
structure
and
it
means
application
have
to
be
exposed
to
encoding
details.
Sometimes
you
don't
want
that,
but
this
kind
of
reflection
based
decoding-
it's
not
already
possible
in
javascript,
but
I
can
do
something
similar
and
that's
something
I
want
to
explore
in
the
future.
I
Then
so,
then,
the
other
api
is
the
face
that
is
common
in
many
other
libraries,
but
in
the
nts
I
named
it
endpoint.
So
traditionally
phase
is
a
central
concept
of
many
indian
client
libraries,
ec
and
the
ncxx
anders,
and
the
nc
ccl
python
indiana
has
has
it
slightly
different,
but
what
does
face
do
face.
Does
two
things?
One
is
perform
interest
data
matching.
The
other
is
through
the
management,
doing
the
prefix
announcement.
If
your
face
is
normally
correspond
to
a
single
transport.
But
the
face
only
do
this
to
understand.
I
If
you
have
a
circuit
error
in
the
transport,
application
has
to
handle
it
manually
or
if
you
want
to
reach
interest,
re-transmission
data,
signing
data,
verification
data
buffering
with
in-memory
storage,
everything
is
manual
and
the
nts
evolved
the
face
into
a
new
concept
called
endpoint,
which
is
more
powerful.
In
the
end
point
the
consumer
can,
on
the
consumer
side,
the
library
can
provide
automatic
interest,
re-transmission
and
automatic
data
verification
for
the
producer.
I
can
do
prefix
announcement,
data
buffering
and
the
data
sign.
I
You
will
see
some
examples
later
and
each
and
pointer
can
have
more
than
one
more
than
one
transport
uplinks
that
can
connect
to
other
ndnts
applications
to
forwarders,
to
iot
gadgets,
and
any
transport
error
will
be
handled
automatically
if
possible,
having
those
or
in
the
library.
This
allows
the
application
to
focus
on
the
application
logic.
I
So
three
examples:
first,
is
the
consumer's
interest
rate
transmission
in
the
nts.
If
you
want
an
infrastructure
transmission,
you
just
need
to
set
one
option.
So
this
is
how
you
write
a
consumer.
You
prepare
the
interest
and
call
the
consumer
function.
The
data
will
come
back
later,
if
possible,
then
retransmission
can
be
unable
to
say.
I
I
want
up
to
two
retransmissions
and
the
rest
will
be
done
by
the
library
and,
if
reaches
if
after
retransmission
data
still
doesn't
come
back,
because
there
will
be
errors
and
error
handling
is
still
necessary,
but
compared
to
other
libraries,
then
developer
has
to
implement
the
interest
rate
transmission.
Basically
it's
this
flowchart.
They
have
to
implement
manually
and,
as
I
observe
in
the
implementations,
most
developers
get
it
around
in
some
ins
in
some
places
on
the
producer
side
and
the
nts
can
support
automatic
automatic
data
buffering.
I
The
use
case
for
automatic
data
buffering
is
when
the
when
the
producer
wants
to
prepare
a
multi-segment
response
to
one
interest
and
then
weight
and
the
subsequent
segment
will
be
answering
the
later
interest.
A
concrete
example
is
in
the
nfd's
management
of
protocol
data
set
of
publisher.
When
you
can
send
the
interest
to
an
ft,
ask
it
to
return
all
the
revengence,
but
but
the
rib
the
rib
can
be
larger
than
a
single
segment.
Is
there
what
can
be
multiple
segments
and
there
is
a
buffering
needed
in
the
nts?
It's
automatic.
I
I
They
can
be
either
a
fixed
key
or
there
or
a
trust
schema
that
choose
a
key
based
on
the
data
packet
name
for
other
libraries.
Developer
has
to
call
keychain
and
validator
manually
and
all
those
small
things,
but
they
need
a
lot
of
code
called
reputation
and
within
the
nts
you
can
eliminate
the
repeated
code
and,
as
I
mentioned
earlier,
one
of
the
challenges
in
the
nts
is
that
the
coder
size
is
a
primary
concern
on
the
web,
because
every
kilobyte
of
code
must
be
downloaded
over
the
network.
I
Visitors
will
expect
your
webpage
to
load
within
five
seconds.
That
metric
is
called
the
time
to
interactive
and
to
to
download
within
five
seconds
what
you
can
download
as
a
code
size
budget
is
170,
kilobytes
compressed,
so
to
solve
this
problem
in
the
nts.
What
I
can
do
is
I
try
to
reduce
the
core
features
that
are
always
included
in
the
compiled
code,
that,
if
application
needs
extra
features,
they
need
to
import
the
module
and
and
pay
the
overhead,
for
example,
data
buffer
feature
I
mentioned
earlier.
I
It's
its
implementation
so
far
is
quite
complicated
and
has
a
lot
of
code.
Therefore,
by
default
is
not
there,
but
if
you
want
it,
you
have
to
import
those
data
buffers
that
module
write
to
this
code.
It's
a
little
bit
of
boilerplate.
That
is
not
really
desirable,
but
it's
a
trade-off
between
api
simplicity
and
the
web
page
performance
and
the
nts
support
a
lot
of
transport
that
are
is
under
that
and
the
point
layer.
I
So
this
is
a
simple
comparison
chart
and
notably,
I
recently
added
http
3,
which
runs
over
quick
under
through
under
a
proxy
of
a
python
based
proxy
program
and
fd
can
also
support
http
3
transport.
This
allows
me
to
do
video
streaming
more
efficiently
than
using
websocket,
since
the
websocket
has
a
tcp
over
tcp
problem,
but
http
3
runs
runs
over
quick,
which
is
over
udp.
I
I
I
Is
different
but
in
browser
it's
those
two,
and
this
is
how
I
use
the
keychain.
It's
a
it's
some
code,
so
first
I
can
open
the
keychain.
If
effectively
it
will
open
index
db
that
restores
the
keys
and
the
certificates
in
the
browser
index
db
is
able
to
store
web
crypto
private
key
without
exposing
the
key
bits
you
will
see
it
later.
I
I
Then
the
nts
has
a
client
for
the
indian
certificate
management
protocol,
so
I
can
call
request
certificate.
It
will
communicate
with
remote
certificate
authority
and
obtain
a
certificate
after
it
succeeds.
I
can
finally
save
letter
certificate
into
the
kitchen,
but
there
are
a
few
limitations
with
with
web
crypto.
First
web
crypto
requests
a
secret
context
effect.
Convince
a
web
page
must
be
delivered
over
https
to
use
web
crypto.
I
This
is
a
requirement
by
the
web
crypto
specification,
but
not
every
page
is
over
https
because,
as
someone
from
philippines
they
wrote
they
wrote
to
me
in
their
countries.
They
don't
have
a
lot
of
internet
and
locals
are
communicating
over
the
coffee
shop
hot
spots.
In
that
case
they
don't
have
internet,
they
don't
have
dms.
They
have
no
way
to
get
a
certificate
from
let's
equip
encrypt
and
similar
things,
so
in
the
nts
security
feature
will
not
work
in
this
environment.
I
have
not
found
a
solution
to
this.
The
other
is
the
web.
I
Crypto
has
limited
algorithms,
the
crypto
algorithm.
Some
newer
indian
specifications
wanted
certain
crypto
algorithms
that
are
not
in
web
crypto,
so
it
means
I
cannot
really
implement
them.
Yeah.
One
of
them
is
the
flick.
Flicker
says
one
flipper
give
one
option
that
is
aes
ccm
web
crypto
doesn't
have
it.
Of
course
I
can.
If
I
deny
the
application,
I
can
pick
the
other,
which
is
aes
gcm.
That
is
there,
but
if
exiting
application
chose
to
use
aes
ccm
with
flickr,
then
on
the
nts
will
not
be
able
to
interoperate
with
that
application.
I
There
are
some
alternatives
to
web.
Crypto.
First
is
javascript
crypto
library
such
as
asm
crypto.
The
other
option
is,
I
can
compile
rust
crypto
as
a
web
assembly
module,
but
both
has
drawbacks.
First
is
the
code
size
increase
by
at
least
10
kilobytes,
maybe
200
kilobytes
in
the
case
of
certain
asm
crypto
and
the
keys
are
not
protected
anymore.
I
Remember
in
web
crypto,
that
is
non-extractable,
but
if
I
use
javascript
crypt,
it's
not
there
anymore,
since
there
is
also
no
effective
way
to
cleanse
memory,
and
if
the
code
is
delivered
over
plain
http,
it's
even
worse.
The
first
is
the
main
in
the
middle
attack,
since
it's
not
encrypted
https
anymore,
and
also
there
is
no
secret
random
number
generator.
It
basically
means
I
cannot
generate
private
key
safely
so
so
far
and
the
nts
is
still
limited
to
web
crypt.
Only
I'm
not
sure
whether
I
want
to
relax
it,
but
currently
no.
I
The
last
issue
is
not
really
api,
but
it's
closely
related,
which
is
how
do
you
name
a
browser
because
name
is
a
secret
source
of
india,
as
alex
said
for
the
enormous
users,
it's
somewhat
simple.
So
this
is
the
code
I
show
earlier,
where
generator
assigning
key.
I
need
to
give
it
a
name,
so
my
current
web
applications.
They
only
serve
anonymous
users.
I
If
I
want
any
user
authentication,
it's
a
different
challenge.
User
experience
is
important.
So
what
to
use
the
most
familiar
with
is
either
username
plus
password
or
email
me
a
magic
link
internally,
it
can
be
implemented
as
obtaining
a
short-lived
certificate
from
a
certificate
authority
that
is
controlled
by
the
web
web
server.
I
Then
we
can
also
try
to
port
open
id
os
web
or
send
those
specs,
but
to
do
it
over
and
yeah.
It
will
internally,
it
will
interact
with
nd
authenticator
app
that
the
user
could
download
or
sell
for
host
on
their
own
server
and
inside
the
center.
App
should
contain
a
as
certificate
authorities
that
are
controlled
by
the
user,
but
in
either
case
we
should
have
a
streamlined
user
experience,
because
visitors
do
not
care
whether
the
web
page
is
using
on
dns.
They
just
care
about
the
body
experience.
I
A
I
If
you
trust,
because
it
fails,
the
transport
will
get
reconnected
automatically.
Since
there
is
in
most
cases
there
will
be
event
emitters.
You
can
hook
into
the
transporter
to
find
out
it's
up
or
down,
but
every
transport
will
try
to
reconnect
indefinitely
following
exponential
backup.
Oh
okay,
there
are
some
transporter.
You
can
notice
the
web
bluetooth.
You
cannot.
If
your
gadgets
is
offline,
this
browser
don't
allow
you
to
reconnect.
A
A
I
A
A
And
you
also
pointed
to
how
would
you
name
the
browser-
and
you
know,
provide
something
like
an
endpoint
or
something
reachable
name
to
the
web
application,
and
I
think
these
are
really
interesting
questions
and
I
think
it's
really
ongoing
work
and
and
needs
niche
further
thoughts.
So,
thanks
again
for
introducing
this
to
us.
A
A
Okay,
yeah
thanks
again
everybody
for
presenting
your
work
and
for
attending
the
meeting
I
think
was
quite
interesting
and
I
think
many
presentations
today
would
probably
lead
to
further
discussions.
Let's
do
that
on
the
main
list
or
reach
out
to
the
individuals
here,
just
some
some
thoughts
by
dave
and
myself
about
next
meetings.
A
A
So,
let's
really
keep
offering
us
crossed
that
travel
will
be
possible
then
so
you
can
expect
the
coffee
papers
and
other
infos
fairly
soon
and
with
that
yeah
thanks
again
for
attending
wish
you
a
really
nice
holiday
season
and
let's
be
in
touch
looking
forward
to
further
discussions
with
you.
Thank
you.