►
From YouTube: IETF110-MASQUE-20210309-1600
Description
MASQUE meeting session at IETF110
2021/03/09 1600
https://datatracker.ietf.org/meeting/110/proceedings/
B
A
As
a
reminder,
this
is
being
recorded.
I
I
assume
most
people
are
familiar
with
meet
echo,
but
if
you're,
not
the
the
button
should
be
fairly
explanatory
in
terms
of
how
to
run
the
queue
unmute
yourself
and
so
on.
As
a
reminder,
please
state
your
name
at
the
mic.
If
you
have
before
you
start
speaking,
so
the
note
taker
can
log
it
accordingly
and,
as
always
just
please
be
respectful
and
courteous
to
others
next
slide.
Please.
A
This
is
the
notewell
as
in
a
I
assume.
Most
of
you
have
seen
this
by
now,
given
that
we're
already
well
into
iatf
week,
but
if
you
haven't,
please
take
a
moment
to
familiarize
yourself
with
it,
either
here
or
online
and
understand
what
it
means
to
contribute
to
the
ietf.
I
like
to
call
it
specifically
the
code
of
contact
again
just
to
encourage
people
to
be
respectful
and
kind
to
others.
A
A
A
A
A
All
right
next
slide,
please
so.
Here's
the
agenda
for
today
just
like
to
go
through
our
primary
working
group
documents,
h3
datagrams,
connect,
udp
and
ip
processing
requirements
and
then,
as
always
as
time
permits,
hopefully
we
can
get
to
tommy's
draft
quicker
we're
practicing
at
the
end,
the
pause
for
a
brief
moment
to
see
if
anyone
has
any
sort
of
adjustments
or
bashing
they'd
like
to
do
before
we
kick
things
off.
A
D
D
The
15
second
summary
of
where
we're
at
we've
adopted
this
document.
So
after
the
I
think
the
interim,
we
had
some
positive
feedback
about
adopting
this
thing
into
mask,
there's
a
bit
of
overlap
between
this
document
and
others,
and
it
could
have
fitted
into
the
http
working
group
and
we've
had
that
discussion.
But
mask
is
our
home
now,
and
this
is
where
we're
going
to
talk
about
stuff.
So
hp3
datagram
is
like
datagram,
but
the
frame
load
must
start
with
the
flow
id
anyone
familiar
with
the
history
of
where
h3
datagram
came
from.
D
So
you
would
imagine
an
application
using
http.
3
has
different
contexts
for
things
and
it
wants
to
support
different
flows
and
make
sure
that
the
right
messages
get
read
out
or
put
in
the
right
place,
but
to
do
that
effectively
requires
some
peer
coordination,
so
you
want
to
be
able
to
say
from
a
client
tell
the
server
what
a
particular
flow
id
maps
to
so
the
way
that
we
do,
that
is,
to
use
http
messages
to
associate
a
message
to
a
flow
id
next
slide.
Please.
D
D
D
But
when
it's
carried
in
a
header,
the
datagram
flow
id
header,
which
I'll
show
shortly
we're
restricted
by
the
rules
of
structured
field.
Integer
encoding.
So
there's
a
hard
limit
on
that
flow
id
of
0
to
10
to
the
15
minus
1,
which
is
all
written
down
and
and
there's
some
kind
of
quirks
in
that
we
might
change
that.
There's
some
open
issues
that
we're
not
going
to
discuss
today,
but
if
anyone's
interested
go
to
our
github
repo
and
have
a
look
so
next
slide.
D
D
That's
good,
okay,
back
back
to
this
one!
Yes,
so
the
case
here
is
that
no
sorry
getting
distracted
that,
yes,
you
can
use
quick
datagrams
when
you're
using
http
3.,
when,
when
that's
the
application
protocol,
you
select
and
you
can
use
these
flow
ids
encoded
in
the
payload
of
the
quick
datagram,
and
you
can
use
that
for
demultiplexing.
D
But
we
should
support
some
applications
that
might
not
actually
want
that
behavior.
They
might
be
comfortable
with
inventing
their
own
demultiplexing
layer.
Maybe
they
want
to
extend
things
in
a
different
way
or
whatever,
like
we
shouldn't
close
the
door
to
people
who
might
want
to
do
things
differently,
although
it's
not
our
concern
about
how
they
do
that
and
the
way
that
we
can
achieve
this
is
via
this
h3
datagram
setting,
which
allows
the
endpoints
to
negotiate
that
you
know
one
both
opt
into
this
thing.
D
F
F
F
H
F
H
F
D
Yeah
and
just
to
add,
you
know
we
we
have
the
transport
parameter,
negotiation
for
the
quick
datagram,
but
just
receiving
that
doesn't
help
because,
as
david
said,
it's
it's
completely
undefined.
What
receiving
a
datagram
should
should
do,
and
I
would
say,
based
on
some
my
personal
past
experience
of
say,
trying
to
deprecate
a
default
feature
that
wasn't
negotiated
via
a
setting,
as
in
the
form
of
priorities
in
h2.
D
J
So
I
have
a
quick
question
about
the
one
of
the
rules
for
using
quick,
datagram
frame.
Payload
feature
that
you're
mentioning
there.
Well,
I'm
totally
in
favor
of
having
the
settings
to
say.
We
want
to
turn
this
feature
on,
but
the
use
case
of
other
applications
might
not
want
to
demultiplexing
seems
like
a
anti-feature
to
me,
because
you
could
always
use
a
very
low
flow
id
and
therefore
only
sacrifice
like
one
or
two
bytes,
and
I
feel
like
in
terms
of
compatibility.
J
We
might
want
to
say
that
the
flow
id
is
mandatory
and
if
you
want
to
put
everything
on
one
flow,
that's
up
to
you
and
I
would
prefer
that
design.
Because
then
it
means
that
we
can
multiplex
multiple
things
over
the
same
h3
connection,
some
of
which
may
want
to
do
your
own
multiplexing
and
some
of
which
may
not
without
having
to
tie
the
faith
of
the
entire
connection.
D
I
think
that's
a
valid
view,
but
personally,
I
think
just
because
we
have
this
setting,
as
it's
stated
it
doesn't.
It
doesn't
add
any
complexity
to
our
specification
to
support
any
case
where
demultiplexing
might
be
needed.
Someone
later
could
come
along
and
define
a
new.
You
know
extension
to
hp3
that
effectively
supersedes
this,
and
people
could
be
free
to
negotiate
that
and
do
what
they
want
if
they
didn't
want
to
eat
this
kind
of
short
flow
id.
L
Yes,
I
accidentally
was
trying
to
screen
share
so
just
first
off
wanting
to
point
out
that
h3
does
not
prohibit
datagram
there's
no
such
frame
in
quick
v1.
Therefore
h3
says
nothing
about
it.
They
just
have
no
defined
semantics,
but
the
thing
that
h3
does
have
and
h2
as
well
is
kind
of
a
difficulty
with
negotiating
things
with
the
peer
you
advertise
statements
about
your
capability
and
then
have
some
rules
about
what
you
do
with
those
sets
where
they
overlap.
F
All
we're
trying
to
say
is
this:
setting
tells
the
peer
that
you
support
the
specification,
that's
it
and
that's
how
we've
understood
like
the
mechanisms
of
defining
semantics
and
http
3
to
work,
because
if
something
doesn't
have
semantics
and
we
give
it
semantics,
we
need
to
make
sure
that
the
other
side
understands.
That's
all
we're
saying
we're
not
suggesting
any
complication
or
ways
to
demultiplex
other
applications.
Here.
L
F
Oh,
I
I
totally
agree.
I
think
that
is
completely
out
of
scope
and
illegal.
The
the
idea
of
the
setting
here
is,
if
later
down
the
road
someone
says
it
comes
up
with
a
better
design.
They
could
not
send
this
setting
and
send
another
setting
and
they
would
have
their
own
different
datagram
thing.
That
is
completely
incompatible
with
this
one,
but
the
connection
would
only
use
that
one.
L
F
M
Cool
yeah,
so
just
echoing
what
a
lot
of
people
have
said
on
chat
already,
I
think
we
need
to
use
the
settings.
Just
how
it
is
is,
I
believe,
the
correct
way.
I
think
it's
more
for
future
proofing,
also
to
be
very
explicit
that
the
h3
application
is
intending
to
do
this
to
some
of
the
earlier
points
of
you
know.
Why
do
we
actually
need
this,
or
how
would
we
use
the
negotiation
versus
not
on
the
connect
udp
draft?
M
There's
a
conversation
we're
having
on
one
of
the
issues
around
if
like
how
extreme
chunks
could
work
and
if
they
could
share
flow
ids
with
datagrams
and
effectively.
This
setting
would
be
very,
very
useful
there
to
know
for
sure
you
know.
Does
this
hop
at
the
http
layer
support
datagrams?
If
it
doesn't,
you
interpret
connect
udp
differently,
I'm
not
saying
that's
necessarily
where
we're
going
to
go,
but
that
is
an
example
of
why
you
need
the
setting,
because
you
could
have
an
implementation,
that
your
quick
layer
always
advertises
that
it
supports
datagrams.
M
N
I'm
trying
to
come
up
here,
yep.
Well,
I
want
to
jump
in
to
echo
some
of
where
I
think
the
conversation
is
on
chat,
but
I
I
really
want
to
say
that
this,
let's
not
over
engineer
this,
and
I
want
to
say
this
now,
because
I
do
I
want
to
say
this
for
subsequent
design
premises
as
well.
We
want
to
build
to
the
use
cases.
We
have
right
now
as
long
as
we
don't
block
other
use
cases
from
happening
in
the
future.
N
I
think
that
should
be
good
enough,
and
this
one
clearly
does
not
block
us
from
doing
other
use
cases
in
the
future.
I
want
to
see
an
hd,
datagram
new
and
then
a
newer
and
newest
datagram
settings
in
the
future.
I
don't
want
to
preempt
those
now
so
yeah.
I'm
I
think
this
is.
This
is
fine.
This
is
great.
If
we
want
to
change
the
semantics
of
what
each
datagram
means
we
can
redefine.
O
Hi
guys,
david
a
long
time
ago,
you
articulated
the
desire
for
mask
servers
or
mass
proxies.
I
guess
to
not
freely
advertise
their
capability,
and
I
wonder
if
this
is
an
unavoidable
effect
of
this
design.
That
I
mean,
unless
servers
are
withholding
settings
of
the
clients
and
settings
that
http
could
be
clued,
that
the
server
has
mass
capability.
F
O
D
Yeah,
I
think
that's
good
feedback.
I'd
just
say
that,
like
having
this
feature
on,
doesn't
mean
that
the
server
needs
to
do
anything
like
you
can
reject
any
request
that
you
want
in
http
that
and
that's
one
of
the
benefits
of
actually
tying
the
usage
of
datagrams
to
messages.
We
can
just
benefit
from
all
that
prior
work.
F
E
P
A
proxy
right
here
in
the
setting
is
not
without
consequences,
and
so
at
the
very
minimum
I
mean
david's
answer
shall
be
expanded
in
the
as
a
privacy
consideration
in
the
security
section
and
that's
a
very
minimum.
My
my
actual
desire
would
be
to
be
able
to
renegotiate
the
setting
once
the
user
is
authenticated,
but
that's
probably
harder.
A
F
D
Cool,
so
this
slide
is
just
stolen
from
david.
I
believe
from
some
previous
talk.
I
don't
know
which
one
it
is,
but
basically,
if
we're,
if
we're
happy
with
the
concept
of
flow
ids,
then
we'll
want
to
discuss
what
the
values
are,
the
values
that
we
use
and
so
on
the
left-hand
side.
We
have
a
a
simple
approach,
say
that,
given
that
this
flow
id
is
associated
with
a
request,
we
just
go
for
a
simple
one-to-one
mapping.
D
There's
some
downsides
to
that,
mainly
on
that
one-to-one
mapping
due
to
the
unique
way
that
streams
are
used
in
quick.
We
can
only
benefit
from
a
quarter
of
the
available
id
space,
so
we
might
have
some
longer
encodings
and
some
overheads,
which
is
it's
not
a
huge
downside,
but
for
some
people
it
could
be,
and
on
the
other
side
of
things,
we've
got
not
a
one-to-one
mapping.
So
we
have
what
we
we
identify
as
a
distinct
namespace,
so
that
we
can.
D
D
Using
that
header,
a
client
would
send
this
header
in,
in
the
request,
say,
for
a
connect,
udp
request,
as
just
an
example,
and
the
server
would
echo
that
value
back
to
confirm
that
that
flow
id
is
fine
to
use,
and
the
benefit
of
doing
this,
as
in
this
decoupled
way
is
that
it
supports
a
many-to-one
mapping
and
I've
got
some
slides
following
this.
That
will
explore
that
a
bit
more,
so
you
don't
need
to
rely
just
on
your
imagination.
D
D
The
specification
uses
this
right
hand
design
at
the
moment
and
again
we'd
like
to
double
check.
That's
the
right
thing
to
use,
and
we
we
have
some
opinions
on
why
we
think
that
is
better,
but
no
matter
what
we
need
to
pick
one
because
other
drafts
depend
on
the
decision
here.
So
if
we
go
on
to
the
next
slide.
D
The
discussion
here
really
boils
down
to
multiplicity
and
what
people
might
like
to
to
do
with
datagram.
So
you
know
the
simple
case
that
I
just
mentioned:
the
one-to-one
stream
or
what
one
stream
to
one
flow.
This
is
like
the
minimum
that
all
implementations
of
h3
data
grammarly
to
support.
There's
there's
like
no
point
of
of
having
one
stream
to
no
flow,
that's
just
normal
http
and
there's
there's
no,
so
that
you
can
have
a
flow
without
an
association
to
a
request
so
option.
D
One
on
this,
this
slide
is,
is
what
we
have
to
do
and
then
there's
additional
things
that
we
can
do
that
might
have
benefits
of
some
use
cases.
So
you
could
have
streams
referring
to
the
same
flow
across
different
http
requests,
and
you
can
see
tommy's
draft
for
that
and
then
there's
another
case
where
we
might
want
one
stream
or
one
request
to
establish
multiple
flows
in
kind
of
one
trip
again.
D
F
Lucas,
sorry
again,
maybe
let's
take
a
moment
to
talk
about
whether
we
want
to
do
multiple
city
or
not
before
we
go
into
the
datagram
format,
if
that's
okay,
so
so
so
the
the
question
kind
of
for
the
working
group
here
and
actually,
if
you
could
go
back
to
slide
five
is
so
far.
We've
seen
two
two
designs:
one
is
what
we
currently
have
in
the
draft,
which
is
to
say
there
is
a
namespace
for
datagram
flow
ids
and
you
allocate
them
like
the
even
ones
or
clients.
F
The
odd
ones
are
on
the
server
and
then
you
exchange
them
via
header.
That
gives
you
enough
flexibility
that
x,
extensions
can
decide
to.
You
know,
do
many
to
one
or
one
to
many.
There
is
another
design
that
is
slightly
simpler,
which
is
to
just
use
the
stream
id.
That
is
a
lot
more
constraining.
It
makes
tommy's
extension,
not
work
and
the
fa
and
from
implementation.
We
know
that
it's
not
that
much
simpler,
because
we
got
intro-op
with
four
implementations
on
the
datagram
flow
id
design.
F
So
if
someone
for
some
reason
thinks
this
is
too
complicated
to
implement
and
wants
their
datagram
floy
allocation,
I
flow
id
allocation
service
to
only
ever
return
the
exact
same
value
as
the
stream.
They
can
totally
do
that,
and
so
that's
why
I'm
personally
pretty
strongly
in
favor
of
these
more
extensible
design.
That
is
only
marginally
more
complex,
but
we'd
really
like
to
get
everyone's
take
on
this.
So
we
can
discuss
it
and
then
ideally
reach
consensus.
A
F
Thanks
on
this
particular
side,
I
think
I
want
to
call
it
first
on
the
left-hand
side,
the
25
of
available
ids,
I
mean
you
could
fix
that
by
dividing
by
four.
So
I'm
not
sure.
If
that's
actually
a
german
comment
and
then
the
other
one
I
was
going
to
say
is
that
reusing
flow
ids
is,
I
would
say,
an
actively
harmful
idea,
and
I
think
this
might
have
been
pointed
out
in
a
prior
meeting.
We
we
should
not
do
that.
F
If
we
do
the
datagram
flow
id
header,
I
prefer
simpler
if
we
can
get
away
with
simpler,
and
so
I
think,
unfortunately,
I
need
to
see
the
rest
of
the
presentations,
because
I
haven't
read
tommy's
most
recent
draft
recently
enough
to
swap
in
why
the
extra
complexity
is
necessary.
I
have
read
david's
draft
on
ecn.
I
F
This
extra
level
of
interaction
so
yeah,
we
please
read
the
drafts
and
and
if
you
have
points
about
complexity,
the
code
base
that
you
and
I
share
supports
this
and
it's
about
10
lines.
It
just
uses
a
un-64
on
the
quick
session
object.
So
I
would
like
to
hear
statements
about
why
people
think
this
is
complex.
A
M
All
right,
so
you
know
I
I
definitely
support
not
making
the
identifier
that
goes
at
the
beginning
of
h3.
Datagram
have
to
be
a
duplicate
of
an
identifier
that
comes
from
a
quick
stream,
partly
just
for
layering
there,
but
I
I
want
to
challenge
us
to
kind
of
rethink,
how
we're
framing
this
in
the
discussion
that
we've
been
having
around
okay,
what
are
the
different
uses
for
these
flow
ids
and
why
you
would
have
multiple
not
talking
about
the
quick
aware
processing
but
like
looking
at
the
ecn
example.
M
M
The
other
way
to
do
it
is
to
say
you
have
the
stream
id
from
the
original
stream
as
the
first
integer
that
goes
into
the
datagram,
and
then,
after
that,
you
have
this
other
number
identifier
that
you
choose
as
like.
An
ecn
specific
marker
that
says,
okay,
this
everything
from
here
on
is
this
flag
or
not.
M
What
I
would
and-
and
similarly
when
we're
talking
about
like
the
stream
chunks
in
connect
udp,
we
have
a
question
of
do.
We
use
like
a
new
name
space
for
stream
chunks
or
are
we
using
datagram
flow
ids,
and
I
would
challenge
us
to
say
that
we
don't
really
need
datagram
flow
ids
at
all
that
these
are
not
actually
identifying
streams.
Fundamentally,
like
there's
kind
of
a
reason,
we
didn't
put
the
flow
identifiers
into
quick
datagrams
itself,
because
it's
totally
up
to
application
interpretation.
M
What
a
given
message
means.
So,
at
the
end
of
the
day,
all
of
these
use
cases,
I
would
argue
whether
it's
normal
connected
udp,
whether
it's
ecn,
whether
it's
quick
aware,
don't
really
care
about
a
flow
of
datagrams.
They
care
about
some
application
defined
meaning
for
a
given
message
and
that
meaning
may
have
nothing
to
do
with
a
quick
stream
identifier
that
tying
ourselves
to
saying
that
this
is
a
flow
that
we
should
think
of
as
a
quick
stream,
I
think,
is
pretty
limiting
and
we
could
just
say
nix
that
field
and
call
it.
Q
All
right,
I'm
luke,
I
think
the
it
might
help
to
draw
some
parallels
here.
In
my
mind,
this
is
in
udp
land.
This
is
close
to
how
rtp
and
rtcp
works
with
the
different
flows
in
the
same
connection
where
they
just
have
one
port
for
rtp
and
another
port
for
rpcp,
and
that's
fine,
like
you
could
have
that
if
you
were
using
mask
for
for
that,
you'd
set
up
a
header,
you'd,
say
rtp.
Is
this
flow
id
and
rtcp?
Is
this
other
flow
id?
Q
If
you
wanted
to
reuse
the
shared
connect
or
you
could
go
a
route
where
you
kind
of
have
the
mux
together?
As
I
know,
webrtc
does
a
lot
today
where
it's
using
a
single
part,
so
I
don't
think
it
matters
too
much.
I
would
like
more
examples
where
it's
useful
to
have
a
multiple
flows
on
the
same
connect
request,
because
you
can
only
there's
always
like
an
alternative
like
rapping.
Whoever
just
mentioned
is
another
way
or
yeah.
F
F
F
If
the
stream,
like
established
your
transport
session,
gets
killed.
That's
when
you
clear
all
your
state,
so
lifetime
is
important
and
I
think
it's
important
to
tie
a
lifetime.
So
let's
say,
for
example,
in
your,
so
I'm
not
an
expert
in
rtp,
but
when
you
have
a
protocol
that
requires
two
sub
protocols
to
work,
it
is
really
useful
to
tie
their
lifetimes
together,
because
if
one
of
them
drops
and
not
the
other,
that's
an
extra
complexity.
You
need
to
handle.
F
So
to
give
you
an
example,
and
that's
something
that
like
not
again,
this
is
an
example,
so
don't
jump
into
the
solution.
Solving
of
this,
but
if
and
when
we
build
connect
ip
as
part
of
this
working
group,
let's
say
we
have
a
flow
id
that
is.
Okay
here
are
regular
ip
data
ip
packets,
and
then
we
have
a
compression
extension
that
is
oh
by
the
way.
If
the
ip
header
is
exactly
this,
you
can
just
send
this
flow
id
instead
and
that
and
that
and
then
just
the
ip
payload
again.
F
This
is
a
vpn
tunnel
with
optional
compression,
and
you
want
to
tie
the
lifetime
of
those
two
things
together.
So
in
my
mind
you
want
them
to
share
one
stream,
which
is
responsible
for
the
lifetime,
but
then
you
want
sub
flows
of
datagrams.
So
that's
how
I
see
an
example
of
why
this
is
useful.
Like
you
said,
all
of
these
are
at
the
end
of
the
day,
isomorphic
you
could
instead
say
you
get
one
flow
id
and
then
you
add
an
extra
layer
of
demultiplexing
after
that.
I
think
that
would
be
unfortunate.
A
All
right
so
we're
going
to
cut
the
queue
at
this
point
it
looks
like
this
is
probably
something
that
needs
a
lot
more
discussion,
most
likely
on
the
list
so
for
the
people
that
are
remaining
in
the
queue.
If
you
have
particular
comments
that
you'd
like
to
weigh
in
that,
you
could
be
brief
about.
Please
do
so,
but
to
make
time
for
the
rest
of
the
presentations
we
need
to
we'll
take
this
to
the
list
when
done
alex.
J
I
just
want
to
add
and
address
something
that
tommy
said.
I
actually
feel
like
this
not
being
in
the
quick
standard
was
actually
a
mistake,
and
I
do
think
that
we
need
this
concept,
and
I
think
the
thing
which
probably
is
up
for
discussion
is
whether
or
not
flow
id
is
the
right
term,
but
I
do
think
that
we
need
some
capability
to
be
able
to
distinguish
whether
or
not
a
bunch
of
datagrams
are
to
be
used
in
a
particular
purpose.
Otherwise
you
can't
multiplex
within
quick,
multiple
things
which
are
using
datagrams.
F
F
J
Yes-
and
I
was
mostly
wanting
to
address
something
that
tommy
was
saying
where
he
was
saying-
challenge
is
to
figure
out
whether
or
not
we
even
need
this,
and
I
think
the
answer
is
we
absolutely
need
this.
The
argument
that
it
wasn't
included
in
quick
is
not
a
strong
one.
The
specific
choice
between
what
is
simpler
here
versus,
not,
I
think,
is
in
the
eye
of
the
beholder.
I
actually
personally
think
the
name
space
is
simpler.
J
F
J
M
Cool
that's
good,
to
clarify
yeah
and
to
clarify
the
comment
around.
Why
quick
doesn't
have
it?
I
don't
I'm
not
trying
to
use
that
as
an
argument,
for
you
know
why
it
needs
to
be
here.
It's
more
that
fundamentally,
this
field
only
has
meaning
from
the
application
semantics
that
are
defining
how
it
wants
to
communicate
a
given
message-
and
that's
you
know
so
in
quick.
M
A
stream
is
identified
by
something
that
has
transport
level
properties,
and
I
think
really
here
the
only
way
we
can
def
decide
what
a
quick,
what
an
h3
datagram
means
is
based
on
the
header
fields
that
come
in
an
http
request
that
first
define
that
value
and
so
for
connect.
Udp,
that's
going
to
be
used
in
one
way.
Web
transport
is
going
to
use
it
in
another
way,
and
extensions
connect.
Udp
can
use
them
in
still
other
ways,
and
these
are
all
really
unique
to
whatever
semantics
those
header
fields
have
so
like.
A
Okay,
so
we
have
drained
the
queue
now.
What
I'd
like
to
do
very
quickly
before
moving
on,
then
it's
just
a
quick
show
of
hands
to
see
where
people
are
sort
of
leaning,
either
left
or
right
in
terms
of
reusing
stream
id
and
matching
it
to
floaty
or
using
the
distinct
name
space.
So
I'm
going
to
do
is
throw
up
a
show
of
hands
for
option
two
and
give
folks
a
quick
moment
to
fill
that
out
should
see
it
now.
A
A
B
A
D
F
Is
like,
I
think,
the
most
important
our
questions
we
have
for
this
session
is
kind
of
nailing
down.
You
know
the
wire
format
and
I
think
like,
for
example,
this
call
we
just
had,
I
would
say
lucas,
it
would
be
nice
to
spend
the
time
we
need
on
the
datagram
flow
id
header,
because
since
or
I
mean
we'll
confirm
this
on
the
list,
but
if
we
assume
that
the
list
matches
what
happened
in
the
room,
we
need
the
datagram
floyd
header.
F
D
F
D
Cool,
so
we've
talked
a
bit
about
multiplicity.
I
want
to
stress
that
the
the
concept
of
a
separate
namespace
for
flow
ids
is
is
slightly
tangential
to
some
of
the
multiplicity
that
we're
going
to
be
talking
about
here.
It
would
be
possible
to
have
a
flow
id
header
that
only
lets
you
send
one
value
in
it,
and
so
that's
that's
something
we
we
need
to
bottom
out
as
well
as
part
of
this
this
discussion.
So
if
you
go
into
the
next
slide,
I
think
people
understand
multiplicity
at
a
base
level.
D
D
You
always
have
to
support
one,
otherwise,
there's
no
point
in
in
trying
to
negotiate
it,
but
that
you
might
have
more
and
that
those
extra
flows
are
kind
of
in
support
of
extension,
behavior
that
may
or
may
not
be
supported
at
the
the
peer
you're
trying
to
negotiate
the
extension
with
and
therefore
we
want
to
give
those
those
flows,
a
name
or
some
some
handle
that
the
other
side
can
look
at
and
think
I
don't
support
that
parameter.
I'm
therefore
effectively
going
to
ignore
this
entry
in
the
list
and
I'll
just
respond
with.
D
You
know
that
the
mandatory
flow,
if
I
was
going
to
support
that
under
the
hood,
this
thing
looks
like
just
a
name,
but
it
is
a
proper
structured
field
parameter.
Although
I've
seen
the
comments
that
the
syntax
isn't
just
one,
it's
a
question
mark
one.
But
but
the
gist
is
it's
bull,
and
if
you
care
to
look
it,
it
could
look
like
that
and
that's
what
the
spec
says
today.
D
D
Basically,
an
implementation
needs
to
look
at
this
header
and
decide
what
it
supports,
what
it
wants
to
do
and
what
it
can
echo
back
to
to
the
peer
that
instigated
it,
but
there's
another
alternative.
That's
come
up
that
isn't
on
the
issue
itself,
but
is
worth
describing.
So
if
we
go
on
to
the
next
slide.
D
Ignore
them,
and
just
look
at
that
list
of
flow
ids
and
easily
identify
the
default
flow
that
the
the
peer
was
trying
to
request
that
potentially
makes
it
less
ambiguous
and
easier
to
do,
and
so.
In
this
example,
we
talked
about
an
ecn
extension
and
you
could
see
if
you
don't
support
ecn
like
most
people.
You
would
just
ignore
that
parameter
and
pick
flow
id
42.
In
that
first
example.
The
benefit
of
this
kind
of
design
is
that
it
allows
maybe
a
better
composition
of
extensions.
D
S
A
G
So
lucas,
I
think,
what's
unstated
in
these
two
slides-
has
been
the
the
point
that
in
the
first
one
you
sort
of
have
to
understand
the
the
name,
the
name
of
the
parameter
and
the
value
of
the
name
parameter
depending
on
which
option
you
have
in
order
to
make
any
sense
of
this
particular
item
and
the
the
assumption
there
is
that
if
you
see
something
there
is
this,
the
sender
saying
is
the
center
of
the
header,
the
receiver
of
the
flow
id.
Or
is
it
something
else.
F
So
let
me
maybe
try
to
explain
here.
The
idea
is
that
so
we
have
a
list,
so
there
can
be
multiple
flow
ids
with
this
one
stream
and
then
the
receiver.
So
let's
say
the
the
proxy
in
this
case
will
do
different
things
with
these
different
floyds.
So,
for
example,
one
of
them
means
a
different
value
of
the
cn
bit
in
the
header.
The
the
important
distinction
here
is
the
it's
possible.
The
proxy
doesn't
understand
the
the
extension
and
we
want
it
to.
G
G
F
Totally
agree
the
the
server
echoes
this
and
actually
that
that
is
a
bug
that
we
just
found
out
right
now.
The
echoing
is
in
the
connect
udp
document.
We
want
to
bring
it
down
to
this
one
because
you're
totally
right.
We
need
that
so
yeah,
sorry
yeah,
that
we
didn't
state
that
that
is
kind
of
the
assumption
of
what
these
are
for.
Yeah.
G
Yeah,
so
I
I
think
the
default
thing
doesn't
make
any
sense
in
that
context,
because
what
you're
asking
someone
to
sign
on
for
is,
if
you
don't
understand,
all
of
these
other
things
just
send
here
and
that
doesn't
really
give
you
any
any
knowledge
about
what
you've
just
signed
on
to
to
the
semantics
of
so
you're
selling.
Onto
saying
this
is
not
a
ct,
but
you
didn't
understand
the
ecn
parameter
anyway,
and
so
you're
going
to
be
sending
these
packets
the
client's
going
to
go.
Oh
yeah,
fine!
G
F
F
The
proxy
doesn't
support
the
ecn
extension.
So
it's
going
to
fall
back
to
regular
connect,
udp
and
it's
going
to
pull
packets
out
of
a
udp
socket,
not
know
what
the
ect
markings
were
on
them
and
when
it
turns
around
to
put
them
in
a
datagram,
it
needs
to
put
them
on
the
one.
That
means
not
ect
yeah
yeah,
you
know,
and
so
then
the
question
is
we
need
a
or,
unless
I'm
misunderstanding,
I
think
we
need
a
way
for
the
proxy
to
know,
okay,
which
of
these
four
numbers.
D
I
I
see
martin's
point.
I
I
think
if,
if
we
had
to
go
with
this
root
of
a
design,
I
won't
just
suggest
that
implementations
have
a
default.
That
is,
is
like
not
tied
to
any
extension,
just
a
plain
datagram
and
and
if
they
can't
do
that,
if
they
really
need
to,
then
then
they
shouldn't
be
expecting
to
have
wide
interrupt
on
on
the
internet
without
some
form
of
up
like
alternative
negotiation.
Here.
F
And
that's
kind
of
what
we're
seeing
martin
is
that
for
the
ecn
extension.
Not
ect
is
the
same
as
this.
This
extension
doesn't
exist
because
and
so
that
that's
what
we
want
is
a
graceful
fallback.
You
don't
want
to
do
a
connect,
udp
request
with
vcn
and
then
go.
Oh,
I
don't
speak
ecn
and
then
I
have
to
do
a
different
connect.
Udp
request.
F
Right,
don't
you?
Yes,
oh
so,
then
that's
one
of
the
things
I
was
thinking
and
here's
another
wrench
thrown
into
these
gears
is
imagine
you
have
another
extension
which
is
like
timestamps
or
something,
and
you
have
this
ecn
extension
and
then
you
have
this
other
extension.
That's
on
all
of
them,
then
you
don't
know
which
is
which
and
that's
why
actually
tommy
came
up
with
the
idea
of
a
default
one
which
is
the
okay.
F
G
F
G
G
F
K
S
F
So,
if
you
have
an
intermediary
between
your
client
and
your
connect,
udp
proxy,
it
might
use
a
different
datagram
flow
id
on
both
legs
there,
and
so
the
intermediary
needs
to
be
able
to
parse
the
datagram
flow
id
header
because
they
might
rewrite
those
numbers
and
therefore
the
added
extensibility
information
is
in
a
parameter
there.
So
when
the
intermediary
rewrites
those
it
takes,
the
parameters
as
an
opaque
string
doesn't
do
anything
with
them
and
leaves
them
there
to
go
upward.
That's
why
it's
part
of
the
same
header
as
opposed
to
a
different
one.
E
So
basically,
all
you
need
to
know
to
follow
this
exact
same
scheme
here
is
like
you,
have
a
base
flow
idea
of
42
and
then
both
ends
understand
that
they
know
what
the
ecn
extension
is
and
how
to
use
it.
And
then
you
could
just
say
you
know
these
two
bits
of
the
flow
id
are
now
the
ecn
field
or
the
last
two
bits
or
we
add
another,
two
bits
after
the
flow
idea
whatever.
E
So
all
you
need
is
really
to
make
sure
that
both
endpoints
understand
the
same
semantics,
and
that
means
you
just
have
to
have
to
have
a
negotiation
for
extensions
and
by
doing
it
this
way
here
you.
This
is
a
little
bit
error
prone,
because
what
happens?
If
you
don't
like
specify
all
the
semantics
fully,
because
you
have
like
these
four
bits
and
you
need
four
different
streams
for
bits
and
if
you
only
specify
two
of
them,
then
you
don't
really
know
what
to
do
here.
F
F
E
F
But
you
need
to
say
which
is
which,
and
so
this
is
a
list,
and
maybe
the
the
property
that
we
didn't
forgot
to
mention.
Http
headers
can
be
reordered,
the
ordering
of
http
headers
doesn't
have
a
semantic,
and
there
and
also
structured
field
lists
can
be
encoded
as
separate
headers.
Therefore,
the
ordering
of
a
list
has
no
semantics.
F
F
D
Slide
10,
please,
yes,
do
we
think
we
can
pick
an
option.
So
if
we
agree
to
keep
this
datagram
flow
id
header,
are
we
able
to
pick
a
format?
So
I
think
of
the
three
options
we
presented
here.
There's
probably
a
fourth
which
is
is
the
zeroth
option,
which
is
do
nothing
but
based
on
the
previous
interim
and
some
of
the
discussion
here
I
don't.
I
don't
think
anyone
would
be
in
favor
of
that.
D
But
it's
something
to
consider,
but
the
options
here
are
what
are
presented
so
option.
One
is
to
require
extensions
to
effectively
define
a
parameter
name
of
their
own
and
then
some
of
the
values
that
they
they
support
or
some
of
the
variants.
I
don't
know
what
we
want
to
call
those
things,
but
it
would
look
like
that
option.
D
Two
is
that
we
define
a
common
name
parameter
and
then
extensions
could
just
define
their
own
names
in
their
own
specifications
as
they
need
and
that
we
can
create
some
language
that
describes
how
how
a
server
or
whatever
would
read
that
name
and
decide
to
do
things
and
then
option
three.
Is
this
default
thing?
D
H
A
A
D
Okay,
so
moving
on
quickly,
the
the
final
issue
we
have
is
about
flow
id
reuse.
So
this
issue
is
created
by
martin
siemen.
I
think
ecker
created
a
similar
one,
so
we
we've
them
together,
just
to
say
that
you
know
the
premise
here
is
that
flow
ids
carried
in
every
frame
and
that
there
could
be
some
attraction
to
using
small
ones.
D
We
introduced
some
notion
that
the
flow
id
allocation
service
can
support
retiring
and
reuse
of
flow
ids,
but
that
places
some
burden
on
applications
to
tell
the
service
when
things
are
ready
to
be
retired
and
detecting
when
it's
suitable
or
safe
to
retire
or
reuse
can
be
hard,
and
so
there's
a
risk
that
recycled
flow
ids
are
used
incorrectly
with
all
the
bad
stuff.
That
could
happen
from
that.
So
we
we
normally
have
a
flow
id.
That's
a
62-bit
integer,
although
not
all
of
the
spaces
available.
D
But
the
question
here
is
enough
numbers:
do
we
really
need
all
this
potential
complexity
and
risk
in
order
to
save
some
bytes?
From
from
from
some
of
the
opinions
we've
seen
and
heard,
we
would
probably
look
at
dropping
this
thing
just
so.
We
could
make
progress,
but
the
question
to
the
working
group
would
be:
is
anyone
opposed
to
dropping
this
feature?
Does
anyone
really
want
oid
reused
to
main
stay
in
the
document.
M
Yeah,
I
just
want
to
say
I
I
think
we
should
not
have
any
of
this
retire
reuse
stuff.
It
adds
a
lot
of
complexity.
I
don't
think
it
has
any
particular
value,
and
I
just
want
to
point
out
like
that
is
reuse
after
retirement
should
be
distinct
from
allowing
extensions
to
use
numbers
how
they
want
right
like
I,
I
think
we
should
not
have
this
feature.
We
shouldn't
have
any
constraints,
though,
necessarily
on
what
an
extension
wants
to
do
with
the
meaning
of
this
arbitrary
value
that
they
have.
F
F
F
H
F
F
Can
I
ask
you
to
follow
an
issue
for
that
ian.
Please,
that's
a
reasonable
question.
Sure
thanks
all
right,
the
editors
will
write
a
pr
to
just
remove
this
and
we'll
be
done,
and
and
for
the
record
it
was
one
person
who
asked
us
to
add
this
feature
and
we
added
it
in
and
then
they
found
the
issue
to
ask
us
to
remove
it.
So
just
make
up
your
mind,
but
anyway,
let's
just
remove
it.
Move
on
everything's,
good.
A
F
All
right
I
will,
I
will
be
as
quick
as
possible,
so
hi
everyone,
I'm
david
scanazzi
and
I
will
say
hi
to
all
masked
enthusiasts
and
martin
thompson.
Who's
decided.
He
is
not
enthusiastic
about
anything
all
right,
then
next
slide
perfect.
Thank
you
also,
for
the
record
lucas
totally
copied
all
my
memes
I'm
kind
of
annoyed
because
he
got
to
present
before
me,
but
all
right.
So
what
if
you
haven't
been
following?
Mass
connect,
udp
is
connect
for
udp
and
it
uses
datagram
frames
next
slide.
Please.
F
So
far,
we
only
didn't
drop
over
the
datagram
encoding
of
udp
packets,
not
the
stream
one,
and
you
know
if
you
look
especially
on
the
issues
for
the
repository
that
is
more
in
flux.
So
that
makes
sense-
and
I
think
our
next
goal
in
terms
of
it
drop,
will
be
to
really
try
the
stream
encodings
to
get
a
sense
for
how
good
the
different
options
are
and
for
the
folks
that
aren't
on
this
interop
matrix
that
have
quick
implementations.
F
F
F
There
are
some
servers
that
so
in
theory,
what
you're
supposed
to
do
as
a
server
in
http
is
you
parse
the
headers,
and
then
you
decide
what
to
do
with
it
and,
for
example,
if
it's
a
post,
you
decide
to
wait
for
the
fin
on
the
stream
to
to
send
that
data
to
your
back
end
or
whatever.
But
there
are
a
bunch
there.
F
I
don't
know
about
a
bunch.
We
don't
have
data
here,
there's
some
servers
that
will
wait
for
the
fin,
no
matter
what
it
won't
actually
process.
The
full
settings
frame
until
they
get
the
fin
and
that
would
completely
break
if
for
connect
udp,
but
also
for
connect
like
this
isn't
a
new
thing
and
so
kazuho
proposed
to
add
a
setting
to
be
able
to
handle
those
servers.
And
I
see
kazoo
in
the
queue.
So
please
jump
in.
U
But
if
we
define
a
new
tunneling
scheme,
then
the
request,
the
the
end
of
the
request
body,
never
arrives
to
the
server
and
the
server
would
simply
wait
for
him.
Eventually,
the
timeout
would
kick
in,
but
there
was,
but
the
actual
problem
for
connect
udp
is
that
the
client
would
sending
datagrams
repeatedly
because
there's
no
response,
so
the
timeout
would
even
be
do
it.
G
E
G
G
The
setting
doesn't
stick
out
if
you
put
it
on
every
connection,
if
you're
willing
to
do
it
in
one
place,
then
say
that
you're
willing
to
do
it
everywhere.
Just
don't
actually
actually
exercise
that
capability,
and
then
you
don't
stick
out
at
all.
So
it
seems
to
me
that
cleaner
is
not
just
cleaner.
It's
we
don't
cause
servers
to
break
when
they're
doing
the
right
thing.
F
N
F
F
N
F
Well,
that's
the
goal.
So
let's
say:
if
you,
for
example,
you
had
a
connect
ip,
but
then
it
would
require
an
authentication
header
on
that
http
request
and
if
you
have
the
header
and
you
you'll
get
a
200
and
if
you
don't
instead
of
seeing
access
denied
it'll,
say:
oh
on
some
unsupported
method,
I've
never
heard
of
what
you're
saying.
F
All
right
so,
then,
the
if
that
that
means
that
people
can't
probe.
But
then,
if
you
have
a
I'm
a
masked
vpn's
server
as
a
setting,
then
people
can
notice
this
even
if
they
haven't
authenticated.
I
think
the
key
difference
is
you
want
to
give
this
information
to
folks
with
the
password
and
not
to
others,
but
if
you
want,
maybe
we
should
take
this
offline
because
we're
a
little
short
yeah.
N
R
V
So
I
guess
my
question
is
I
mean:
is
this
actually
over
a
case
where
these
bro,
I
think
it's
sort
of
related
to
the
question
of
you
know
the
you
know
you
don't
connect.
Gdp
to
random
servers
is
ever
a
case
where
you
know.
Is
it
just
that
you
get
the
failure?
You
know
the
correct
behavior.
With
these
servers
you
get
the
failure
sooner
rather
than
after
the
timeout.
V
You
know
you
get
an
you
know
if
it
if
this,
if
we're
just
working
around
the
fact
that
some
servers
will
give
you,
you
know
timed
out
rather
than
unknown.
You
know
timed
out
after
30
seconds,
rather
than
you
know,
unknown
method
immediately.
I
think
that's
not
worth
worrying
about.
You
know.
You
already
know
you're
talking
to
the
wrong
cert.
You
know
you
know
you're
talking
to
the
wrong
server,
no
you're
talking
to
the
wrong
server
30
seconds
earlier.
It's
not
a
huge
win.
It's
already
configuration
error,
go
fix
it.
V
So
I
think
I
would
say
don't
worry
about
this
because
you
know
if
you're
talking,
unless
there's
some
case,
where
you'd
expect
that
you
know,
like
you,
have
some
proxy
such
that
you'd
actually
successfully
get
a
connect
udp
if
we're
doing
the
right
thing
and
the
settings
were
there,
but
you
know
if,
because
it's
broken
you
don't,
I
don't
see
how
that
would
work
so
other
than
that.
I
don't
see
why
this
is
worth
worrying
about.
F
Okay,
thanks
what
I'm
getting
here
and
cheers
correct
me.
If
I'm
wrong
is
we
have
people
with
opinions
on
you
want
to
mute
jonathan?
We
have
people
with
opinions
on
both
sides
of
this,
so
I
don't
think
we're
going
to
reach
a
resolution
in
the
room
today.
So
I'd
say:
let's
take
it
to
the
issue
and
move
on
to
the
next.
F
F
F
In
my
opinion,
it
is
completely
pointless.
This
is
just
to
be,
you
know,
compliant
with
some
existing
specifications,
and
so
at
first
I
created
a
mask
scheme
and
then
folks
were
telling
me
that,
oh
you
can't
just
do
that.
That's
a
lot
more
work
and
work
for
no
benefit
is
not
something
I
like
to
do
so.
Then
I
said
like
how
about
we
just
use.
Https
like
the
scheme
is
completely
useless.
It
will
not
be
acted
on
by
anyone,
but
if
we
need
a
value
in
there
and
it
needs
to
not
be
empty.
F
T
First,
first
of
all
off,
I
think
this
is
a
total
bike,
so
the
color
of
your
bicep
painting
is
not
very
important,
but
I
think
it's
a
little
bit.
Martin
thompson
points
out
that
there
are
two
udp
schemes
and
we
should
have
a
third.
I
think
that's
the
point
of
his
comment
anyway,
since
this
is
not
really
used,
we
can
use
either
udp
scheme
and
get
the
get
the
same
results
right.
So
I
would
use
udp
here
just
because
it's
it's
a
bike.
U
F
I
mean,
oh,
so
that's
an
other
design
decision
which
I
thought
we
had
reached
agreement
on,
where
we
could
have
used
extended,
connect
with
a
protocol,
but
we
decided
to
go
with
connect2udp
instead,
I
don't
think
there's
too
much
interest
in
revisiting
that,
because
that's
also
a
bike
shed
at
the
end
of
the
day,
they're
completely
isomorphic,
but
I'd
rather
just
stick
with
this
for
now,
just
because
we
agreed
on
this
like
last
year.
At
some
point,
I
think.
F
All
right,
so
maybe
we
need
to
put
a
pin
in
this
until
we've
reached
consensus
on
the
previous
slide.
So
maybe
we'll
take
this
one.
Also
to
the
list
last
issue
which
right
now
the
two
are
on
the
same
issue
number
23,
which
we
should
probably
split
it
up,
because
it's
kind
of
a
mess.
But
I
can
take
care
of
that.
F
M
Yeah,
I
just
wanted
to
bring
up
something
I
think
I
brought
up
at
the
interim
do
do
you
think
we
need
to
have
this
document
specify
the
specific
scheme
you
need
to
use
like
we
can
say
you
must
have
a
scheme.
Do
we
need
to
mandate
what
it
is?
I
don't
think
other
methods
mandate,
what
scheme
you
must
use
with
them
like
gantt
or
any
other
ones.
So
can
we
just
make
it
not
our
problem.
F
That
would
equally
be
totally
fine
to
me.
I
remember
some
people
having
strong
opinions
against
that
when
you
proposed
it
on
the
issue-
and
I
am
seeing
all
sorts
of
various
amusing
scheme
proposals
here,
left
and
right
here
thanks
everyone
all
right.
Let's
maybe
take
this
to
the
issue
and
maybe
can
maybe
we
should
consult
with
the
hdp
working
group
to
see
what
is
legit,
because
I
know
they
have
strong
opinions
there.
F
N
F
Yep
all
right
this
actually,
so
I
I
have
a
few
more
well,
let's
see
how
many
slides
do
I
have
like
this
is
six
all
right.
How
about
this
we're
we're
really
short
on
time,
and
I
want
to
leave
time
for
the
other
presentations.
I'm
gonna
quickly
present
these,
but
maybe
unless,
like
maybe
let's
say,
keep
the
discussion
on
the
list
or
on
the
issue
as
opposed
to
here.
So
we
can
leave
time
for
the
other
presentations
so
very
quickly
here
or
chairs.
How
does
that
sound.
F
Some
folks
were
saying:
well,
it
would
be
cool
if
we
could
negotiate
them
like
halfway
through
a
stream
yeah,
it
would
be
cool
and
there
are
some
advantages
for
doing
that.
There
are
some
downsides
because,
like
well
added
complexity
in
the
protocol,
but
also
out
of
complexity
and
intermediary
implementation.
F
F
I
mean
like
the
more
we
talk
about
it,
the
more
I'm
not
sure.
So
I
would
say,
let's
punt
this,
for
now,
let's
implement
one
of
those
things
either
or
both
and
see
how
it
feels
to
implement
them
to
make
an
informed
decision.
But
again,
please
come
to
the
issue.
If
you
have
thoughts
next
slide,
please
connection
migration.
F
So
if
you're
doing
quick
over
mask
over
quick
or
sorry
quick
over
connect
udp,
you
can
end
up
in
a
situation
where
the
mask
connection,
by
which
I
mean
the
one
where
the
connect
qdp
request
goes
over,
is
migrating
and
that
one
will
reset
its
congestion
controller
in
response
to
migration,
the
inner
you
know
encapsulated
or
tunneled.
However,
you
want
to
call
it
end
to
end
quick
connection
will
not
necessarily
notice
this
migration.
F
The
client
will
notice,
but
the
target
server
won't
actually
know
that
it
happened,
so
it
might
send
a
full
window
of
data
which
then
the
intermediate
or
the
proxy
sorry
is
gonna,
get
it
and
then
it's
not
gonna
be
able
to
put
it
on
datagram
frames
because
those
are
protected
by
connection
control.
So
it's
going
to
drop
them
on
the
floor.
F
We
should
definitely
add
some
text
to
do
this
and
we
might
have
some
ideas
of
mitigation
such
as
maybe
the
proxy
should
switch
its
target
target
facing
port
to
make
the
server
realize
that
a
port
migration
happened
again.
This
is
tricky
and
I'm
sure
there
are
a
lot
of
implications.
So
please
bring
thoughts,
ideas,
suggestions
to
the
issue
and
next
slide,
please,
which
should
bring
me
to
the
end
of
my
slides.
Yes,
this
is
all
the
slides
I
had
for
today.
W
Up,
okay,
hi
everyone,
I'm
dallas,
mccall
and
I'll,
be
talking
about
mask
ip
processing
requirements
today.
So,
if
you
can
move
to
the
next
slide,
I'd
like
to
start
with
discussing
like
a
few
fundamental
features
of
the
requirements
and
then
time
permitting
I'd,
also
like
to
discuss
some
of
the
open
issues
that
we
have.
W
So
the
first
one
which
seems
quite
existential,
is
let's:
let's
go
ahead
and
agree
on
what
we
mean
when
we're
talking
about
ig
boxing
in
the
in
the
current
requirements
document
that
we
we
have
posted
we're
discussing,
proxying
ip
packets,
including
the
header.
Alternatively,
there's
been
the
suggestion
of
proxying
ip
payloads,
which
would
include
sending
the
metadata
for
the
the
actual
flows
through
some
side
channel.
W
I
like
to
go
back
and
and
kind
of
look
at
the
the
the
use
cases
that
we're
discussing
for
both
of
these
and
the
the
the
trivially
used
case,
where
we're
discussing
connecting
basically
one
flow
with
like
one
ip
endpoint
on
either
end
is
just
as
easy.
I
would
argue
using
approach
one
here
or
approach,
two.
W
E
Yeah
thanks
for
putting
this
down
this
way.
That
really
makes
sense
to
me.
So
the
point
about
option
two
is
actually
that
we
are
kind
of
already
halfway
there,
because
it's
very
similar
to
connect
udp
like
if
you
take
connect
udp
and
you
add
like
a
little
bit
to
it.
Then
you
get
the
same
thing
for
ip
proxy.
E
J
Yeah,
I
just
want
to
say
that
I
don't
think
it
is
fair
to
use
the
existence
of
another
draft
in
order
to
inform
the
requirements
of
a
different
one,
because
we
can
also
just
as
easily
say
just
as
we
have
the
connect
udp
draft.
We
also
have
an
implementation
that
currently
does
the
more
vpn
style
thing
within
google
and
partly
also
open
sourced.
So
I
don't
think
that
for
a
requirements
document
we
can
immediately
use
the
existence
of
running
code.
E
Okay,
I
just
yeah,
so
I
think
the
the
I
was
just
talking
about
you
know.
What's
the
solution,
we
want
to
see
here
and
I'm
not
sure
on
what
the
right
one
is,
but
for
the
requirements
document
I
actually
want
a
document
that
doesn't
favor
any
of
the
two
solutions
and
and
just
keeps
that
open
for
a
later
decision
when
we
actually
know
what
it
means
to
implement
one
or
the
other
solution
and
how
complicated
it
is.
E
W
Yeah,
so
I
I
think
we
might
might
kind
of
be
agreeing.
So
I
I
the
the
the
point
that
I'm
trying
to
get
across
is
that
the
the
the
thing
that
we
want
to
define
requirements
for
is
on
one
side
of
this
proxy
feed
in
ip
packets
and
on
the
far
side
of
this
proxy
send
out
ip
packets
and
and
so
the
the
the
whether
or
not
we
strip
off
the
headers
and
put
them
onto
something
else
and
then
and
then
re-combobulate
them
on.
W
The
far
side
seems
like
sort
of
an
implementation
detail,
and
that's
that's
kind
of
why
I
was
hoping
that
we'd
be
able
to
sort
of
at
the
level
of
the
requirements.
Just
say
all
we're
doing
is
taking
ip
packets
from
one
side
to
the
other
side.
And
then
we
should
have
the
extension
knobs
to
be
able
to
munch
those
packets
in
some
useful
way,
such
as
this,
where
we're
compressing
the
headers.
But
but
that
seems
kind
of
like
a
further
detail.
E
H
H
Let
me
try
that
again,
I
said
lossless
like
a
lot
of
the
it's
it's
very
common
for
anything
that
tries
to
proxy
an
ip
payload
with
metadata
by
side
channels
is
going
to
be
trying
to
re
re-encode,
essentially
create
a
compression
format
for
for
ip
packets.
It's
very
easy
to
turn
that
into
a
lossy
compression
format
accidentally
because
there's
an
unlimited
space
of
potential
future
variability.
H
J
T
F
On
alex,
that's
I
when
he
said
lossless
now
I
found
that's
why
I
got
me
confused
as
well:
it's
not
lossless
in
the
sense
of
packet
loss.
It's
lossless
instead
of
fidelity
loss
in
compression,
and
I
think
maybe,
if
I
can
slightly
restate
what
you
said
ben
to
to
clarify
is
the.
If
we
have
something
that
just
compresses,
then
you
can
fall
into
this
trap.
Whereas
that's
if
we
do
something
that
by
default
sends
full
payloads,
then
there
is
that
trap
doesn't
exist.
H
H
Something
that's
tremendously
complicated
to
implement
that's
very
challenging
as
a
vpn
implementer
shipping
ip
blobs
around
without
having
to
look
inside
them,
is
strongly
preferable
and
also
there's
another
requirement
here
that
I
think
has
been
missing
a
lot
from
this
discussion,
which
is
mtu.
Consistency
we
just
recently
saw
had
an
issue
where
a
slight
miscalculation
in
the
in
the
mtu
expectations
of
dtls
sctp
resulted
in
in
a
user-facing
outage,
because
we
didn't
quite
get
it
right.
Having
variable
overheads
is
pretty
scary.
We
already
have
some
of
that,
but
let's
not
make
it
worse.
F
Cool
thanks
ben,
so
I
I
actually
want
to
underscore
a
little
bit
what
ben
said
and
having
implemented
a
an
ip
tunnel
in
a
previous
life
between
apple
watch
and
iphone.
Actually
with
compression
the
big
learning
there
was
that
a
design
that
takes
the
fields
it
wants
and
sends
them
is
what
ben
was
calling
lossy
it
can
cause
serious
problems
if
something
happens
that
you
didn't
think
of,
whereas
the
design
that
we
eventually
landed
on
that
worked
really
well
was
by
default.
F
You
send
uncompressed
and
if
you
see
something
that
your
compressor
knows,
that
it
can
compress
in
a
way
with
100
fidelity,
then
it
compresses,
but
you
always
have
the
escape
hatch
of
sending
uncompressed,
and
I
think
that
is
an
important
design
decision
and
that's
kind
of
one
of
the
things
we
reflect
here
with
option,
one
you
proxy
ip
packets.
We
can
talk
about
compression
later,
maybe
it's
in
the
course
spec.
F
Maybe
it's
in
extensions,
but
the
core
fundamental
property
is
that
we
proxy
ip
packets
and
another
point
I'd
like
to
make
is
to
strongly
disagree
with
miria's
point,
which
is
maria
said
that
the
requirements
document
shouldn't
be
opinionated
here
and
should
allow
both.
We
can't
do
that
like
we.
The
point
of
this
requirements
document
is
to
guide
what
we're
going
to
build,
and
so,
if
we
can't
agree
on
what
the
name,
what
mask
ip
proxy
means
we're
never
going
to
get
anywhere
like
the
or
the
requirement.
F
Second
is
not
going
to
be
useful,
so
my
personal
as
an
individual
take
here
is
that
we
really
should
agree
on
what
this
means
and
what
ip
proxying
is,
and
we
built
that
we're
not
saying
that
mask
won't,
build
the
option
too
at
some
point
in
the
future.
Who
knows
like
that
can
always
happen
later,
but
for
now
it
would
be
nice
to
get
a
requirement
stock
out
the
door
with
option
one,
and
that
way
we
can
start
building
a
protocol
for
it.
I
think
that
is
really
the
the
best
way
forward.
I
You
know,
engineering
guidelines
as
it
should
be
too
complicated,
and
maybe
you
should
be
changing
your
cpu
or
whatever
right.
I
guess
I
am
starting
to
wonder
frankly,
if
we've
like
outlived
the
usefulness
of
this
of
this
requirements
exercise
you
know,
you
know.
I
think
this
is
really
done
in
tempest
with
the
problem,
but
I'm
now
starting
to
feel
like
this
is
like
becoming
proxy
arguments
about
what
the
fight,
what
the
you
know,
what
the
protocol
looked
like
in
the
end.
I
L
L
The
requirements
draft
is
trying
to
talk
about
inputs
and
outputs
of
the
black
box,
and
we
should
absolutely
be
agnostic
about
what's
happening
inside
it,
but
we
cannot
be
agnostic
about
what's
entering
and
exiting
so
we
need
to
decide.
Are
we
supporting
arbitrary
ip
header
options?
Are
we
supporting
ip
arbitrary
ip
versions
across
this
tunnel
like
if
there's
an
ipv10?
Should
it
be
able
to
transit
this?
L
K
All
right
we're
going
to
cut
and
see
if
we
can
wrap
things
up
on
this.
I
do
think
the
point
about
requirements
versus
proxy
discussions
around
versus
a
discussion
around
what
we
think
we
actually
want
as
an
implementation
is
well
taken.
So
let's
try
to
keep
a
focus
on.
You
know
we.
The
second
bullet
here
says
some
use.
Cases
can
be
implemented
with
either
if
there
are
use
cases
that
cannot
be
implemented
with
either.
I
think
that
would
be
the
thing
to
bring
up
right
now.
E
Yeah,
I
do
agree
that
there
should
be
an
option
where
you
can
proc,
where
you
can
like
put
packets
in
ip
packets,
and
then
you
get
the
same
ip
packet
out
at
the
other
end,
but
they
also
use
cases
where
it's
actually
unnecessary
to
create
the
whole
ip
header.
When
you
just
create
the
payload
and
you
can
create
the
ap
header
later
at
the
proxy
and
that
just
saves
you
some
overhead
that
saves
you
some
bites,
and
all
I
want
is
that
we
don't
preclude
to
have
this
option.
E
However,
it
looks
like
I
I
mean,
like
I
think
compression
is
actually
wrong
term.
I
brought
it
up
a
couple
of
minutes
ago,
but
it's
not
the
right
term
here.
It's
just
like
you,
don't
even
create
the
ip
header
at
the
input,
because
you
you
don't
need
to
so
I
don't
want
to
preclude
in
the
requirements
that
we
also
can
easily
support
this
case,
and-
and
I
can
well
imagine
that
we
come
up
with
a
solution
where
both
is
easily
possible
without
a
lot
of
overheat.
F
So
my
understanding
of
one
here
miriah
is
that
it
doesn't
preclude
this
case.
You
can
at
some
point
you
know
later
either
again
can
be
in
the
core
protocol,
but
most
likely
an
extension
say.
Okay,
I
don't
want
to
be
transferring
the
ip
header
or
I
don't
want
to
be
building
the
ip
header.
I
mean
at
the
end
of
the
day
that
the
fact
that
you
built
an
ip
header
that
you
chose
not
to
send
or
you
just
didn't
build.
It
is
an
implementation
detail
that
has
no
impact
on
the
protocol.
F
E
J
F
Choice
is,
I
think,
important
in
a
requirements
document,
because
if
we
can't
even
think
about
what
the
architecture
it
is
we're
building,
then
what
is
the
point
of
a
requirements
document,
because
we
thought,
like
the
three
authors
when
we
wrote
this,
we
took
this
as
an
axiomatic.
We
thought
that
it
was
clear
that
we
were
forming
ipagets
and
based.
You
know
some
discussions
with
you.
F
We
realized
that
that
wasn't
an
obvious
statement
and
that's
why
we
want
to
reach
to
to
have
this
discussion
working
open,
which
consensus
on
the
over
architectural
bit,
which
is
oh
max
ip
proxying
means
we
proxy
ip
packets,
and
I
mean
I
I
understand
that
you
disagree
with
that,
but
I'm
getting
a
sense
that
we're
the
authors
aren't
alone
in
thinking
that
this
is
a
reasonable
architecture.
Choice.
E
So
it
doesn't
mean
it
doesn't
matter.
If
that's
a
reasonable
architecture
choice,
I
don't
think
you
should
make
the
architectural
choice
in
the
requirements
document,
and
I
agree
with
ecker
that
we
probably
got
over
the
point
where
this
requirement
discussion
is
useful
and
we
have
to
talk
about
mechanisms.
E
F
A
Actually
dallas
what
we'd
like
to
do
at
this
point
is:
do
a
hum
between
option
or
yeah
option,
one
and
two
just
to
really
nail
this
down
and
then
confirm
on
the
list,
because
we
have
been
sort
of
floating
around
these
two
different
proposals
for
a
while.
Now
we
just
like
to
get
consensus.
So
what
I'm
gonna
do
now
is
do
a
show
of
hands
for
option
one
and
then
option
two
so
start
with
option.
One
just
take
a
moment
to
fill
it.
A
F
A
Okay,
so
it
sounds
like
most.
People
are
in
favor
of
option
one,
but
there
was
also
some
support
for
option.
Two
well
we'll
confirm:
that's
all
on
the
list,
but
it
it
sounds
like
things
are
leading
in
a
particular
way.
They
also
can
flip
it
back
to
you
but
note
that
we're
at
the
top
of
the
hour
and
mostly
out
of
time.
So
just
a
quick
question
before
we
start
here.
F
A
Yeah,
thank
you.
I
was
just
going
to
say
that
we're,
as
is
per
mass
tradition,
now
we're
going
to
have
an
interim
likely
soon,
so
you
should
see
a
dutiful
go
out
with
times
between
now
and
ietf11
made
you
one
or
or
more
than
one,
depending
on
how
much
work
needs
to
get
done.
But
hopefully
we
can
resolve
some
of
these
issues
then
and
continue
progress.
So
eric
do
you
have
anything
to
say
before
we
wrap
up.
K
Just
a
thank
you
to
our
scribes
and
notetakers
and
such
if
there's
anything
that
as
we
talk
about
requirements,
it
really
is
time
to
start
making
some
decisions
and
moving
forwards
beyond
requirements
to
what
we're
actually
going
to
do
so.
The
we
we
are
talking
about
packets
and
payloads,
and
can
we
do
both?
Should
we
do
one?
Does
that
even
belong
in
requirements?
The
thing
that
I
think
would
be
most
helpful
is
if
we
can
detail
the
use
cases
that
we
cannot
do
with
either
that
would
require
both
or
one
or
the
other.