►
From YouTube: IETF103-6LO-20181105-1610
Description
6LO meeting session at IETF103
2018/11/05 1610
https://datatracker.ietf.org/meeting/103/proceedings/
A
So
before
we
start
I'd
like
to
ask
for
a
minute
taker,
we
have
a
jabber
scribe
already
Thank
You
Rahul,
wherever
you
are
hopefully
you're
there
out
somewhere,
but
we
do
need
a
minute
taker.
So
there
anybody
who
couldn't
take
the
minutes
and
again
what
we
need
is
not
detailed
notes.
What
we
need
are
just
the
action
items
that's
more
than
enough,
so
anybody
can
volunteer
for
that.
A
A
A
A
The
agenda
for
today
we
have
some
updates
from
the
chairs
and
we're
gonna
have
a
series
of
updates
from
Pascal
on
the
6lowpan
nd
document,
basically
down
the
isg
review,
then
we're
gonna
have
updates
on
a
P
and
D
document
and
on
the
fragment,
forwarding
document
as
well
in
fragment,
recovery
from
us
got
a
bit
and
finally,
also
from
Pascal
backbone.
Router
preparing
for
working
group
last
call
we're
gonna.
Have
then
a
ad
review
comments
or
looking
at
those
four
NFC
NFC
document.
A
Similarly,
working
group
last
call
comments
for
the
packet
delivery
deadline.
Bye,
charlie.
Then
we
could
have
an
update
on
the
PLC
document
and,
finally,
a
performance
report.
Some
very
interesting
results
from
on
the
fragment
forwarding
graphs
by
Rahul
and
to
finish
it
off.
We
have
catalyst
with
an
update
on
the
ble
mesh.
There's
some
good
news
in
the
ble
mesh
implementation
front.
A
The
draft
status
we
have
6775
update,
which
is
really
really
close
and
we'll
hear
more
about
that
and
backbone.
Router
is
getting
ready
for
working
bless.
Call
a
PMD
is
in
progress,
NFC
is
progressing,
it
was
a
little
is
G.
We
have
some
baby
review
stuff
to
look
over
updates.
As
we
said
on
ble
mesh,
the
use
cases
document
just
issued
working
group
last
call
so
that
will
be
on
for
another
two
weeks.
This
is
the
the
applicability
document
or
use
cases,
as
you
may
have
known
it.
A
Please
send
your
comments
on
that
document,
even
if
it's
just
to
say
it
looks
good
and
even
if
it's
no,
if
it's
not
detailed,
so
please
do
that
and
that
will
run
for
two
weeks
and
finally,
the
deadline.
The
deadline,
time
document
is
as
bits.
Various
you
review
will
see
some
comments
now,
Suresh.
Is
there
anything
yeah.
B
A
The
fragmentation
side
of
things
the
design
team
was
concluded
some
time
ago
and
now
we're
just
having
the
to
result
in
documents
progressing
as
usual.
We
have
the
minimal
fragment
and
the
fragment
recovery
and
we'll
see
some
update
on
that
today
and
finally
and
I
believe
Suresh
already
just
sent
an
email
to
the
mailing
list,
but
both
Samantha
and
myself
will
be
stepping
down
and
after
this
IDF
I,
maybe
even
replaceable
before
the
next
IDF
summit.
I
think
for
sure
so
Suresh
might
have
some
words
of
wisdom
here
on
how
to
handle
the
overlap.
Yeah.
B
And
thank
you
very
much
Gabe
and
some
it
a
like
for
all.
You
have
done
like
I
really
enjoyed
working
with
you
on
this
and
I
hope.
You
can
continue
to
work
here
and
I
really
appreciate
all
the
work
you've
done
here
and
personally.
I
want
to
start
bringing
in
at
least
another
chair
in
very
soon
so
they'll
be
a
transition
and
I
don't
mind
going
with
three
chairs
for
a
bit
and
then
like
eventually
like
transition
like
you
or
summat
outright
like,
but
so
I
don't
mind
putting
as
many
chairs
as
needed.
B
To
make
sure
this
happens
and
if
anybody's
interested
come
talk
to
me
and
I
can
brief
you
on
what's
required,
like
what
is
the
status
of
the
documents
and
everything,
so
it
shouldn't
be
like
too
time-consuming
unless
the
work
starts.
Picking
up
again,
so
right
now,
like
it's
kind
of
manageable
at
this
point,
but
like
there's
like
bursts
of
work
here
so
like
sometimes,
you
might
get
like
daily
or
run
by
so
just
come.
Talk
to
me,
oh
thank
you.
Yeah.
A
D
B
D
B
D
D
D
E
D
Then
the
fryer
show
me
give
me
that
the
message
every
trendiest,
the
okay
for
him,
the
first
one-
is
decisions
with
the
full
issue.
If
there
was
t
us
about
the
use,
Oh
mi,
you
acts
actually
in
this
document
of
the
mi
us
is
most
I
have
a
most
to
use
must
be
used,
but
I
just
put
the
issue.
The
key
word
in
the
document
just
changing
the
the
key
word
to
shoot
to
the
most
and
the
next
one
is
the
section
eight
of
a
photo
a.
D
D
Extension
I
know,
I
feel
for
NFC
use,
f,
ru,
t
fourth
mi
you
as
a
defined
it
F,
RFC
49:44,
and
this
one
is
the
section
for
the
three.
This
is
about
the
to
increase.
The
randomness
of
Tito
general
generate
iid,
actually
did
natural
ID
in
the
function.
The
is
from
the
RFC,
the
71
3
636.
Actually,
these
NATO
IDs
the
planet
is
ocean
optional,
so
I
just
mentioned
about
this
net
net
ID
in
the
varieties
the
the
function
can
provide
secured
and
the
stable
IIT
from
NFC
enabled
device
the
add.
D
In
addition,
an
optional
parameter
network
ID
may
be
used
to
increase
the
when
the
news
of
the
general
generate
ID
like
this,
and
this
one
is
section
4.5.
This
is
about
the
explanation.
The
6vr
behavior
of
NFC
device
actually
section
force
of
five
just
mention
about
the
details
of
the
behavior
by
Ln,
but
so
he
want
me
to
put
the
behavior
of
the
six
a
all
and
air.
We
are
it
when
the
NFC
device
became
becomes
the
Theron
area.
D
So
to
put
the
last
bullet
there,
the
vendor
and
honest
device
became
becomes
that
sixty
Lawrence's
or
six.
The
NFC
device
must
followed
the
section
six
seven
of
out
of
six
six,
seven
seven
five,
and
this
one
is
the
last
one.
Actually
this
is
the
worst
scenario.
There's
no.
He
said
to
me:
there's
no
any
technical
explanation
about
these
tools
to
connect
with
he's
so
I.
D
Just
put
two:
let
pass
to
the
past
they're
just
for
so
nice
about
the
NFC,
enabled
device
connected
to
internet
scenario
and
topology
just
put
there
just
I
just
mentioned
about
something
technical,
for
example
the
others
collision
of
neatly
there,
and
this
one
is
the
isolated,
NFC
device
network.
This
Authority
I
just
put
the
technical
fail.
F
F
F
F
Have
extended
the
didactic
message
so
as
to
carry
this
bigger
Rover
field,
which
is
this
extension
of
the
unique
ID?
So
this
is
the
core
of
6725
update
and
the
news
is
we've
gone
through
the
ANS
tapes,
so
we
were
happy
with
IANA
with
disambiguated
the
code
with
the
RFC
editor.
So
now
the
the
text
with
the
RFC
editor.
So
now
we
are
in
the
RFC
edit
of
States
spoke
text
cleanup
hand
and
we
were
waiting
for
the
earth
48,
which
is
hopefully
coming
soon,
meaning
that
we'll
have
an
erection
number,
hopefully
before
Christmas.
F
If
we
behave
but
but
we
we
did
one
pass
with
the
other
cities
already,
so
we
behaved
so
far
yeah.
So
that's
it.
The
two
other
drafts
are
very
active.
The
first
one
is
address
protection.
So,
like
I
said
this
one
does
two
important
thing.
The
first
thing
is
you're
free
to
form
under
tries
any
arise,
doesn't
have
to
be
looked
looking
like
a
CGI,
but
since
you
have
this
registration
mechanism,
you
register
it
with
a
crypto
token,
which
ensures
that
nobody
else
can
later
claim
an
address
that
you
formed.
F
So
the
address
is
yours:
as
long
as
you
maintain
the
registration
active,
nobody
can
come
and
claim
that
same
address
over
six
lap
and
MD.
The
second
thing
is
you
need
to
declare
your
authorized
to
the
six
hour.
If
you
start
using
an
address
that
you
did
not
declare
on
very
day
to
the
six
zero,
then
the
six
alarm
may
actually
destroy
your
packets
to
ensure
that
you're
not
issuing
traffic
on
behalf
of
somebody
else
and
attacking
that
guy
by
faking
traffic.
F
You
can
see
that
as
if
it
was
a
public
key,
it's
a
hash
of
it,
but
it's
it's
kind
of
a
public
key
and
if
the
6r
doesn't
have
a
registration
for
you
or
does
trust
that
you
own,
that
the
descriptor
talk
and
then
you
can
challenge
you
with
the
notes
classical
challenge
based
on
the
private
key
and
these
nouns
and
announce
that
you
also
form
so
the
nonce
on
DNA
it
announced
on
ENS
now
are
different.
We
have
to
announce
s,
we
can
actually
the
six
around
will
sign
this.
F
With
this
you
prove
ownership
of
the
crypto
target
if
the
first
registration
ever
for
this
advice
was
done
with
that
critter
token,
it
proves
that
it
was
you
the
owner
of
this
address,
so
the
6a9
is
happy
with
that
can
can
recompute
exactly
based
on
the
CIPO.
It
can
recompute
that
this
is
actually
what
was
used
to
to
sign
this
nd
PSO
and
invalidate
the
enero
from
there.
F
You
register
with
that
Cicero,
so
you
can
register
with
multiple
six
hours
and
the
first
time
you
register
well
well,
when
you
register
to
a
six
allah,
it
will
go
to
a
6
lb
l
validate
that
the
registration
already
exists
at
the
6
MB
era.
If
it
does,
then
it
has
to
be
the
semi
arrow,
but
the
6
LVL
doesn't
validated
the
crypto
token
only
the
six
RR
does.
So
if
we
are
in
a
mesh
case,
which
is
not
a
Wi-Fi
case,
but
mesh
case,
the
6
Allah
can
be
separated
from
a
6
lb.
F
Are
the
validation
is
done
by
the
6
law?
Not
the
6
appear,
so
there
needs
to
be
a
trance
big
notice.
If
there
are
the
same
box
like
a
Wi-Fi
AP
and
then
obviously,
this
prong
does
not
exist.
So
recent
changes
is
we
finally
got
her
next
trick
in
others
expert
on
security
to
join
us
as
a
contributor
later
and
based
on
his
help.
We
actually
change
a
few
things,
so
one
thing
we
rolled
back
is
the
show
2:56.
We
had
this
trick.
F
F
So
we
said:
okay,
too
bad,
let's
use
512,
which
means
that
if
you
have
an
implementation
that
uses
both
the
default
NIST
curve
and
and
the
additional
it's
a
DSA
curve,
you
will
need
to
implement
two
different
hash
functions,
one
five
to
fifty
six
and
one
five.
Twelve,
that's
that's
life,
so
that
these
are
the
biggest
change.
So
now
we
are
kind
of
confident
that
we
have
the
security
level,
wrote
it
in
this
draft.
So
it's
going
to
be
very
close
to
last
call
time.
F
F
F
So
I
already
mentioned
it's
the
six
allowed
the
six
MBR
if
they
are
separated,
since
the
600
is
the
only
one
doing
the
validation.
The
six
MBR
must
trust
that
the
six
arrow
is
doing
the
right
thing.
So
we
still
have
this
possibility
that
a
rogue
6rr
could
eject
addresses
on
behalf
of
the
non-existent
six
round.
So
that
needs
to
be
something
which
is
outside
of
this
protocol
to
establish
a
strong
trust
between
the
six
around
six
MBO.
F
So
if
we
don't
have
this
trust,
then
that
could
be
a
need
following
the
same
kind
of
challenge
all
the
way
from
the
sixth
year,
so
it
would
really
validate
that
whatever
the
six
are
our
size
is
actually
true.
Should
it
be
done
in
this
document?
We
don't
think
so,
should
it
be
done
in
repo,
if
you
have
record
of
the
way
where
I
do
think
so
so
I
propose
that
to
to
roll
this
morning.
F
If
you
have
a
ripple
Network
there,
could
we
cascade
the
trust
chain
all
the
way
to
the
6ln,
using
a
method
that
chooses
the
rover
and
probably
I
will
propose
that
to
to
roll
soon
in
a
6
lb.
R
is
the
same
as
the
sixes
six
at
the
roll
root,
then
that
that
will
give
you
the
same
property
as
if
the
6
lb
I
was
challenged
anyway,
and
that's
what
I
also
mean
by
can
decrypt
ID
be
used
by
watching
protocol?
F
Now
we
allow
for
rava
field
that
is
more
than
2
64
bits.
Like
I
said
we
have
to
have
to
get
a
good
degree
of
security
now,
should
we
actually
have
stronger
words
for
this
kind
of
recommend
not
to
be
as
small
as
64
again,
if
you
have
a
feeling
about
this,
it's
a
good
time
to
go
to
the
mic
and
say
oops.
Don't
use
64,
use
larger.
F
Second
question
to
the
group
and
please
come
to
the
mic.
If
you
think
that
it's
three
too
costly
to
have
to
implement
both
shout
256
and
sha-512
on
a
single
device,
and
you
think
that
you
need
to
support
both
curves
come
to
us
and
and
go
fight
that
fight
at
the
security
area,
to
make
an
update
of
1832
to
support
for
256
as
well.
I
thought
it
could
be
trivial
and
the
more
he
told
me
it's
not
that
trivial.
F
F
Okay,
do
you
have
an
RFC
which
size
how
to
be
able
to
use
a
certain
curve
with
a
certain
sha,
because
I
understand,
family
2
is
the
expert
or
if
it's
one
a
that
each
time
you
want
to
use
a
different
sha
with
a
different
curve.
You
need,
you
need
an
RC
which
puts
those
two
together.
So
if
you
have
an
RFC
that
actually
builds
that
nicely
right
now
we
just
have
one
optional
crypto.
We
could
have
a
second
optional
crypto
very
easily
for
us,
it's
just
to
mention.
F
F
F
And
now,
if
you,
if
we
have
more
our
C's
with
more
bits,
we're
setting
the
other
bits,
you
can
have
more
curves,
it's
just
that
right
now
there
was
no
nobody
expressing
the
need
for
a
little
curve
or
different
shara
whatever
so
the
beat
is
both
a
hash
plus
a
curve
right.
His
book,
the
crypto,
a
dashing
and
and
yes,
we
have
more
bits.
Free
anything
kills
I.
F
F
That's
when
all
this
crypto
ID
parameter
option
comes
into
play,
which
lists
all
the
parameters
that
are
used
to
to
build
the
signature
which
is
in
dntps,
oh,
so
those
parameters
include
announced
which
is
coming
from
the
device,
the
nonce
that
was
coming
from
the
six
an
hour
around
I.
Don't
worry
about
what
but
number
of
things,
and
this
is
all
side
with
the
private
key
that
was
used
to
build
this
crypto
a
well
that
corresponds
to
the
public
key
that
was
used
to
build
a
critter
ID
right.
F
So
you
with
a
public
key
which
is
actually
inside
those
people.
You
actually
validate
that
you
can
build
this
crypto
ID
and
then
you
validate
the
signature
in
the
ndpa
so
that
signs
the
cipa.
That's
how
you
make
the
connection
between
the
script
ID
and
everything
that
is
being
claimed
here,
including
the
crypto
ID,
which
is
sure,
does
the
thing
say
sign
here:
the
nonce
the
nodes.
So
you
have
you,
have
this
tight
chain
of
security
so.
F
No
all
the
information,
because
six
alan
is
free
to
phoned
to
any
six
and
is
free
to
attach
to
a
six
or
six
and
is
freed
from
any
form
of
address.
Privacy
is
recommended,
but
you
can
form
any
address.
It's
completely
independent
to
the
crypto
ID,
and
none
of
that
has
to
be
pre-programmed
into
the
six
or
off.
The
only
thing
is
the
six
around
must
have
enough
CPU
to
get
to
do
all
those
computation,
validation
and
needs
to
have
enough
neighbor
countries.
F
So
you
can
also
reject
DNS
if
he
cannot
start
in
navigation
tree,
but
it
can't-
and
it
just
needs
for
the
CPU
to
validate
the
sipo
and
the
signature.
And
then
you
can
forget
all
this,
because
once
it
has
formed
the
neighbor
country,
the
only
thing
you
need
to
keep
is
the
crypto
ID
and
the
6n.
That
goes
with
it
right
that
Jonker
makaras
interface
Younker,
which
is
what
goes
naturally
in
the
indicators,
indication
20.
A
You
know
and
we
got
renee-
that's
that's
great,
yes,
helps
which
helps
a
lot.
But
the
fact
is,
this
is
a
very,
very
quick
kinds
of
document.
I
was
wondering
if
it
wouldn't
be
up
that
idea
to
just
stand
and
sag,
for
example,
in
the
side
meeting
and
presented,
because
they
might
have
feedback
that
we
haven't
thought
about.
I
think
there
are
the
edge
persons
in
the
security
area,
open
group
or
something
like
that.
So.
A
B
Krishna,
so
one
thing
gave
this
right
like
we
can
ask
for
early
sector
review
for
that
right
and
that
kind
of
instead
of
presenting,
because
they're
gonna
say
like
hell.
What's
this
6lowpan
and
6lo
and
stuff
like
that,
so
I
think
it
might
be
good
to
just
push
the
early
review
button.
So
I
can
talk
to
the
ISA
cádiz
and
you
tell
me
whenever,
like
it's
ready
to
go
like
and
I
can
push
a
button
for
a
early
SEC
review.
What
I'm
hearing
is
it's
almost
ready
for
working
the
blast
columns
there
I
mean.
B
F
B
I'll
get
it
done
right
away
and
I'll
talk
to
the
SEC
ADEs
to
make
sure
that
it
it's
seen,
because
it's
gonna
get
sick
review
anyway,
right
like
when
it
goes
to
like
ITF
last
call
and
before
it
hits
is
G.
But
if
there's
like
something,
we
can
avoid
like
earlier
I,
don't
mind
doing
that
too.
Yeah.
B
F
Still
it's
a
public
key
private
key
exchange,
but
the
operation
that
we
described
here
is
is
really
really
classical
right.
You
you
get
announced
you
sign
it
with
your
private
key,
a
that's
nice
as
usual,
so
I
don't
expect
much
surprise.
The
one
thing
to
remember
is
that
the
six
LPR
doesn't
get
to
validate
this
excel
only
the
six
along,
because
otherwise
we
did
the
flow
all
the
way
from
the
six
NBR
and
we
have
not
designed
that
flow.
So
we
have
that
trust.
F
That
is
not
specifying
this
document
well
by
the
six
he'll
be
are
really
trust
at
the
six
are
is
not
compromised,
which
is
only
a
promise
you
have
a
match.
This
is
why
I
want
to
to
actually
recursively
close
that
gap
using
the
reader
routing
protocol
in
between
all
the
way
to
a
6
lb
are
so
I
will
have
a
proposal
to
repo
to
actually
do
that.
F
So
you
will
trust
the
dowels
as
they
flow,
but
I
don't
see
once
we
get
that
it's
it'll
be
I
will
have
the
trust
from
ripple
and
part
of
what
we
do
in
role
is
actually
to
avoid.
Having
both
6lowpan
and
row
do
the
same.
Signaling
like
this
guy
keeps
updating
role
that
it's
present
and
you
at
the
same
time.
F
Usually,
you
should
normally
have
to
eight
or
six
MBA
I'm,
still
there
as
well
to
refresh
a
lifetime
where
we
condense
this
too,
and
for
the
same
reason,
we'd
like
to
condense,
the
security,
so
that,
if
the
chain
of
trust
is
actually
done
within
repo,
we
can
go
all
the
way
to
the
six
lbr
without
being
without
having
l6
allowed
to
see
cell,
be
a
communication
doing
the
exact
same
thing.
My.
A
Feeling
about
this
is
the
document,
what
I
think
of
these
particles
and
end
to
it
solving
the
entire
thing.
This
trust
between
600
and
CTR
is
essential
for
this
to
work.
If
that's
not
encompass,
appalled
or
definable
within
this
document
within
six
level,
maybe
that
means
it
should
be
in
enroll,
I
mean
if,
for
all,
is
no
way
to
solve
a
role.
A
F
So
I
don't
think
there
is
words
to
do
exactly
that,
so
we
can
add
them,
and
you
help
believe
that
appreciate
it.
I
think.
The
worlds
that
we
have
in
the
Security
section
is
that
we
are
creating
a
boundary
of
trust
at
the
6ro,
meaning
that
we
protect
this
network
from
you
know
the
leaves
which
are
not
part
of
the
ripple
Network
and
not
necessarily
trusted,
but
we
still
expect
that
the
ripple
network
itself
is
kind
of
protected.
F
This
is
true,
if
you
have
like
your
keys
and
all-
and
there
is
no
compromising
right,
because
the
others
when
you
have
this
ripple
Network
like
your
ECG
mesh
or
rice
and
network
like
for
your
electricity,
then
they
will
protect
all
the
way
to
the
metals.
But
if
you
decide
to
attach
a
washing
machine
to
the
matter
using
6lowpan,
you
don't
want
a
washing
machine
to
inject
anything
in
in
wrong
right
in
repo.
F
You
could
build
this
trust
because
each
time
you
go
and
challenge
all
the
way
to
a
six,
and
we
need
to
build
that
in
repo,
but
we
could
mention
it
here,
but
right
now.
The
assumption
for
this
draft
is
yes,
we
are
just
building
this,
this
layer
of
this
boundary
for
the
report
that
work.
While
we
establish
this
trust,
but
we
think
that
the
whole
ripple
Network
or
whatever
watching
protocol
you
are
using
because
this
is
agnostic
to
ripple
is-
is
trusted.
F
So
that's
written
in
the
Security
section
that
we
we
need
this
trust
inside
the
network,
but
we
are
not
saying
that
we
are
willing
to
work
in
role
to
do
it
because
that's
just
winning
I,
don't
know
how
far
I
mean
you
have
to
work.
That
correctly
will
be
appreciated
because
I
don't
know
exactly
how
to
world
that.
We
want
to
do
something
more,
but
it's
certainly
a
tool
that
we
need
to
go
over
all
the
wines
that
ripple.
F
Okay,
yeah
and
so
the
news
yes
like
I,
said
I.
Think
I'm
through
this
and
the
last
of
this
free
Trust
is
the
backbone
router.
So
this
one
okay,
remember,
the
CRC
6775
is
like
a
Wi-Fi
Association
write.
The
second
draft
is
like
making
it
secure.
Oh
so
nobody
can
steal
your
Wi-Fi
MAC
address
equivalent,
so
this
MAC
address
belongs
to
these
guides.
They
are
nowhere
else.
The
third
thing
that
you
need
to
have
the
equivalent
of
layer.
F
2
operation
is
the
proxy
operation
between
the
Ethernet
side,
which
is
doing
normal
and
D,
and
this
registration,
and
so
that's
what
the
backbone
router
is.
It's
one
of
those
quote,
unquote
fronting
protocols
that
can
consume
the
6lowpan
registration
and
turn
it
into
something
else.
So
we
already
know
repo,
which
turns
with
the
ripple
unaware
leaf.
We
turn
the
67
75
into
a
ripple
packet
into
a
Dao.
We
have
rift
which
turns
that
into
a
TI
e,
and
now
we
have
the
backbone
router,
which
turns
that
into
a
proxy
and
the
operation.
F
F
Okay,
well
can
we
still
call
last
time
we
said
we
would
call
for
workgroup
last
time
you
improve
the
dog
by
reshuffling
it
you
did
not
reach
changed
any
semantics
in
there.
It's
just
that.
It's
only
it's
a
lot
more
readable
if
it
was
almost
right
for
Lesko
I
think
we
are
still
right
for
let's
go
so
I
thought
that
you
thought
differently
now,
you're
neutral,
so
I
would
say
we
are
where
we
were
last
time
so
ready
for.
Let's
go
now.
F
F
G
H
H
H
Intermediate
routing
points
to
have
delay,
aware
forwarding
and
scheduling
decisions
in
particular
if
the
deadlines
passed,
it's
a
good
idea
to
possibly
drop
the
packet
and
just
not
waste
any
more
bandwidth
on
it.
So
if
you
that,
since
you
are
trying
to
many
decisions
based
on
particular
deadline
time,
it
does
already
essentially
apply
the
requirement
a
time-synchronized
Network,
and
since
you
already,
whose
this
thing
isgetting
card
hold
on
a
minute
I
said
it
was
drooping.
A
H
Of
the
comms
house
that
is
routing
into
so
the
draft
has
been
discussed
many
times
during
night.
If
we
had
a
few
revisions
for
the
individual
draft
and
it
was
adopted
as
a
working
group
document,
three
IETF
Seco
and
then
we
had
a
revision
based
on
a
lot
of
editorial
Corrections
in
suggestions
from
the
reviewers
and
then
recently
there
hasn't
been
very
much
done
to
it
and
would
keep
looking
at
it
and
I.
Think
it's
pretty
much
ready
for
her
last
call.
I
H
You
for
those
reviews
very
helpful
and
here's
the
updates
that
have
been
made.
We
we
had
in
the
document
some
description
about
the
6lo
RHA
and
we
just
replaced
that
by
reference
to
the
published
document
and
put
in
a
figure
to
illustrate
the
change
to
the
origination
time
when
you
cross
to
a
different
time
zone,
because
if
you
want
to
have
an
accurate
view
of
the
origination
time,
it
really
needs
to
be
done
in
the
time
zone.
According
to
the
time
in
the
time
zone,
where
the
track
track,
the
packet
is
traveling.
H
H
Working
group
and
it's
progressing
nicely,
but
anyway
it's
just
an
example:
it's
not
normative
on
this
draft.
There
was
a
question
from
one
of
the
reviewers
that
when
is
the
origination
time
and
so
from
the
point
of
view
of
the
application
there.
What
matters
about
the
packet
traveling
over
the
network
is
how
long
it
takes
since
the
application
essentially
tried
to
transmit
the
packet
or
requested
the
packet
to
be
transmitted.
H
Is
in
queued
for
transmission
so
that
essentially
made
that
very
specific,
and
then
we
included
just
mentioned
a
couple
of
other
sources
for
why
packet
might
be
delayed,
and
then
there
was
some
discussion
about,
but
we
have
this
if
a
packet
really
could
supposed
to
be
drawn.
But
if
you
set
the
BT
bit
to
be
0,
then
you
can
still
forward
it.
But
why
would
you
want
to
do
that?
Well,
you
wouldn't
want
to
forward
it.
H
E
H
You
have
a
reason,
then
it's
it's
not
actually
a
protocol
violation
to
forward
the
packet
if
the
deep
it
is
set
to
0
and
then
finally,
we
just
upgraded
the
bibliographic
citations
for
the
mesh
and
my
son,
so
I've
gone.
You
think
you've
seen
the
packet
format
quite
many
times,
just
just
to
mention
that
the
times
are
actually
represented
in
somewhat
of
a
compressed
format.
That
shows
the
time
units
here.
H
One
of
these
four
possibilities
are
actually
one
of
these
three
possibilities,
and
then
they
exponent
to
allow
you
to
have
a
very
wide
range
of
possible
deadline.
Time,
specifications
and
the
same
thing
is
true
for
both
the
resonation
time
and
the
deadline
time.
Those
who
use
the
same
scheme
basically
so
that
allows
compression
of
the
numeric
format
and
that's
about
it
I'd
be
happy
to
answer
questions
I,
don't
think.
There's
any
remaining
issues
on
the
draft
at
all,
and
yes,
we'd
like
to
see
it
move
forward.
B
J
Hello,
everyone.
So
currently
we
have
arrived
at
the
fifth
version
of
this
draft,
so
the
we
have
done
some
revisions
based
on
the
comments
that
we
have
received
during
the
last
ITF
in
trail
and
on
the
meeting
list.
So
there
was
concern
raised
during
their
last
ITF.
It
was
about
privacy
issue
in
56,
address
auto-configuration
for
PLC
devices.
J
So
in
the
last
version,
one
of
the
options
to
config
the
ipv6
address
for
POC
devices
is
by
combining
IP,
prefix
and
I
did
raped
by
the
UI
addresses.
But
if
we
use
the
such
kind
of
address
to
communicate
ways
the
public
network
there
were
me,
there
may
be
some
privacy
issues
because
it
could
be
recognized
what
kind
of
device
it
is
and
who
is
its
manufacturer
and
what
kind
of
traffic
headaches.
So
in
this
version
we
have
added
some
limitation
to
such
kind
of
addresses.
J
The
UI
to
drift
IP
address
can
only
be
used
following
a
local
purpose
and
it
not
should
be
should
not
be
used
for
a
communication
with
the
public
network.
So
the
section
the
second
issue
was
raised
on
the
mailing
list.
It
is
about
the
terminology.
As
you
know,
in
this
draft
we
have
covered
three
different
POC
technologies
and
in
the
last
version
the
terminology
was
not
by
our
lines.
So
in
different
sections
we
have,
we
have
been
using
the
terminology
from
different
POC
technologies
together,
so
it
may
create
some
obstacles
for
readers.
J
J
J
The
packet
into
different
sizes,
according
to
the
the
channel
condition,
but
it
there's
nothing
related
to
what
we
do
in
the
deputation
layer,
whether
the
fragmentation
is
required
in
the
adaptation
layer
depends
only
on
MTU
that
there
are
two
spots
so
in
in
this
latest
version.
We
have
added
some
clarifications
to
to
help
people
understand
the
situation
situation,
so
we
have
done
other
modifications
as
a
space
talents
comments
on
the
meeting
list
and
hopefully,
we'll
have
to
make
this
craft
more
clear
and
more
comprehensive.
J
So
for
the
next
step,
I
think
we
will.
We
would
like
to
call
for
working
group
adoption
because
currently
exact
the
the
power
grid
really
are
scenarios
more
and
more
IP
based
applications
are
communicating
via
PLC
devices.
It
should
be
a
better
to
have
a
guideline
for
PLC
ipv6
adaptation.
So,
looking
forward
to
your
first
comments,
questions.
A
A
K
L
Hello,
everyone
Bravo
Jadhav,
so
this
is
the
presentation
is
about
the
fragment,
forwarding
performance.
So
there
are
two
darts
that
have
been
that
that
have
been
added
to
6lowpan
Word
documents,
which
is
the
fragment,
forwarding
and
the
fragment
recovery.
So
this
there
is
another
competing
work
or
the
similar
similar
work,
that's
happening
in
Elle.
We
guess
also.
So
we
were
highly
excited
about
the
prospect
of
using
fragment
forwarding
because
we
had
some
specific
use
case.
Basically
in
our
networks
for
the
authentication,
the
fragments
are
mostly
for
our
fragmented.
L
If,
if
the
fragmentation
frog
forward
from
fragmentation
forwarding
can
help
us,
it
could
essentially
mean
we
could
decrease
the
network
convergence
time,
so
that
was
our
primary
motivation.
So
briefly,
let
me
just
explain
what
the
fragment
forwarding
is
all
about.
So
this
is
the
traditional
609
4
4
mechanism
of
per
hop
reassembly.
You
you
receive
fragments,
you
reassemble
at
the
next
stop
and
then
yuri
fragment
and
then
send
it
up
upstream.
L
A
L
The
animation
it
works
for
mesh
under
my
show,
oh
yeah,
so
this
this
this.
The
important
thing
here
is
that
all
this
is
happening
on
top
of
mesh
over
or
router
networks
in
in
mesh
under
this
already
happens,
the
same
way
like
you,
you
you,
you
have
a
similar
mechanism
or
invention
tour
already.
It
already
does
fragment
forwarding,
but
I'll
I'll
come
to
that
point
in
the
later
slides.
What
happens
there?
So,
a
with
regards
to
fragment,
forwarding
what
we
are
trying
to
do
is
we.
The
fragment
train
is
forwarded.
L
There
is
no
reassembly
happening
on
the
intermediate
routers
and
the
fragments
of
our
data
as
it
is.
There
is
a
table
that
has
to
be
maintained
here
which
contains
information
such
as
tag,
sequence,
iid
and
the
timer
as
well,
because
at
some
point
of
time,
if
the
fragments
all
the
fragments
do
not
arrive,
the
the
corresponding
entry
has
to
be
removed.
So
there
is
a
timer.
L
L
So
our
motivation,
like
I,
mentioned
before
now.
So
when
we
started
this
experiment,
we
wanted
to
primarily
check
the
latency
and
PDR
implications
of
using
fragment
forwarding.
We
were
less
focused
on
the
memory
utilization
actually,
but
the
memory
utilization
part
was
already
covered
by
a
yacht
in
the
previous
IT
f-102,
and
it
showed
that
memory
utilization
is
good.
We,
the
the
motivation
for
us,
was
again
as
I
mentioned
in
case
of
EAP
pana.
L
The
hazard
size
is
actually
very
bulky
for
EAP
pana,
which
causes
fragmentation
in
127
bytes
MTU
Network.
So
we
wanted
to
check
whether
fragment
forwarding
can
actually
improve
improve
the
conditions
there,
which
can
directly
result
in
improving
the
network
and
convergence
time.
We
also
wanted
to
try
for
other
bulk
traffic,
such
as
meter
readings,
but
turns
out
that
we
already
use
square
block
wise
transfer
for
that.
So
it's
not
much
of
an
issue.
L
This
is
a
test
configuration.
We
had.
We
used
eight
node
to
two
15.4
in
unsorted
single
channel,
2.4,
gigahertz
mode
of
configuration,
it
had
say
carrier
sensing
enabled,
but
it
no
2.15
dot
for
does
not
have,
does
not
have
a
DAC
TS,
or
at
least
we
don't
have
it.
I
don't
know
whether
anyone
else
supports
our
tier
cts
here
in
each
route
or
15.4.
I'd
be
highly.
L
It
would
be
very
interesting
for
me
to
know
the
L
M
is
127
bytes,
the
Mac
maximum,
a
critize
are
three:
the
network
configuration
we
had
just
50
nodes,
it
was
a
grid.
Topology
and
I
mentioned
the
load
internal
distance.
We
used
ripple
routing
with
M
Rho
F,
with
ETA
X
as
the
routing
metric
trigger
parameters.
M
Rho
spur
thresholds
were
all
same
across
all
the
nodes
and
across
all
the
permits,
the
data
transmission.
L
So
what
we
did
was
we
had
a
40
seconds
interval
for
the
data
and
each
data
packet
was
256
or
the
each
payload
was
256
bytes
for
40
seconds,
which
resulted
in
three
fragments
for
80
seconds.
It
was
512
which
is
35
fragments
and
for
160
seconds
it
was
1
1
KB,
resulting
in
9
fragments.
So
what
happened?
What
we
are
trying
to
check
here
is
that
if
you
increase
the
number
of
fragments
for
a
particular
payload,
there
would
naturally
be
high.
L
F
L
M
L
F
Basically,
whatever
will
will
show
here,
which
show
exactly
same
way,
both
works.
If
there
were
two
packets
in
a
row,
but
then
it
just
would
not
be
two
fragments
interfering,
but
all
the
fragments
of
one
packet
interfering
with
all
the
fragments
of
the
next
packet,
which
would
make
life
an
order
of
magnitude.
Worse
okay.
F
If
you
have
multiple
packets
that
have
to
be
sent
from
the
root
to
different
next
hop
shuffle
them
so
that
you
send
one
packet
to
these
next
up
and
you
can
forward
it
at
the
same
time,
you
can
start
sending
a
packet
to
a
different
next
up,
so
they
don't
kind
of
collision
at
the
first
hop
or
something.
So
it's
kind
of
a
rule
of
thumb,
recommendation
that
is
in
that
space,
but
even.
L
F
F
But
at
least
you
will
avoid
the
first
effect,
which
is
the
next
hop,
is
forwarding
the
first
packet
as
you're,
sending
the
student
second
packet
to
him.
He
can't
be
listening
to
you
if
he's
sending
to
the
next
house.
So
at
least
you
avoid
that
first
hop
effect
as
it
goes.
We
are
working
in
a
Weiss,
an
environment
which
has
the
channel
hopping
technology,
so
we
don't
really
care
about
the
next
hop.
The
answer
to
your
question
is
they
will
be
operating
on
different
channels
because
of
the
chatter
happens.
F
L
Yeah,
thank
you.
Thank
you
for
the
scenario.
Actually,
there
are
a
lot
of
scenarios
that
we
haven't
really
tested.
It's
not
like
this
is
a
comprehensive
performance
report
of
all
the
scenarios
and
all
the
layer,
two
mechanisms
that
can
be
it's
not
so
basically
this
that's.
Why
I'm
specifically
showing
this
is
the
test
configuration
that
we
had.
This
is
the
data
transmission
scheme.
Maybe
it
is
not
it
is.
It
is
cute
to
a
particular
use
case.
It
is
cute
to
a
particular
scenario,
but
yeah.
That's
how
it
is.
You
know
we.
F
E
F
L
So
yeah,
it's
not
so
that
this
came
as
a
big
surprise
to
us
as
well.
You
know
that's
when
we
know
you're,
not
okay,
anyways,
let's
go
to
the
data
part,
and
then
we
can
have
that
discussion.
So
this
is
the
packet
delivery,
the
rates
that
we
saw.
So
if
you
see
the
per
hop
radius
were
reassembly,
there's
fragment
forwarding
with
no
pacing.
L
We
have
fragment
forwarding
with
pacing
50
millisecond
I'll
come
to
what
pacing.
What
exactly
pacing
is
in
this
context.
So
if
you
see
pretty
much
per
hop,
reassembly
is
working
out
very
well,
except
for
that,
if,
if
you
introduced
pacing
with
fragment,
forwarding
it
slightly
improves
but
but
but
statistically,
it's
insignificant,
so
fragment
forwarding
with
pacing,
with
a
good
amount
of
pacing
works
as
much
as
good
as
per
Opry
assembly.
L
What
is
pacing
what
we
added
here
were.
So
we
had
this
discussion
on
the
six
slow
design,
team
and
castle
custom
Pascal
suggested
about
using
use
of
pacing.
What
what
it
means
is.
On
the
sender
side,
we
introduced
a
fixed
delay
before
every
fragment
is
saying
in
the
six
slow
layer.
So
what
happens?
Is
it
increases
the
latency
right?
It
naturally
increases
the
latency,
but
it
also
increases
the
overall
packet
delivery
rate.
That
is
what
that
is
what
we
saw
in
the
previous
slide.
So,
but
here
you
can
see
what
happens
to
the
latency.
L
K
L
L
Yeah,
so
she
leads
into
so.
You
can
see
clearly
from
here
that
the
Mac
transmit
failures
is
pretty
high
in
case
of
fragment
forwarding
and
it
becomes
slow
if
you
introduce
pacing.
Now
this
Mac
Mac
transport
failures
complete
failures,
even
after
three
retries,
the
packet
would
not
be
sent
the
data
in
the
in
the
github.
It
shows
what
happens
on
first
rate,
how
many,
how
many
of
the
actual
packets
go
through?
First,
we
try
secondary,
try
and
third
retry.
So
all
this
data
is
available
on
the
github
observations.
L
Ff
seem
to
be
doing
bad
without
pacing.
Having
said
that,
like
I
mentioned,
it's
for
this
particular
l2
scenario
for
a
single
channel
hopping,
anyways
I'll
come
to
that
in
the
sir
next
slide.
If
you
add
pacing,
then
latency
is
impacted
negatively,
naturally
or
obvious,
and
it
seems
to
be
doing
better
both
in
terms
of
PDR
in
latency,
at
least
in
this
particular
scenario.
Basically,
we
were
almost
on
the
I
mean
we
tried
experimenting
with
this
because
we
wanted
to
actually
use
it,
deploy
it
in
our
scenario.
L
But
because
of
these
reasons
we
could
not
go
ahead
and
deploy
it.
Maybe
if
the
l2
layer
changes
for
us
in
the
future,
maybe
we
can
consider
it
a
game
or
if
there
is
any
Mac
interface,
which
has
advanced
primitives
such
as
RTS
or
CTS
it
might,
it
might
be
better
to
use
fragment,
fragment
drops
for
us
due
to
memory
and
availability
was
very
less.
L
It
was
nil,
almost
negligible,
because
the
if
you
see
the
kind
of
data
transmission
scheme
that
we
had
you
might
say
that
it
was
cute
to
our
scenario,
so
we
didn't
had
really
any.
Maybe
any
packet
drops
because
of
memory
and
ability
and
we
used
a
grid
topology.
So
there
were
no
there's,
not
a
single
bottleneck
node.
So
it
was
a
great
topology.
There
was
sufficient.
Balancing
traffic
pattern
was
sparse,
more
more
fragments.
It
results
in
higher
payload
loss.
Probability
here,
I
feel
maybe
the
fragment
recovery
mechanism
might
might
be
of
some
help.
F
F
F
If
there
was
some
randomized
time
here
when
you
start
to
see,
and
even
if
you
don't
have
a
big
delay
and
if
you
have,
if
you
had
change
your
threshold
of
sensitivity
to
the
energy
in
the
air,
you
would
you
did
not
detect
well
enough,
that
there
were
those
collisions
and
that's
about
your
tuning
of
your
network
right
sensitivity
to
energy,
detect
and
and
randomize
time
to
forward,
so
that
they
don't
try
at
the
very
same
time.
And
so
one
detects
the
other
and
there
is
no
collision.
But.
L
At
the
same
time,
we
have
fragment
for
hop
reasonably
working
in
the
same
network
with
the
same
parameters.
So
what
I'm
trying
to
say
is
you
know
this?
These
schemes
will
come
into
picture
even
for
and
it
will
improve
scenarios
for
per-fragment
operation
P
as
well.
So
what
this?
This
is
a
genetic
thing
that
you
mentioned,
which
will
work
even
for
fragment,
forwarding
even
for
Perot
pre-assembly,
yes,
but
but
the
point.
F
F
So
if
you
do
those
two
things,
you
know
you
instead
of
putting
50,
you
said
a
random
number
between
10
and
50,
and
then
you
say:
oh
either,
I
lower
my
energy
level,
because
maybe
you're
crying
out
a
lot
too
high
or
you're
not
sensitive
enough
to
the
energy
detect,
but
just
tuning
this
thing,
I
think
you
can
dramatically
change
those
numbers.
Yeah.
F
F
F
L
F
F
L
So
Oh,
what
I'm
trying
to
say
is
here
all
the
nodes.
All
the
nodes,
apart
from
the
border
after
our
senders,
are
sending
are
sending
to
the
border
router.
So
it
there
is
a
chance
of
other
nodes.
I
mean.
That
is
why
we
don't
have
hundred
person,
maybe
period
here
but
but
depends
on
the
load
you
have,
but.
F
Until
the
pram
is
with
with
one
thing
like
that
of
two
packets
following
one
another,
that
kind
of
synchronize
loads
and
the
if
they
cannot
even
detect
the
other,
because
the
transmission
are
synchronized
and
you
lose
all
the
protections
you
have
a
day
or
two
to
you.
You,
under
this
situation,
yeah.
L
Clearly,
we
have
a
lot
to
check
out.
Definitely
so
randomization
is
something
that
we
thought
about,
but
then
it
was
not
that
trouble
to
implement.
So
we
just
cornered
with
the
fixed
delay
yeah,
but
because
still
it
gives
you
a
clearer
picture
that
actually
pacing.
If
you
do
some
sort
of
pacing,
it
will
improve
what
how
exactly
to
do
pacing.
Even
if
you
have
like
20
to
50
millisecond
randomization,
it
might
still
induce
latency.
You.
F
You
you
have
to
insert
a
very
huge
pacing,
because
you
are
too
may
be
unsure
that
the
packet
went
all
the
way
through
before
you
quits
the
fragment
before
you
could
send
the
next
one.
But
that's
because
you'll
see
your
kitchen,
an
assessment
didn't
work
at
all,
otherwise,
by
having
a
small
way
to
just
to
make
sure
they
don't
try
to
say
at
the
same
time
and
then
detect
the
energy
in
the
air
without
on
the
job
that
you
would
want
from
out
your
city,
yeah
yeah,
yeah,
yeah,
okay,
because.
G
L
Okay,
so
again,
these
inferences
are
drawn.
These
inferences
are
drawn
in
the
context
that
we
were
experimenting
in
so
if
a
performance
is
tied
to
l2,
so
l2
with
RT
C
T
is
based
to
see
a
mechanism
or
not
necessarily
RTC
TS.
There
are
advanced
avoidance
scheme
in,
for
example,
I
get
not
to
rot
11s.
It
has
its
own
mesh
collision
avoidance
scheme,
so
some
of
that
scheme
might
actually
benefit
fragment,
fragment
forwarding.
We
have
to
remember
one
thing
that
any
mesh
under
protocol
actually
uses
a
stream
train
of.
L
If
you
generate
a
payload
which
is
bigger
than
what
Mac
can
handle,
it
is
going
to
generate
a
train
of
fragments,
so
in
that
case
mesh
under
already
you
has,
if
someone
uses
submission
to
the
routing
protocol,
then
the
fragmentation
at
IP
layer
is
going
to
cause
a
train
of
fragments,
so
it
is
going
to
fall
into
the
same
problem
statement
as
whatever
we
are
discussing
here.
It
works
today.
L
But
having
said
that,
4/8
not
I
tried
checking
what
eight
not
to
rot
eleven
esters
and
it
has
this
advanced
mesh
collision
avoidance
schemes
which
a
mesh
which
prevents
such
things
from
happening.
So
basically,
the
ball
is
in
the
lower
layer.
L2
is
layer,
okay,
yeah
yeah
in
in
this
case
at
least.
Perhaps
the
VA
simply
is
not
as
bad
as
it
sounds
is.
Essentially
we
thought
that
reassembly
would
be
performing
much
worse
than
fragment
forwarding,
but
it
turned
out
to
be
a
big
surprise
for
us
simulation
tool.
Now.
L
One
thing
we
wanted
to
do
for
sure
was
we
wanted
a
realistic
RF,
so
we
use
n
s,
3
l
RW
pants,
so
there
is
a
Whitefield
framework
that
we
have
developed
a
couple
of
years
back,
which
we
used
for
this
experimentation
it
uses
NS
3
is
lr
w
pan
in
the
backend
for
realistic
RF.
The
advantage
with
this
framework
that
we
have
is,
we
can
directly
plug
in
the
quantity.
A
protocol
stack
on
top
of
this
framework,
such
that
you
can
try
out
big
networks
and
work
out.
E
L
L
This
is
the
implementation,
so
we
added
the
implementation.
Add
slack
resolves
few
extra
bytes
in
the
first
fragment
because
you
Sixto
compression
is
variable
at
every
hop.
So
you
have
to
make
sure
that
you
add
some
sort
of
slack
in
the
first
fragment
slack
is
needed
because
the
first
fragment
size
might
change.
Enroute
second,
is
the
timers.
L
L
We
clearly
need
more
experiments
to
be
done.
May
experience
in
with
different
ahrefs
it
note
of
11
with
RTS
cts.
Maybe
it
might
not
work
as
well,
but
it
not
2.11
s
uses
l2
mesh
and
this
will
result
in
a
fragment
forwarding
like
behavior.
So
already
there
are
other
techniques
which
are
using
the
similar
concept
like
fragment
forwarding.
It
will
eventually
lead
to
fragment
forwarding
at
l2,
so
even
the
fragment
forwarding
should
work
in
better
in
that
case,
so
there
is
there.
Is
we
wanted
to
experiment
with
8,
not
2.11
s
in
the
next
phase?
L
More
optimal
pacing
algorithms,
NIC
required
so
should
pacing
be
done
only
at
the
original
receive
is
a
sender
side.
Well,
that
is
very
trivial
to
implement,
but
may
not
give
you
all
the
benefits.
If
you
can
do
some
sort
of
pacing
at
intermediate
hops
as
well
I
that
might
the
it
might
be
not
able
to
implement,
but
my
do
better
gains,
but
we
have
not
really
experimented
with
any
of
these.
L
L
E
E
Right
all
right
so
I,
you
know
it's
very
good
that
you
do
simulation,
but
I
think
anything
that
you're
measuring
it
has
nothing
to
do
with
fragment
forwarding.
It
is
entirely
due
to
the
fact
that
you
have
bursty
generation
of
data,
the
pacing
everything
you
talk
about
this,
it's
a
layer,
two
thing
and
and
and
throwing
you
know
saying
you
know,
throwing
out
conclusions
like
fragment
forwarding
is
less
efficient
than
per
hop.
E
Reassembly
makes
very
little
sense
if
you
don't
tune
your
Mac
layer,
I'm
looking
here
at
a
at
some
studies
that
yet
did
where
I
mean
we
can
send
you
this,
where
reliability
says
that
a
hundred
percent,
so
I
will
be
very,
very
cautious
and
throwing
out
statements
like
this.
Given
that
you,
you
know
it
all
depends
on
the
Mac
layer,
and
so
maybe
I'm
misunderstanding,
but
if
my
understanding
is
that
what
you're
seeing
is
the
effect
of
bursty
traffic
at
nodes
has
nothing
to
do
with
it
fragment
forwarding
itself.
L
E
L
E
L
Is
absolutely
no
difference,
so
what
we
try
to
check
is
whether
the
block
wise
transfer
of
coop
will
result
in
the
same
issue,
because
you
are
fragmenting
at
the
application
layer
and
then
sending
the
packets.
But
then
there
is,
there
is
an
acknowledgment
at
the
application
layer
and
then
you
send
the
next
packet
in
case
of
block
wise
transfer.
So
it
might
not
have
this
kind
of
issues
fragment
forward.
It.
N
L
N
E
A
N
So,
first
of
all,
let's
take
a
look
at
the
status
of
the
document,
so
the
last
revision
was
0
3.
This
was
published
in
July
before
the
last
IDF
and
in
fact
the
document
has
not
been
updated
since
the
last
idea,
because
we,
the
authors,
believe
that
the
document
is
ready
in
the
sense
that
we
are
not
aware
of
any
outstanding
issue
or
any
potential
updates
that
may
not
be
applied.
N
We
have
extended
bleach
in
order
to
support
the
mesh
draft,
so
among
others
we
have
added
the
six
la
role
and
also
now
heather
compression
is
performed
as
per
our
mesh
draft.
Then
one
important
detail
in
the
implementation
is
that,
as
of
today,
it
is
based
on
static
routing,
so
recall
that
our
mesh
draft
requires
route
over.
However,
no
specific
routing
protocol
is
mandated,
then
we
have
also
been
able
to
perform
some
initial
experiments
and
tests
using
devices
such
as
the
ones
you
can
see
in
the
figure
on
the
slide.
N
These
are
CC
26:15
devices,
the
ones
on
the
left
are
called
launchpad,
the
red
ones.
The
other
ones
are
called
sense
attack
all
of
them
implement
bluetooth.
For
that
one
and
in
our
experiments
they
all
run
Kentucky
OS.
So,
for
example,
we've
been
able
to
enable
end-to-end
communication
in
a
topology
like
the
one
you
can
see
here,
which
is
a
three
hub,
ble
topology
between
the
6ln
on
the
left
and
the
signal
BR
on
the
right.
N
Then
we
have
also
started
to
perform
some
preliminary
latency
measurements
and,
for
example,
we
have
measured
an
average
RTT
over
a
to
hop
scenario
of
252
milliseconds.
When
the
ble
cone
interval
setting
is
125
milliseconds,
this
parameter
can
interval
determines
the
time
between
two
consecutive
connection,
events
in
an
established
really
link
layer
connection.
Therefore,
this
means
that
the
time
between
the
moment
when
there's
a
packet
to
be
sent
and
the
actual
time
for
transmission
will
be
something
between
zero
and
125
milliseconds.
But
how
still.
F
Tyria,
just
to
mention
that
the
vendor
of
this
particular
chip-
they
don't
know
if
we
can
mention
it,
but
that
vendor
as
ripple
implementation,
that's
derived
from
Kentucky,
so
I
would
really
like
you're,
very
close
to
having
the
dynamic
protocol
you're
talking
about
at
least
using
ripples.
So
if
you
try
it,
please
let
us
know,
because
that
would
be
great
news.
We'd
love
to
see
your
work
with
ripple,
overwrite
and
and
the
code
exists
for
this
job.
Yes,.
N
Sir
I
think
that's
actually
the
way
to
go,
because
we
started
with
static
routing
as
the
initial
step,
let's
say,
but
of
course
it
would
be
better
to
have
something
like
ripple
running
here.
Thank
you
so
yeah,
based
on
this
setting
of
con
interval,
the
expected
average
latency
in
a
one
hop
one-way
transmission
will
be
actually
in
theory,
62.5
milliseconds.
So
the
two
hopper
TT
that
we
measured
is
actually
matching
quite
well.
The
theoretical
expectation
seems
in
this
two
hop
round-trip
time.
We
have
four
times
this.
N
A
F
F
There
was
wondering,
if
you
foresee
any
impact,
because,
basically,
when
you
implement
something,
that's
when
you
discover
oh
I,
I
did
not
think
about
adding
this
or
that
in
my
protocol
and
sure
you
having
running
only
with
static
routes
so
that
she's
wandering
a
would
there
be
an
impact
if
once
we
at
least
try
it
with
with
ripple
since
it's
there,
so
my
intuition
would
be
a.
Why?
F
Don't
we
wait
for,
for
these
ripple
trials,
make
sure
that
we'll
be
able
to
have
this
dynamic
protocol
over
right
or,
if
you're,
really
clear,
that
there
cannot
be
any
any
change
or
making
the
dynamic
protocol
run
intuitively.
You
know
it's
just
setting
route,
so
it
should
be
okay,
but
sometimes
when
you
try
it,
oh
I
should
have
provided
this
information
in
here
and
go
down.
You
know
so
yeah.
N
N
E
F
Having
only
static
route
feels
me,
I
mean
I
feel
like.
Oh,
maybe
we're
missing
something
about
the
two
exchanges
of
whatever
happens.
You
know
the
broadcast
domains
or
anything
which
which
could
actually
be
a
primed
for
for
writing.
So
it
would
have
liked
you
to
run
a
writing,
suits
and
I
mention
ripple,
because
I
know
it's
available
on
Kentucky
or
their
life
Kentucky
on
this
platform,
so
I
said:
hey,
let's
try
it
before
we
ship
this
thing
make
sure
it
makes
sure
it
works.