►
From YouTube: IETF97-LWIG-20161117-1110
Description
LWIG meeting session at IETF97
2016/11/17 1110
B
B
Okay,
thank
you
rock
with
it
a
jabber,
scrubber
I'm,
because
on
the
meet
a
co,
who
can
you
know
forward?
Christine,
Xander,
yeah,
okay,
Thank,
You,
Jean,
ok,
I
will
hand
over
the
blue
sheet,
it's
very
important
in
Sidon,
so
we
can
start.
We
have
updated
milestones.
So
basically
you
can
check
the
many
nice
and
the
chartered
text
on
that
we
do
have.
We
do
have
a
lot
of
walking
anthem
that
fail
to
have
come
out
with
the
walking
of
last
call
because
of
the
lake
of
the
views,
but
we
are
anyway.
We
are.
B
B
So
here
is
the
agenda
today,
so
basically
we
have
their
first
talk
from
the
carlos
on
tcp
/
constrained
notice
has
bigger
a
draft
I
think
this
is
second
version
of
these
drops.
We
have
some
discussion
today
because
suppose
they
are
witnessed.
The
home
of
these
two
draft
and
the
second
Hawk
is
from,
is
a
update.
B
We
prefer
more
heat
on
the
light
when
immigration
experience
of
the
crypto
on
sensors
and
the
sir
talk
is
from
Rahu
chedva
Jeff,
a
which
is
a
relevant
topic,
but
there's
not
a
no
mapping
draft
yet,
but
at
the
issues,
as
that
will
be
discussed
today,
will
be
relevant
to
the
implementation
guidance
gear.
So
that's
why
we
have
a
small
feel
any
question
to
the
agenda.
C
C
However,
in
Berlin
itself,
we
got
this
confirmation
that
L
week
would
be
the
working
group
for
the
draft,
and
we
submitted
an
initial
00
version
of
the
draft,
including
a
week
in
the
name
of
the
file
which,
however,
didn't
include
any
other
modifications
and
all
the
actual
updates
that
we
have
applied
are
in
in
version
01.
By
the
way,
these
updates
try
to
address
most
of
the
comments
that
appeared
after
the
initial
publication
of
that
draft
and
I'd
like
to
thank
everyone
for
the
great
feedback
that
we
got.
C
C
C
Also
exempt
EP
is
used
in
some
IOT
scenarios
and,
for
example,
MQTT
is
a
non
IETF
application
layer
protocol,
which
is,
however
popular
and
all
of
these
protocols,
are
using
TCP.
So,
while
TCP
have
been
little
bit
neglected
or
even
criticized
regarding
it's
possible
use
in
IOT
scenarios,
we
have
that
it's
actually
being
or
will
be
used
in
many
IOT
scenarios.
So
the
purpose
of
this
document
is
to
offer
simple
measures
for
suitable
TCP
implementation
and
operation
over
constraint,
node
networks.
C
So
let's
go
through
the
updates
in
version
01.
First
of
all,
our
C
2119
language
has
been
removed.
So
the
idea
is
that
the
purpose
of
the
document
is
to
explain
how
TCP
can
be
used
in
constrained
networks.
So
what
we
are
not
trying
to
do
is
something
like
proposing
a
new
TCP
variant
in
the
introduction.
C
Xmpp
has
been
added
to
the
list
of
application
layer
protocols
used
in
CNN's,
which
are
using
TCP,
then
in
in
section
2,
which
shows
the
characteristics
of
CNN's
which
are
relevant
for
TCP.
One
detail
has
been
added,
which
is
the
fact
that
often
the
link
layers
which
are
used
in
this
kind
of
scenarios
are
offering
low
transmission
rates.
This
can
be
roughly
categorized
as
typically
below
one
minute
per
second.
This
is
relevant
in
the
fact
that
this
gives
the
idea
that
throughput
is
typically
not
the
main
concern
in
this
kind
of
scenarios.
C
We
have
to
traverse
a
middle
box
which
may
be
in
between
the
constraint
device
and
the
unconstrained
device.
This
kind
of
scenario
is
symmetric
in
several
aspects.
First
of
all,
there's
the
obvious
difference
in
terms
of
resource
availability
in
comparing
constrained
and
unconstrained
devices
and,
on
the
other
hand,
assuming
that
the
majority
of
constrained
devices
will
probably
be
sensors,
then
the
amount
of
data
sent
by
the
constrained
devices
is
probably
going
to
be
greater
than
the
amount
of
data
received
by
these
constrained
devices.
C
Then
section
4
provides
the
recommendations
and
guidance
on
tcp
/,
this
kind
of
scenarios.
We
have
added
a
subsection
for
that
one,
which
explains
that
typically,
the
TCP
connection
would
be
initiated
by
the
constrained
device.
This
is
in
order
to
better
support
the
energy
conservation
techniques
by
the
constraint
device.
C
Then
in
Subsection
for
the
two,
we
have
the
text
that
discusses
about
the
maximum
segment
size
and
we
have
other
text
explaining
that
if
there's
a
lean
layer
which
offers
a
not
so
constrain
MTU,
so,
for
example,
an
empty
or
greater
than
280
bytes,
it's
still
good
to
set
the
MSS
so
that
the
ipv6
Datagram
size
does
not
exceed
the
twelve
hundred
and
eighty
bite
threshold.
So
the
idea
here
is
to
avoid
issues
with
internet
links
which
might
not
have
an
MTU
greater
than
280
bytes.
C
C
Then
in
Subsection,
for
that,
for
this
focuses
on
the
retransmission
time
out
here.
Well,
we
have
actually
kind
of
a
question
because
we
would
like
to
to
recommend
the
use
of
an
alternative,
RTO
estimation
algorithm.
So
the
idea
would
be
to
use
something
different
from
what
is
the
actual
RTO
scheme
used
in
in
TCP,
which
is
defined
in
RFC
62
98.
C
We
have
some
experience
with
cocoa,
which
is
the
an
adaptive
congestion
control
algorithm,
which
is
now
a
working
group
document
in
the
core
working
group,
and
this
has
been
designed
specifically
considering
some
of
the
characteristics
found
in
constraint,
node
networks,
and
we
believe
that
we
have
some
evidence
that
this
is
working
better.
Then
approaches
based
on
62
98.
C
So
here
we
have
a
question
which
I
don't
know
when
or
where
should
this
actually
be
resolved,
but
we'd
like
to
to
find
out
how
to
proceed
because
the
use
of
cocoa
is
actually
conflicting
with
several
TCP
specifications
with
several
masts,
such
as,
for
instance,
RFC,
62,
98,
and
also
in
cocoa?
We
are
using
weaker
titties,
so
this
is
in
conflict
with
the
current
algorithm.
So
this
is
something
that
will
need
to
find
out
how
to
proceed.
C
Then
about
the
TCP
connection,
lifetime
in
Subsection
followed
5.
We
have
restructured
a
little
bit
the
section
and
we
have
added
subsection
here.
So
the
main
idea
was
that,
in
order
to
minimize
the
overhead
in
the
communication,
the
best
the
ideal
situation
would
be
to
have
permanently
open,
tcp
connection
between
the
two
TCP
endpoints.
C
However,
this
is
probably
not
going
to
be
feasible,
considering
that
often
will
have
middleboxes
such
as
firewalls,
which
may
perform
deletion
of
filter
state
records-
let's
say
early
earlier
than
expected,
and
this
might
lead
to
breaking
participe
connection.
So,
in
addition,
we
have
the
TCP
keep.
Alives
are
probably
not
going
to
be
useful
to
solve
this
issue
since
the
default
timeout
for
the
tip
life
is
two
hours
and
it
cannot
be
lower
than
that.
C
So
possible
approaches
rely
on
having
application,
layer,
heartbeat
messages
and
then
there's
another
approach,
which
was
suggested
by
a
vision
on
the
list,
which
is
the
use
of
TCP
first
open.
The
idea
here
would
be
ok.
If
we
have
a
middle
box
which
is
creating
these
problems,
then
okay,
we
can
try
to
initiate
a
new
connection.
C
That
is
that,
for
security
reasons,
a
cookie
must
be
obtained
by
the
device
which
is
going
to
initiate
the
connection,
and
this
cookie,
which
may
have
4
or
16
bytes,
has
to
be
included
them
in
sin
segments
and
also
it
has
to
be
refreshed
from
time
to
time.
So
here
we
should
try
to
compare
what
is
better
to
use
TCP
first
open,
even
if
we
have
the
cookie
and
it
has
to
be
refreshed
or
to
open
a
new
connection.
C
Then
in
Subsection
for
that
seven
we've
discussed
TCP
options
and
the
text
has
been
modified.
A
little
now
explain
that
for
single
MSS
for
devices
that
use
a
single
MSS
receive
or
transmit
window
the
IDS
not
to
support
Windows
scale,
TCP
times
thumbs
and
sac
or
sac
permitted,
and
to
ignore
these
options.
C
If
it
received,
however,
for
less
constrained
devices,
for
example
with
more
memory
allowing
for
a
greater
window,
then
it
is
that
selective
acknowledgement
may
be
positive,
may
be
good,
since
they
can
avoid
necessary
retries
and
they
may
allow
reducing
latency
band
with
an
energy
consumption.
We
have
to
take
into
account
that
we
are
dealing
with
lossy
scenarios
and
therefore
sack
selective
acknowledgments
may
be
useful
here.
C
We
have
added
a
new
subsection
which
discusses
delayed
acknowledgments.
The
idea
is
that,
on
the
one
hand,
a
device
that
advertises
a
single
MSS
receive
window
actually
needs
to
avoid
supporting
delayed
acknowledgments
in
order
to
avoid
contributing
some
extra
delay
to
the
rtt.
This
additional
delay
might
be
up
to
500
milliseconds
and
in
general,
delay
that
knowledge
months
would
not
be
really
recommended
in
constrain,
not
networks,
since
traffic
is
mostly
of
transactional
type,
with
a
transaction
size,
often
below
or
maybe
in
the
order
of
the
MSS.
C
C
C
Finally,
we
have
added
an
annex
to
the
document.
The
purpose
here
is
to
document
which
other
characteristics
of
existing
TCP
implementations
for
constrained
devices,
so
we
have
subsections
for
micra
p
for
lightweight
IP
and
a
placeholder
for
riot,
and
for
the
moment
we
have
an
overview
for
my
crappy
and
lightweight
IP.
So
for
the
first
one,
my
cry
p
is
a
tcp/ip
implementation
intended
for
8
and
16-bit
CPUs,
with
a
code
size
around
five
kilobytes,
which
comprises
checksum
in
IPS,
MP
and
TCP,
and
here
there's
a
global
single
packet
size
buffer
for
incoming
packets.
E
Shadow
from
hobby,
so
can
you
please
yeah
so
you
mentioned
know
before
out
doing
data.
So
I
think
I
would
have
to
contradict
here,
because
I
feel
there
are
two
buffers
used
in
you
IP
as
compared
to
one
buffer
in
UDP,
for
you,
IP
tcp.
So
the
reason
being
that
you
cannot
really
application
doesn't
have
any
control
over
the
sequence,
numbers
or
emesis
values
at
the
TCP
layer,
so
it
has
to
keep
the
buffer
and
that
buffer
is
kept
in
to
you
IP
connection
structure,
yeah.
C
E
Quantity
to
dirt
sex
there
was
a
single
buffer
used
for
incoming,
as
well
as
outgoing
data,
the
IP
above,
but
at
the
same
time
quantity,
2,
dot,
7
introduced
another
a
you
happy
connection
on
/
socket
basis,
then
I
introduce
another
buffer
because
there
was
no
way
possible,
for
you
know:
application
to
maintain
the
sequence
number
and
a
message
by
it.
So,
okay
yeah.
So
thanks.
C
For
the
common-
and
definitely
we
have
to
be
careful
and
address
these
subsequent
revisions,
so
yeah
so
for
lightweight
IP.
This
is
a
tcp/ip
implementation,
also
for
8
and
16-bit
CPUs.
However,
this
is
not
so
constrained.
Actually,
the
code
size
is
greater
depending
on
the
platform
it
could
be
between
14
and
22
kilobytes
out
of
which
the
tcp
code
size
is
between
9
and
14
kilobyte.
C
So
here
we
have
a
buffering
of
incoming
and
outgoing
data,
so
applications
don't
have
to
well
can
be
decoupled
from
the
network
stack
and
a
transmission
window
greater
than
a
single
segment
is
supported
and
functions
such
as
slowstar
congestion
avoidance
funds,
fast
retransmit
and
fast
recovery
are
also
supported.
Also,
we
have
some
issue
here
about
possibly
the
versions
of
the
implementation,
because
in
some
older
version
of
lightweight
ap,
selective
acknowledgement
and
windows
scale
are
not
implemented.
However,
in
a
more
recent
version,
these
are
supported,
as
mentioned,
for
instance,
by
the
chair
on
the
list.
C
Well,
I
think
we,
it
depends,
for
instance,
in
riot,
which
is
texted
this
to
be
provided
in
subsequent
versions.
I
know
there
has
been
an
implementation
which
is
really
using
the
single
window
single
MSS
window,
so
it
depends
I,
understand
that,
possibly
for
subsequent
versions
of
the
draft,
it
would
be
good
to
try
to
determine
which
recommendations
would
be
more
suitable,
for
instance,
for
+1
devices,
which
might
be
better
for
class
devices
and
so
on
so
I
think.
Possibly
we
can
try
to
do
this
this
exercise
and
instead,
instead
of
providing
this
broad
rough.
C
C
D
C
D
H
I
D
So
description
again
so
lie
ma.
If
this
document
gets
adopted
here,
I
would
really
like
to
run
the
working
of
glass
calls
on
both
the
group's
doesn't
make
sense
so,
like
you
know,
you
won't
have
any
sink
for
a
little
bit
right,
but
when
the
document
the,
when
the
voting
group
feels
the
document
is
ready,
we
gonna
bring
it
back
to
TC
p.m.
to
check
if
everything
still
okay.
Okay,
thank.
B
You
yes,
I
think
we
have
the
Nullah
example
that
we
can
then
from
4
p-7.
There
is
a
TCP
queuing
for
the
HTTP
working
go
for
HTTP
draft,
which
is
actually
handled
and
in
the
HTTP
piece
working
group,
but
actually
asking
the
NASCAR
is
also
handling
on
both
working
groups.
So
I
think
we
have
a
pre
experience
on
that,
so
we
can
just
follow
the
examples
there.
B
J
So
I
I
did
present
this
draft
in
in
Berlin,
but
just
for
the
benefit
of
those
of
you
who
are
not
there
I'll
very
briefly
and
quickly
go
through
what
what
the
draft
is
all
about.
So
our
goal
for
this
work
was
to
see
how
hard
it
is
to
do
public
key
cryptography
on
very
small
devices.
So
we
wanted
to
see
three
things
so
as
as
a
developer,
what
kind
of
libraries
I
have
are
they
easily
available?
Is
there
some
open
source
libraries
available
are
and
so
on?
Then,
then?
J
The
next
goal
was
how
hard
it
is
to
actually
use
them.
So
how
much
hacking
does
it
require
from
from
me
as
a
developer
and
and
once
that
is
done,
it's
up
and
running
what
kind
of
performance
can
I
get
so
what
kind
of
performance
numbers
can
I
expect
from
from
these
libraries?
So
for
all
the
work
that
we
did,
we
used
arduino
mega
bored.
It
has
a
atmel
2560
processor,
so
it's
8-bit
processor
has
about
8
kilobytes
of
RAM
in
total,
so
yeah.
J
So
the
first
thing
that
we
did
was
see
the
performance
of
RSA
and
and
no
surprises
there
for
smaller
key
sizes.
You
were
able
to
get
reasonable
performance,
but
for
anything
for
four
biggest
key
sizes,
the
performance
was,
was
undies
undesirably
slow,
so
you
you
wouldn't
probably
use
that
and
it
took
quite
a
while
and
a
lot
of
memory
to
to
do
RSA
for
reasonable
a
key
size
that
you
would
use
so
something
like
2048,
which
is
what
is
recommended.
J
The
execution
time
was
so
large
that
probably
you
won't
want
to
use
it
in
in
any
real
scenario,
and
then
we
found
for
libraries
that
the
elliptic
curve
cryptography.
In
particular,
we
looked
at
elliptic
curve,
digital
signature,
algorithm
and
again
no
surprises
here.
Elliptic
curves
perform
much
faster
than
RSA
use.
Smaller
key
sizes,
smaller
signatures,
and
one
interesting
thing
to
note-
was
that
if
you
really,
you
know,
get
down
to
implementing
things
on
these
small
devices,
you
can
actually
do
a
lot
of
thing.
J
So,
for
example,
for
one
of
the
curves,
some
of
the
math
was
implemented
in
assembly.
There
was
for
that
8-bit
microprocessor
and
you
were
able
to
do
signature
hash
the
message
and
sign
it
within
2
61
milliseconds,
which
for
many
IOT
devices
to
61
milliseconds,
is
reasonable
performance,
and
this
was
within
33
thousand
bytes
of
RAM.
So
you
can
get
reasonable
performance
even
even
on
the
small,
smallest
devices.
J
J
So
the
reason
why
we
wanted
to
do
it
was
we
wanted
to
build
an
example
application
where
you
wake
up
once
in
a
while
and
send
a
signed
update
to
the
proxy.
So,
instead
of
instead
of
this
sensor,
device
acting
as
a
server,
the
sensor
device
actually
sends
a
signed
update
to
the
proxy
and
any
client
that
is
interested
in
the
data
will
go
and
then
fetch
it
from
from
the
mirror
proxy
and
you
would
still
get
end-to-end
data,
authenticity
and
integrity.
J
So
we
implemented
this
whole
application
on
the
same
platform,
and
here
are
some
number
so
implementing
co-op
implementing
all
the
crypto
implementing
all
the
UDP.
Everything
was
less
than
five
thousand
bytes
and
yeah
I
mean
we
didn't
really
try
to
optimize
the
flash
memory
consumption,
but
if
you
want
to,
you
could
probably
get
rid
of
lot
of
lines
of
code
even
even
there.
J
So
what
we
learned
well,
the
first
thing
was
that
we
chose
this
platform
was
on
purpose.
It
was
unnecessarily
restrictive.
So
what
we
wanted
to
show
was
that
if
you
can
do
it
on
a
8-bit
device,
you
can
for
surely
do
it
much
more
easily
on
a
16-bit
and
a
32-bit
microprocessor,
and
just
because
of
economies
of
scale.
Probably
you
would
use
a
32-bit
processor
because
they
are
actually
cheaper
than
then
they'd
wit
devices
these
days.
J
Then
the
draft
has
like
lot
of
details
on
feasibility
of
public
key
crypto.
How
do
you
do
message?
Freshness
if
the
sensor
only
wakes
up
once
in
a
while
and
cents
cents,
a
message
sign
message:
how
do
you
protect
against
replay
attacks?
So
how
do
you
still
use
sequence,
numbers
or
timestamps,
and
things
like
that,
especially
in
this
unidirectional
communication?
J
There's
discussion
on
a
symmetric,
key
verses,
asymmetric
crypto
and
whether
you
do
krypton
Link
Network,
transport
or
application
layer
and
what
are
the
trade-offs
and
whether
you
do
it
on
one
of
the
layers
or
all
of
the
layers?
And
how
does
it
combined
so
I
I
won't
go
into
the
details
but
come
to
what
has
changed
since
the
last
version.
So
in
the
ITF
in
Berlin
we
had
a
working
group
reduction
call
in
the
group
and
there
was
interest-
and
this
was
later
confirmed
on
the
mailing
list.
J
I
got
a
lot
of
feedback
boats
on
the
mailing
list
and
off
the
mailing
lists
out:
Thank
Akbar
Rahul
Daniels
John,
a
vegan
friends,
Owen
endre,
one
big
reference
was
to
this
DTLS
group
keys
and
we
have
removed
that
reference.
So
there
was
a
mistake
on
our
part
from
the
author,
so
that
reference
is
it's
removed.
There
was
a
ton
of
editorial
suggestions,
so
we
have
fixed
that
also.
J
We
refer
to
the
mirror
proxy
draft
and
it
would
probably
make
sense
to
update
it
with
the
pub
sub
broker
draft
so
that
that
we
would
do
then
another
comment
we
got
was:
we
show
a
lot
of
numbers
for
four
key
sizes
that
are
not
necessarily
secure,
and
that
is
just
done
to
give
you
a
perspective
or
more
of
a
reference.
So
at
no
point
do
we
recommend
using
anything,
that's
not
secure
and
we
already
do
state
that,
but
we
will
state
that
even
more
explicitly
so
don't
use
smaller
key
sizes.
J
K
Yeah
custom
Owen
we're
seeing
all
these
faster
cpus
but
I
think
one
one
other
interesting
thing
that
has
been
happening
in
the
last
couple
of
years
or
three
years
is:
we
are
seeing
much
lower
power
radios,
so
I'm
not
sure
that
the
the
conventional
wisdom,
which
was
avoid
radio
usage
at
any
cost.
You
can
use
a
lot
of
computation
for
that,
whether
that
isn't
actually
shifting
back
a
little
bit.
So
I
think
it
would
be
nice
to
have
some
some
more
more
current
numbers
on
this.
K
J
J
K
K
J
B
B
E
Rahul
shadow
from
Huawei
and
the
presentation
is
about
neighbor
management
policies.
No,
there
has
been
some
discussion
that
happened
on
mailing
lists
on
roll
mailing
lists.
As
soon
you
know
if
the
node
density
is
higher,
how
do
you
control
the
neighbor
cache
or
the
neighbor
neighbor
table?
So
what
this
presentation
describes
is
how
is
it
handled
currently
in
different
open
sources?
Some
literature
analysis,
as
in
what
does
the
literature
say
and
what
we
eventually
ended
up
doing
in
one
of
our
practical
deployments.
E
So
the
challenge
is
that
the
network
size
can
be
huge
and
even
though
the
network
size
is
ug,
there
is
some
control
over
the
maximum
number
of
devices
that
can
be
connected
in
the
network
or
can
be
attached
in
the
network,
but
there
is
absolutely
no
control
over
the
maximum
density.
The
node
density
varies
from
deployment
to
deployment.
E
If
you,
if
you
keep
a
neighbor
cache
of
30
entries
well,
if
the
neighbor
node
density
is
100,
then
it's
going
to
overflow
for
sure
in
that
case,
which
are
the
best
entries
to
evict
now,
that
is
the
decision
that
an
n
play
and
implementation
has
to
take.
Now
there
is
one
sample
policy
that
we
have
described
in
this
presentation,
so
some
of
the
current
neighbor
management
techniques
or
policies
that
are
followed,
for
example,
by
quantity,
Quantic,
uses
least
eviction
policy
of
removing
the
least
recently
used
entry.
E
So
the
the
biggest
problem
with
this
is,
you
will
get
or
you
might
get
route
that
route
down
time,
so
the
traffic
will
be
impacted
if
the
node
density
is
higher
than
the
neighbor
cache
size
riot
riot.
Does
it
on
first
come
first
serve
basis.
The
problem
with
this
approach
is
typically
in
a
in
a
wireless
network.
E
You
have
diu
storm
now
for
the
sake
of
this
presentation,
I
am
going
to
make
use
of
our
pure
ripple
oriented
network
or
ripple
based
near
routing
protocol
and
a
key
management
protocol
also,
so
we
take
a
holistic
approach
towards
solving
this
neighbor
management
protocol
ec.
So
what
is
the
expectation
of
the
neighbor
management
policy
eventually,
so
it's
expected
that
yeah,
you
will
end
up
in
a
suboptimal,
behavior
or
sub
optimal
performance,
but
it
should
be.
There
should
be
some
deterministic
way
of
you
know
allowing
all
the
routes
to
be
established
in
the
network.
E
So
some
of
the
literature
literature
analysis
that
I
did
so
most
of
the
literature
talks
about
the
link,
estimation
techniques.
So
how
do
you
compare
the
link
quality
of
two
neighbors
and
then
prioritize
one
neighbor
over
other
other,
but
in
case
of
dense
deployment?
This
will
seldom
come
into
picture
because
the
well,
the
network
is
dense.
All
the
neighbors
are
close
to
each
other,
so
the
signal
quality
is
going
to
be
good
anyways.
So
it's
not
only
about
the
link
estimation
per
say
here,
but
also
about
prioritizing
the
neighbors.
E
So
we
try
to
take
a
holistic
approach
here.
We
tried
neighbor
management
policy
in
context
to
a
ripple
based
network
plus
the
panna
based
k,
authentic
key
management
protocol.
So
so,
essentially
we
we
used
expand
our
mechanism
for
key
management
which
is
used
by
wisin,
so
the
deployment
the
deployment
that
we
have
targeted
is
a
mi
network
here
so
cases
now,
usually
the
neighbor,
the
neighbor
cache
table
is
populated
using
neighbor
discovery
mechanisms
such
as
NS
any,
but
in
case
of
constraint,
networks
most
likely
this.
E
E
The
first
case
in
which
the
neighbor
table
update
happens
is
while
pyaari
selection
is
been
done
by
PSC,
so
PA
c-span,
a
client
p
re
is
the
panera
laylamon.
So
there
are
different
names
to
this.
I
just
came
from
60
and
nanima
working
group
meetings
and
they
call
it
join.
J,
ay
and
GCE
join
assistance
and
assistant
and
join
coordination
element,
so
join
coordination
element
essentially,
is
this.
This
is
the
j
j.
A
join
assistant
and
I
will
element
as
it
is
called
here,
and
this
is
the
panic
line,
the
new
joining
node.
E
So
these
are
the
cases
in
which
the
neighbor
table
updates
here.
So
there
is
an
example
table
given
over
here
for
n
3,
so
it
has
four
entries,
so
two
entries,
n1
and
n2
are
ripple.
Parents
and
five
is
the
ripple
direct
child.
Now
this
distinguishing
is
this.
It
is
very
important
to
distinguish
this
fact
that
it's
a
direct
child,
because
only
the
neighbor
entry
for
the
direct
child
is
stored,
so
through
an
five
and
six
and
seven
are,
are
going
to
throw
n
three.
E
But
these
entries
and
six
and
seven
of
course,
are
not
their
own
n
three,
so
NY
is
the
direct
child
for
n
3
and
the
state
for
pack
or
the
connect
land
is
authentication
in
progress.
So
this
relay
element
at
any
point
of
time
does
not
know
the
state
at
which
the
authentication
signaling
is
it,
so
it
does
not
know
whether
the
authentication
is
completed.
Is
it
in?
Is
it
in?
Isn't
it
access
phase
or
join
face?
It's
not
aware
of
that
at
all.
E
So
the
insertion,
so
what
are
the
different
neighbor
management
operations
that
have
to
be
done?
Insertion
eviction
and
reinforcement
so
insertion?
How
do
you
insert
the
simple
logic
of
the
table?
Space
is
available.
You
insert
the
neighbor
entry
now.
Well,
that's
that's
that's
going
to
cause
problems
in
case
where
repulse
di
strong
is
going
to
is
going
to
cause
all
the
neighbor
table
entries
to
get
full
parent
selection
procedure
may
result
in
case
of
ripple.
The
parent
selection
procedure
may
result
in
the
same
parent,
been
selected
by
all
the
child
nodes.
E
So,
in
which
case
all
the
Dow's
will
go
through
the
same
parent.
So
there
is
another
problem
there.
Similarly,
the
neighborhood
discovery,
the
PRI
discoveries
of
the
pap
and
I
element
is
covering
me
result
in
the
same
PRI
been
made
use
of
by
all
all
the
pana
clients
for
eviction
they
the
issue.
One
of
the
biggest
issue
with
the
eviction
is
a
routing
child
direct
child.
It
is
difficult
to
evicted
because
there
might
be
dependent
child
based
on
the
routing
direct
charge
for.
E
In
the
previous
slide,
we
saw
that
if
enfa
is
evicted,
it
has
direct
impact
on
n,
6
and
n
7
as
well.
So
it's
very
difficult
to
edit
such
a
such
a
neighbor
evicting
non-preferred
parent
information
is
usually
possible
without
much
immediate
implications.
So
this
is
this
is
one
of
the
key
point
that
is
highlighted
here
is
that
it
is
possible
to
evict
a
non-preferred
pattern.
E
For
example,
now
one
can
have
it
the
least
effective
parent
entry
from
neighbor
table
the
third.
The
third
part
is
reinforcement,
so
you
have
the
link
estimation,
but
you
have
to
keep
updating
it.
So
whenever
you
get
a
message,
you
have
to
keep
updating
the
estimation,
the
quality
parameters
so
yeah,
so
it's
it
can
be
done
based
on
whenever
you
get
the
next
di
message
or
any
traffic
packet
from
from
the
neighbor.
E
The
other
thing
is:
how
do
you?
How
do
you
take
back
the
neighbor
table
entries?
So
how
do
you
clear
the
neighbor
table
entries
so
one
of
the
problem
is
there.
The
routing
invalidation
is
very
important
because
if
the
routes
are
still
throughout,
the
steel,
droughts
may
cause
major
problems
with
the
neighbor
table
entries
the
pyaari
neighbors.
Now
I've
mentioned
this
already
that
the
P
re
neighbors,
the
P
re
by
itself
is
stateless.
E
E
Now
some
of
the
recommendations
that
we
have
done-
or
you
know
some
of
the
observations
that
we
had-
is
it's
better-
that
to
reserve
route,
make
a
reservation
for
routing
direct
charts
and
4p
re-authentication
signal
no
now
this
is
the
most
easiest
approach
that
can
be
followed.
A
reservation
policy,
but
the
best
part
here
is
if
these
entries
are
not
occupied,
the
are
tripled.
E
There
are
some
mechanisms
in
ripple
already
introduced
already
present
to
reject
the
routing
direct
child
dowse.
So
if
it
now
is
sent
from
a
direct
child,
then
you
can
reject
it
using
a
knack.
Similarly,
for
panic
line
the
result
or
that
there
are
ways
to
reject
the
neighboring
entry
by
using
a
result,
code
AVP.
E
E
So
what
is
the
impact
of
neighbor?
This
neighbor
table
management
policy,
so
so
we
had
so
we'll
if
we
don't
assume
that
there
is
any
restriction
on
the
neighbor
table
size.
Ideally,
we
might
get
this
network,
but
if,
with
neighbor
with
assuming
that
the
max
neighbor
table
entries
are
three,
you
will
end
up
getting
this
sort
of
network
now.
I
E
E
L
E
So
the
idea
why
I
presented
this
peep,
it
is
yeah
to
check
if
there
is
already
any
work
being
done
in
this
context.
You
know
okay,
yeah
and
if
necessary,
then
I
would
work
on
the
draft
so
basically
I.
There
are
already
implementation
if
there
is
any
other
implementation
available
which
solves
a
problem
in
a
different
way.
I
I
think
we.
L
Should
have
a
draft,
then
I,
don't
think
I
think
it
may
be
very
welcome
in
ripple
as
enroll.
Can
you
go
back
a
couple
slides
sure
I
just
had
a
couple
of
questions.
Understanding
your
your
analysis.
Go
back.
Sorry,
couple
more
more
more
of
the
diagram
that
one
one
who
does
n
3
did
you?
Are
you
thinking
that
n
3
was
in
radio
distance
of
n,
6
and
n
seven,
so
it
might
have
heard
them,
but
that
they
didn't
pick
it
as
a
parent,
but
no.
L
But
but
I'm
saying
a
and
6
and
n
seven
could
well
have
heard
a
DI
Oh
from
n
3,
but
the
DAO
from
n5
was
much
better
link
quality,
so
they
picked
it
yes,
right,
well,
yeah,
and
so,
and
also
in
a
storing
network.
At
least
n
3
would
know
that
n,
6
and
n
seven
are
attached
to
that
direct
child
and
so
could
bump
the
priority
of
keeping
that
direct
child.
You
you're
saying
we
always
want
to
keep
direct
child
anyway,
but
that
the
number
of
things
below
there
could
also
ranked
the
direct
child's.
L
If
you
ever
found
that
you
have
to
do
it
to
push
direct
children
out,
okay,
which
would
be
terrible
to
do.
But
you
know
it
might
cause
the
network
to
rebalance
yeah.
Okay,
if
you
did
that,
but
but
that
would
tell
you
how
bad
it
was
in
terms
of
the
different
things
non,
storing
load.
We
have
no
idea
yeah.
L
Then
you
know
gets
the
other
part
of
the
key,
so
it
actually
will
hear
when
that
thing
is
things
it's
going
to
have
a
new
key.
If
not,
if
it's
not
pana
right,
then
the
Keith,
then
to
one
of
two
things
will
happen:
either
the
new
node
will
negotiate
a
key
using
I,
don't
know
mesh
link,
exchange
or
59
or
something
so
actually
it
would
know
that
there's
a
the
new
node
has
now
established
a
key
and
is
no
longer
indicating
okay,
yeah.
L
So
does
it
separate
signaling
there's
other
clues
in
there?
What
I'm
saying
is
other
clues
in
there
that
can
feed
that
right.
What's
going
on,
and
the
key
thing
is
that
the
neighbor
table
has
some
other
pieces
that
there
and
but
very
clearly
you
mean
it
needs
to
reserve
a
slaughter
to
for
authentication
right,
but
it
also
needs
to
limit
in
how
many
it's
willing
to
spend
because
that
it's
a
denial
service.
That's.
L
E
E
Is
some
information
available?
Yes,
that
can
be
made
use
of
you,
that's
very
good,
so
there
are
some
limitations
to
this
policy.
You
know
that
I
have
not
mentioned
in
this
presentation,
but
there
are
limitations
to
this
policy.
You
know
it
in
certain
cases.
Certain
nodes
may
not
be
able
to
join
the
network
ever
so.
For
example,
if
a
new
node
comes
up
over
here,
let's
say
an
N
seven
node
comes
up
over
here
and
it
tries
to
attach
to
the
border
outer
border.
Router
has
only
three
neighbor
table
entries.
E
E
So
the
only
eviction
that
can
be
done
is
for
the
parent
nodes,
but,
as
Michael
mentioned,
you
know,
evicting
a
direct
child
will
have
a
ripple
effect.
You
know
eventually,
all
the
other.
It
will
result
in
complete
the
complete
load
or
the
subdue
dag
getting
rebalanced.
So
that
is
something
which
has
to
be
avoided,
because
it
will
result
in
a
larger
control
over.
E
In
you,
you
know
what
yeah,
let's
I
in
this
case,
maybe
in
some
cases
border
router,
has
a
larger
memory,
not
in
not
necessarily
in
all
the
cases.
For
example,
in
my
case
and
the
the
pilot
program
that
I
am
working
on
the
border
router,
the
platform
used
here
is
exactly
same
as
any
of
the
other
node.
It
has
the
same
ax,
so
it
just
has
a
USB
connectivity
to
linux
here
or
or
some
other
platform
here,
but
this
platform
remains
the
same
as
these
platter,
but
yeah
this
depends
upon
deployment
to
deployment.
You
know.