►
From YouTube: IETF108-ANRW-20200730-1300
Description
ANRW meeting session at IETF108
2020/07/30 1300
https://datatracker.ietf.org/meeting/108/proceedings/
A
A
A
Okay,
good
afternoon,
everyone
I'm
going
to
start
with
the
introduction
slides
from
the
chairs,
so
we
have
a
few
more
minutes
for
people
to
join.
Welcome
back
to
the
applied
networking
research
workshop
2020.,
my
name
is
ron
treszczyk
dye
and
my
co-chair
is
melia
couleuvent
who's
waving
to
you
from
on
the
screen,
a
quick
hold
on
there.
We
go
a
quick
reminder
that
we
are
generally
supported
by
akamai
and
comcast
and
a
quick
reminder
of
logistics
and
links.
There
is
a
slack
channel
on
the
sitcom
workspace
specifically
for
this
workshop.
A
If
you
would
like
to
have
a
second
screen
to
chat
on
or
if
you
want
to
ask
questions
to
our
speakers
later
on,
you
can
go
to
the
sitcom
slack
workspace.
There
is
a
joining
link
shown
here
on
the
slide,
but
it's
also
up
on
the
a
rw
webpage,
the
program
and
all
of
the
pdfs
of
the
papers
are
available
through
the
irtf
website
as
well.
A
This
is
also
a
reminder
that
this
session
is
being
recorded
and
will
be
made
available
on
youtube
after
the
workshop.
So
if
you
do
ask
questions-
and
if
you
do
decide
to
share
your
video
know
that
this
will
be
recorded
and
shown
on
youtube
later
on
and
all
of
the
slides
are
up
in
the
ietf
data
tracker,
a
quick
note
for
those
of
you
who
are
not
in
the
previous
session
and
have
not
been
participating
in
the
ietf
so
far.
A
If
you
would
like
to
join
the
queue
for
the
question
and
answer
session,
please
click
on
the
little
microphone
logo
with
the
hand
next
to
it
to
join
the
queue,
and
you
can
also
click
on
this.
If
you
decide,
your
question
has
already
been
answered
and
you
would
like
to
leave
the
queue
this
session
has
two
papers
in
it
and
without
further
ado,
we're
going
to
go
to
our
first
speaker
and
our
first
speaker
is
stephen
christian.
Who
is
a
research
associate
at
the
university
of
glasgow?
A
B
C
B
Thinking
about
how
internet
standards
documents
are
typically
written,
they're
generally
centered
around
descriptions
in
english
pros
to
some
extent,
this
is
desirable.
Natural
language
makes
it
easier
to
exchange
ideas,
to
facilitate
discussion
and
to
build
consensus,
and
these
are
all
important
parts
of
the
standardization
process.
B
However,
as
protocols
become
more
complex,
the
limitations
of
this
approach
become
clear.
Natural
language
allows
inconsistencies
and
ambiguities
to
be
introduced
into
documents.
This
makes
it
not
only
more
difficult
to
express
a
concise,
consistent
specification,
but
it
in
turn
makes
it
more
difficult
to
develop
an
implementation
that
conforms
to
the
standard.
B
Instead,
we
want
to
decouple
the
input
description,
language
from
the
output
programming
language,
using
a
common
protocol
representation
in
this
architecture,
standards
documents
are
parsed
and
a
common
protocol
representation
is
derived
from
this
common
representation.
Partial
implementations
can
then
be
generated.
B
In
addition,
tools
can
be
written
to
inspect
the
common
protocol
representation,
allowing
properties
to
be
checked
or
validated
in
this
presentation.
I'll
briefly
talk
about
all
three
components
of
this
architecture
outlining
how
description
languages
fit
within
the
itf
standardization
process
and
in
particular,
how
the
social
barriers
to
their
adoption
can
be
addressed.
B
B
For
this
we
can
look
at
protocol
type
systems
like
etpl,
an
enhanced
version
of
the
tls
presentation,
language
and
yang,
a
data
modeling
language
or
others
like
data
script
and
packet
types
that
are
more
general
with
a
basic
set
of
types.
These
languages
allow
the
semantics
of
the
protocol
data
to
be
captured,
but
they
also
couple
the
external
format.
That
is
the
bits
that
are
sent
on
the
wire
with
an
internal
representation.
B
B
So.
Finally,
then
we
have
more
recent
protocol
representation
systems
that
allow
for
a
description
of
the
external
syntax
and
a
separate
internal
representation
to
be
captured.
While
the
two
systems
that
we
discuss
in
the
paper
nail
and
narcissist
go
some
way
towards
meeting
our
needs.
There
are
important
limitations.
B
To
that
end,
we
introduce
the
network
packet
representation,
a
typed
protocol
representation
that
is
decoupled
from
any
particular
protocol
description,
language
and
from
any
particular
output
programming
language.
It
provides
type
constructors
for
a
set
of
basic
type
classes
that
can
be
composed
to
model
complex
protocols.
B
B
Within
each
structure,
fields
might
have
constraints.
In
this
example,
the
v
field
should
equal
2
for
an
incoming
pdu
to
be
successfully
passed
as
a
valid
rtp
data
packet
and
more
complex
constraints
also
exist
again.
In
the
example,
the
presence
of
the
header
extension
block
is
dependent
on
the
x
field
being
equal
to
one
and
again.
We
need
to
be
able
to
capture
these
more
complex
constraints.
B
Within
the
header
extension
block,
we
can
also
see
the
need
for
contextual
data
here.
The
first
field
of
the
header
extension
is
defined
out
of
band
using
a
separate
signaling
protocol.
However,
this
value
is
necessary
to
determine
how
this
pdu
should
be
parsed,
so
we
must
be
able
to
model
this
contextual
data.
B
B
B
B
Firstly,
designers
of
protocol
description
techniques
should
be
aware
that
most
readers
will
be
human
beings
in
introducing
new
elements
or
making
existing
elements
machine
readable.
It
should
be
remembered
that
they
should
be
easy
to
understand
and
discuss.
We
should
avoid
introducing
elements
that
cannot
be
easily
understood.
B
Similarly,
it
should
be
easy
to
author
machine,
readable
elements
without
special
tools
or
workflows.
Authors
in
the
ietf
have
a
diverse
array
of
workflows
and
tools
and
requiring
the
adoption
of
a
particular
tool
will
likely
limit
its
adoption
or
exclude
authors
that
don't
adopt
it
next.
While
it
would
be
straightforward
to
introduce
machine,
readable
elements
as
an
appendix
to
an
existing
specification,
this
should
be
avoided.
B
B
B
B
They
see
small
clusters
of
adoption,
where
a
particular
group
has
determined
that
the
technique
is
well
suited
to
the
types
of
specification.
They
are
writing
as
a
result.
Any
tool
that
aims
to
see
broad
adoption
needs
to
be
able
to
accept
multiple
description
formats
and
the
network
packet
representation
is
designed
for
this.
It
is
agnostic
to
any
particular
input.
B
Language,
parsing,
structured
languages
is
well
understood,
and
indeed
parsers
for
abnf
and
dsn1,
for
example,
have
been
around
for
a
long
time
and
so
far
as
the
network
packet
representation
can
represent
the
same
protocols
as
those
formats.
It
should
be
straightforward
to
generate
it
from
descriptions
in
these
languages.
B
In
summary,
we
have
attempted
to
balance
the
structure
and
uniformity
that
is
needed
for
machine
parsing,
while
also
maintaining
the
flexibility
that
is
needed
for
the
format
to
remain
useful.
In
practice,
we
have
developed
prototype
tooling,
that
supports
this
format
and
that
generates
the
network
packet
representation
from
descriptions
that
use
the
format.
B
B
In
summary,
the
network
packet
representation
allows
support
for
different
personal
models
like
parser
combinators,
to
be
implemented
once
and
reused
for
languages
that
share
that
model.
Writing
this
code
once
is
likely
to
reduce,
bugs
and
promote
the
development
of
generators
in
different
languages.
B
B
A
A
D
Go
ahead,
yeah.
Thank
you
for
the
nice
presentation,
I'm
sure
you've
seen
the
the
updates
to
the
quick,
specs
they're
using
a
new
packet
definition
format
now,
which
was
mainly
used.
I
think,
to
make
it
more
readable
for
humans,
and
I
wonder
what
you
think
of
the
new
format
and
how,
if
it
makes
it
easier
or
more
difficult
for
works
like
yours
to
automatically
parse.
A
D
B
So
the
the
architecture
that
we
tried
to
describe
in
the
paper
is
is
quite
flexible
about
how
protocols
are
described,
and
so
where
we
outline
this
packet
header
diagram
format
in
the
paper.
That's
just
an
example
of
how
drafts
can
can
describe
protocols,
and
the
real
constraint
is
that
these
descriptions
need
to
be
regular
enough,
that
we
can
parse
them
out
with
a
bit
of
code
and
beyond
that,
we
really
don't
mind
what
format
they
take,
and
you
know
personally,
I
think
it's
great.
E
So
you
end
up
with
just
like
0
to
32
on
the
x-axis,
which
doesn't
mean
anything
and
actually,
when
we,
when
we
came
up
with
our
own
kind
of
scheme,
it
saved
a
lot
of
space
in
the
document
as
well,
which
is
a
consideration.
So,
on
the
whole,
I
think
it
was
probably
the
the
best
direction
and
we
landed
those
changes
without
much
resistance,
even
though
we
were
very
far
along
in
the
whole
quick
document
iteration
cycle.
E
A
A
F
F
B
So
that's
a
good
question,
so
there's
there's
a
couple
of
things.
I
think
what
we're
trying
to
do
with
the
sort
of
diagram
based
language,
which
is,
is
just
an
example
of
a
description
technique,
is
we're
trying
to
encourage
people
that
aren't
typically
drawn
to
using
formal
and
structured
languages
to
see
the
benefits
of
using
them,
and
we
think
that
using
something
that's
quite
familiar,
so
these
diagrams,
you
know
we're
in
use
already
using
that
familiar
language
is
a
good
sort
of
first
step
towards
that.
B
B
I
think
the
other
point
I'd
make
is
there
are
other
people
working
on
the
sort
of
literate
programming,
type
approach
that
you're
that
you're
talking
about,
and
you
talked
about
in
the
chat
and-
and
I
think
there
are
approaches
to
that-
that
integrate
well
with
what
we
are
building
so
but
yeah.
I
think
the
important
thing
is
that
this
is
just
a
first
step
towards
using
these
languages.
We
want
to
encourage
it.
A
A
H
Hello:
everyone.
I
am
narayan
g
from
the
national
institute
of
technology,
karnataka,
india.
I
will
be
discussing
about
our
work
on
developing
nest
or
network
stack
tester.
My
co-authors
are
shantanu
sri
ganeshakaram,
leslie,
moniz
and
mohit
p,
tahyani
performing
network
experiments
and
studying
network
protocol
behavior
is
a
non-trivial
process.
H
Linux
network
namespaces
are
a
suitable
alternative
to
physical
testbeds,
because
we
can
quickly
set
up
a
lightweight
emulation
testbed
for
the
experimental
evaluation
network,
namespaces,
basically
virtualize
the
network
stack
by
isolating
the
network
stack
and
creating
multiple
namespaces.
We
can
emulate
a
network
in
doing
so,
we
can
basically
build
a
complex
topology
or
emulate
any
real-life
network
using
a
single
system.
H
H
H
Once
the
topology
is
built,
well-known
tools
like
flint
can
be
used
to
run,
network
tests
flank
provides
predefined
experiments
and
intuitive
means
to
collect
statistics.
It
can
be
used
to
test
a
physical
topology
set
up
using
multiple
systems
or
within
a
system
to
test
a
topology
built
using
network
namespaces.
H
Initially,
we
attempted
to
build
a
wrapper
around
flint
and
incorporate
topology
setup
using
network
namespaces,
but
flint
is
designed
to
run
from
a
single
node
or
controller
in
a
network.
Also,
it
uses
ssh
to
control
and
get
statistics
from
remote
machines
using
ssh
to
communicate
between
name
spaces
is
an
additional
overhead.
H
Although
many
too
many
flows
and
collecting
statistics
can
be
achieved
with
some
minor
tweaks.
It
is
a
difficult
process
in
plan.
Mininet,
on
the
other
hand,
provides
nice
apis
for
setting
up
topology
and
using
network
namespaces,
but
lack
support
for
advanced
traffic
control
transfer
is
developed
by
google,
specifically
for
testing
transport
protocol
performance.
H
It
expects
a
pre-setup
topology
with
physical
systems
that
is
in
multi-server
mode,
but
handles
creation
of
network
namespaces
when
run
in
single
server
mode.
However,
it
offers
very
little
flexibility
in
terms
of
dispatch.
Configuration
netstore
is
similar
to
flint,
but
has
fewer
number
of
tests
and
provides
less
data
on
statistics
teacup,
on
the
other
hand,
concentrates
on
testbed
configuration
and
data
collection,
but
requires
a
physical
topology
setup
beforehand.
H
H
H
H
H
H
H
Next,
an
experiment
called
my
test
is
setup
and
a
flow
is
added
to
it.
The
flow
api
takes
in
arguments
for
the
source,
node
destination,
node
and
the
destination
address
to
uniquely
identify
itself.
Additionally,
the
start
time
stop
time
and
the
number
of
flows
is
specified
in
the
arguments
note.
Just
a
single
flow
is
added
in
this
example,
but
nest
allows
adding
multiple
flows
between
any
two
pairs
of
nodes.
H
H
H
H
Apis
like
flow
creation
experiment
runs,
are
part
of
the
experiment:
module
the
experiment.
Module
provides
apis
to
generate
traffic
and
extract
the
statistics
from
the
nodes
and
interfaces
experiment,
module
relies
on
engine
to
provide
apis
for
generating
traffic
and
obtaining
the
required
network
statistics.
For
example,
flow.
Addition
in
experiment
leads
to
network
being
run
in
the
background,
while
presenting
the
results
to
the
user.
Topology
map
is
used
by
the
experiment
to
convert
the
nest's
internal
given
names
back
to
the
user,
given
names.
H
H
H
H
About
the
limitations
of
nest,
it
emulates
the
network
stack
and
does
not
set
up
a
real
network.
Hence
it
lacks
the
support
of
hardware
nix.
The
effect
of
hardware
level
optimizations,
which
are
done
in
modern
nix,
are
not
reflected
in
nest,
for
example
in
the
modern
nix.
Certain
tasks
that
are
otherwise
done
in
software
level
are
offloaded
to
the
nix,
also
to
prevent
buffer
bloat
the
nics
limit
the
size
of
the
queue
by
the
number
of
bytes.
These
effects
are
not
visible
in
nest.
H
Another
limitation
is
that
nest
currently
uses
the
network
stack
provided
by
the
linux
kernel.
So
it
is
not
possible
to
emulate
a
test
environment
with
different
implementations
of
the
network
stack
such
as
those
in
bsd
windows
or
stacks
that
run
atop
user
space
packet
processing,
libraries
such
as
netmap
and
data
plane,
development
kit,
or
also
known
as
dpdk.
H
H
H
H
H
Next,
we
observe
the
throughput
distribution
for
each
flow
when
codel
is
used.
The
throughput
obtained
for
every
flow
is
fair,
because
codal
has
a
better
queue,
control
and
avoids
bulk
packet
losses
due
to
congestion
fifo,
on
the
other
hand,
has
poor
q
control
and
leads
to
bulk
packet
losses
when
congestion
occurs.
H
H
H
H
A
Okay,
thank
you
maria.
I
let
you
into
the
session.
If
you
want,
you
can
also
share
your
video.
I'm
also
letting
you
go
authors.
I
saw
some
discussion
about
the
paper
on
the
on
the
chat.
So
if
people
have
questions,
please
feel
free
to
join
the
queue
and,
in
the
meantime,
I'm
going
to
switch
and
pop
up
the
slides.
I
I
have
a
question
from
miriah.
G
Yes,
let
me
put
on
my
camera
as
well.
He
listens
to
me,
so
I
saw
in
your
paper
that
you
do
mention
mininet
as
something
similar,
but
actually
designed
for
a
different
purpose
and
more
testing
sdn,
like
networks
and
not
protocol
stacks,
but
I
guess
the
step
from
meaning
to
your
tooling.
Isn't
actually
that
much
so
did
you
compare
that
or
what's
missing.
G
H
G
H
C
Okay,
thank
you
yeah
yeah.
Maybe
I
can
add
a
bit
meera,
I'm
mohit,
I'm
also
the
co-author
on
the
paper.
So
one
of
the
works
that
we
were
doing
at
our
team
was
primarily
on
the
tcp
and
q
disciplines
and
we
have
been
closely
following
the
efforts
on
l4s
and
sce
at
tspwg,
and
we
wanted
to
kind
of
replicate
the
experiments
that
we
saw
in
the
beat
heist
repository
which
were
kind
of
being
used
for
evaluating
the
performance
of
upcoming
l4
standards
and
sc
standard.
A
I
Yeah,
so
I
saw
you
have
a
slide
in
there
where
you
compared
the
difference
between
the
physical,
a
physical
network
configured.
Similarly
to
the
the
nest
virtual
network,
I
was
wondering
if
you
could
speak
a
little
bit
to
the
differences
you
found
between
physical
and
virtualized
networks,
because
one
of
the
questions
that
we
always
have-
and
one
of
the
reasons
that
we
might
use
physical
networks,
is
because
we
are
concerned
that
the
results
that
we
have
on
the
virtual
setups
won't
reflect
reality.