►
From YouTube: IETF106-LWIG-20191118-1810
Description
LWIG meeting session at IETF106
2019/11/18 1810
https://datatracker.ietf.org/meeting/106/proceedings/
A
B
C
D
C
B
E
Yet
here's
some
update
since
last
IDF
or
oh,
we
didn't
have
meeting
last
time
and
we
have
walking
blast
Corps
for
the
TCP
draft
and
which
has
been
updated
plans
and
we
are
going
to
report
the
walking
rubric
last
score.
Update
of
this
document
today
and
the
other
Trotter
is
related
to
crypto
and
the
status
of
the
drafts
there.
E
We
curve
representations
are
in
the
ad
evaluation,
but
we
have
some
discussion
with
the
CFR
G
research
group,
chair
and
I
think
the
current
consensus
that
st,
I
think
is
still
be
it
can
be
processed
to
you
and
but
I
think
it's
a
kosher
perd
with
the
to
working
group
and
we
are
sent
the
IETF
last
core
knows
too
the
cfrp
Sivaji
many
lists,
and
happily
we
had
to
long
walking.
Group
document
updated
during
this
period.
The
first
wine
star
customs
drop-down.
There
are
c
17
to
28
piece
and
we
are
waiting.
E
E
C
So
my
just
speaking
no
hat
as
a
participant
I
think
we
got
some
information
that
NIST
is
also
doing
something.
What
this
has
liquor
representations
is
doing.
Perhaps
John
and
Renee
have
more
information
on
this.
Since
they
fall
honest
much
more
than
I
do
there
is
probably
some
overlap,
but
that
there
is
no
reason
why
we
should
move
this
forward.
I,
don't
know
if
John
you
want
to
comment
something
on
that.
E
E
Yes
hand,
the
blue
sheet,
so
I
think
the
title.
This
light
is
wrong,
and
so
we
we
have
some
other
working
group
document
that
has
been
adopted,
but
there
seems
no
activity.
Since
for
these
draft,
we
are
going
to
ask
the
all
sorts
of
restaurant,
how
what's
the
status
of
the
draft
and
so
that
we
can
have
pre
plan
about
each
draft
and
anything
want
to
mention.
But
I'm
going
to
ask
one
by
one.
F
So
we
really
were
looking
for
the
review
reviews.
We
had
the
implementation
in
place.
The
performance
results
in
place,
but
since
we
didn't
get
any
any
any
any
any
any
feedback
from
the
working
group,
so
I
mean
we
just
didn't
update
it
anymore.
But
if
there
is
any
one
interested,
we
really
feel
that
the
problem
is
kind
of
important
to
be
handled.
We
have
seen
that
problem
getting
discussed
on
Wi-Fi,
Alliance,
mailing
group
and
all
that,
but
to
continue
any
further.
We
need
some
sort
of
feedback
from
the
working
group.
E
Suggesting
that
we
can
issue
the
working
group
last
call
right
after
the
meetings,
so
that
because
people
tend
to
avoid
doing
anything,
if
there
is
no,
then
I.
So
if
we
issue
a
walking
blast
core,
probably
there
will
be
P
critical
views
or
you
know
help
for
views
about
these
routes.
There
will
be
helpful
for
you
and
also
the
working
group
that.
E
F
E
G
Yeah
not
a
time
to
update
this.
The
plan
is,
as
discussed
last
meeting
to
update
it
with
GLS
102
and
DTLS
one
or
two
as
well
as
group
or
score
for
two
parties
and
I.
Think
I
have
been
contacted
by
I,
don't
remember
which
University
but
asking
exactly
for
TLS
one
or
two
numbers
the
new
available
numbers.
So
you
can
compare
if
TLS
103,
TLS,
102,
there's
just
high
level
like
500,
bytes
and
so
on.
G
H
A
A
It's
a
bit
weird
that
we
that
there
are
three
drafts
covering
two
bases.
One
is:
what
does
the
existing
protocol
allow
you
to
do
and
then
there's
one
new
protocol.
The
new
protocol
has
its
own
draft,
but
the
existing
thing
for
some
reason
got
split
up
between
six
low
and
and
a
week
that
doesn't
make
a
lot
of
sense.
But
it's
how
this
this
document
came
to
be
so
the
virtual
reassembly
document.
A
A
H
Suresh
krisshnan,
as
like
responsibility
for
both
of
these
I,
don't
mind
holding
it
until
this
gets
to
me
before
it
goes
forward.
That
could
be
something
we
do
or,
if
you
think,
there's
value
in
merging
them.
That's
okay
with
me
too!
So
catalyst
is
also
here,
so
he
can
comment
as
well,
but
I
don't
see
why
they
cannot
be
the
same
document.
If,
if
that's
your
question,
so
we
can
work
on
the
specifics,
so
we'll
figure
out
how
to
do
this.
Okay,
Alice,
you
want
to
say
something.
D
Carlos
Gomez
so
yeah.
Basically
in
the
6lo
session
on
Wednesday,
we
have
a
lot
dealing
with
both
fragmentation
related
documents.
So
one
of
the
points
there
was
something
that
the
rise
from
the
internet
area
directed
review,
which
was
related
with
the
intended
status
for
the
six
long
document,
so
that
we'll
be
wanting
to
discuss.
E
Okay,
this
one's
had
be
fixed,
I,
good,
very
productive.
Today,
how
about
this
one
is
Daniel
here
or
any
body
on
the
AUSA
list,
no
going
to
skip
this
okay,
this
one
is
a
pretty
tricky
because
I
think
III
really
stalk
him
in
multiple
times.
I
think
he's
a
useful
document,
but
the
thing
is
that
the
core
has
been
changed
too
much.
So
we
start
to
really
to
up
this
document
to
reflect
the
advancing
call
walking
group
or
we
can
leave
it
along
custom.
So.
A
The
within
the
car
Wagner,
we
have
been
discussing
that.
Maybe
we
need
something
that
that's
more
that's
more
along
the
lines
of
what
was
it
RFC
48
five,
my
RFC
number
guesser
doesn't
work
today,
which
was
document
in
the
rock
working
group
where
we
for
for
five
years
kept
it
open
as
a
internet
draft
and
collected
errors
and
clarifications.
A
So
the
the
work
that
needs
to
be
done
is
to
risk
redistribute
the
content
between
those
two
documents.
So
the
other
one
is
in
the
car
working
group,
but
not
particularly
active
at
the
moment,
but
we
have
started
collecting
issues
that
need
to
go
into
that
document.
So
there
is
some
work
being
done,
but
just
not
the
document
yet,
but
on
the
github
repository
and
the
next
step
is
actually
getting
these
issues
over
there
and
then
to
look
at
the
two
documents
and
to
see
which
part
goes
where.
E
C
Someone
who
can
be
editor
so
that
we
can
poke
this
editor
every
now
and
then,
if
the
draft
is
not
being
updated
because,
like
the
author's
clearly
have
moved
on
to
other
things,
document
hasn't
been
updated
in
quite
a
while.
It's
very
useful
piece
of
information,
but
we
need
someone
to
kind
of
see
through
yeah,
that's
good!
You
and
you
volunteer
to
be
the
editor.
H
Yes,
Kristen
and
I
would
say
let
it
die
for
now.
It's
like
a
document.
It's
like
you
know
it's
available
for
whenever,
when
when
this
energy
to
edit
it
like
some,
we
can
just
revive
it
and
go
on.
So
it's
like
a
carson
finds
time
in
february
or
in
june
right
whenever
there's
something
to
update
like
somebody's
gonna
come
back
with
it.
Then
we
update
it
because
I
think,
if
there's
no
energy
to
update
it,
like
you
know,
I,
don't
want
to
be
stuck
with
the
Stockman
because
nobody's
going
to
review
it
either.
H
E
A
Are
several
new
things
in
in
this
document?
Of
course,
we
already
have
published
as
having
a
true
28,
so
there
are
new
things
in
here
and
it
would
be
good
to
get
some
feedback
about
these
new
things.
What
one
new
thing
is
security
classes,
which
is
an
interesting
thing
given
the
other
draft,
but
there
are
also
some
some
other
new
parts
about
energy
usage
and
about
additional
classes
of
processor
power.
So
I
think
it
would
be
good
to
get
some
reviews
for
that
and
then
I
actually
would
propose
adopting
it.
C
So
I
think
before
we
move
forward
with
the
agenda
for
today
in
a
week.
Maybe
this
is
something
for
the
participants
to
consider.
Where
do
they
see
the
working
group
going
in
the
future,
because
one
challenge
I
see
with
the
documents
is
that
they
are
kind
of
very
specific
on
certain
topics,
so
the
crypto
document
is
is
being
driven
by
one
or
two
guys
who
know
no
crypto,
but
then
there's
very
few
participants
who
are
actually
providing
reviews
the
same
with
minimal
s
or
some
of
the
other
documents.
C
Participants
and
provide
comments-
and
you
know
the
participation
is-
seems
to
be
going
down,
so
maybe
as
a
suggestion.
One
way
we
can
think
about
it
is
we
don't
have
a
physical
meeting
every
time,
but
only
when
there
is
a
significant
mass
of
documents
that
have
been
updated.
We
keep
the
working
group
alive.
We
keep
the
mailing
list
alive
when
there
is
sufficient
drive.
Let's
say
from
caution
on
on
certain
documents:
we
can
schedule
a
meeting
or
when
John
updates
the
protocol
comparison
document.
C
A
One
one
one
problem
that
we
have
is
that
sense
tract
of
humans
always
override
informational
documents.
So
during
an
IETF
week
it's
really
hard
to
find
spare
cycles.
Maybe
we
should
actually
do
virtual
interims
at
some
point
at
some
point
where
we
are
not
in
a
frenzy
getting
stuff
done
here,
the
ITF
and
try
to
progress
documents
in
this
way.
H
Like
what
do
you
say,
it
sounds
good
to
me
and
if
Carson
like
once,
you
try,
it
I
think
I'm
open
to
it,
like
you
know,
just
like
set
up
a
meeting,
probably
like
mid
cycle.
If
you
want
and
see
if
people
turn
up
right,
but
I
do
see
the
low
energy
too
and
I
think
it's
like
fair.
Like
you
know,
similar
thing
happened
to
DHC
right,
so
DHC
had
like
a
period
where,
like
I
know,
there
was
not
much
energy
and
then
like.
H
They
had
like
a
little
bit
more
right
like
there's
like
maket
as
assignment
came
up
and
then
there's
more
energy.
So
it's
it's
up
to
you
guys,
like
you,
know,
I'm,
fine,
keeping
the
group
open
and
then
just
waiting
it
out
to
see
like
give
it
give
it
a
year.
That's
kind
of
what
I
told
the
DAC
chairs
like
I,
give
you
a
year
and
if,
like
nothing,
turns
up
I
close
it
down.
So
that's
kind
of
like
the
thinking
I
have
your
ass.
D
Let's
go
miss
well-known
the
question
about
future
of
the
working
group,
but
on
the
point
of
getting
participation
on
specific
topics,
for
example,
for
the
TCP
draft,
the
involvement
of
TCP
M
has
been
great,
so
I
think
that
trying
to
involve
participants
from
the
more
related
topic
topic
related
working
groups
would
be
great
to
get
feedback.
Indeed,.
E
D
Hello:
everyone,
my
name
is
Carlos
Gomez
I'm,
going
to
present
the
current
status
and
the
last
update
of
the
draft
and
title
TCP
uses
guidance
in
Internet
of
Things.
First
of
all,
let's
see
the
status
of
the
document.
The
last
time
the
draft
was
presented
was
in
brac.
That
was
the
revision
0-5.
Then,
around
that
time
we
received
comments
by
stuart
shire
and
corey
Fairhurst,
which
led
to
revisions
0,
6
and
0
7
respectively.
D
Well
now,
let's
look
at
the
update
in
this
last
revision.
First
of
all,
ill
Poe
had
three
rather
minor
comments.
Basically,
he
suggested
to
replace
a
term
pure
ACK
by
another
term
ACK
without
payload,
then.
The
second
point
was
related
with
the
section
where
we
explained
that
Windows
size
of
5
segments
is
needed
in
order
to
trigger
first
retransmit
and
fast
recovery.
So
we
have
an
example
there
and,
however,
the
there
was
a
sentence
that
could
mislead
the
reader
to
understand
that
segments
1
to
6
could
be
sent
immediately
right
from
the
beginning.
D
So
we
corrected
that
and
also
there
was
one
purely
editorial
improvement
suggested.
So
we
applied
that
as
well,
then,
regarding
Marcus
outstanding
comments,
there
was
a
more
general
comment
about
a
term
which
was
single
segment.
So
in
most
of
the
versions
of
this
document,
we
have
been
using
the
term
single
MSS.
D
Basically,
this
refers
to
implementations
that
handle
window
sizes
and
buffers
of
size
of
single
MSS.
However,
in
the
previous
version
we
had
maybe
spiritually
changed
that
to
single
segment.
However,
after
comments
by
Markov,
it
became
clear
that
single
MSS
was
actually
the
more
appropriate
term
to
use
here,
because
it
reflects
the
behavior.
D
What
is
supported
in
the
category
of
more
lightweight
TCP
implementations,
which
support
single
MSS
window
sizes
and
buffers,
and
also
that's
what
is
described
and
consistent
with
what
we
explained
in
the
document,
then
in
the
section
where
we
provide
guidance
on
how
to
set
the
NSS,
there
was
a
suggestion
to
change
the
phrase
limit
MTU
to
limit
the
IP
datagram
size,
and
we
did
that
change.
In
fact,
the
MTU
is
rather
parameter
property
of
the
underlying
network
technology
below
ipv6.
D
Then
there
was
another
comment
in
the
section
where
we
attempted
to
provide
guidance
for
how
to
set
the
MSS
when
ipv4
is
used.
However,
after
a
comment
by
Markku,
we
thought
that
it
was
better
to
remove
that
attempt,
because
in
fact
there
is
not
an
ipv4
equivalent
of
the
ipv6
MTU
requirement,
so
it
was
hard
to
provide
guidance
in
the
same
way,
then,
in
a
section
that
discusses
single
MSS
stacks,
we
explained
that
in
coop,
there's
usually
stop
and
wait
behavior,
so
usually
a
single
MSS
window
would
be
sufficient
for
for
that
use.
D
However,
there
is
one
exception
noted
by
Markku,
which
is
that
there's
the
CSM
message.
This
is
for
co-op
over
TCP,
the
CSM,
which
is
sent
at
the
beginning
of
a
connection
which
can
be
followed
immediately
by
the
first
application
layer
message
that
carries
actual
user
data.
So
here,
in
this
case,
depending
on
the
sizes
of
the
CSM
and
the
first
application-layer
message,
then
perhaps
single
MSS
window
might
not
be
sufficient.
D
Then,
in
the
section
that
discusses
delayed
acts
for
single
MSS
implementations,
we
have
made
some
clarifications.
We
had
a
sentence
where
we
explained
that
the
saving
disabling
Nagel
has
no
impact.
If
the
sender
can
only
handle
stop
and
wait
operation,
we
added
at
the
end
of
the
sentence
that
this
is
the
TCP
level
to
avoid
potential
confusion
with
stop
and
wait
operation
at
the
application
level,
and
also
we
applied
some
additional
editorial
clarifications.
D
D
In
the
previous
version,
we
explained
that
with
limited
transmit
window,
size
of
three
segments
in
the
previous
version
would
be
enough
to
trigger
sending
segments
one
to
five
in
the
example
that
we
have
in
that
section
where
segment
number
two
is
lost.
However,
marco
pointed
out
that
it's
actually
two
segments
that's
needed
as
a
window
size
to
trigger
the
transmission
of
those
segments.
One
to
five,
however,
there's
the
downside
of
the
sender
having
to
wait
for
the
delayed
ACK
for
second
one.
D
E
E
The
the
the
the
final
item
on
the
agenda
is
the
presentation
from
Rahu
and
it
there's
no
draft
reflecting
this
presentation.
But
the
content
of
this
presentation
has
some
insights
and
can
provide
some
insight
to
our
IT
airport
code,
especially
for
the
IOT
realm
and
I.
Think
we
can
all
learn
from
something
for
me
and
especially
for
the
portico
designers,
hello,.
F
Everyone
I'm
Rahul
Jadhav,
so
this
is
more
of
a
deployment
experiences
which
we
took
back
and
you
know
which
had
a
lot
of
impact
on
the
protocol
and
protocol
designs,
which
we
took
back
to
the
individual
working
groups
and
we
found
it
not
useful.
So
this
is
essentially
in
2014.
We
started
off
with
a
project
for
AMI
and
we
found
that
you
know
we
assembled
a
protocol
stack,
we
tested
it
in
Kuja.
We
found
that
everything
is
working
all
fine
and
then
we
try
to
check
whether
it
can
actually
scale.
So
we
would.
F
We
had
to
put
up
a
hardware
based
test
environment
of
300
nodes,
and
it
was
really
really
difficult
to
manage
that
kind
of
scale
on
hardware,
and
we
realized
that
on
hardware
the
same
protocol
stack
was
not
able
to
scale
at
all
and
then
we
tried.
We
tried
to
check
what
was
the
problem
and
we
realized
there
were
a
lot
of
deficiencies
in
the
individual
protocols
that
were
not
addressed
because,
especially
from
the
performance
point
of
view
in
Kuja
everything
worked.
Fine.
The
network
convergence
time
was
great.
F
The
node
joining
time
was
great,
but
in
reality
it
didn't
really
scale
up
that.
Well,
so
that's
when
we
started
about
about
this
work
roughly
around
idea
of
96
four
years
back
and
most
of
the
work
that
we
had
taken
back
reversed
was
for
the
role
working
group,
and
that
is
what
the
there
is
one
draft
in
a
week
also,
which
is
about
neighbor
management
policy,
which
had
that
particular
framework
had
a
lot
of
impact
on
it.
So
what
is
this
about?
It's
about
experience
sharing.
F
F
For
example,
if
you
want
to
actually
simulate
a
thousand
nodes
network
or
hundred
nodes
network,
there
are
options
available
like
in
s3
or
castelia
omnibus
press,
but
it's
got
them
too
hard
to
use
those
tools,
and
this
is
where
we,
this
is
what
exactly
we
had
been
through,
and
this
this
this
particular
talk
is
about
that
those
experiences.
So
my
context
here
we
started
off
with
multi-hop
mesh
routing
protocols.
We
had
very
bigger.
We
had
big
networks,
1,000
nodes.
F
We
we
aim
to
reach
to
that
scale
of
1,000
nodes
with
16
ops,
a
typical
ami
scenario.
So
this
is
what
we
thought.
What
we
want
is
from
this
from
this
framework
is,
you
know
we
wanted
something
which
we
can
benchmark
for
and
we
can
have
other
peoples
submit
that
data,
their
results
or
their
experiments
in
the
same
framework
so
that
it
can
be
compared
in
the
same
context.
This
was
the
most
important
thing
we
wanted
something
to
be
reproducible.
The
data
should
be
reproducible
in
in
on
a
different
system.
F
F
You
can,
of
course,
use
the
realistic
real
hardware,
but
to
deploy
real
hardware
with
five
hundred
or
forget
you
in
five
hundred
you
in
one
hundred
nodes
is
it
requires
a
lot
of
manpower
and
requires
a
lot
of
not
not
most
of
the
most
of
the
teams
here
could
muster
that
kind
of
that
kind
of
energy
or
that
kind
of
resources
that
are
required
for
a
hardware
test,
but
the
third
important.
The
next
important
thing
was
the
interrupt
testing
we
wanted
to
test
at
scale.
So
we
have
a
lot
of
open
source
options
available.
F
F
But
if
you
want
real
performance
at
scale,
if
you
are
putting
two
100
nodes,
a
lot
of
protocol
specific
idiosyncrasies
that
come
up
which
results
in
a
very
bad
performance
eventually
for
the
whole
network,
and
we
want
something
we
wanted,
something
which
we're
in
a
scenario
configuration
could
be
shared
to
other
developers.
They
can
just
take
the
scenario,
configuration
and
start
from
there
and
get
the
data,
so
we
understood
that
realistic
models
aren't
necessarily
especially
for
wireless
constrained
networks.
F
Performance
data
is
important
to
be
measured,
but
best
is
to
use
hardware,
but
it's
not
always
possible.
So
the
these
were
the
premises
that,
where
we
build
upon
so
now
that
we
are
talking
about
yet
another
framework,
I
should
explain
that
there
are
a
lot
of
framework
already
in
place,
for
example
the
Kuja
it's
very
good
to
use.
It
has
extremely
good
visualization,
and
that
is
why
we
could
see
that
almost
60
to
70
percent
of
I
Triple
E
papers
give
data
based
on
Kuja.
F
It's
it's
and
it
integrates
very
easily
with
the
existing
most
popular
open-source
operating
system
called
quanta
key
and
it's
it.
It
makes
it
very
easily
real
easy
to
use.
It
supports
hardware,
emulation
that
is
another
feature
that
it
has,
but
it
doesn't
really
have
any
realistic
path,
loss,
modeling
and
propagation
models.
It
cannot
scale
to
hundreds
of
nodes.
It
works
on
top
of
JVM.
F
If
you
try
to
put
in
hundreds
of
node
that
it's
going
to
just
die
off,
one
good
option
is
to
use
NS
300
minute
plus
plus
these
are
these,
provide
you
realistic
options,
but
it
is
impossible
to
use
the
realistic
net
real
network
stack
if
you
want
the
network
stack
from
riot
or
quantity
or
any
other
Linux
kernel
for
that
matter
to
be
used
on
top
of
NS
3
or
only
clusters.
You
have
to
put
your
code
in
context.
2
n
is
3
or
a
minute
plus
plus,
which
is
a
really
really
big.
F
Ask
it's
it's
it's
a
big
work
in
itself,
so
there
are
certain
options
such
as
NS
3
provides
something
called
as
tab
bridge,
but
these
options
cannot
scale
to
hundreds
of
nodes.
You
can't
have
really
I
mean
you
can
have
hundreds
of
tap
interfaces,
but
it's
really
an
ugly
way
of
doing
that
using
the
doing
at
that
kind
of
scale.
You
know
you,
you
don't
want
1,000
tap
interfaces
on
your
machine
just
for
simulation
powers.
F
There
are
hardware
based
test
test
bits
in
three
fyt
IOT
lab
they.
You
get
practical
data
from
that,
but
you
have
limited
scale
and
the
access
to
those
test
bits
are
rather
limited
in
the
sense
that
you
can't
really
play
with
it.
You
have
confined
time
in
which
you
can
operate
on
them.
You
can't
really
change
configuration
and
quickly
check
the
data,
so
realistic
simulation
frameworks
are
difficult.
To
use.
Here
is
the
data
from
one
of
the
papers
which
had
been
recently
submitted.
F
If
you
see,
Kuja
is
the
most
dominant
tool
and
it's
3
is
also
another,
the
second
most
dominant
tool,
but
Kuja
beats
everyone
else
by
a
big
big
number.
It's
63
person,
you
see
the
the
data.
The
graph
on
the
right
hand,
side
shows
you
how
many
of
the
experiments
had
actually
used.
Hardware
less
than
40%
of
experiments
have
actually
used.
Hardware
and
80%
of
those
experiments
use
less
than
60
nodes,
so
not
mu
and
mu.
F
If
you
see
most
of
the
documents
in
a
lot
of
working
group,
talks
scaling
to
thousands
of
nodes
while,
while
while
there
are
no
practical
frameworks
which
can
actually
deliver
on
that
task,
so
this
work
we
had
started
during
ITF
96.
It's
called
white
fill
and
this
is
basically
how
it
operates.
You
know
you
you
have
you
have,
so
you
have
the
realistic
protocol
stack
quantity
right
and
then
you
have
an
s3
or
only
plus,
plus
right
now,
a
minute
plus
plus
is
not
integrated.
Only
the
NS
3
is
integrated
in
this.
F
You
can
use
real
Network
stack
in
this
and
the
same
network
stack
can
be
as
it
is
migrated
to
the
hardware.
So
the
advantage
is
you,
you
you'll,
be
able
to
experiment
with,
and
it
can
scale
as
well.
It
can
scale
to
find
it
nodes
on
on
a
regular
laptop.
It
supports
an
s3
as
of
now,
but
it
can
support
ideal
air
ideal
air
is
a
is
the
context
in
which
in
which
you
can
actually
have
configurations
which
can
be
shared
to
everyone
else.
F
You
have
deterministic
models
where
the
same
thing
can
happen
over
and
over
again,
and
you
can
share
the
configuration
to
someone
else
question
a
vision.
Yeah
I
have
a
general
question
from
the
previous
slide.
The
statistics
that
you
have
shown
over
there
in
that
pie
chart
so
the
small
amount
of
coordinate
percentage
percentage
for
coordinate
I
mean.
Is
it
because
of
its
quali
qualitative
reason?
Or
is
it
because
of
prohibitive
cost
and
I?
Well,
I.
Don't
know
about
that
because
the
paper
doesn't
talk
about
it.
This
is
the
data
from
the
paper
that
have.
C
F
Have
we
have
done
experiments
in
Kuja
and
s3
ohm,
net
and
WS
net
as
well,
because
I
am
also
ended
attached
to
University
and
quality's
a
pain
working
for
anticipation,
I,
don't
know
where
the
quality
is
a
paid.
It's
a
paid
tool,
I,
don't
know,
I,
don't
even
know
about
that.
Okay
yeah!
So
so
this
is
what
we
have.
F
Essentially,
what
we
have
is
we
have
individual
protocol
stacks
operating
and
we
have
a
virtual
airline
which
operates
only
the
physical
and
Mac
layer
inside
the
airline
and
it
the
the
the
network
stack
whenever
it
delivers
a
packet.
It's
delivered
to
a
corresponding
virtual
node
in
the
airline,
using
a
message
queue
right
now.
F
The
message
queue
is
implemented
using
abstract
UNIX
domain
sockets,
but
the
realism,
the
wireless
realism
that
you
get
is
from
actually
the
industry,
but
the
best
part
is
that
you
don't
have
to
change
your
code
or
you
don't
have
to
change
your
design
to
suit
in
s3.
You
can
use
the
existing
protocol
stack
in
context.
When
is
three,
so
that's
a
so
quantity
right
and
right
is
already
supported.
Open
thread.
Support
is
in
progress.
It's
it's
still
not
there.
F
Every
stack
line
here
is
an
individual
process,
so
what
we
do
essentially
is
every
stack
line.
For
example,
kontiki.
We
have
added
support
a
platform
support
for
white
fill.
It
takes
the
packet
from
quanta
key
and
sends
it
to
the
NS
three
corresponding
virtual
node
in
the
NS
three
and
then
it
goes
go
on
to
the
target
node,
and
then
it
comes
back
to
the
stack
line
again.
So
maximum
60,000
nodes
could
be
scale,
but
we
have
practically
tested
it
for
1,500
nodes.
F
As
of
now,
we
don't
have
a
machine
that
powerful
to
run
60,000
nodes,
but
anyways.
We
have
ran
it
for
1,500
node
at
max.
The
airline
stack
line
and
communication
line
are
all
decoupled,
such
that
the
new
new
new
stacks
could
easily
be
added.
Here
we
have
planned
to
add
sapphire
as
well
in
the
near
future.
It
already
we
have
tested
Interop
between
quantity
and
right
in
the
in
this
platform.
So
this
is
how
it
looks.
F
You
know
there
are
a
lot
of
configuration
that
has
to
be
input
in
this,
but
what
we
are
trying
to
do
is
trying
to
synergize,
or
we
are
trying
to
give
all
this
common
configuration
to
the
whiteford
core
and
then
let
the
white
coat
give
you.
The
results
of
the
OEM
is
same
across
all
the
stack
lines.
So
even
if
you
use
quantity,
alright,
your
onm
is
the
same.
The
the
the
white
fill
integrates
with
all
the
oils
for
individual
stacks,
so
case
to
be
one.
F
So
this
has
been
one
of
the
most
important
draft
that
we
have
been
working
in
roll
most
of
the
data
that
we
have
we
have
gathered
for
this
particular
work
has
been,
has
been
taken
using
this
framework.
Without
this
framework
we
wouldn't
have
been
possible
to
you
know,
get
Candice
get
the
kind
of
results.
For
the
first
time
we
were
able
to
test
inter
up
between
riot
and
quantity
at
scale,
and
we
found
lot
of
issues
with
the
primary
issue
been
that
the
DAO
aggregation
is
not
handled
in
quantity.
F
So
there
is
some
messaging
that
needs
to
be
handled.
So
it's
not
handled.
We
reported
that
arc
welder
fragmentation
issue
on
write
mailing
list.
This
was
discussed
like
any
year
year-and-a-half
before.
Basically,
essentially,
we
could
read
Interop
at
scale
network
convergence
time
for
three
hundred
nodes
quantity
nodes
in
Kuja.
It
reports
less
than
twenty
seconds
if
you
use
Kuja,
but
but
if
you
try
to
do
the
same
thing
with
why
white
field
or
with
realistic
hard
with
real
hardware,
the
convergence
time
is
in
minutes.
F
So
there
is
clearly
a
major
difference
between
what
you
see
in
the
simulation
platforms
versus
what
you
really
get
control
over.
It
was
very
different,
so
the
control
over
it
when
you
test
it
with
Kucha,
is
very
different.
You
get
very
little
control
control
over
it
because
the
very
less
losses,
the
interference
is
less
then
our
interference
model,
but
those
are
not
realistic
case.
Two
we
have
NP
de
which,
which
showed
the
impact
of
optimized
value
in
validation
on
overall
network.
F
F
Neighbor
management
policy,
which
the
draft
which
we
have
here
in
albuquerque,
expired
but
yeah,
so
we
we
showcased,
we
already
had
presented
our
performance
data
last
time
in
a
week.
It's
about
the
impact
of
neighbor
cash
policy
on
the
overall
network,
stabilization,
how
stable
your
network
will
run
if
we
have
limited
neighbor
cash
size,
the
minimal
fragment
draft
again
we
had
presented
this
in
in
in
in
L
wig,
as
well
as
six
low
before
it
shows
the
impact
of
a
two
2.15
dot
for
single
channel
mode
of
operation
on
fragment
forwarding.
F
So
all
this
data,
all
the
data
that
I
am
talking
of,
is
available
with
the
detailed
configurations
and
observations
and
the
raw
data
on
the
on
the
same
whiteford
frame
for
github.
So
there's
another
interesting
piece
of
work
which
started
last
year
in
called
as
IOT
bench.
It's
a
community
effort
to
better
evaluate
and
compare
low-power
wireless
network,
the
principles
of
AIT
bench
and
while
Whitefield
are
more
or
less
similar.
So
basically
we
did.
F
The
aim
is
that
the
developers
the
implementers
should
be
able
to
share
their
configurations,
share
their
observations
and
it
should
the
data
should
be.
Reproducible
IOT
bench
provides
an
excellent
conceptual
framework.
It
clearly
abstracts.
What
are
the
configurations
that
are
required:
the
performance
metrics
eventually
and
Whitefield
in
the
und
going
forward.
We
will
try
to
use
lot
of
recommendations
from
this
work.
F
C
C
Publicize
with
the
within
the
IOT
block
that
Steve
writes
because
I
think
this
has
implications
across
several
working
groups
so
based
on
this
kind
of
more
real-world
simulations.
We
had
these
these
these
troughs,
which
were
then
affecting
these
working
groups.
Kind
of
showing
that
why
having
realistic
implementations
in
the
ITF
is
is
our
way
of
working
a.
H
Solution,
I
think
I
can
do
even
better.
We
can
go
on
IETF,
durog
blog.
If
you
want
right
so
we
can
I
can
like
introduce
you
to
Greg.
We
can
probably
write
something.
We've
done
this
before.
We've
done
something
for
lp1
like
we
wrote
like
an
article
like
I
sat
down
and
with
Pascal
and
Alex
and
wrote
something
so
if
you're
interested
like
you
know,
I'll
talk
to
Greg
and
we
can
figure
out
how
we
want
to
write
about
it.
Ok,
so
it
goes
an
idea
or
I
have.
F
H
Like
there's
been
like
lot
of
drafts
like
I,
especially
like
no
earlier
in
the
idea
of
which
had
like
test
vectors
directly
in
the
RFC's,
like
so
I,
think
there's
like
pre-existing
stuff
for
that.
So
I,
don't
see.
Why
not
I
like
that?
You
can
publish
this
like
configuration,
kind
of
thing,
I,
don't
see
why
it
should
be
an
issue,
but
a
blog
entry
would
be
just
as
good
I
think,
but
if
you
can
publish
it
and
we
can
reference
it
somehow,
it
should
be
ok
too,
and
it's
pretty
much
permanent
as
well.