►
From YouTube: IETF96-MANET-20160720-1400
Description
MANET meeting session at IETF96
2016/07/20 1400
A
A
A
A
A
So
working
group
overview
we
have
not
met
at
the
last
two
ITF.
This
is
the
first
one
we've
had
in
a
while.
We've
had
some
interim
meetings
we
were,
we
were
on
the
we
were
put.
They
put
to
task
to
finish
up
the
documents
that
we
had
and
get
them
out,
we're
very
close
to
doing
that,
I'm
not
going
to
go
over
the
whole
issue
and
the
whole
happenstance
with
a
odv
be
to
that
happened.
A
A
The
other
one
is
on
my
plate
is
OS
r,
seck
threats,
the
information
one
we
had
a
last
call.
We
didn't
have
really
any
comments
on
that.
So
I'm
going
to
take
it
upon
myself
to
do
a
thorough
review
and
either
write
up
the
Shepherd
document
or
not
I,
don't
think
it'll
be
a
big
deal,
but
I
do
owe
them
at
least
a
thorough
review
of
that
the
rest
are
proceeding
nicely
and
the
only
other
document
that
is
kind
of
in
limbo.
Right
now
is
the
OLS.
A
A
It
had
passed
last
call
Chris
got
in
some
very
pertinent
comments
right
after
that,
so
we
pulled
it
back.
We
did
it
again
and
it's
still
kind
of
in
limbo,
they're
working
out
the
details
and
until
they
kind
of
agree
and
I
agree
with
them
or
Stan
agrees
with
them.
It's
going
to
sit
where
it's
at.
So
please
read
that
draft
and
get
comments
back.
I
think
it
is
a
useful
thing
to
have.
If
we
do
it
right,
I
don't
want
to
break
things
when
we
do
it.
That's
the
main
thing
for
me.
A
A
So
I
don't
have
a
slide
on
that
right
now
I
can
I'll
try
to
pull
it
up
at
the
end.
We
do
have
some
milestones
coming
up
and
they're
relatively
tight
schedule.
They
include
many
management
and
kind
of
how
we
deploy
mayonnaise.
Lots
of
people
have
been
asking
for
that
outside
of
a
working
group,
and
we've
had
two
attempts
at
that
before,
and
they
kind
of
missed
the
mark
on
either
end
either
too
generic
or
too
specific.
So
we
want
something
kind
of
in
the
middle.
A
So
authors
of
those
two
documents,
I
would
encourage
you
to
try
to
come
together
and
work
on
that.
I
see
one
of
them
james
here,
hopefully,
oricon
and
thomas
are
interested
in
working
on
that
again,
but
others
are
welcome
as
well,
and
the
other
ones
are
dlf
extensions,
olsr
maintenance
or
other
extensions,
20
srb2
and
the
man,
a
fib
man,
a
multicast
fib,
which
I'm
going
to
give
a
presentation
on
and
I
need
more
people
participating
in
that,
and
hopefully
this
will
help
facilitate
some
discussions
on
how
we
restructure
this.
So
the
next
one.
B
A
So
we
are
as
a
song.
We
are
tasked
with
designing
a
forwarding
information
base
for
multicast
in
mayonnaise,
so
I'm
going
to
be
presenting
a
little
bit
about
what
we've
learned
at
NRL,
with
our
implementation
of
SMF
and
our
implementation
of
elastic
multicast,
which
Brian
presented
a
few
I
TFS
back
kind
of
the
structure
of
our
code,
because
in
the
next
slide
and
kind
of
what
we've
learned
in
what's
missing
in
the
current
SMF
draft
and
how
we
can
capture
it
in
another
draft
and
separate
things
out
a
little
bit
better.
So
real,
quick
background.
A
Smf
is
a
simplified
multicast,
forwarding,
protocol
and
experimental
and
the
man
a
working
group.
It
does
man
a
wide
broadcasts.
It
doesn't
allow
you
to
limit
where
the
broadcast
goes.
It
goes
all
the
way
through
the
man,
a
network
they
uses
CDSs
connected
dominating
sets
much
like
olsr
and
other
many
routing
protocols.
It
devotes
a
lot
of
the
text
in
there
to
duplicate
packet
detection
and
at
the
time
we
didn't
know
what
worked
and
what
didn't
it
has
both
hash
based
and
I
debased
mechanisms,
and
we
found
through
practice
that
it
depends
on
your
network.
A
Your
traffic,
your
device,
is
what
you
want
to
use,
so
we're
kind
of
leaning
right
now
to
leaving
them
both
in
there
as
optional,
because
there
are
some
networks,
you
want
to
use
hash
and
there's
some
that
you
want
to
use
ID.
It
really
depends
on
what
kind
of
network
you're
using
with
hash
certain
traffic
patterns,
will
give
you
a
lot
of
false
positives
and
you'll
end
up
dropping
a
lot
of
packets
that
you
otherwise
would
want.
A
Similarly,
with
hash,
you
can
end
up
draining
your
batteries
when
your
mobile
device
was
really
fast.
Alternatively,
packet
IDs
is
a
big
security
hole.
If
you
change
that
ID
to
you
know
somewhere
in
the
future,
and
then
all
the
other
packets
get
dropped
because
they're
in
the
past
way
past
and
nothing
gets
through.
A
Have
a
slide
on
that
they're
statically
configured
right
now
and
they
they
do
interoperate
to
some
extent
their
caveats
in
that,
if
you're
doing
duplicate
packet
detection
with
the
IDS,
the
nodes
that
are
injecting
multicast
into
the
man,
a
viet
gateway,
andrey
forwarding
and
rebroadcasting,
their
sequence
IDs
or
if
their
sources
in
the
men
a
they
need
to
sequence,
the
IDs
otherwise
they're
going
to
get
dropped
by
the
nodes
that
are
going
to
do.
The
ID
based
forwarding,
because.
A
But
otherwise,
if
those
injection
points
are
taken
care
of,
then
everything
would
work
and
there
is
some
merit
to
doing
kind
of
a
hybrid
where
you
mark
the
package
with
an
ID
to
give
it
a
different
hash.
So
you
kind
of
get
both,
but
you
also
get
the
drawbacks
of
both
and
it's
they're
not
intended
to
scale
a
large
networks
because
you're
flooding
the
entire
network.
So
you
really
don't
want
to
use
this
in
600
nodes
thousand
node
networks.
It
would
be
very
inefficient.
A
A
Space
and
performance
suffers
because
of
that
when
you're
scraping
all
the
packets
up
in
the
user
space
and
then
sending
them
back
down,
so
we
want
a
better
design
where
we
have
a
forwarding
bit
that
all
the
rules
are
clearly
defined
and
how
to
control
it
is
clearly
defined
so
that
we
can
push
that
part
down
and
keep
the
control
up
in
user
space,
but
have
the
forwarding
take
place
more
in
the
kernel
space
design-wise?
We
want
to
design
it
that
way,
so
it
people
can
implement
it
that
way.
A
Easily
packets
right
now
are
disseminated,
like
I,
said,
to
the
entire
MANET.
That's
fine
for
small
networks,
where
everyone
wants
to
hear
all
the
multicast
traffic,
but
in
large
networks
that's
really
not
good.
So
there's
also
no
group
membership.
You
don't
know
if
your
man
a
wants
a
specific
multicast
address
or
not,
if
anyone's
listening
or
not
you
just
flood
it.
There's
no
rules
for
different
multicast
addresses
and
that's
an
issue
that
we
should
address:
CTS
algorithms.
Currently,
the
algorithms
in
the
appendix
of
the
SMS
draft,
are
only
nominal
algorithms.
A
There
are
others
that
could
be
developed,
but
the
ones
that
are
there
do
not
support
multiple
interfaces.
Well,
they're,
either
on
or
off
in
terms
of
forwarding
and
flooding.
There
are
other
algorithms
out
there
that
can
do
multiple
interfaces
a
lot
better,
but
the
algorithms
we
define
have
not,
and
we
should
define
the
40
information
base
to
support
better
control.
E
Rick
Tyler,
have
you
looked
at
using
broadcast
wallace
links
so
using
the
broadcast
facility
of
the
lower
layer
to
assist
the
multicast
as
part
of
the
SMS
work.
Not
quite
sure,
I
understand
your
question.
Okay.
E
So
if
you've
got
a
radio
system
which
has
a
effectively
a
shoutcast
channel
on
there,
so
the
ability
to
beacon
out
to
all
receivers
that
are
listening,
integrating
that
within
your
larger
multicast
topology
so
and
the
one
packet
effectively
costs
the
same,
whether
it
goes
to
one
endpoint
or
all
of
them
right,
OH
flooding
suddenly
actually
becomes
a
cheap
option.
I
wonder
whether
you've
looked
at
integrating
that
into
any
of
the
SMF
stuff.
So
far,
we.
A
Generally
use
the
multicast
on
a
radio
if
it
has
that
we
like
would
send
it
out
to
all
of
them
here.
If
you
have
different
interfaces,
I
gave
a
presentation
a
while
back
on
how,
if
you
have
multiple
interfaces,
it
may
be
redundant
to
send
it
back
out
the
same
interface
it
came
in
on
because
it
might
be
a
wired
link
and
everyone
already
got
the
packet
on
that
it
could
be
a
directional
antenna.
A
point-to-point
link
and
I.
A
Don't
want
to
send
a
packet
back
out
on
that
interface
because
it's
going
to
a
guy
who
already
hasn't.
He
send
it
to
me
the
current
algorithms.
Don't
allow
you
to
do
that
right.
So
there
are
other
algorithms
and
very
simple
ones,
says
you
know
if
everyone,
if
you
have
only
one
neighbor
on
that
link,
don't
send
it
back
out
there.
You
could
reduce
it,
but
there's
no
algorithms,
it's
not
designed
with
that
in
mind.
A
Brian,
my
colleague
who's
co-op,
whose
main
author
of
NRL
SMF,
would
disagree
with
me
on
this
last
bit
that
fording
rules
are
not
well
defined
with
multiple
interfaces,
and
my
point
here
is
that
in
the
SMF
draft,
there's
a
lot
of
text
dedicated
to
gateways
how
to
ricci,
quence
and
forward
over
these
interfaces,
but
there's
not
a
lot
of
text
regarding
algorithmic
control
of
what
gets
forwarded
where
based
upon
what
interface
is
coming
in
on
and
then
to
go
out
on,
and
that's
kind
of
what
I'm
talking
about
here
and
duplicitous.
A
One
is
talked
about
on
how
to
do
it.
Put
then
various
algorithms
you're
going
to
want
dpd
to
work
either
on
the
incoming
interface
or
on
outgoing
interfaces
or
both
depending
on
how
your
forwarding
the
traffic.
Sometimes
you
want
to
do
it
on
the
outgoing
interface,
because
node
a
wants
it
to
go
somewhere,
but
this
guy
over
here
wants
you
to
go
somewhere
else.
So
you
it's
this
even
though
it's
the
same
packet,
you
wanted
to
go
out
a
different
interface,
even
though
the
first
guy
didn't
want
it
to
go
next.
A
A
A
It
has
a
remote
control
interface
that
we've
defined
it
that
that
interface
is
not
defined
in
the
SMF
draft,
because
the
draft
just
says
either
flood
or
not
you
use
these
algorithms
or
not.
Smf
is
one
big
happy
thing.
Well,
we
separated
that
out.
The
algorithmic
control
is
in
the
routing
protocols
or
the
neighbor
discovery.
Protocol
and
sm
f
is
the
forwarding
engine
the
forwarding
bit
and
it
has.
We
have
a
very
simple
api
to
control
it.
A
We
want
to
expand
on
that
because
there's
more
things
that
the
forwarding
engine
can
do
that
we're
not
opening
up
the
api
to
do.
We
know
what
we
want,
but
we
haven't
defined
that
api.
Yet
it's
still
the
very
simple
because
the
algorithms
don't
define
those
well,
it's
still
very
simple:
yes,
you
forward
on
all
interfaces.
No,
you
don't
next
slide.
A
So
this
is
a
current
SMF
architecture.
And
one
thing
to
note
here
is
the
SMF
interfaces
on
the
left
it
can
take
in
from
multiple
different
interfaces.
So
you
can
have
multiple
physical
interfaces
and
have
them
map
to
a
single
SMF
interface.
That
then
does
duplicate
package
detection.
It
puts
it
out
on
various
SMF
interfaces
that
are
also
mapped
to
physical
interfaces
so
that
it
can
reef
or
word
on
a
set,
a
subset
or
all
of
the
interfaces
that
you're
running
on,
and
you
can
have
different
rules
associated
with
those
outbound
interfaces.
A
So
this
is
a
conceptual
slide
again
illustrating
that
we
want
to
separate
out
the
control
from
the
forwarding
and
there's
another
little
bit
here
and
that
the
14
information
base
should
be
a
conceptual
design
on
what
the
fording
engine
uses.
It's
not.
It
should
be.
It
should
be
kind
of
like
a
table
and
NH
DP,
that
it
defines
the
table
and
how
things
operate,
but
it's
not
necessarily
a
physical
thing
and
it
might
be
represented
in
the
40
engine
in
some
other
way.
A
We
have
an
arrow
going
back
to
the
control
plane
and
that
is
for
our
work
in
elastic
multicast.
We
needed
feedback
on
what
new
packets
were
coming
into
the
network
and
what
to
do
with
them,
because
if
you're
going
to
do
group
based
stuff,
you
need
to
know
what's
happening
in
your
network
and
if
you
want
to
forward
that
packet
or
not
it's
into
more
detail
in
a
second
next
slide.
So
this
is
our
current
design.
A
You
have
n
HTTP
or
another
control
algorithm
up
at
the
top.
You
have
your
SF
s:
MF
management,
nib
and
the
mid
is
kind
of
in
pieces
as
well,
because
some
of
it
controls
the
algorithm-
and
that
goes
over
to
na
GP
and
some
of
it
controls
what's
happening
with
your
duplicate,
pocket,
detection
and
re
sequencing
on
interfaces
and
that
sort
of
thing-
and
that
goes
down
to
your
SMF
instance
down
at
the
bottom.
So
the
SMF
mibbe
is
kind
of
talking
to
both
pieces
because
of
how
the
SMF
was
designed.
I'm.
C
C
A
Is
available
and
we
actually
are,
we
have
some
limited
amount
of
the
SMF
management
mid
available
as
well.
James
would
have
more
information
on
that,
but
we
did.
We
did
do
some
of
the
mid
design
as
well
and
I,
say
undefined
algorithmic
control
here,
even
though
we
have
our
own
API
that
talks
it
uses
depending
on
your
system.
It
uses
different
methods
of
talking
from
one
instance
to
another
of
two
different
damon's
running,
but
it's
undefined
in
terms
of
the
documents
we've
defined,
an
API
that
allows
you
to
control
the
SMF.
A
A
So
we
we
want
it
to
to
change
to
something
more
like
this,
where
there's
a
richer
amount
of
filters
and
state
in
SMF
that
you're
going
to
control,
affording
information
base
you're
going
to
control
on
this
standardized
fording
information
base,
API
that
would
control
what's
happening
in
the
last
slide.
I
said
it
was
undefined
we
defined
one,
but
it's
not
specified
anywhere
and
that's
what
we
want
to
work
on.
E
Rick
Taylor
again
paypal-
and
this
is
more
of
a
question
to
the
chairs
Leno
you're,
one
of
the
chairs
enter
Alvaro-
is
working
on
an
API,
a
suitable
thing
for
the
working
group
to
be
working
on
I,
understand
working
on
that
the
conceptual
fib
definition
very
useful
and
then,
as
part
of
describing
the
phpbb
you
could
go
into
detail
about.
Well.
E
Updates
in
these
ways
are
are
useful:
you're
starting
to
drift
off
internet
comfy
yang
II,
oh
I
want
to
update
an
information
base
realm
or
we're
getting
into
well,
I'm
using
unix
domain
sockets,
and
this
is
what
my
capi
looks
like
and
I'm
not
quite
sure
whether
this
is
that
work.
Specifically,
it's
good
for
should
be
done
in
the
working
group.
Fib
yeah
absolutely
sounds
great
API
I'm,
uncertain
I'm,
looking
to
the
chairs,
and
over
over
for
this,
I.
A
Agree
with
you
somewhat
at
a
at
a
very
minimum,
we're
going
to
have
to
just
define
what
is
allowed
and
not
allowed
yeah
in
the
same
way
you
find
in
NH
TP
is
what
you
can
and
can't
add
externally
to
it.
So
we
might
not,
you
know,
say
specifically
what
the
messages
look
like
and
how
they're
getting
past,
but
how
it
can
be
changed
to
point
in
a
strong
direction
on
an
API
that
could
be
written
to
do
these
things.
Okay,
that's
reasonable!.
A
Next
time,
this
is
just
a
quick
overview
of
elastic,
multi-gas
and
I'm
presenting
this
here,
because
this
is
driving
a
lot
of
our
work
at
terms
of
what
we've
learned
about
what
we
need
in
the
forwarding
information
base,
a
quick
recap
on
elastic
multicast,
it
its
uses
SMF
to
broadcast
out
all
the
multicast
traffic
SMF
informs
a
controller
when
new
flows
are
happening.
The
controller
will
then
send
out
acts
to
see
who
wants
this.
A
If
anyone
wants
this
and
if
no
one
wants
it,
it
ends
up
turning
off
that
flow,
so
it
will
reduce
the
amount
of
flooding
happening
in
your
network
and
it's
a
very
simple
method
of
doing
it.
It
uses
multicast,
joins
and
acts
to
see
who's
joined
and
then
it
kind
of
it
and
it
also
takes
into
account
very
dynamics.
So
if
your
network
is
very
dynamic,
it
won't
slow
things
down
as
much
and
it
will
let
it
flood
around
more
brian
has
more
on
that
in
the
previous
presentations.
A
Another
key
thing
is
that
its
flow
based
and
I'll
get
to
that
in
a
minute
next
again,
just
illustrating
that
for
elastic
multicast
to
work
and
other
algorithms,
one
that
it's
not
a
multicast
algorithm,
but
it
is
an
algorithm,
is
reactive
protocols
need
to
know
when
a
packet
is
going
out
and
there's
no
destination,
so
they
inform
up
higher.
So
something
like
this
could
work
for
a
unicast
routing
protocol
or
be
used
by
it.
The
feedback
feature
is
kind
of
important
and
the
flow
I'm
going
to
get
what
I
mean
by
flow
in
a
minute.
A
A
So
in
our
SMF
implementation
we
have
an
idea
of
a
flow
and
a
flow
and
contains
a
destination
source
or
protocol
and
nominally
an
incoming
interface.
So
you
can
categorize
a
packet
based
upon
this
flow
and
that's
kind
of
how
it's
how
it's
being
routed
is
based
upon
its
flow
ID
and
its
flow
isn't
going
to
really
change.
A
And
we're
still
working
on,
we
have
some.
We
have
this
working.
There
are
other
ways
to
make
this
work
as
well.
It
can
get
really
complicated.
You
can
have
a
default
way
of
say
if
it's
multicast
I
flooded
out
on
my
interfaces,
I
inform
higher
up
and
then,
if
it's
a,
if
it's
a
specific
multicast
I
know
no
one's
interested
in
I
drop
it
because
it
matches
that
source
destination
and
I
know
that
no
one's
interested
in
that
flow,
so
I
dress
drop
it
next.
A
So
what
do
we
do?
What
do
we
do
with
the
flow?
Do
we
just
Ford
it
or
drop
it?
Well,
we
found
that
we
don't
just
forward
it
or
drop
it.
There
are
actually
other
things
we
want
to
do
and
our
implementation
right
now
has
you
either
forward
it.
You
can
forward
it
with
a
limited
rate.
So
we
have
a
cue
that
limits
how
many
packets
can
go
out
at
a
certain
rate.
That
gives
you
a
priority
basically
priority
or
you
can
reduce
the
amount
of
flow
you
get
more
control.
A
A
You
can
queue
up
a
packet
and
wait
first
fixed
amount
of
time
and
then
drop
it
or
you
can
send
an
air
just
to
like
no
route.
Those
are
ideas
again,
stressing
that
the
the
the
forwarding
information
base
should
not
just
be
a
unidirectional
flow
of
information.
The
foreign
information
base
should
send
stuff
back
up
to
the
controller
based
upon
the
flow
and
what's
happening
next
and
as
I
kind
of
hinted
at
it.
Should
we
should
we
design
this
with
only
multicast
in
mind?
Is
it
useful
for
other
things?
Are
we
getting
too
deep?
A
E
E
D
D
E
We
should
be
interfacing
with
them,
rather
than
inventing
our
own
little
bespoke
solution
and
discovering
that
the
big
system
integrators,
because
money
is
always
exists
within
a
bigger
picture
that
there
at
the
edge,
but
there's
the
rest
of
the
system
in
there
and
if
we
can
use
the
same
tooling.
This
is
moving
on
from
the
mid
conversation.
So
this
cross
over
to
the
management
discussion
is
I
think
we
should
be
looking
at
some
of
the
stuff
that
I
to
RS
are
doing
with
net
conf
to
solve
a
similar
but
different
problem.
E
E
Letter
to
thought,
I,
Cisco,
completely
brick,
one
of
things
that
you
may
want
to
do
faster
rather
than
slower,
is
yes,
who
has
been
working
with
the
net
mod
guys
quite
a
bit.
They're
still
I
think
something
lost
in
translation
there
for
them
to
understand
the
requirements
from
a
router,
for
example.
A
Is
it
time
for
general
questions
you
about
this?
Yes,
I'm
I
believe
that
was
my
last
slide.
Okay,
oh!
This
was
just
a
slide
showing
that
we're
looking
at
real
code
in
kernels
that
are
and
how
we
can
modify
them
to
get
some
kind
of
forwarding
engine
in
them
in
an
easy
way.
That
was
all
that
was
the
last
night.
Yes,
open
open
for
questions,
comments.
F
A
You
different
group
memberships.
The
group
membership
part
is
part
of
the
control
algorithm,
that's
going
to
control
what
groups
get
forwarded
or
not,
but
in
terms
of
the
forwarding
base,
it's
just
another
identifier
on
a
flow.
It's
a
multicast
address
the
group
address
so
yeah
you
could
you
could
flood
certain
group
addresses.
You
can
send.
Other
group
addresses
out
a
different
interface.
You
can
have
different
rules
based
upon
that
the
group
address,
but
we
we
consider
them
just
it.
F
Right
but
the
dirt
mean
there
could
be
some
columbia,
I'm
not
sure,
but
maybe
some
danger.
Let's
say
you
had
500
nodes
or
a
thousand
nodes
in
the
network,
and
there
were
three
of
them
were
scattered.
You
know
to
get
to
be
part
of
a
multicast
group,
then
the
total
amount
of
control
signaling
to
find
them
somehow
could
even
be
worse
than
just
flooding.
I,
don't
know,
depending
on
the
mobility
and
besides
that.
F
A
So,
to
give
you
a
quick
overview,
real
quick,
the
last
multicast
work,
we
did
worked
exactly
how
you're
saying
a
use
of
CD
s.
It
uses
a
default
SMF
algorithm
it
gets
sent
out,
it
would
use
the
hybrid
method
of
14
out
the
packet,
so
they
would
get
sent
out.
Then
the
controllers
would
would
be
told
hey.
We
got
this
multicast
packet.
What
do
you
want
to
do
and
they
would
send
out
messages?
The
control
would
send
out
extra
messages
using
n,
HTTP
and
other
messages
to
say.
A
Does
anyone
want
this
stuff
or
you
want
to
join
this
group?
And
if
no
one
said
yes,
they
would
turn
that
flow
off.
They
would
turn
that
group
off
and
as
people
said,
yes,
they
would
keep
it
on.
They
would
add
a
rules
to
do
it.
Instead
of
a
hybrid
approach,
they
would
do
the
CD
s
flooding.
So
at
worst
case
it
would
work
the
same
as
CD
s,
flooding
best
case.
It
would
prune
off
everything
and
it
would
it
wouldn't
flood
at
all.
Can.
G
F
F
A
G
G
As
we
said
earlier,
dilip
is
in
ad
review.
The
ad
did
come
back
with
comments.
We've
addressed
those
comments
and
posted
a
a
deal
up.
23
yesterday
day
before
one
of
the
two,
the
biggest
change
was
to
use
RFC
5082
or
is
it
5802
I
forget,
which
it's
a
GTS
n
on
the
team
on
the
TCP
session?
There's
some
discussion
about
that
going
on
on
the
man
a
list
right
now
and
we
will
follow
up
with
that
discussion.
G
I'd
like
to
follow
up
with
our
discussion
before
we
give
it
back
to
the
ad
okay.
So
that's
where
we're
at
their
the
other.
The
other
issue
is
that
we
we
had
disallowed
some
data
items
on
destination,
announced
response
and
an
item
was
brought
to
the
list
that
we
should
allow
the
same
data
items
on
destination,
announce
response
that
we
allow
on
like
desktop
and
that's
been
changed
as
well.
So
next
slide,
please
and
in
terms
of
the
credit
extension,
it's
also
an
ad
review.
The
ad
came
back
with
comments.
G
They
have
not
been
fully
addressed
yet
so
it
has
not
been
resubmitted
to
the
ad.
The
biggest
issue
revolves
around
credit
window
synchronization
and
that's
work
in
progress.
So
next
slide,
please.
The
other
thing
I
wanted
to
talk
about
was
an
extension.
That's
not
yet
been
submitted
to
the
working
group.
The
one
that
were
chartered
for
we
had
talked
for
a
couple
of
I
ETFs
now
about
deal
up.
Extensions
for
metrics
by
traffic
class
are
essentially
metrics
by
dscp
code.
Point
I've
got
that
I'm.
G
Writing
that
it's
not
ready
to
post
yet
expect
the
draft
00
draft
it's
in
the
next
couple
of
weeks,
and
once
we
get
that
posted,
we
can
talk
about
it
on
the
list
to
make
the
necessary
changes
and
try
to
drive
for
first
thing
would
be
accepting
it
as
a
working
group
document
and
then
we'll
go
forward,
but
the
work
is
in
work
is
in
process
and
I.
Think
that's
all
I've
got
on
d
lab
so,
but
I
see
people
running
to
the
microphone
so.
E
H
Or
2
comments,
so
metrics
bike
traffic
class
sounds
interesting.
I'd
be
I'll,
be
interested
to
see
how
you
manage
the
mapping
of
traffic
classes
to
cues
and
because
usually
it's
the
cues
that
have
the
metrics,
not
necessarily
traffic
classes,
because
you
have
multiple
traffic
classes,
mapping
the
same
cues
so
that'll
be
interesting
and
have
you
thought
about
credit
by
traffic
class
or
bike?
You.
H
E
This
is
it
it's
Rick
Taylor
again,
it's
not
a
dealer
question.
It's
a
process
question
following
on
from
lose
comment
that
he
and
some
of
his
guys
he's
working
with.
Also
have
some
extensions
I'm,
not
sure
how
familiar
people
are
with
the
inner
workings
of
Dean
up.
Of
course,
you've
all
read
all
the
drafts
because
you've
come
come
to
the
working
group.
The
extension
mechanism
is
within
deal
appears.
Both
parties
announced
the
extensions
they
support
as
part
of
the
negotiation
at
session
initialization.
E
G
H
E
As
Rick
Taylor
again,
just
as
a
follow
on
from
that
I
understood,
I
want
to
avoid
having
optional
optional
things
again.
So
I
said
I
have
one
document
with
three
extensions,
which
kind
of
go
hand
in
hand,
but
actually
I'm
only
supporting
one
of
them
out
of
the
such
a
set
of
three.
So
I
think
a
little
bit
of
care
needs
to
be
taken
with
this
I.
C
Like
the
Julia
scrubber
check,
I'd
like
to
pull
in
the
other
direction,
I
like
big
documents
that
have
a
single
introduction
and
you
understand
what
you're
reading
and
there's
an
order
and
as
you
are
implementing
you
get
all
the
background
in
a
single
document.
Rather
than
chasing
pointers
between
hundreds
of
documents.
And
so
I
would
like
to
encourage
the
group.
I
know
it's
more
difficult
for
the
group
and
it's
more
difficult
for
the
editors.
But
I
would
like
to
encourage
the
group
to
make
big
documents
list
of.
G
I
think
I,
as
I
interpret
the
point
blue
made
its
that
as
a
vendor,
it's
hard
to
go
to
your
customers
and
say
I
support,
sections,
38
and
17
of
RFC
8989
right.
Yes,
that's
not
really
a
good
deal,
but
it's
not
a
good
idea.
So,
if
you're
going
to
write
the
document,
you
either
support.
What's
in
it
or
you
don't
so
it
lends
credence
to
the
idea
from
a
functional
perspective,
get
it
down
to
something:
that's
bountiful
and
quantifiable
and
then
publish
that
and
you
need
to
publish
multiple
documents
if
you're
doing
multiple.
C
Things
he's
absolutely
right
and
I'm
right
too,
and
he
has
he's
pulling
in
the
direction.
That's
convenient
for
the
vendor
I'm
pulling
in
the
direction
that's
convenient
for
the
implementer
you're,
probably
pooling
in
the
direction.
That's
convenient
for
the
chair
and
we'll
end
up
at
the
point
that
suits
everyone
or
nobody.
A.
C
H
So
when
I
specify
an
RFC
I,
don't
have
I,
don't
know
if
there's
too
many
options,
I
don't
know
what
I'm
going
to
get
and
what's
really
cool
is,
if
you
have
enough
options
and
I've
personally
been
involved
with
a
spec
that
failed
this
way,
if
you
have
too
many
options,
you
can
get
to
vendors.
That
say
they
implement
the
same
RFC
and
they
don't
interoperate
or
deliver
the
same
thing
that
we're
not
doing
our
job.
If
we
do
that,
that's
that's
the
real
issue.
E
Rick
Taylor
again
just
take
you
up
on
Judas's
first
point,
which
was
I
like
a
big
document
because
I,
like
all
the
intro
stuff
in
one
place,
it
is
in
one
place.
It's
called
dealer
I
we're
talking
about
extensions
to
a
core
document
that
describes
what
it
is,
how
you
do
it
what's
the
minimal
you
must
support,
so
I
think
we've
kind
of
satisfied
that
requirement
the
rest
are
really
appendices
published
after
the
date
for
loose
reasons
which
I
do
agree
with
and.
I
John
diet
lied
I'd
like
to
speak
from
the
point
of
view,
the
poor
people
who
have
to
specify
what
it
is
that
they're
buying,
because
I
don't
think
I've
ever
seen
a
product
listed
with
the
sponsor
a
section
of
an
RFC,
it's
a
the
neuro
say
or
isn't
and
I
think
actually
the
people
specifying
have
limited
technical
expertise
and
they
go
right.
So
do
we
use
this
document,
or
do
we
not,
and
so
I
personally
would
like
to
see
it
split
out
as
several
RSC's,
and
also
that
means
they
can
be
worked
on
independently.
I
J
J
So
this
is
a
work
from
Sri
Krishna
Panti,
who
is
also
in
the
audience
and
myself.
We
are
PhD
students
at
the
telecom,
dodgy
telecom,
chair
of
communication
networks
in
t.o,
Dresden
Germany,
myself,
I'm
with
Batman
mesh
software,
which
might
have
heard
of
I'm
working
on
bed
for
more
than
10
years.
Now
it's
also
part
of
a
linux
kernel
and
we
would
like
to
introduce
our
research
project
called
mesmerized.
D
J
Our
sees
how
to
split
but
how
to
publish
it
and
maybe
also
get
you
to
collaborate
with
us
yeah,
so
feedback
would
be
very
welcome.
I
plan
to
do
this
presentation
in
10
to
15
minutes,
so
it
will
be
very
brief,
but
yeah
I
hope
you
can
get
a
glance
so
next
slide.
Please,
ok,
so,
basically
mesmerized
as
a
multipath,
opportunistic
mesh
routing
protocol,
which
is
based
on
network
coding.
J
We
want
to
exploit
the
broadcast
nature
because
many
routing
protocols
which
are
also
standardized
on
the
yeah
use,
mud,
unicast,
routing
and
one
of
innovative
things
is,
but
we
just
don't
have
repeaters,
which
just
forward
messages
as
they
are,
but
we
have
relay
nodes
which
recode
using
network
coding.
I
will
explain
that
in
a
minute,
so
our
objectives
is
mostly
high
resilience
to
topology
changes
and,
if
possible,
also
aggregate
throughput,
I.
Think
that's
already
known
from
our
multipath
approaches.
J
Typically,
in
a
Wi-Fi
network
you
send
just
packets,
they
all
have
a
sequence
number
and
if
lost
packets,
when
you
would
just
reset
them
based
on
some
kind
of
feedback,
a
network
coding,
you
just
don't
send
the
packets
as
is,
but
you
combine
them
to
create
linear
combinations
of
these
packets.
You
attach
a
vector
coding
vector
which
describes
what
kind
of
packets
have
been
combined
and
how
and
on
the
receiver
side,
you
can
solve
a
linear
system
and
recover
the
original
packets,
and
in
that
way
you
don't
need
specific
retransmissions.
J
You
just
need
a
sufficient
number
of
packets
received,
so
you
you
can
solve
for
in
your
system
all
right.
One
interesting
feature
you
get
the
fat,
linear
combinations
is
recoding.
So
is
you
see?
We
have
three
notes
here:
encode
a
rico
down
the
decoder
and
the
encoder
sends
two
packets
which
are
linear
combinations
and,
as
you
can
see,
the
ricoh
to
sense.
A
combination
of
these
two
packets
it
received
so
can
create
unique
you,
but
still
valid
information.
J
Packets
right
and
every
recoder
can
create
different
packets,
not
only
from
by,
for
example,
randomizing
or
choosing
specific
packets,
but
also
a
recorder
might
have
got
different
packets
because
I'm
often
when
loss
and
if
they
only
got
some
of
them
well
then
never
slide
here
next,
please
so
you
see
here.
I
think
that
lets
taking
the
second
and
the
third
on
top
and
combining
those
two,
a
new
packet
which
has
been.
D
G
J
J
We
are
pretty
independent
of
arrival
order
and
I
think
it's
very
interesting
to
apply
all
these
characteristics
to
mesh
networks
in
two
ways:
multi-hop
and
multipath.
We
will
explain
that
next,
please
so.
First
thing
is
a
multihop,
a
typical
problem.
If
you
have
multiple
offices,
these
these
numbers
show
the
probability
of
the
packet
received
from
A
to
B
or
HTC
or
hid,
and
on
each
link
you
might
lose
the
packet
and
if,
if
you
lose
it,
the
original
sender
has
to
send
it
again,
so
it
the
probability,
multiplies
next
slide.
Please
and
with
recoding.
J
C
J
J
Okay,
so
first
thing
you
said:
recording
to
leverage
for
broadcast
medium.
We
don't
just
think
in
one
single
path.
We
think
in
corridors,
so
there
might
be.
Some
links
which
are
met
requires
very
similar
to
the
to
the
best
path
and
we
think
of
every
transmission
as
a
custom
multicast.
We
decide
which
nodes
of
the
way
should
take
part
of
that
way.
J
Based
on
on
some
metrics,
we
go,
don't
go
into
detail,
but
it
could
be
airtime,
for
example,
and
different
relays
will
hear
different
packets.
So
we
also
made
some
experiments
that
we
saw
but
yeah
they
just
get
different
packets
and
some
of
them
are
loss,
and
these
are
not
really
correlated.
Ok.
Next,
please
so
and
another
thing
what
we
can
do
to
leverage
the
network
coding
characteristics
is,
but
Rico
does
only
send
out
packets
when
they're
ranked
increases
the
rank
is
the
number
of
linear,
independent
packet,
so
figure
of
it?
J
Is
you
only
send
out
a
packet
if
you
get
new
information,
if
you
get
the
same
information
which
is
linear
dependent
to
the
packet
you
already
have
you
then
don't
send
anything
and
the
funny
thing
about
that
is,
but
you
can
implicitly
avoid
writing
groups.
You
don't
send
anything
which
is
already
known,
which
might
be
interesting
also
for
the
first
as
a
math
talk,
which
we
heard
today.
J
Wait
for
the
periodic
updates.
We
can
still
use
the
other,
our
paths
which
which
are
already
set
up
to
forward
for
that
specific
multicast
transmission,
and
we
we
will
have
feedback
which
tells
us.
Okay,
please
send
me
some
more
information
packet
and
this
will
control
how
many,
which
Rico
to
sense,
how
many
packets
we
can
also
specify
the
size
of
the
corridor.
So
if
we
make
a
call
it
a
very
narrow,
we
will
be
at
the
unicast
case,
which
we
already
know.
We
can
also
make
very
wide
to
be
more
resilient.
Alright.
J
Next
we
did
some
pretty
yeah
some
experiment.
We
are
also
in
the
process
of
implementing
all
of
that
ideas
and
see
how
it
works.
This
is
our
our
chair
and
listen
and
we
just
had
the
source
destination
and
to
realize
we
were
comparing
with
a
battement
protocol
and
visa
had
very
bad
links,
and
we
were
comparing
UDP
as
far
as
I,
remember,
and
you
see
with
just
using
the
second
relay,
gives
some
little
bit
of
improvement.
Doing.
J
J
E
J
So
that's
yeah.
So
to
summarize
we
what
we
think
we
can
do
is
to
exploit
the
broadcast
nature
of
a
wireless
medium.
We
can
improve
error,
resilience
and
possibly
improve
network
throughput
as
well.
Maybe
not
if
everything
is
on
the
same
channel,
but
if
we
have
distributed
channels,
for
example,
we
also
eliminate
the
need
for
xsplit,
explicit
scheduling
and
pathfinding,
which
we
would
normally
have
to
do.
If
we
do
yeah
multipath
routing,
we
are
currently
in
an
evaluation
phase.
So,
as
I
said,
there's
not
really
something
written
down.
J
K
Schwartz
jigsaw
I've
noticed
that
a
lot
of
mesh
routing
systems
seem
to
work
very
nicely
with
sparse
message
meshes
where
each
node
can
see
a
few
other
nodes
and
collapse
completely
under
radical
congestion
in
ultra
dense
environments
with
you
know
like
this
room,
if
we
all
had
a
mesh
node
in
our
seat
and
we
had
total
visibility,
you
get
these,
for
example,
situations
where
somebody
emits
something
and
everybody
else
tries
to
echo
it
simultaneously
on
the
same
wireless
channel.
So
how?
How
does
your
system
fair
in
dense,
noted
and
so.
D
I
J
J
I
L
J
C
J
A
Thank
you
for
the
presentation,
Justin
Dean,
I'm
working
group
chair,
but
I'm
participating
now
as
a
participant,
I
think
it's
really
interesting.
Work
I
see
this
type
of
work
becoming
what
we're
doing
in
the
future.
I
and
I'm
glad
you're
at
the
idea
from
glad
some
people
from
Batman
or
finally,
at
the
IDF
I've
been
trying
for
a
while
to
get
you
guys
to
come.
So
that's
nice.
A
The
piece
that
I
find
really
interesting
is
how
this
works
with
what
we're
scheduled
to
do
right
now,
which
is
a
fib
and
if
that
interfaces
at
all
or
if
we
should
design
certain
features
into
a
fib
that
would
that
this
would
be
able
to
take
advantage
of
or
not
so
you
mean
how
to
split,
but
in
my
mind,
I.
Just
the
one
that
came
to
me
was
I
had
listed.
You
know
for
drop
q
hybrid
well!
This
is
another
one.
This
is
encode
yeah.
D
M
J
J
E
Rick
Tyler
again,
do
you
have
any
any
data
on
I
understand
with
the
network
coding?
You
add
overhead
in
order
to
to
add
the
redundancy
within
the
mathematics.
D
N
E
J
D
J
J
But
that
goes
a
little
bit
into
detail,
but,
for
example,
of
rate
control,
algorithm
from
Wi-Fi
driver
also
tells
us
what
is
the
drop
probability,
and
we
can
take
that
into
account.
We
can
also
say:
okay,
we
have
two
or
three
neighbors
where
we
sent
some
I
will
tell
my
neighbors
through
feedback,
hey
I
have
let's
say
nine
packets,
and
each
of
you
should
send
free
of
them.
Recode,
for
example,
I
think.
J
That's
that's
a
good
question.
So
usually,
if
you
use
the
coding
in
a
blocked
scheme,
you
have
to
wait
for,
let's
say
ten
input
packets
before
you
can
start
coding
them
and
sending
them
out
there.
But
there
are
also
other
approaches
where
you,
for
example,
send
the
packet,
as
is
immediately
and
just
said,
redundant
packets.
At
the
end,
that's
called
systematic
coding.
In
that
case,
if
you
actually
receive
the
packet,
then
you
can
push
it
up
immediately
and
only
if
you
didn't
receive-
and
you
have
to
wait
for
redundant
redundant
packet,
I.
O
Am
I'm
Jim
we
I'm
just
wondering
if
you
have
you
testing
a
larger
scales,
maybe
like
20
note
or
I,
don't
know
15
or
something
like
that,
as
for
things
and
and
applies
some
kind
of
money,
catalytically
mobility,
deeper
option,
a
delay,
packet
loss
and
also
latency
as
well.
Okay,.
J
So
short
answers
no
and
no,
we
have
implemented
or
tested
it
on
for
node
networks.
We
also
in
the
middle
of
simulating
and
if,
if
all
that
goes
well,
we
will
probably
get
a
50
200
notes
to
make
a
bigger
set
up
just
in
the
University.
At
that
point
it
will
be
static
and
we
have
some
ideas
to
also
test
a
little
bit
with
drones
and
stuff
like
that.
But
that's
not
yeah.
We
didn't
put
too
much
thought
into
that.
Yet.
A
C
Julia
scrubber,
Trek
and
I
wish
to
apologize
for
two
things.
One
is
that
I
didn't
read
the
two
management
drafts
and
the
other
one
is
that
I'm
going
to
repeat
something
that
I've
repeatedly
said
on
the
mailing
list
and
that
I
will
keep
repeating
until
the
chairs
called
the
security
call
security
and
get
me
kicked
out.
C
There
is
some
really
remarkable
work
that
is
being
done
in
the
whole
network
and
group
on
autonomous
management
of
networks
I've.
Given
a
talk
on
that
on
Monday,
it
was.
We
in
Paris
have
been
trying
to
experiment
with
the
hell
net
technologies
in
a
mesh
environment.
It
works
surprisingly.
Well,
it
needs
some
work.
I
think
it
would
be
a
great
pity
and
a
great
wasted
opportunity
if
the
management
work
for
many
was
done
in
isolation
of
the
work
that
has
been
done
whole
net.
C
What
I'm,
hoping
for
is
a
man,
a
configured
management
protocol
that
interoperates
with
the
whole
net
stuff
in
some
weaker
sense,
not
full
interoperability.
What
exactly
can
be
achieved
is
not
yet
clear
to
us.
We've
been
discussing
that
with
Shannon
raga
and
Martin,
and
Marcus,
Steinberg
and
well.
I
will
keep
working
on
that
and
I
will
keep
repeating
that
at
every
opportunity
and
and.
G
And
I
would
say
that
sounds
like
a.
I
absolutely
agree
with
you
that
the
work
should
not
be
done
in
isolation.
It
should
be
done
in
conjunction
with
on
that
be
we're.
Looking
as
the
IETF
always
is
we're
looking
for
volunteers
to
help
us.
So
would
you
like
to
take
that
work
on
with
inning
rogue
I
and.
C
A
N
A
Had
talks
with
with
authors
of
all
srb2
in
the
past
regarding
position,
I
think
it's
something
that
we
would
be
open
to
considering.
The
first
thing
that
comes
to
my
mind
is
how
you
can
augment
hola.
Sorry
too,
with
position
information
put
into
TL
vs
attached
to
addresses
that
seems
like
it
would
be
relatively
straightforward,
and
then
you
could
select
mprs
or
next
hop,
neighbors
based
upon
it.
That
would
be
interesting.
Work.
I,
don't
think
we
need
to
make
a
whole
new
protocol.
I.
Think
I
think
we
got
the
pieces
that
we
can.
A
We
can
build
on
what
we
have
and
also
allow
it
to
be
used
by
other
protocols
that
might
come
along
later.
So
yes,
please,
please
write
to
list,
please.
If
you
have
questions
about
our
many
architecture
and
what
we
have
right
now
and
how
that
might
fit
in
please
ask:
are
there?
Are
people
out
there
myself,
others
we.
N
Have
an
in-house
project
armed
with
drones,
actually
where
we
know
exactly
the
the
path
de
ja
flying
and
we
had
already
good
results
in
increasing
the
reactivity
of
the
of
the
met
with
such
algorithm.
So
we
can.
We
could
also
share
our
work
in
for
the
working
group
in
order
to
standardize
something
like
that.
No.
A
That
would
be.
That
would
be
great
if
you
want
to
try
to
put
together
a
presentation
for
next
ITF
that
would
yes,
even
better.
Okay,.
A
A
I
have
to
check
my
schedule.
The
plan
of
error
might
want
to
stand
up
and
speak
to
this
before
the
recharter.
We
had
a
lot
of
work
that
was
kind
of
blogging
us
down
in
terms
of
getting
new
work.
If
there
is
enough
participation
on
the
list
and
there's
enough
new
work
happening
we're
going
to
meet,
and
so
we
need
to
keep
moving.
We
have
a
very
tight
schedule
and
our
deliverables
there's
lots
of
good
work.
A
That's
out
there
and
I'm
happy
to
see
new
faces
as
well
to
kind
of
energized
the
working
group
and
and
move
us
forward
in
a
good
direction.
So
I
think
once
a
year
would
be
too
little.
I
think
to
a
year
might
be
okay,
depending
on,
like
I,
said,
depending
on
activity
on
the
list
and
work
that
will
be
presented
and
worked
on
at
the
next
idea.
Sorry,.