►
From YouTube: IETF109-MASQUE-20201120-0900
Description
MASQUE meeting session at IETF109
2020/11/20 0900
https://datatracker.ietf.org/meeting/109/proceedings/
C
C
A
Great
all
right,
all
right
all
right,
so
we
can
get
started
thanks
everyone
for
joining
for
the
final
session
of
this
ietf.
A
Perfect,
as
you
all
know,
by
now,
this
is
being
recorded.
We're
following
the
the
sort
of
usual
process
for
you
know,
participating
engaging
in
the
meeting
if
you
haven't
used
the
meat
echo
tool
before
the
instructions
to
interact
with
it
are
here.
A
If
you
want
to
say
something
at
the
mic,
you
queue
yourself
up
by
pressing
the
little
hand
icon
and
then
leave
by
also
pressing
the
hand
icon,
but
in
the
opposite
direction
you
need
to
make
sure
you
explicitly
send
your
audio.
A
Otherwise
we
won't
hear
you
we'll
just
like
be
asking
you
whether,
where
you
are
what's
wrong
with
your
mic,
it
would
be
helpful
to
the
note
takers
and
or
to
the
notetaker
and
scribe
if
you
could
state
your
full
name
at
the
mic
just
so
we
can
get
everything
down
on
the
record.
Clearly
next
slide,
please.
A
This
is
the
no
well
if
this
is
not
your
first
session
for
the
the
meeting
you
may
have
seen
this
before,
just
like
to
point
out
the
code
of
conduct.
You
know
please
be
respectful
to
everyone
here
and
of
their
perhaps
differing
opinions.
We
have
no
we've
had
no
issues
so
far
and
I
don't
expect
we
will
have
any
issues,
but
just
let's
all
be
nice.
A
A
Right
so
before
we
can
go
any
further,
it'd
be
really
helpful
and
great
if
we
could
have
a
scribe
or
notetaker
to
to
help
us
keep
track
of
things
that
transpired
today.
So
someone
could
volunteer
for
both
of
these
things.
That
would
be
very
lovely
robin
says
he
can
describe.
Thank
you
to
clarify.
Do
you
mean
jabbascriber,
no
taker.
A
A
That
lucas
is
going
to
present
before
going
into
this
any
further.
I
want
to
pause
briefly
to
ask
if
anyone
wants
to
bash
the
agenda
or
make
any
adjustments.
F
So
just
a
quick
bash
not
required,
but
if
we
look
at
the
presentations
while
they're
grouped
right
now
by
like
what's
adopted
and
what's
not
topic-wise,
we
have
two
documents
on
connected
udp
and
two
documents
on
proxy
requirements,
and
it
may
be
a
little
bit
less
whiplash
and
better
for
the
conversation.
If
we
can
talk
about
them
together,
okay
with
people-
I
don't
I
don't
know
if
people
have
objections
to
that.
A
Yeah,
from
my
perspective,
that
seems
quite
reasonable.
I'd
like
to
at
least
avoid
context,
switching
as
much
as
you
can
given
the
hour
of
day
for
most
people
mary.
The
proposal
was
to
lump
together
the
connect,
udp
presentations
and
then
lump
together
the
ip
proxy
requirements
at
the
end.
A
A
Yeah-
let's
just
I
guess,
let's
just
say
with
what
we
have
for
now.
If
not
it's
not
unanimous
might
as
well,
not
change
it
all
right
on
that.
We
can
pop
over
to
the
interop
report.
Nicu!
H
E
Oh,
I
got
a
clown
one
and
I
don't
think
people
will
like
that,
but
anyway
mask
interrupt.
Yes,
so
having
you
know,
convened
the
mask
working
group,
I
think
well,
personally
speaking
as
I've
been
really
looking
forward
to
doing
anything
related
to
tunneling
something
in
quick
for
a
few
years
now,
I
know
david's
been
kind
of
working
on
lots
of
ideas
and
stuff
in
the
background,
but
I
never
had
a
chance
to
to
really
sit
down
and
kind
of
play
with
implementing
this.
E
So
I
was
super
excited
for
an
interrupt
next
slide,
please
so
so
during
the
hackathon,
some
of
us
have
been
doing
some
interoperability
testing
full
mask.
So
what
we
have
is
a
nice
kind
of
kind
of
a
bit
like
the
quick
interoperability
matrix
but
different,
and
this
page
is
hosted
by
tommy
on
github.
But
what
this
is
in
a
nutshell,
is
a
a
presentation
of
some
of
the
requirements
taken
directly
from
the
document,
alongside
some
implementations
that
have
been
trying
to
do
interoperability.
E
So
I
might
let
tommy
talk
to
more
about
how
this
was
all
generated,
but
effectively
the
the
list
of
requirements
is
pulled
out
of
the
documents
by
some
magic
and
then
the
the
check
boxes
or
whatever
symbols
on
the
right
hand.
Side
is
manually
populated
here
and
so
like
we
could
go
into
each
of
these.
I
don't
think
that's
important
myself.
It's
good
to
see
green.
Yes,
we've
got
an
ability
to
see
if
things
are
being
failed
or
if
the
features
aren't
even
supported,
etc.
E
But
for
me
the
the
important
stuff
was
that
I
kind
of
look
at
mask
as
being
both
connect
method
being
used
in
quick
which
isn't
strictly
true.
I
know
so
I
apologize,
but
that's
how
I
look
at
it.
So
connect
method,
connect
qdp
in
this
quick,
aware,
proxying
thing
that
we'll
get
onto
later
on
in
the
session.
E
But
you
know
what
I
did
during
this
hackathon
was
to
take
quiche.
We
recently
landed
datagram
support
into
the
main
line,
and
so
you
know
I
forked
off
quiche
and
tried
to
build
a
mask
on
the
top
of
that
just
doing
self
tests
to
start
with
on
localhost,
and
then
you
know
during
the
course
of
the
hackathon,
I
put
up
a
public
test
server
and
had
tommy
fire
things
at
me
and
see
what
worked
or
not.
So
that
was
quite
fun.
E
This
view
is
just
the
requirements
of
connect.
Udp
there's
a
lot
of
green
there
connect
udp
is
simpler
if
you're
going
to
the
next
slide.
Please
you
see
there's.
This
is
quick,
aware,
proxying
with
more
requirements
and
less
green.
That's
that's
the
summary
I
will
give
to
that.
I
don't
know
if,
if
this
is
the
best
way
to
grock
what
happened
in
terms
of
success
for
an
interrupt,
what
I'll
say
is
I've.
E
I
measured
success
by
tunneling
http
3
within
an
http
3
connection,
so
having
a
mask
client
and
a
mask
server
speak
across
the
internet
to
a
web
server
across
the
internet
again
and
without
any
substantial
changes
to
to
our
quiche
transport
library
or
http
3
implementation.
E
E
If
anyone
wants
to
do
some
more
interrupt,
even
though
the
hackathon's
finished
I'll
be
continuing
to
run
that
server
on
the
internet,
but
it
does
effectively
act
as
a
relay
to
any
other
site
on
the
internet,
so
I've
got
some
access
control
there
that
I'm
using
obscurity
for
my
security
model.
So
let
me
know.
B
Out
of
the
queue
to
talk,
so
thanks
lucas,
this
is
really
really
cool.
So
I
just
wanted
to
add
that
I,
and
by
which
I
mean
the
google
implementation,
is
not
on
this
matrix,
because
I
was
planning
on
getting
it
done
last
week,
but
other
work
priorities
got
in
the
way
because
such
as
life,
but
I'm
proud
to
announce
that
I
got
it
working
a
half
hour
ago.
B
So
I
got
connect
udp
working
with
myself,
but
anyway,
all
that
to
say
it.
I
want
to
echo
what
lucas
was
saying
which,
when
you
already
have
an
implementation
that
supports
h3
and
datagrams
it's.
It
was
pretty
straightforward.
The
only
modification
in
the
course
stack
I
had
to
do
was
some
tweaks
to
make
sure
that,
like
some
server
request
handler
could
handle
requests
where
the
thin
bit
was
set
like
connector
connect
udp,
because
that
part
of
our
code
didn't
support
that.
Yet.
B
But
apart
from
that,
everything
works,
so
I'm
going
to
try
intro
up
with
your
server
sometime
next
week,
lucas
when
I'm
going
to
clean
up
the
code
first,
because
this
was
like
completely
a
crash
land
half
hour
ago,
yeah
thanks.
E
Cool
just
to
respond,
I
know
this
is
maybe
detracting
slightly
from
from
interrupt
purely
but
the
the
complication
I
found
with
the
implementation.
I
was
able
to
all
to
do
all
this
in
my
application
code,
but
I
needed
to
rework
the
application
code
to
consider
effectively
recursive
connections,
so
you
know
a
quick
connection
that
could
hold
a
quick
connection
and
that
was
like
for
me
the
hardest
part
really
for
somebody.
Like
a
you
know,
a
browser
vendor
or
client
vendor.
E
B
So
what
I
implemented
so
far
was
kind
of
like
quick
and
quick.
I
I
didn't
actually
do
the
work
of
plumbing
it
into
the
chromium
proxy
layer,
but
that
shouldn't
be
like
overly
hard,
specifically,
like
you
said,
like
there's
already
code
that
handles
this.
So
it's
just
it's
just
a
matter
of
plumbing,
so
hopefully
I'll
get
that
done
soon.
If
time
permits.
A
F
There's
more
to
the
list,
but
effectively
you
can
just
create
a
pr
with
a
json
file
that
defines
your
particular
implementation
and
you
just
list
kind
of
booleans
for
which
features
worked
or
didn't,
and
then
those
features
kind
of
know
how
to
annotate
themselves
as
like.
Oh
that's,
really
bad
or
that's
good.
A
Thanks
lucas,
unless
you
have
anything
else,
I
think
we
can
move
on.
E
I
I
had
a
final
point:
I'll
take
it
to
the
list.
It
was
mainly
about
trying
to
whether
there'd
be
any
benefit
in
defining
like
target
servers
for
tcp
or
udp
to
help
test
this,
but
I'll
take
it
to
the
list.
It's
a
good
idea.
Yeah.
Thank
you.
A
All
right
with
that
we'll
go
on
to
the
first
presentation:
connect
qdp
david.
You
are
up.
B
All
right
I
see
slides,
can
you
hear
me
great
success?
Okay,
so
hi
everyone,
my
name
is
david
schnazzy.
I
work
at
google
and
I
am
still
a
mask
enthusiast
next
slide,
please
so
yeah.
I
just
saw
this
on
twitter
yesterday
and
I
thought
it
was
really
it's
just
oddly
relevant
as
I
was
making
my
mask
slides.
So
I
figured.
I
would
just
point
it
here
because
I
thought
it
was
funny.
B
So
swift
on
security
is
a
well-known
infosec
account
and
oh
weird,
the
slide
just
went
black
for
a
second,
but
we're
back
and
like
there
are
enterprises
where
you
know
the
only
port
they
allow
you
to
talk
to
is
443,
and
I
was
kind
of
happy
that
we
might
be
able
to
have
a
solution
for
that
anyway.
Next
slide,
please.
B
All
right,
so
I'm
going
to
very
quickly
go
over
what
connect
udp
is
for
folks,
who
haven't
been
there
for
at
108,
which
was
our
last
session,
but
very
quickly.
Connect
udp
is
like
connect,
but
for
udp.
That's
all
there
is
to
it.
It's
very
simple
and
the
kind
of
key
property
is
when
you
we
use
http
3.
It
uses
quick
datagram
frames
to
avoid
retransmitting
your
udp
packets,
which
improves
performance.
B
The
big
change
since
last
atf
was
that
the
working
group
adopted
the
draft
next
slide.
Please
so
the
way
it
works
you
when
it's
in
http
3,
we
rely
on
the
datagrams
with
hdb3
draft,
and
so
the
way
those
work
is
every
datagram
it
has
in
its
payload
starts
with
a
flow
identifier
and
then
both
endpoints
kind
of
agree
on
what
these
identifiers
mean
using
a
header
that
is
sent
alongside
the
connect,
udp
request.
B
So
as
a
client,
when
you
say
I
want
to
connect
udp
to
server.example.com,
you
say
by
the
way
the
flow
id
I
want
to
use
for
this
is
42,
and
if
the
server
agrees,
it
echoes
that
in
the
response
and
boom
you're
good
to
go,
you
can
start
sending
on
that.
With
that
flow
id,
you
can
actually
start
sending
at
the
same
time
as
sending
your
connect2dp
request
in
a
stream
frame
just
that,
if
it
gets
lost,
then
your
udp
packets
gets
lost.
So
this
just
performance
optimization
with
some
copy
outs.
B
What
okay?
This
is
what
I
get
for
letting
the
chairs
right
access
to
those
slides.
Thank
you
very
much
next
slide.
Please.
B
I
I
I'm
scared
to
say
it
a
third
time
next
slide,
please
all
right
we're
back
okay,
so
we
do
have
a
sort
of
a
process
problem
with
connect
udp,
which
is
that
we
have
kind
of
a
layering
of
normative
dependencies
between
drafts
where
so,
as
we
were
saying
earlier,
the
connect
udp
draft
has
been
adopted
by
the
mass
working
group
and
at
the
bottom,
the
quick
datagram
draft
is
adopted,
which
regulates
how
you
used,
and
the
datagram
frame
in
quick
is
adopted
by
the
quick
working
group.
B
The
problem
is,
you
need
something
to
define
how
you
use
datagram
frames
with
http
3,
and
that
is
currently
an
individual
draft
of
mine
and
that's
not
good
right.
We,
we
need
we're,
not
going
to
be
able
to
publish
connect
udp
this
way.
So
let's
talk
about
how
we
can
resolve
this
next
slide.
B
Please
so
what's
in
these
slides,
wow
slides
drafts
what's
in
these
drafts
so
on
the
connect2dp
draft
currently
has
the
connectudp
method,
which
makes
sense,
but
one
one
point
that
is
a
little
weird
that
I
we
might
want
to
fix
is
that
the
datagram
floyd
hdb
header
is
also
currently
in
the
connect
udp
draft
and
then
underneath
the
h3
datagram
draft
has
the
concept
of
a
flow
id
and
datagrams,
and
it
also
has
http
settings
to
setting
to
negotiate
that
use,
but
that's
a
little
bit
less
interesting
and
then
the
quick
datagram
draft
has
datagram
frames
and
the
quick
transfer
parameter
that
allows
you
to
negotiate
them
next
slide.
B
B
Simplest
way
to
do
that.
Is
you
put
an
identifier
at
the
start
and
we
went
with
a
variant
like
the
rest
of
quick
because
they're
nice,
and
so
because
this
is
an
extension
to
http
3.
We
use
a
setting,
because,
theoretically,
there
could
be
another
extension
that
defines
this,
but
these
identifiers
have,
to
you
know,
have
a
namespace
so
that
you
can
refer
to
them
and
like
create
new
ones
that
are
like
that.
B
You
know
that
haven't
been
used
before
that
you
unique,
and
on
top
of
that
you
need
a
way
to
synchronize
that
information
between
the
two
peers.
So
let's
say,
if
you
decide:
okay,
I'm
going
to
use
datagram
42
for
this
connect,
udp
stream
and
4
for
that
one
in
a
way
for
the
server
to
understand
that.
So
how
should
we
do
this
next
slide?.
B
B
Thank
you
so
this
it.
I
initially
had
a
way,
but
I
had
a
conversation
with
victor
vasiliev
and
he
prefer
had
a
different
way.
So
he
proposed,
like
just
ins,
using
the
http
request
stream
id
as
the
flow
identifier,
and
so
in
a
way
that
is
pretty
simple,
but
the
the
main
downside
is
it
really,
by
its
nature,
forces
a
one-to-one
mapping
from
an
http
request
to
a
flow
identifier
and
one
of
the
downsides.
B
There
is
because
of
the
way,
quick
stream
ids
work,
the
stream
id
encodes,
the
direction
of
the
stream
and
whether
it's
uni
or
bi-directional.
So
because
http
requests
are
only
client
generated
or
client-initiated.
Sorry,
bi-directional
streams
that
only
gives
you
a
quarter
of
the
stream
ids.
So
you
would
end
up
like
having
way
less
and
so
because
it's
a
warrant
you'd
very
quickly,
bump
into
bigger
encodings,
which
gives
you
less
room
for
application.
Payload,
not
the
end
of
the
world,
but
not
ideal.
B
So
what
is
currently
in
the
draft
and
what
I
personally
prefer
is
to
have
a
separate
namespace
which
is
to
like
you,
generate
a
new
id
anytime.
You
need
one
and
then
you
negotiate
it
with
a
header.
So
it's
a
separate
namespace
from
the
streamid
namespace
and
what
that
allows
you
to
do
is
have
a
many
to
one
mapping.
B
For
example,
where
let's
say
you
could
have
multiple
connect,
udp
streams
that
share
the
same
datagram
flow
id.
That's
that
feature
isn't
used
by
connect
udp
itself,
but
it's
used
by
the
quick
proxy
extension
and
tommy
is
going
to
describe
that
in
our
later
presentation
and
it
allows
also
reusing
flow
ids.
Let's
say:
if
you
have
you
know
low
numbers
and
that
connect
udp
request
has
been
closed
and
shut
down.
B
You
know
that
that
flow
id
is
no
longer
used,
and
if
you
received
a
new
packet
based
on
the
quick
packet
number,
you
can
actually
tell
if
it's
the
new
or
something
old,
so
you
could
in
theory
reuse
them.
That's
I
don't
know
if
we
want
that
kind
of
complexity,
but
it's
a
nice
benefit,
and
so
my
general
gut
feeling
is
that
having
a
separate
namespace
with
negotiation
is
more
extensible
and
might
be
better.
B
So
I
like
to
pause
here
to
ask
for
opinions
from
the
room
about
so
if
we
should
just
I'm
inclined
to
keep
what's
in
the
draft
today,
which
is
what's
on
the
right.
But
I
just
wanted
to
have
this
conversation
in
the
working
group.
So
lucas.
E
Hey
david,
I
I
think
I
raised
an
issue
about
this
on
one
of
the
drafts,
but
like
because
I
was
speaking
to
somebody
about
datagrams
and
my
example
was:
oh,
you
send
a
connect
udp
with
flow.
I
did
well
stream
id
0
and
then
flow
id
0.
and
every
example.
They
were
the
the
streaming
flow
ids
are
always
in
lockstep,
and
I
think
if
you
look
at
that,
it's
kind
of
like
yeah
this
is
this
is
a
bit
weird.
I
think
it
comes
to
the
presentation
like
you
have
on
this
slide.
E
You
start
with
the
simpler
case,
so
people
naturally
want
to
gravitate
to
that.
If,
if,
instead,
you
showed
the
data
ground
flow
id
on
the
left
hand,
side
with
the
the
requirements
and
the
capabilities
it
has
and
then
said,
you
could
throw
all
that
away
to
have
something
simpler,
but
you'll
lose
all
of
these
things.
E
It
might
come
up
with
a
different
answer,
and
I
think
this
is
just
a
facet
of
where
we
are
in
in
mask
is
that
we
haven't
talked
about
like
the
the
quick
aware,
proxying,
and
I
think
as
soon
as
you
understand
that
you
go.
Oh,
that's
that's
why
this
is
actually
really
useful
to
have
a
datagram
flow
id.
So
I
haven't
walked
that
path.
I'm
I
think,
I'm
in
the
camp
of
keeping
the
separate
flow
ids
now.
B
Thanks
yeah,
no
that
and
that's
a
good
point,
maybe
well
well,
let's
go
through
the
queue
see
how
people
feel
where
I
mean
that
chairs
can
correct
me,
but
like
we're,
not
gonna
make
any
like
definitive
decision
here
like
we'll
take
anything
to
the
list
anyway.
So
if
folks
change
their
mind
based
on
later
presentations,
that's
okay,
tommy.
F
F
Having
done
the
implementation
for
this,
I
did
find
it
a
bit
simpler
to
handle
the
logic
for
is
essentially
like
if
you
were
doing
a
connected,
udp
layer,
that
layer
will
be
explicitly
needing
to
open
up
some
datagram
flow
connectivity
with
quick
and
having
that
be.
The
quick
api
can
essentially
offer
just
like.
F
For
so
essentially,
there's
too
many
entanglements
with
implementations
about
how
the
stream
id
is
going
to
actually
get
assigned
when
you
send
and
it's
a
lot
easier
to
deterministically
have
consistent
behavior
if
the
h3
mask
layer
is
controlling
all
of
it.
So
I
think
we
should
stick
with
what.
B
We
have
cool
thanks
and
oh
and
actually
a
point
I'll
add
on
this-
that
I'm
somewhat
getting
from
what's
going
through
the
jabber,
which
I'm
not
fully
following
sorry
right
now,
is
that
if,
let's
say
someone
were
to
build
a
different
application
over
http
3
or
an
extension
to
http
3
that
say
did
some
stuff
over
a
unidirectional
stream
in
http
3.
They
could
still
have
a
way
to
build
this.
I
I
don't
know
it's
just
just
a
common
to
general
extensibility.
H
Mariah
yeah,
I
generally
often
think
that
probably
having
a
distant
namespace
is
much
more
flexible.
H
I
just
wanted
to
note
that,
depending
on
how
you
assign
the
flow
ids,
you
might
need
some
kind
of
conflict
handling
whatever,
which
makes
it
slightly
more
complicated,
but
that's
also
something
that
really
we
can't
discuss
right
now,
because
I
think
this
needs
to
be
further
specified
before
we
can
go
into
like
a
depth
and
it
is
there
cool.
Thank
you.
I
Ecker
I
mean
so
I
mean
first,
I
think
I
think
like
this,
you
know
this
longer
burn
encoding.
Things
like
a
thing
seems
like
a
red
hair
into
me.
As
my
vision
points
out,
there's
like
it's
pretty
easy
to
it's
pretty
easy
to
take
that
space,
and
also,
as
far
as
I
can
tell
just
means
that
you
get
to
like
two
bites,
especially
you
get
to
one
bite
and
like
at
the
point
where
you're
running
like
a
zillion
concurrent,
yeah
yeah.
That
was
just.
I
You
know
I
I
guess
my
take
on
this
is
an
example
of
you're
not
going
to
need
it
and
we
don't
need
it
for
this
application
and
if
we
ever
need
it,
it's
easy
to
add
one
thing.
That's
worth,
or
I
guess.
I
We
do
not
need
multiple,
we
do
not
need
reusing
employees,
we
do
not
do
not
need
many-to-one
mappings
at
this
point,
and
so,
and
so
this
is
quite
a
bit
simpler.
It
also
has
the
advantage
that
it
also
has
the
advantage
that
you
can't
say
incoherent
things
so
in
this
process,
so
your
proposal,
for
instance,
I
can
do
two
requests
with
the
same
connection
flow
id
and
then
the
whole
interactive
checking
thing
falls
over
and
victor
is
because.
B
I
mean
and
in
some
cases
that's
a
benefit,
that's
not
a
negative
like
so
to
do
I
mean
maybe
he
relies
on
it,
but
yeah.
I
Sorry
go
ahead,
yes,
I
I
understand
that
I
understand
this
useful
proposal,
but
since
I'm
gonna
complain
about
the
proposal,
when
I
see
it
that
doesn't
pursue
me
very
much
so
but
as
I
say,
an
advantage
of
vision
proposal
is
that
you
ca
that
you
can't
accidentally
reuse,
flow
ids
and
therefore
does
not
require
servers
facing
allows
you
to
check
for
it,
because
you
already
have
a
server
service
unless
you
already
have
the
connect
to
check
for
http
reuse,
and
it
simply
goes
one
to
one.
B
So
having
implemented
this
like,
I,
that
did
not
introduce
any
complexity
in
my
implementation,
but
I
recognized
that
you
know.
B
I
Sure
I
I
mean
I,
I
guess
I
guess
you
know
angles
lawyer-
have
to
ask
how
big
this
this
this
protocol
is
in
general.
But
it's
like
a
new
piece.
It's
a
new
thing.
You
have
to
do
and
something
you
can
get
wrong.
So
it's
like
not
it's
not
it's
not
free,
all
right,
fair
enough
and
you
go
into
fahrenheit
effort
and
quick
in
other
places
and
quick
to
avoid
being
able
to
say
things
that
are
stupid.
So
so
again,
okay,
I'm
done
so.
The.
B
Way,
I
personally
think
about
this
is
that
it's
analogous
to
push
ids
in
http
3..
They
have
their
own
namespace.
That
is
distinct
from
streams
and
that
works
so
anyway,
but
thank
you
victor.
D
I
wanted
to
say
this:
the
reason
where
I'm
suggesting
stream
ideas
specifically,
is
that
streams
are
pretty
much
the
only
thing
in
kwik
that
exists
permanently
on
top
of
connection.
D
So,
if
you
have
an
http
connection,
all
of
your
datagram
flows
will
be
naturally
associated
with
some
stream,
because
otherwise,
what
else
would
they
be
associated
with?
Because
nothing
else
really
exists
and
the
reason
I'm
advocating
for
this
is
just.
I
believe
that
one
to
one
is
mostly
enough
for
everything
and
I've
read,
connect
quick
draft
and
I'm
still
not
convinced
why
what
this
cannot
be
engineered
with
one
to
one:
okay,
tommy.
B
Completely
inaudible
tommy,
maybe
type
it
in
the
jabber.
Let
me
reconnect
audio
cool
thanks
I'll,
take
lucas
in
the
meantime
and
hopefully
by
then
you'll,
be
back
lucas.
E
And
then
we'll
cut
the
queue
after
that,
I
think
so.
The
the
connect
qdp
method
that
currently
in
draft00
is
up
to
date
is
defined
to
be
used
across
all
http
versions,
and
so
there's
some
text
in
there.
That
describes
the
proxy
training
case
where,
if,
if
you're
talking
to
a
h3
proxy.
B
E
B
B
So
so
this,
and
actually
like
that's,
going
to
be
the
topic
of
my
next
slide,
the
this
is
actually
a
question
for
datagrams
in
h3.
Overall,
that
is
not
specific
to
connect
udp
and
the
reason
that
victor
particularly
cares
is
from
the
web
transport
perspective.
Web
transport
is
interested
in
having
a
variant
overage.
B
F
Right
and-
and
for
that
and
it
I
would
strongly
prefer
to
have
it,
be
something
that
is
negotiated,
that
the
flow
ids
are
explicitly
done
at
a
higher
level
like
in
header
negotiation
here,
because
if
we
do
not
do
that,
we're
essentially
eliminating
any
possibility
of
a
request
in
the
future.
That
needs
to
open
up
two
datagram
flows,
for
you
know
like.
I
agree
that
maybe
we
don't
have
those
use
cases,
but
that's
different
from
saying
we're.
F
B
So
if
we
so
this
kind
of
covers
what
we
were
just
saying,
where
the
clearly
the
connect
udp
method
should
stay
in
the
connect,
udp
draft
and
if
you
look
at
like
our
layering
here,
like
with
the
webcast
working
group,
might
end
up
standardizing
http
3's
transport
over
some
kind
of
h3
datagram,
and
so
the
question
here
for
the
group
is
we
have
like
some
things
that
we
can
do
like,
for
example-
and
I
I
had
this
conversation
with
the
mass,
quick
and
hdb
chairs
of
what
do
we
want
to
do
with
the
concept
of
an
http
3
datagram.
B
Clearly,
there's
a
need
for
such
a
concept
and
there
are
multiple
uses.
So,
from
my
perspective,
defining
this
in
connect.
Udp
wouldn't
be
great,
because
then
you
would
have
things
like
web
transport,
relying
on
connect
udp
but
or
like
depending
normatively,
on
connect
gtp
without
using
it,
which
sounds
odd
to
me,
and
another
option
would
have
been
to
fold
it
into
the
quick
datagram
draft
over
and
quick.
B
But
the
vibe
I
got
at
the
time
was
that
very
much
like
that:
draft
wanted
to
stay
at
the
transport
layer
and
just
do
datagram
frames
and
not
merge.
So
I'm
thinking
of
having
three
separate
drafts
and
move
the
mac
mechanism
that
allows
you
to
negotiate
flow
ids
from
connect2dp
to
h3,
datagram
martin
red
is
in
the
queue
what's
up.
B
K
I'm
I'm
starting
to
wonder,
as
as,
as
you
know,
I've
been
a
little
concerned
about
the
about
ecn,
whether
or
not
it's
actually
in
the
connect
udp
draft.
I
would
be
sad
if
the
the
outcome
of
this
process
was.
K
The
only
way
to
use
ecn
for
quick
over
quick,
quick
over
mask
was
to
go
to
ip
proxy,
but
if
we,
if
we
do
it
so
again,
whether
there's
another
draft
for
this
or
not,
that
implies
some
sort
of
packet
level
feedback
per
packet
feedback,
which
implies
a
change
to
the
datagram
frame.
So
I'm
I'm
wondering
if
we
need,
I
I
I'm
not
sure
if
there's
a
path
besides
like
maybe
this
disassociating
the
concept
of
an
h3
datagram
into
the
into
the
separate
application
needs
that
are
sitting
on
top
of
it.
B
So,
and
not
going
to
go
too
deep
down
the
rabbit
hole
into
problem
solving
here,
but
so
I
agree
that,
like
there
should
be
a
way
to
do
ecn,
probably
as
an
extension,
to
connect
udp.
But
I
think
that's
a
real
totally
something
that
we
should
design
qdp
to
support
and
like
kind
of
riffing
off
to
tommy's
earlier
comment.
You
could
imagine
saying
you
do
you
connect
udp
request
and
you
say:
here's
the
datagram
flow
id
for
most
of
my
udp
packets
and
here's
a
separate
one
for
congestion
experienced.
B
So
you
would
need
to
have
two
flow
ids
associated
with
one
request,
so
that
for
me,
is
kind
of
an
indication
to
like
that
that
the
model
that
we
have
on
this
slide
works
so
yeah.
But
I
agree
with
you:
we'll
have
to
figure
that
one
out
and
that's
kind
of
why
I'm
really
would
prefer
to
err
on
the
side
of
extensibility.
K
Okay,
yeah,
so
that
is
actually
yeah,
probably
quite
a
bit
cleaner
than
having
another
field
in
datagram.
So
I
I
guess
from
that
perspective,
I
would
agree
with
your
assessment,
which
way
we
should
go
just
simply
for
that.
You
reason.
B
Cool
before
I
move
on
do
folks
have
thoughts
on
the
split
of
drafts
or
which
working
groups
they
should
be
in
the
the
vibe
I
got
from
the
chairs
was
that
this
makes
sense
and
it
sounds
like
the
ad
agrees
as
well,
but
if
anyone
objects
to
that
idea,
please
tell
us
why.
A
This
was
a
conversation
amongst
the
hd
biz,
quick
and
mass
chairs,
and
the
consensus
was
sort
of
to
move
it
in
the
direction
of.
B
Mask
all
right,
so
the
well
we'll
have
to
have
more
like
clearly
from
the
conversation
earlier.
The
streams
versus
separate
name
space
is
going
to
be
an
interesting
conversation
that
we
haven't
completely
resolved,
but
I'm
getting
some
sense
of
consensus
that
the
mechanism
for
this-
and
you
know
if
we
use
streams
that
makes
it
even
easier,
but
should
be
defined
in
one
draft.
B
B
B
And
now
for
something
completely
different,
let's
look
at
some
of
the
open
issues
that
we
have
on
github
and
try
to
knock
through
as
many
as
we
can.
A
B
All
right
so
the
first
one
is
and
that's
I
have
to
apologize
on
this
one.
These.
I
had
these
slides
at
the
previous
ietf
and
then
I
completely
skipped
them
because
it
was
4.
00
am
and
my
coffee
hadn't
kicked
in
yet
so,
let's
go
through
them
again,
so
conceptually
when
you're
doing
mask
from
a
client
you're
talking
to
a
through
a
proxy
to
talk
to
an
end
server
and
from
your
perspective
the
proxy
is
one
box.
B
B
So
it's
totally
possible
that
you're
using
http
3
from
a
client
to
the
intermediary
and
then
http
one
one
from
that
reach
to
the
back
end
and
you're
canis
qdp
request
is
going
to
span
multiple
http
versions
and
on
the
first
hop
it
can
do
datagram
and
from
the
client's
perspective
you
think
you
can
do
datagram,
but
then
it's
not
going
to
be
able
to
do
it
on
the
rest.
So
next
slide.
Please.
B
Thank
you,
the
and
so
the
the
problem
there
is,
if
you're
sending
datagrams
and
they
can't
go
any
further.
Things
are
going
to
break
right
now.
What
we
do
in
the
in
the
draft
is
to
use
the
datagram
flow
id
header
to
the
server
echoes
the
one
from
the
client
and
that's
the
way
the
server
says:
hey,
let's
do
datagrams
in
this
case.
B
If
we
were
to
make
datagram
flow
id
a
hub
by
hop
header
that
would
kind
of
force
the
intermediary
to
drop
it,
even
if
it
doesn't
speak,
connect
udp
and
ensure
that
we
fall
back
to
sending
everything
over
tcp,
but
it's
top
by
hop
headers
are
really
no
longer
in
fashion.
So
I'm
not
sure
what
the
best
recommended
way
and
I'm
seeing
mike,
who
definitely
knows,
should
be
way
better
than
I
do,
but
first
eckerd's
in
the
queue
ecker
what's
up.
I
I'm
having
a
little
trouble
understanding
how
you
get
into
this
hole,
so
these
are
both
operated
by
the
same
person,
and
so
why
isn't
this
a
case?
If
you
don't
do
this,
then.
B
I
I
mean
my
my
put
is
like
don't
like
if
you,
if
you
have
this
kind
of,
if
you're
I
mean,
if
you
have
a
split
architecture
like
this,
then
don't
accept
like
that.
Then
then
don't
then
I
mean
the
client's
not
aware
of
this.
You
complete
control
of
your
writing.
So
so,
like
don't,
don't
accept,
don't
accept
this
this
this
proposal
and
then
forward
someone
doesn't
take
it
and,
and
that
makes
the
entire
problem
go
away.
B
L
So,
first
off
I
just
wanted
to
point
out
that
the
connection
header
and
hop
by
hop
headers
aren't
a
thing
in
h2
or
h3.
L
Whoops,
sorry,
they
don't
exist,
but
the
other
piece
here
is
that
connect
and
connect
udp,
I
presume,
are
essentially
a
make
this
happen.
I
don't
care
how
so
yeah
you're
going
to
negotiate
your
flow
id
now
the
question
of
whether
that
header
passes
along.
L
But
ultimately,
like
you're,
what
you
have
on
the
diagram
here,
it
doesn't
matter
because
you're
doing
an
h3
connection
with
connect,
udp
you're
asking
it
for
udp
connection,
and
it's
going
to
ask
the
next
top
for
a
udp
connection
as
well
using
its
own
proxy.
You
don't
have
to
know
their
multiple
intermediaries.
B
M
So
there's
been
a
discussion
in
the
chat.
I
think
the
scenario
that
you've
shown
here
is
probably
not
the
the
most
interesting
one
to
be
talking
about.
The
really
interesting
one
to
be
talking
about
is
the
client
talks
h2
to
the
intermediary,
but
the
intermediary
talks
h3
to
the
back
end
and
what
happens
in
that
case?
If
the,
if
the
intermediary
doesn't
know
about
connect,
udp
is
it
goes.
M
J
M
And
the
headers
go
all
the
way
back
through
and
it
all
breaks,
because
the
client
thinks
he's
getting
datagrams.
The
the
ultimate
proxy
thinks
it's
getting
datagrams,
but
nothing
is
getting
through
this
link,
that's
h2,
so
what
you
really
want
here
is
something
like
connect
and
mark
mentioned
this
in
the
chat.
I
think
it's
the
right
solution
here,
which
is
use
a
setting
confirm
that
the
other
side
supports
connect
udp
using
the
setting,
and
you
will
never
go
any
further
than
one
hop
with
your
request
and
at
that
point
you're.
M
Fine
and
the
other
thing
that
I
would
suggest,
then,
is
that
if
you
happen
to
be
sending
this
over
http
1
1,
then
you
can
put
the
datagram
flow
id
in
a
connect
connection
header.
So
it
won't
go.
It
won't
travel
any
further
than
you
might
expect
and
then
I
think
you
have
a
relatively
complete
solution
to
this
with,
but
you
don't
get
the
ability
to
to
skip
intermediaries.
You
have
to
confirm
that
everyone
along
the
way
is
willing
to
participate
and
I
think
that's
a
feature.
No,
no.
B
Yeah
totally,
that
makes
sense
cool
thanks.
That's
that's,
really
helpful
tommy
and
then
maybe
after
tommy,
we
stop
and
we
move
on
to
the
next
topic
next
step.
A
Can
I
interrupt
quickly
yeah
yeah
yeah,
so
just
the
chatter
in
the
the
the
discussion
in
the
chat
suggests
that
we
can
people
want
to
go
over
to
get
through
all
all
these
issues
so
feel
free
to
burn
through
them
as
needed.
David.
F
Go
ahead
just
bouncing
off
of
what
martin
was
saying,
because
I
think
that's
definitely
the
right
approach.
We,
you
already
do
have
a
setting
for
supporting
h3
datagrams
right.
Yes,
so
I
I
think
it'd
be
useful
to
analyze
the
situation
like
if
that
first
h3
hop
in
the
example
that
martin
gave
doesn't
know
about
connect
udp.
It
likely
also
doesn't
recognize
that
setting
and
I'm
wondering
if
we
can
just
say
if
you
recognize
that
setting
you
have
to
know
what
connector
udp
and
these
headers
mean.
B
Would
have
to
put
the
two
in
the
same
draft
because
you
can't
well,
I
mean
it
would
be
silly
to
have
a
normative
upref,
so
I
would
be
inclined
to
add
a
second
setting
to
like
have
a
clean
separation
so
that,
if
someone
defines
another
method
say
you
know
we're
talking
about
connect
ip
or
connect
network,
whatever
it'll
be
they
that
could,
you
know,
have
its
own
setting
as
well.
I
Guys
because
I
think
I
had
a
amaze
late,
but
I
or
earlier
something
but
a
little
tracking
on
the
scenario
martin
was
describing.
So
as
I
understand
the
scenario,
and
is
that
that
you
have
you
know
a
chain
of
h3,
h2
h3
and
that
you
send
connect
udp
to
h3
and
it's
like
and
and
it
doesn't
barf
all
over
and
and
and
this
is
able
to
do
it
as
unpowerful
overview
and
then
and
then
it
gets
for
the
h2
when
they
shoot.
B
So
maybe,
let's
take
this
offline,
so
I
I
mentioned
that
like
we.
Maybe
we
should
move
on
to
the
to
the
next
one.
I
I
think
mt
has
a
clean
solution.
As
long
as
you
have
a
setting,
then,
like
you,
you
force
the
fact
that
the
the
first
intermediary
understands
connect
udp
means
that
it
won't
fall
over.
Doesn't
that
resolve
the
problem
for
you.
I
I
guess
I
don't
understand
what
the
problem
is.
Is
my
question,
like
oh.
B
Okay,
so
imagine
think
of
it
like
this,
you
have
h3
h3
and
h2
in
the
middle,
and
so
you
start
off.
Connect
udp
comes
in
the
the
two
intermediaries,
don't
know
about
it,
so
they
forward
it
along
over
h2,
including
the
datagram
flow
id
header,
and
then
it
gets
to
the
other
side
and
the
like
the
last
intermediary
or
the
back
end.
Sorry
says
yeah.
This
looks
fine,
so
it
replies.
It
echoes
that
and
then
makes
it
all
its
way.
B
So
the
first
thing
term
jerry
and
the
back
end
both
think
that
everything
is
okay.
The
problem
is,
they
have
an
h2,
only
thing
in
the
middle
and
so
everything's
connected,
but
then,
when
they
oh,
when
they
send
to
the
h2
you're
saying
they
just
I
don't
know
what
I'm
saying
so,
no
no
yeah
the
h31s.
They
would
receive
datagrams
and
then
not
know
what
to
do
with
them,
because
they
don't
actually
speak
connect2dp.
They
let
the
requests
through
they
let
the
response
through,
but
they
actually
don't
know
what
this
means.
B
I
Okay,
so
so
this
is
so,
if
I
understand
correctly,
like
I
restated
you're
saying
that
for
some
reason,
the
the
the
the
proxies
one
and
two
don't
they're
like
hey,
I
don't
underst
they're
unaware
of
connecting
udp
and
they're,
just
they're
just
handling
the
generic
requests
that
they
forward
to
proxy
three.
I
I
Like
the
way
to
handle
this
is
the
back
end.
If
you,
if
your
system
is
constructed
in
a
you
know,
in
a
way
where,
in
a
way
where
you
do
not
have
consistency,
all
the
way
through
the
chain,
the
back
end
should
choke
when
it
gets
the
message
and
that
allows
for
an
incremental
deployment
or
not.
So
I
guess
I
just
like,
like
all
these
scenarios,
where,
like
within
this
blue
box,
there's
a
bunch
of
weird
consistencies
like
just
seem
to
be
like,
like
don't
do
those
things.
B
Yeah,
so
the
then,
and
then
I
totally
agree
so
then
we
kind
of
have
two
solutions
there.
One
is,
we
just
say:
hey,
don't
do
this
in
the
blue
box
and
the
other
is
mt's
proposal
of
having
a
setting
to
say
that
you
support
a
method
which
is
kind
of
weird
given
how
the
all
other
http
methods
work
and
that
would
kind
of
force
the
breakage.
B
If
someone
it
would
prevent
the
foot
gun
I'll
have
to
think
about
it,
some
more
because
for
for
the
kind
of
hidden
server
part
of
mask
the
setting
is
kind
of
a
dead
giveaway
and
I
think
in
h3
we
dropped
the
feature
to
allow
you
to
update
the
settings
mid
connection,
unlike
h2,
so
yeah
we'll
have
to
think
about
this
some
more,
but
I
think
like
that,
has
I
think,
we're
ready
to
move
on
to
the
next
topic
yeah.
But
thank
you.
I
Sure,
certainly,
if
you
can
discuss
this
yeah,
I
mean
certainly
we
can
discuss
this.
When
I
mean
I
guess
at
the
point
where
we
have
a
proposal
that
should
do
something
here
we
should
we.
We
should
discuss
that
bit
more.
Do
we
need
something
right?
I
mean
it
sounds
like
martin
floyd
or
something,
but
that
would
change
the
draft.
So
if
we
have
someone
want
me
to
change
the
draft
we'll
discuss
it,
then
right.
B
Yeah
absolutely
so
like
this
would
probably
turn
into
a
discussion
on
the
list
or
or
the
github
issue,
or
you
know
pr
and
all
that
cool
next
slide.
Please
and
there's
some
really
good
conversation
on
this
in
the
jabber,
but
it's
going
back
so
fast
that
I
can't
follow
it
while
presenting
slides
so
I'll
go
back
after
this
and
reread
through
everything
yeah.
B
Please
make
sure
that
the
entire
jabber
log
is
in
the
minutes
chairs.
That
would
be
amazing
all
right
so
now
for
a
much
simpler
issue.
B
This
very
clearly
states
that
all
methods,
including
new
methods,
must
have
a
target
uri,
and
that
includes
you
know,
scheme
authority
and
path,
and
that
document
has
an
exception
for
connect,
and
so
what
I
did
in
the
draft
originally
was
to
kind
of
mirror
connect
for
connect
udp,
but
that
is
technically
incorrect
or
sorry
in
violation
of
the
http
semantics
documents,
and
I
found
when
I
was
implementing
this-
that
I
had
a
whole
bunch
of
code
that
was
validated
that
the
scheme
was
present
and
failing
the
request
if
it
wasn't
and
I'm
kind
of
tempted
to
just
say:
okay,
let's
use
udp
colon,
slash
and
move
on
with
our
lives,
and
the
path
is
just
a
single
slash
and
you're
done.
B
What
do
people
think
about
that?
Oh
yeah
and
the
proposal
of
udp
was
from
mike
bishop
on
the
issue.
B
M
So
it
turns
out
that
I
just
did
a
little
search
and
there
are
already
two
uses
in
the
registry,
at
least
according
to
wikipedia,
because
that
was
the
most
convenient
place
to
find
these
and
they're
weird.
M
B
Lucas
is
proposing
mt
colon,
slash,
slash
in
the
jabber,
maybe
just
connect
connect,
dash,
udp
or
clone
slash,
slash
that
would.
B
M
B
All
right,
I'll,
probably.
M
I
I'm
I'm
not
sure
that
you
quite
appreciate
the
the
extent
of
the
work
that's
involved
at
this
point,
but
good
for
you.
B
Wait
as
in
getting
the
ina
registration
for
a
new
scheme
is
that
hard.
M
B
G
Say
that
I
think
that
if
we
are
going
to
be
getting
a
scheme,
since
we
were
talking
about
hypothetical
methods
for
connect,
ip
or
connect
network,
or
something
like
that,
maybe
if
it
is
in
fact
going
to
be
difficult
to
get
one
properly,
we
should
consider
if
we
should
have
one
for
all
of
them
or
one
each
because
it
it
it
feels
like
it
could
be
unnecessary
work
if
they're
all
sort
of
describing
a
similar
concept.
B
G
Being
suggested
in
the
jabra
chat,
which,
like
I
think,
would
also
be
okay,
because
what
I'm
sort
of
thinking
about
is,
if
we're
doing
something
like
connect
ip,
something
like
the
port
is,
is
presumably
only
describing
the
target
host
right.
It's
not
something
that
we
need
further,
so
I
I
think,
there's
definitely
opportunity
to
do
something
coherent
at
the
mask
level,
rather
than
per
proposed
method.
B
B
So
kazuo
was
asking:
if
the
method
would
be
connect,
no
the
method
would
still
be
connect,
udp
here,
all
right.
Anyone
else
all
right
next
slide
by
the
way
chairs.
If
for
this
one,
since
we
have
a
clear
resolution,
if
you
could
put
that
in
the
github
issue,
that
would
be
cool.
Thank
you
yes.
So
this
is
an
interesting
security
issue.
So
in
connect,
when
you
you
know,
ask
your
proxy
to
connect
to
a
server,
it
sends
a
tcp
syn
and
waits
for
the
synag.
B
It
doesn't
let
you
send
any
application
data
to
the
server
to
the
target
server
until
that
server
has
repo
responded
with
a
synag
that
you
know
prevents
some
levels
of
amplification
vectors
or
just
you
know,
kind
of
denial.
Service
attacks.
Udp
doesn't
have
this
at
all.
B
So
should
we
fix
this?
You
know.
To
what
extent
do
we
care
because,
like
at
the
end
of
the
day,
the
server
sending
you
a
synack
isn't
really
consent
to
receiving
a
giant
mountain
of
application
data
like
if
I
go
talk
to
any
website
on
port
80,
I
will
get
a
synag,
and
so
do
we
need
to
solve
this?
Yes,
no,
and
also,
if
we
want
to
solve
it,
how
should
we
solve
it?
B
I
I'm
not
sure
a
better
suggestion,
but
it
seems
to
me
that,
like
that
the
point
bender's
pain
and
job
was
the
salient
point,
which
is
that
that
that
synap
basically
opens
the
connection,
but
the
real,
the
real
defense
is,
that
is
it
the
sir?
Is
it
the
proxy
in
connect?
I
Does
tcp
continue
control,
and
in
this
case
that
is
not
true
right
in
this
case,
basically,
because
the
proxy
doesn't
get
to
examine
the
any
any
of
the
quick
data
like
it
has
no
idea
like
whether
things
are
being
actors
thrown
on
the
floor
or
whatever
right,
and
so
that,
and
so,
like
the
rate
control
starts
to
happen,
end
to
end,
and
so,
given
that
the
most
likely
things
are
going
to
be
killed
by
this
are
going
to
be,
in
fact,
quick
servers
and
therefore
will
accept
connections,
and
you
won't
even
get
to
and
you
wouldn't
even
get
to,
you
won't
even
get
to
observe.
I
Like
I
mean
now
we're
like
not
all
the
things
we
did
to
make
it
like
impossible
for
like
little
bias
to
inspect
the
traffic
or
gotta
come
and
divide
us
in
the
ass.
Like
basically,
you
know
you
know
so,
like
you
know
I
can.
I
can
open
the
case
to
the
server
and
just
like
pour
traffic
down
it
and
the
proxy
doesn't
even
get
to
observe
like
that.
I
The
server
sent
me
an
rsd
right,
so,
like
I
I
mean
I
can
see
why
it
would
be
appealing
to
to
do
to
do
this,
but
I
think
it
doesn't
actually
help
very
much
okay.
I
I
I
totally
agree
with
you:
what
do
you
think
we
should
do
from
here?
I
I
don't
know
I
mean
I
think
like
this.
This
is
an
inherent
problem.
Actually,
like
basically,
I
mean
if
we
just
step
back
from
this
whole
thing,
and
you
say,
like
you
know
I
mean
so
so
the
traditional
thing
you
would
do,
obviously,
is
that
the
server
would
penalize
the
the
the
apparent
client
right,
but
but
in
this
case
that
means
penalizing
all
the
co,
all
all
the
people
are
co-tenanting.
I
On
that
same
on
the
same
proxy,
which
seems
bad,
I
mean,
if
we
had,
I
mean
just
just
to
clarify
right.
You
know,
if,
like
I'm
not
if,
if
like,
if
proxy
co
is
operating,
some
giant
proxy
farm
and
like
a
lot
of
people
are,
are
I
connected
to
google
then
and
like
one
of
them
is
being
abusive?
Google,
like
you
know,
google
people
has
proxy
cover,
they
realize
all
the
people
are
connected
to
google
as
well.
I
So
this
is
an
interesting
problem
which
I
can
have
to
deal
with
more
generally
on.
You
know
in
terms
of
like
the
manageability
of
the
whole
system,
and
I
don't
think
I
have
a
clear
answer
so
I'm
so
so
I'm
not
going
to
step
back,
but
I
think
that's
it,
but
I
don't.
In
any
case
I
don't
think
would
be
any
new
issue.
I
don't
think
the
initial
initial
window
is
the
problem.
B
Yeah,
no,
I
agree
because
if
we
take
an
even
further
step
back
like
the
there's,
the
dino
denial
service
problem,
but
there
are
like
other
ones.
Let's
say,
for
example,
that
you
use
connect
today
and
you
go
and
you
deface
a
wikipedia
page
like
in
your.
If
you
do
this
in
some
countries
in
the
eu,
they
will
like
come
after
proxy
corp
with
like
warrants,
because
that
ip
showed
up
in
the
logs-
and
let's
say
you
put
something
that
is
very
specifically
illegal
on
a
wikipedia
page.
B
I
I'm
going
to
turn
that
problem
around
like
this
right
and
and
there's
no
way
for
them
to
do
that,
whereas
you
know,
if,
if
you
face
the
wikipedia
page
law,
enforcement
comes
up
and
they're
like
hey,
you
know,
like
you
know,
like
this
user,
defines
wikipedia
page
like
you,
that's
like
a
slow
motion
event,
or
this
is
like
this
is
like
a
merchant
event.
So
I
think
the
the
time
scales
are
quite
different.
M
Here
is
that
the
there
are
two
two
parties
that
want
to
confirm
permission
to
send
and
the
client,
presumably,
if
in
the
protocol
that
it's
talking
whatever
protocol
that
happens
to
be,
will
be
verifying
that
the
server
wants
to
talk
to
it
before
it
sends
it
any
significant
amount
of
traffic.
If
it's
a
well.
H
M
Client,
but
what
we're
looking
for
here
is
that
the
server
being
able
to
independently
verify
that
the
the
server
is
not
the
proxy.
I
should
use
the
word
proxy.
The
proxy
as
well,
is
able
to
verify
that
the
server
is
willing
to
talk
to
this
particular
client
as
well,
and
that's
challenging.
M
If
it
were
a
quick
connection,
I
could
say
you
know
what
just
just
watch
for
the
initial
original
destination
connection
id
to
come
back
and
everything
will
be
golden,
but
those,
but
that
doesn't
work
because
you
have
to
understand
the
protocol
in
use
at
a
level.
That
is
probably
a
little
bit
too
much
to
ask
of
this
level.
Yeah.
B
Well
to
the
point
where
we
would
then
like
as
a
quick
enthusiast,
I
would
be
extremely
sad
if
deployment
of
mass
caused
us
to
ossify
a
quick
version
that
would
be
like
the
worst
possible
outcome.
M
B
One
potential
suggestion
that
actually
came
from
olivia
bonavochura
earlier
this
week,
so
I
didn't
have,
I
didn't
put
on
the
slides
but
or
actually
came
yesterday
after
I
made
the
slides
was
about
icmp
one
like
what
do
we
do?
What
do
you
do
on
the
proxy?
If
you
receive
you
know
port
unreachable
from
the
server
and
that's
kind
of
a
mixed
bag
of
in
a
way,
it
kind
of
helps
us
solve
this
problem
to
some
extent,
but
it
actually
doesn't
solve
it.
B
M
N
N
For
any
thing
that
runs
on
top
of
udp,
we
call
it
a
circuit
breaker
and
we
apply
circuit
breakers
to
pretty
much
anything
that
says,
I'm
gonna
run
on
udp,
but
I
don't
have
a
you
know
like
a
tunnel,
for
example
that
doesn't
necessarily
have
a
construction
controller.
All
you
say
is
well.
If
you
get,
if
you
start
sending
too
much
stuff
too
quickly
or
something
like
that,
then
there's
a
circuit
breaker
that
goes
into
place.
N
The
problem
you're
facing
here
is
exactly
that:
it's
it's
it's!
It's
not
a
new
problem,
but
I'd
imagine
that
it
means
certainly
different
than
than
than
connect,
because
you
said
with
synac
you
get
some.
You
get
a
very
clear
signal,
but
yeah
I.
N
I
don't
think
that
you
can
really
solve
this
as
a
protocol
mechanism.
I
think
the
best
you
can
expect
is
suggest
some
things
for
deployments
in
terms
of
protections,
because
that's
ultimately
what
you're
looking
for
here
is
that
you
don't
want
to
allow
abuse
or
a
dos
sort
of
a
situation.
So
I
imagine
that
the
best
you
will
be
able
to
do
here
is
is
suggest
some
things
for
a
deployment
to
up
to
employ
mechanisms
to
employ
so
that
it
doesn't
exhaust
resources.
B
Cool
thanks
that
makes
sense
yeah.
I
think
we
might
have
a
proof
of
impossibility
to
some
extent,
all
right
next
slide
and
next
slide
and
yeah.
So
do
we
have
any
questions
that
are
not
specific
to
any
of
these
issues
on
connect
udp.
We
are
clearly
over
time,
but
thank
you
like.
I
think
those
conversations
really
helped
do
any
comments
or
questions
on
connect2dp.
Before
we
move
on
to
the
next
presentation.
B
G
C
G
Slides
all
right,
thank
you
hi,
my
name
is
alex
schranhofsky.
I've
worked
with
dallas
and
david
snazzy
on
these
slides
dallas,
unfortunately
was
unable
to
present
today,
so
I
am
taking
over
for
him
next
slide,
please
so
we're
going
to
first
start
off
by
talking
about
some
of
the
unchanged
requirements.
From
the
last
time
we
talked
about
mask
ip
proxime,
so
I'm
going
to
go
a
little
bit
fast
over
some
of
these
things,
because
there
are
unchanged
exact,
same
slides
that
we
had
last
time.
It's
mostly
a
recap.
G
So
there's
three
general
use
cases
we're
going
to
go
into
detail
of
all
three
of
them
with
some
work
examples
after
some
clarifications
later
on.
So
our
first
sort
of
use
case
is
point
to
point.
We
want
to
create
a
tunnel
between
two
endpoints.
This
could
be
used
for
something
like
you
know.
You
have
container
networking
and
you
want
your
container
pod
to
be
able
to
talk
to
another
one
on
the
same
machine
with
different
addresses
or
possibly
on
a
different
machine
with
the
same
addresses.
G
Then
we
have
the
point
to
network
use
case.
This
looks
more
like
a
traditional
vpn
sort
of
if
you
were
to
go
and
buy
a
vpn
from
one
of
the
commercial
providers
in
order
to
get
a
different
ip
address
either,
because
you
want
to
access
the
network
from
a
different
geographical
region
or
privacy
or
some
other
concern,
but
you're
currently
using
something
like
ipsec
or
dtls
in
order
to
get
there.
G
This
is
also
frequently
used
by
enterprise
networks
in
order
to
get
access
to
their
internal
things,
which
are
not
generally
exposed
to
the
public
internet,
and
the
last
use
case
that
we're
sort
of
interested
in
is
the
network
to
network
use
case,
which
is
also
called
a
site-to-site
vpn
a
lot
of
times.
Enterprises
or
small
businesses
will
use
this
in
order
to
connect
all
other
different
branch
offices
together,
for
example.
G
This
is
also
kind
of
interesting
when
you
have
devices
that
themselves
cannot
run
vpn
clients
that
you
want
to
connect
to
avpn
next
slide,
please
so
again,
sort
of
unchanged
here
we're
gonna.
First
go
over
the
security
requirements.
We
want
whatever
we
do
here
to
have
transport
security,
so
we
think
that
this
should
only
run
over
something
like
quicker
tls,
because
that
provides
mutual
authentication
confidentiality
integrity.
Sort
of
the
next
thing
that
we
also
want
is
that
this
traffic
should
be
indistinguishable
from
regular
https
web
traffic.
G
G
Authentication.
We
want
to
have
some
mechanism
for
a
client
to
authenticate
to
the
server
to
establish
its
sessions.
We
don't
want
to
specify
yet
what
that
should
be,
but
it
could
be
something
like
an
oauth
token
or
some
vendor
specific
implementation
and,
lastly,
identity.
The
endpoints
that
are
involved
here
need
to
be
able
to
have
some
sort
of
cryptographically
authenticated
identifier
to
determine
the
identity
of
their
peer.
This
sort
of
ties
back
into
the
earlier
authentication
requirement
and
can
basically
be
like
oh
cool.
G
G
M
A
I
Back
yeah,
so
I
think
go
back.
I
So
so
I
think
I
think
we're
sort
of
bike
shedding,
but
I
think,
but
it
may
be
relevant,
so
it
seems
to
me
that
there
are
three,
it
seems
to
me.
It
seems
to
me
that
there's
sort
of
a
how
do
I
phrase
this
so
so
conventionally
the
way
so
so
maybe
I'll
start
brought
back
into
it.
So
conventionally,
the
way
this
would
work
would
be.
You
know
if
this
were
like
connect.
I
Tcp
is
that
over
over
h2
is
that
you
would
have
a
you
run
over
tls.
So
you
have
you.
Have
this
first
point
you
make?
Then
you
have
the
the
the
server
authenticate
cryptographically
authenticated
at
the
tls
layer
and
bound
into
the
m
and
bounded
in
the
transfer
protocol,
and
it's
a
client
cryptographically
authenticated.
I
If
you
want
to
call
it
cryptographic
at
the
at
the
at
the
application
layer,
and
in
fact
I
mean
it's,
not
necessarily
even
cryptographic
right
I
mean
like
you
know
it
could
be
using
my
password
right,
and
so
I
guess
I
think
that
I
I
I
so
the
point
being.
I
I
have
trouble
with
sometimes
heartburn
with
this
like
last
point
of
identity,
in
the
sense
that
I
think
that
it's
clear
that
the
the
the
server
has
to
be
cryptography
authenticated
and
that
has
to
be
tied
into
transport,
but
it's
not
clear
to
the
client's
trafficking
that
it
authenticated
in
a
meaningful
way.
That's
that's!
There
are
some
applications
about
there
somewhere.
It's
not.
G
Yeah,
I
think
this
is
mostly
a
matter
of
wording
and
I
certainly
would
be
interested
in
a
suggestion
here.
I
don't
mean
to
imply
that
something
like
username
or
password
would
be
unacceptable
for
the
client.
Okay.
I
G
All
right,
thank
you.
So,
moving
on
to
sort
of
session
requirements,
we
want
the
client
to
be
able
to
establish
an
ip
session
along
with
configuration
options.
They
may
have
sort
of
one
thing
that
we've
sort
of
been
assuming
here
is
that
it
is
valuable
for
a
server
to
be
able
to
accept
or
deny
the
client's
request
this
discretion.
So,
for
example,
the
client
wanted
to
talk
to
some
ip
destination
that
we
didn't
want
to
permit
by
policy.
The
the
server
is
not
obligated
to
forward
traffic
there.
G
One
also
additional
requirement
is
we'd
like
to
proxy
ip
packets.
I
think
this
is
probably
self-evident
in
something
called
requirements
for
iproxying,
so,
whatever
mechanism
that
we
use
for
the
underlying
data
transports,
which
either
should
be
something
like
quick
data,
grams
or
stream
frames,
we
should
be
able
to
take
the
ip
packets
unmodified
in
their
entirety,
and
we
want
to
support
both
ipv4
and
ipv6
and
also
any
future
ip
versions
should
they
exist.
G
We
also
believe
it
is
important
to
multiplex
different
ip
sessions
over
the
single
http
connection,
sort
of
going
to
some
of
the
discussion
that
we
had
at
davidskenazi's
earlier
point
around
flow
ids.
I
want
to
quickly
clarify
for,
as
a
result
of
that,
I
don't
necessarily
believe
that
we
need
to
multiplex
over
different
flow
ids
or
the
same
flow
id.
I
don't
want
to
specify
that
here,
but
I
do
think
that
at
least
based
on
what
we
seem
to
be
heading
to
in
the
connect
udp
draft.
G
That
seems
like
we're
going
to
already
have
this
capability.
And
lastly,
one
sort
of
important
thing
here
on
session
requirements
is
that
we
want
to
be
able
to
support
both
h2
and
h3.
G
Clearly,
we
do
believe
that
there
is
a
strong
preference
for
using
h3
where
we
do
have
the
datagram
frames,
but
we
do
think
that
h2
cases
for
fallback
would
be
useful
in
places
where
udp
is
unavailable
sort
of
using
an
example
from
industry.
I
know
that
I
believe
cisco's
vpn
product
uses
dtls
and
then
falls
back
to
tcp
over
tls
sorry
tls
over
tcp.
In
the
event
that
the
network
blocks
gdp-
and
we
think
that
is
a
useful
thing
to
continue
to
make
available
miriam.
H
Yeah
actually
on
the
proxy
and
ip
packets.
You
said
this
very
obvious,
because
that's
what
you
want,
however,
the
way
you
phrased
it
here.
It's
not
completely
obvious
because
you
say
in
an
unified
entirely
so
that
rules
out
any
kind
of
ip
header
compression
or
anything
like
that,
and
I
think
that
needs
more
discussion.
G
I
I
do
not
think
it
is
appropriate
for
a
mask
server
to
be
performing
any
sort
of
compression.
I
think
it
for
the
connect
ip
case.
We
really
should
be
moving
the
packets
along
entirely,
and
I
think
that
if
you
want
to
go
and
introduce
any
sort
of
thing
which
is
going
to
apply
transformations
to
the
ip
packets,
it
should
be
raised
as
an
extension.
G
H
G
C
B
And
what
in
terms
of
design
principles-
and
I
kind
of
like
touched
on
this
and
connect
udp
a
little
bit-
I
I
think
as
a
working
group,
and
maybe
we
can
have
that
discussion
at
some
point.
It
might
be
worth
it
to
try
to
in
my
so.
My
opinion
here
is
that
we
should
have
both
connect
ip
and
whatever
proxy
becomes
be
really
minimum
viable
products
like
as
dirt,
simple
as
possible
and
but
extensible.
So
all
sorts
of
cool
features.
So
trust
me.
B
I've
implemented
ip
compression
for
a
proxy
before
and
it
makes
huge
performance
wins,
but
it's
never
a
requirement
of
the
core
thing
and
actually
having
these
kinds
of
things,
as
extensions
is
much
better
because,
like
take,
I
I
built
in
compression
to
the
first
thing
and
it
turns
out
that
it
we
came
up
with
a
better
compression
scheme,
and
that
was
a
nightmare
if
you
built
it
as
an
as
an
extension
to
the
first
mechanism,
you
can
replace
it
with
another
extension,
which
is
often
a
better
way
to.
B
H
So
I
guess
I
can
reply
right
so
with
compression
like
what
I
have
in
mind
is
really
just
not
sending
the
ap
header,
I'm
not
talking
about
certain
compression
scheme,
and
if
you
don't
send
the
ip
header,
you
need
some
kind
of
additional
signaling,
but
all
the
signaling
is
completely
identical
to
connect
udp,
because
there
you
don't
have
an
ip
header.
Neither
so
you
need
the
same
kind
of
signaling
mostly,
and
you
and
the
benefit
you
get
is
just
like
reducing
overhead.
H
I
think
it's
super
simple,
because
we
already
have
connect
udp.
If
we
wouldn't
have
it,
then
it
wouldn't
be
simple,
but
as
we
have
it
already
and
you
can
assume
the
proxy
has
implemented
already.
It's
simple
to
reuse
that
and
especially
if
you
think
about
the
kind
of
vpn
use
case
that
like
reduces
actually
complexity
and
makes
it
much
more
simple.
I
understand
that
it's
that,
like
for
the
network
to
network
case
it
kind
of
makes
it
more
complicated,
but
for
the
for
the
vpn
case,
it's
much
more
simple.
G
I
I
just
want
to
say
that
I
disagree
with
most
of
that.
I
think
that
if
you
go
and
do
something
like
removing
the
entire
ip
header,
you're,
basically
tying
yourself
down
to
a
single
connection,
and
you
basically
only
can
handle
something
like
point
to
point
or
point
to
network
and
as
a
result,
I
think
you're
in
the
interest
of
being
generic
and
we're
actually
going
to
go
through
this
later
in
the
slides
of
the
work
examples
with
the
requirements
as
we're
currently
stating
them
here.
G
We're
stating
that
we
have
the
ability
to
do
so.
We're
not
saying
that
it
is
exclusive.
Like
we're
we're
saying
that
you
have
to
be
able
to
forward
ip
packets,
like
whatever
implementation
would
you
needs
to
have.
This
capability
is
not
saying
that
it
exclusively
only
must
do
ip
frames.
We
can
go
and
introduce
extensions
as
you
propose
in
order
to
have
the
exact
same
semantics
as
with
connect
udp
and
not
have
to
go
and
relay
that
redundant
data.
G
H
G
H
Because,
if
you,
if
you're,
not
if
you
not
connect
two
private
networks
to
each
other,
then
making
sure
that
you
handle
the
ip
addresses
correctly.
If
you,
if
you
connect
like
to
an
open
network,
making
sure
you
handle
that
you
just
connectly,
gets
the
complexity
in
and
by
just
letting
the
proxy
handle
that
you
can
avoid
like
these
kind
of
things.
And
if
you
have
the
proxy
handling
the
ip
address.
There's
actually
not
much
more
to
do
for
the
proxy
to
create
an.
C
Some
more
discussion
on
this,
and
if
we
don't
already
have
a
github
issue,
can
can
we
have
one,
but
as
we
do
that,
can
we
try
to
make
sure
that
we're
framing
the
need
for
a
requirement
this
way
or
the
other,
with
the
use
case
that
it's
supporting
rather
than
the
solution
that
we
think
it's
going
to
enable.
G
I
I
guess
I'll
try
and
make
it
quick,
I
think,
going
back
to
requirements
right.
We.
I
think
that
the
key
requirement
question
seems
to
me
is:
do
we
need
to
support?
I
guess
what
you're
calling
site
to
say
vpn
and
if
we
do,
then
you
clearly
have
to
like
put
the
ip
header
like
in
the
thing
or
it's
not
gonna
work.
So
I
think
that
so
I
think
I
think
my
understanding
was
that,
like
there
was,
there
was
some
agreement
that
we
had.
I
We
have
support
scientific
vpn
and
if
people
don't
think
that,
then
we
should
like
they
would
like
to
make
that
point,
and
then
I
think
the
question
then
becomes
is:
is
there
a
requirement
to
have
a
is
requirements
not
desirable
to
have
a
a
more
compact
compressed
mode
for
when
you,
when
you're
doing
like
these?
I
You
know
these
like
the
like
a
more
or
more
standard
like
user
facing
vpn,
where
you
know
we
we're
just
like
trying
to
like
conceal
like
what
they're
watching
your
location
doctor
who,
when
you
ask
for
the
pc
to
watch
doctor
who
right-
and
I
guess
one
thing-
I
one
thing
I
would
say-
and
I
think
I
said
some
pre
and
add
meetings
is
one
thing,
because
I
don't
like
requirements
documents
it's
like
people
that
want
to
negotiate
the
entire
protocol
requirements
document
so,
like
I
think,
like
the
question
of
the
second
question,
is
something
we
can
make
we
can
face
down
later.
I
You
know,
I
think
the
core
question
is
like
is
like,
unless,
unless
somebody
thinks
we
should
only
have
a
mode
in
which
the
ip
header
is
not
carried
in
not
carried,
and
it
then
re
reconstructed
the
other
side,
then
I
think
we
clearly
need
the
mode
that
is
in
in
this
in
this
project.
This
is
this
in
this
document
and
we
can
discuss
whether
we
need
a
more
compressed
mode
later.
F
Comment
on
this,
while
you
know,
I
definitely
agree
that
we
need
to
support
full
ip
packets
in
here.
I
I
think
we
need
to
be
careful
to
ensure
that
we
do
not
have
the
requirements
document
limited
to
saying
it
will
only
do
that.
Like
I
know,
you're
expressing
like
yes,
we
you
don't
want
to
have
the
ip
header
compression.
F
I
think
that
needs
to
be
allowable
in
the
protocol,
that
not
all
deployments
will
do
it,
but
we
need
to
leave
it
extensible,
and
so
I
think
the
extensibility
needs
to
be
a
requirement.
I.
F
G
A
few
other
things
here,
reliable
transmission.
We
do
believe
that
in
general,
these
things
are
going
to
be
going
over
datagram
frames
and
will
be
unreliable.
Although
there
are
some
cases
we
have
seen
where
it
may
be
desirable
to
go
and
ask
for
certain
packets
to
be
sent
reliably
in
order
to
help
optimize
session
establishment
for
flow
control.
We
would
like
these
connections
to
not
be
subject
to
flow
control
so
that
we
are
allowing
the
n10
principle
to
take
place
for
the
underlying
tcp
session
and
finally
load
balancing.
G
P
G
That's
certainly
one
thing
that
I
would
be
interested
in
in
exploring
I've
also
seen
some
suggestions
that
implementations
that
want
to
process
individual
streams
or
potentially
datagram
flow
ids
on
different
cores,
because
the
crypto
is
officially
separated
out.
So
I
think
both
of
them
would
be
worthwhile
to
be
able
to
at
least
not
preclude.
P
G
G
I
do
not
want
to
specify
in
this
document,
because
I
think
that
there
is
enough
other
prior
art
and
other
rfc
specifying
what
to
do
with
flows
as
to
how
to
map
individual
flows
onto
individual
datagram
flow,
ids
or
or
quick
streams.
Or
what
have
you?
I
think
that
is,
I
think,
outside
the
scope
of
mask.
I
am
merely
saying
that
I
think
it
is
important
that
for
ip
proxying
we
have
the
ability
to
have
multiple,
possibly
independent
flows
in
the,
in
the
mask
sense
that
those
active
flows
can
be
mapped
onto.
P
I
okay,
I
think
that
sounds
I
mean
this
is
part
of
the
solution,
space
so
etc.
For
that
resolving
that,
but
I
think
you
need
to
have
clear
indicators
of
that
there's
excess
solutions
that
can
make
this
working
and
pointing
to
some
of
these
but
yeah
it's
for
the
solution,
but
I
think
they're,
just
kind
of
disgusting.
I
think
wonder
about
the
complexity
of
solving
these.
G
All
right
I
mean
I'm
trying
to
go
and
add
some
text
saying
that
that
is
out
of
scope,
and
there
are
other
things
that
sort
of
dictate
how
to
use
those
things
but,
like
I
think
in
general,
that's
sort
of
one
thing
which
makes
this
sort
of
requirements
document
hard
is
that
while
there
are
use
cases-
and
we
are
talking
about
some
of
these
things-
they're
we're
talking
about
capabilities
here-
we're
basically
talking
about
things
that
we
want
the
protocol
to
allow
we're
not
specifying
things
that
implementations
must
do
and
we're
not
necessarily
even
saying
that
we
will
do
all
these
things.
G
We're
talking
about
guidelines
for
how
we
want
to
make
sure
we
make
things
at
least
possible,
and
when
you
bring
up
concerns
like
this,
like
I,
I
don't
want
to
minimize
them
in
any
way.
They're
very
valid,
but
they're
they're,
much
more
implementation
oriented
and
have
like
real
world
concerns
than
I
think
is
appropriate
for
a
requirements
document
empty.
M
You
think
that
makes
absolutely
no
sense
to
me
if
we're
sending
ip
diagrams.
I
imagine
there's
an
expectation
that
you'd
want
them
to
be
in
datagram
frames.
Why
would
we
even
consider
streams
and
why
would
streams
be
the
unit
at
which
you
can
divide
things
between
cpu
cores
or
whatever?
It
is.
This
seems
nonsensical.
G
To
me,
so
I
think
this
is
again
a
terminology
problem,
so
one
of
the
things
that
we
did
in
the
draft
is
we
use
the
terminology,
data
transport
to
refer
to
either
the
h2
or
h3
stream
or
the
datagram
flow
id
tuple
thing
and
that
a
particular
set
of
ip
frames
can
be
mapped
onto
so
basically,
the
reason
we
chose
the
word
stream
here
is
probably
an
editing
error,
because
we
also
wanted
to
support
doing
iproxy
over
h2
and.
M
I'm
not
I'm,
I'm
still
not
saying
how
this
is
relevant,
so
I
can
imagine
having
a
requirement
that
you
be
able
to
create
multiple
connections
so
that
you
can
access
the
same
network
with
multiple
like
with
the
same
ip
address
from
multiple
proxies.
But
that's
all
like
that.
This
seems
a
little
too
much
for
me.
G
I
I
do
not
think
that
this
is
about
multiple
connections.
I
I
am
very
much
talking
about
within
the
individual,
h2
or
h3
connection.
We
did
see
in
our
own
implementation
a
difference
when
the
multiple
streams
were
in
use
with
google,
quick
and,
as
a
result,
we
do
believe
that
this
is
an
important
capability.
M
G
M
G
N
Thanks
alex,
I
wanted
to
echo
martin's
comment,
but
but
perhaps
slightly
differently.
You
were
making
the
case
earlier,
and
I
was
100
in
agreement
that
you
want
to
build
something
as
minimal
as
possible
in
terms
of
ip
forwarding
and
in
terms
of
being
an
ip
level
vpn,
and
to
that
extent
I
think
this
might
again
fit
in
that
space
of
an
extension.
N
I
don't
think
that
you
want
to
forgo
any
performance
benefits
that
you
get
for
doing
this
potentially,
although
it
does
seem
weird
I'll
agree
with
that
that
this
I'm
also
curious
to
understand
where
this
exactly
yields
performance
benefits.
N
But
that
said,
if
it's
an
extension,
if
it's
something
that
you
can
implement,
if
you
care
to,
then
it's
valuable
to
have
as
a
as
a
side
thing,
but
I
wouldn't
make
it
part
of
the
core
requirements.
C
Just
wanted
to
chime
in
a
little
bit
in
to
the
comment
that
you
made
alex
about
it's
kind
of
weird
doing
a
requirements
talk
like
this,
because
I
think
it
is
and
and
that's
something
that
we
should
kind
of,
acknowledge
and
meet
up
front
as
we
we
built
in
this
ordering
structure
to
how
we
wanted
to
to
approach
this
work
as
a
group
and
what
I
think
we're
trying
to
accomplish
with
the
requirements
and
definition
of
use
cases
is
very
much
not.
Let's
describe
the
solution
that
we
think
we're
going
to
implement
in
the
protocol.
C
Details
of
how
we're
doing
it
and
and
you've
you've
agreed
with
that,
so
that
this
isn't
a
disagreement
there.
But
I
think
the
our
main
task
right
now
is
to
find
the
minimal
set
of
things
where,
whatever
solution
we
end
up,
picking
and
achieving
consensus
on
as
a
working
group
is
something
that,
if
it
did
these
things,
we
would
be
happy
and
by
happy
I'm
defining
that.
C
As
you
know,
I
would
have
something
that
I
could
use
for
my
use
case
to
deploy,
and
so
I
think
really,
the
the
conversation
that
we're
trying
to
have
is
what
are
the
use
cases
that
we
believe
we
need
to
support
and
what
do
those?
What
requirements
do
those
place
on
our
solution?
C
Not
what
are
the
requirements
that
describe
a
current
solution
of
of
any
form?
And
that's
that's,
that's.
I
think
something
that
you're
walking
a
very
fine
line
of
of
of
doing,
and
thank
you
for
for
endeavoring
to
do
that,
because
that's
not
an
easy
thing
to
do
so.
So,
just
as
we're
having
the
conversation
around
this,
the
more
we
can
keep
it
grounded
in
the
use
case,
I
think
the
the
happier
we
will
be,
but
that's
that
is
always
a
hard
thing,
especially
when
there
are
a
couple
of
different.
G
Yeah
and-
and
I
definitely
recognize
and
appreciate
that-
and
I
think
the
feedback
that
we
received
here,
but
this
load
balancing
requirement
is
better
emitted
or
included
as
an
extension
is
a
good
and
useful
one,
because
it
is
the
one
which
I
think
is
probably
least
grounded
in
a
particular
use
case
that
we
will
describe
next
slide.
Please
things
out
of
scope.
This
is
just
recap:
we're
not
going
to
talk
about
how
you
assign
ip
packets
or
sorry
addresses
to
your
ips.
G
We
simply
say
that
there
is
some
mechanism,
because
I
don't
think
the
protocol
itself
needs
to
be
concerned
with
it,
we're
not
going
to
include
any
sort
of
network,
address,
translation
or
modification
of
packets
that
they're
forwarded
in
scope
here
in
this
particular
thing.
I
think
there's
enough
prior
art
on
how
to
do
that.
G
G
H
Yeah,
I
think
we
cannot
avoid
to
totally
talk
about
address
translation
and
there
is
a
use
case.
We
actually
want
where
the
client
wants
a
proxy
to
hide
its
appear
address
from
the
server,
and
in
that
case
I
mean
doing
the
trans
address.
Translation
is,
is
not
that
complicated,
but
you
need
to
talk
about
how.
G
G
What
we
are
saying
is
out
of
scope
is
the
mechanism
by
which
ip
addresses
are
selected
from
the.
What
we're
saying
is
some
other
component
will
tell
the
system.
This
is
the
ip
to
use.
We
are
not
going
to
go
and
talk
about
policy
that
that
is
out
of
scope
for
the
protocol.
That
is
all
I'm
saying,
so
I
agree
that
the
use
case
that
you
want
to
solve
is
important.
I
am
saying,
but
I
don't
think
it
requires
any
mass
protocol
changes.
H
So
I
think.
D
H
It
would
be
the
proxy
that
has
a
certain
range
of
ip
addresses
that
you
can
use
and
giving
guidance.
How
to
use
these
ip
addresses
is
also
something
important.
I
think
like
it's,
it's
just
like
too
tightly
phrased
in
the
draft.
G
H
Yeah
I
mean
like
you
need,
I
think
you
need
some
signaling
to
actually
give
the
give,
for
example,
the
client
some
information
about
what
the
out-facing
ip
address
is
so
at
least
that
there
is
a
different
one,
that
this
is
applied
and
so
on.
So
I
think
maybe
we
also
want
to
add
a
requirement
somewhere
that
this
is
supported.
G
B
David
quick
point
because
I
think
I'm
detecting
a
misunderstanding
between
folks
here
so
think
of
this.
So
the
way
like
we've
been
thinking
as
the
authors
of
the
document
here
is
all
right:
how
do
we
just
proxy
ip
packets
so
conceptually
like?
How
do
we
do
the
esp
part
of
ipsec
just
the?
What
is
the
wire
format
that
you
take
these
packets
and
you
shove
them
there
and,
and
maybe
a
little
bit
of
the
ike
part
which
is
okay?
B
How
do
you
get
addresses
and
routes
communicated
to
the
you
know,
control
channel,
so
nat
is
something
for.
Like
the
vpn
use
case,
you
will
absolutely
need,
but
if
you
look
at
the
all
the
ipsec
documents,
none
of
them
mention
nat.
Part
of
that
is
that
people
pretended
nat
didn't
exist
at
the
time,
but
conceptually
that
doesn't
need
to
be
in
those
documents.
B
You
just
need
a
way
to
say:
okay,
we're
gonna.
These
are
the
ips
that
we
have.
These
are
what
we're
gonna
send.
What
we're
saying
is
out
of
scope.
Is
the
oh,
how
you
pick
your
one
ip
like
or
you
know,
if
you're
gonna
do
a
nat?
What
kind
of
nat
are
you
going
to
use?
Those
are
things
that
are
kind
of
going
to
be
on
the
same
box
as
your
mask
server,
but
they
don't
need
to
be
in
this
specific
document.
H
Can
it
quickly
reply?
So,
as
I
said,
I
think
this
is
too
generally
placed
so
more
words
might
help
you,
but
I
think
there's
also
the
case
where
actually
kind
of
the
client
wants
to
influence
influence
like
how
certain
api
dresses
are
picked.
For
example,
if
the
client
wants
to
have
a
stable
ip
address
or
something
so
this
is
really
too
broadly
phrased
here.
I.
H
I
G
All
right
so
next
slide,
please
so
one
of
the
things
that
we've
got
feedback
on
from
sorry,
the
previous
slide,
one
of
the
things
that
we
got
feedback
on
that
we
sort
of
realized
was
a
terminology
issue.
From
last
time,
when
we
were
talking
about
ip
assignments
and
what
previously
was
called
a
a
ip
route,
we
have
recognized
that
those
words
have
implications
that
we
did
not
want
to
convey.
G
So
we
have
optimistically
chosen
to
instead
call
these
reachable
destinations
so
a
reachable
destination
here
is
the
client
or
the
server
going
and
saying
hey.
I
can
make
these
following
ip
addresses,
reachable
to
you
over
this
capability.
So
why
don't
we
go
through
the
next
slide?
Example:
real,
quick,
which
I
think
will
be
of
interest
to
miriam,
because
it
is
sort
of
the
point
to
network
sort
of
classic
vpn
example.
G
G
So
if
the
client
were
to
go
and
use
any
other
address,
the
server
can
and
probably
should
go
and
drop
it,
because
that's
not
an
address
that
it
offered
to
forward
packets
on
behalf
and
also
what
the
client
also
needs
to
know
is
what's
reachable
using
that
address.
So
the
server
also
says
you
can
reach
anything
in
2001,
db8
32.,
so
not
only
if
the
if
the
client
uses
a
source
address
which
is
not
one
which
it
received,
but
also
if
it
tries
to
send
to
a
destination
address.
O
O
H
Yes,
so
I
see
why
you
want
to
provide
reachable
addresses
in
the
network
to
network
case,
but
I'm
not
sure
why
you
need
it.
In
the
point
of
network
case
where
the.
G
Network
is
the
open
internet.
Okay
in
the
port
network
case,
think
of
a
office
vpn
where
you
want
to
provide
a
reachable
destination,
which
is
the
internal
addresses
of
the
office.
But
you
don't
want
to
proxy
the
client's
entire
internet,
yeah.
H
Okay,
but
so
like
in
my
case,
it
would
be,
it
would
be,
reaching
the
open
internet
over
the
proxy
right.
So
the
network
is
the
opening.
G
Well,
we
think
it
is
valuable
for
the
protocol
to
be
able
to
pass
it
right,
because
if
the
client
might
be
something
stateless
or
the
server
might
have
a
different
network
configuration
depending
on
like
if
they
got
geographically
load
balanced
differently
so
like,
while
I
agree
that
it
could
be
done
out
of
band,
I
think
there
is
value
in
letting
a
server
additionally
provide
that
information
so
that
you
can
have
simpler
clients
or
you
could
have,
as
you
mentioned,
thicker
clients
which
have
the
information
out
of
that.
But
again,
this
is
a
capability
right.
G
G
Yes,
I
I
think
we
do
and
I
think
what
I'm,
what
I'm
explicitly
saying
is.
I
think
that
ip
addressing
information
generally
should
be
going
over,
that
signaling
yeah.
C
G
We
only
have
two
more
slides
next
slide,
please.
So
the
thing
that
we
wanted
to
say
next
here
is
a
point-to-point,
just
sort
of
a
degenerate
case
of
pointing
network
where,
rather
than
trying
to
access
a
large
range,
we're
just
trying
to
access
an
individual
range.
G
G
P
Thank
you
yes,
so
I
guess
this
is
I
I
think
this
is
much
clearer
when
it
was
before
about
really
reachable
et
cetera.
So
to
avoid
those
savvy,
I
mean
suicidal
validation
requirements
and
even
routing
would
be
saying
that
as
long
as
you're
the
math
service,
a
good
citizen,
only
offers
what's
in
that
local
routable,
it
knows
routable
domain
ad,
it's
it's!
G
Again,
I
I
I
recognize
what
you
are
saying,
but
this
is,
I
think,
out
of
scope.
This
is
merely
talking
about
the
protocol
being
able
to
support
this
thing.
Someone
may
wish
to
go
and
implement
reachability
as
you
described,
by
going
and
doing
a
route
injection
and
needing
to
go
and
do
such
validation
or
they
could
go
and
be
ranges
that
the
endpoint
that
the
like
same
entity
owns
and
already
has
like
some
sort
of
apples
involved
here.
These
are
concerns
which
I
think
are
better
handled
by
standards
and
systems
that
already
exist.
P
Yes,
the
requirement
is
a
single
mechanism
and
then
the
security
implications
of
this
mechanism,
in
the
general
case
is
in.
If
for
the
need,
that's
I
think
is
the
problem
I
see
is
that
you
actually
for
secure
deployment
using
this
mechanism,
you
either
tighten
the
scope
to
a
particular
use
case
or
a
particular
usage,
or
you
have
to
implement
additional
mechanisms.
P
G
I
don't
think
that
follows
because
the
server
is
not
obligated
to
go
and
forward
any
packets
for
a
reachable
destination.
As
for
the
point
we
mentioned
in
the
requirement,
this
is
merely
an
advertisement
of
what
can
be
reached.
It
is
not
an
obligation,
so
if
you
go
in
first
of
all,
you
don't
have
to
implement
this
capability
and,
second
of
all,
if
you
do
implement
this
capability
and
the
client
asks
for
something
which
is
the
violation
of
your
policies,
then
you
are
not
obligated
to
forward
the
packet.
P
Yeah,
but
I
mean
that
tunnel
also
need
to
at
least
con,
has
those
considerations,
so
I
think
it's.
I
think
it
comes
down
to
pointers
later
on
in
the
security
considerations
and
things
like
that
with
the
actual
employments
and
because
you're
integrating
several
mechanisms
into
one
here.
I
think
that's
gonna
apply
later
on
when
we
come
to
the
solutions.
G
I
really
think
that
we're
having
a
communication
issue
here,
because
we
are
not
mandating
that
anyone
implement
this.
This
is
talking
about
the
protocol
being
able
to
describe
something
it
may
translate
into
the
implementation
as
you
describe,
but
no
one
is
obligated
to
implement
those
capabilities.
There
are
still
additional
authentication
authorization
requirements
here
and
there
is
also
entire
art.
I'm
not
entirely
sure
how
I
can
better
message
this
so.
A
P
A
I
think
we
need
to
cut
it.
We
are
extremely
short
on
time
now
and
there's
still
one
more
person
in
the
queue.
What
could
I
ask
you
to
take
this
to
an
issue
on
the
requirements
draft
to
discuss
it?
There.
I
And
then
I'm
sorry,
but
can
you
go
back
two
slides
to
slide
ten,
that
the
point
two
point,
the
network,
one.
I
So
I
I
apologize
for
not
raising
this
earlier,
because
I
think
I
just
got
a
little
lost,
I'm
kind
of
tired.
So
in
your
scenario,
so
so
I
I
I'm
trying
to
this
first
bullet
point.
I
These
addresses
are
internal
the
tunnel
right
so
like
in
this
classic
use
case
where
I
like,
where
I
want
we're,
like
you
know,
I'm
like
I'm
like
in
the
us
and
I
want,
but
I
want
to
appear
to
be
in
the
uk
right,
so
the
I'm
going
to
admit
packets
with
I
want
packers
to
come
out
the
other
door
at
the
door.
The
other
end
with
the
uk,
the
uk
address
and
but
locally.
I
Of
course
I
have
a
us
ip
address
and
I'd
thought
when
you
first
said
this,
that
the
server
was
going
to
tell
me
hey
when
you
transmit
using
the
ukip
address
and
I'll
just
leave
it.
But
when
I
see
internal
I
don't
believe
that
anymore.
So
I'm.
G
A
little
confused,
yeah
sorry,
I
think
this
was
an
edit
that
was
introduced
later
into
the
slides.
That
is
a
little
bit
unclear
in
this
worked
example.
The
addresses
here
are
internal
to
the
tunnel
in
that
we're
not
talking
about
the
outer
address
of
the
quicker
http
3
connection,
we're
not
saying
that
this
is
a
private
space,
ip
address.
G
So
in
your
example,
if
you,
if
we
were
to
give
out
to
over
the
the
mass
connection,
a
public
uk
ip
address,
that
is
what
would
be
here,
so
your
outer
packet
would
be
your
usfp
address,
talking
to
the
mask
server
and
then
inside
of
it
you
would
be
using
the
publicly
reachable
ukip
address.
I
G
Yeah,
so
there
is
a
small
gray
box
here
of
saying
out
of
scope
policy
and
that
one
could
go
and
choose
to
do
ip
address
translation
through
nat.
If
they
wanted
to
sure
it
is
not
a
requirement
that
we
think
is
is
presented
on
top
of
the
mass
protocol.
I
Okay,
great,
I
I
mean,
and
I
and
if
the
chair
should
feel
for
the
time
I've
been
getting
too
far
into
engineering,
but
but
some
many
vpns
allow
you
to
actually
attempt
to
select
the
address
rate.
The
address
agrees
address
range
in
some
way.
Do
we
think
that
that
do
we
do
do
we
think
that
has
to
be
supported,
and
if
so,
does
it
have
to
be
specified
here?
I
It's
like
you,
you
say:
look
I
want
to
watch
soccer,
so
I
need
to
be
in
in
spain
right.
I
don't
think
I
I
don't
think
we
have
to
like
specify
technology
for
that,
but
I
wonder,
does
that
have
to
be
it
would
have
to
be
at
this
level
if
you
wanted
to
make
that
assertion.
So
I
just
don't
know
where
this,
where
this
fits
in
our
in
our
our
life.
G
Yeah,
I
think,
that's
interesting.
I
was
personally
sort
of
imagining
that
that
selection
would
be
happening
outside
of
this
by
the
choice
of
the
mask
server
you
choose
to
connect
to,
but
I
could
totally
see
an
extension
adding
that
additional
information
to
the
signaling
mechanism
thanks-
and
I
turn
it
over
to
the
chairs.
C
J
Traffic
selector
negotiation
in
a
very
similar
way,
and
I
just
suggest
to
look
at
our
experience
and
actually
the
client
as
initiator
in
getting
equity,
not
only
may
ask
for
an
internal
address.
It
can
only
suggest
its
view
of
the
policy
on
which
ap
addresses
want
to
to
go
to.
So
this
it's
kind
of
negotiation,
not
just
several
signs
type
arrangement,
is
allowed
to
go.
So
I
just
suggest
to
look
at
our
experience
at
our
work
in
ipc
can
be
working
group
because
it
is
very
similar.
C
All
right,
thank
you,
and
with
that
we
have
a
solid
six
minutes
left
tommy.
Your
next
we've
been
chatting
about
the
potential
of
scheduling,
an
interim
to
try
to
get
some
of
the,
as
is
all
the
rage
these
days
to
try
to
get
some
more
face-to-face
ish
discussion
on
both
of
these
issues,
and
I
think
both
of
our
remaining
agenda
items
would
fit
very
well
at
one
of
those.
So
tommy
you're
welcome
to
fill
five
minutes
or
if
you
want
to
wait
for
that,
we
can
have
mirror
to
fill
five
minutes.
F
Right
so
I
I
certainly
do
not
want
to
get
into
any
other
presentations.
I
think
it
interim
would
be
a
good
idea,
but
since
I
was
next
up,
I
will
take
advantage
of
a
little
bit
of
time.
If
you
don't
mind
to
kind
of
make
a
broad
meta
comment
that
I
think
overall,
it
would
be
good
for
us
as
a
working
group,
to
define
our
stance
and
our
plan
for
extensions,
because
it
seems
very
clear
that
we
have.
F
You
know
these
core
items
of
connect,
udp
and
ip
tunneling,
and
I
very
very
much
agree
with
the
notion
that
you
know
we
should
keep
them
keep
focused
on
them.
We
should
have
them
be
minimum
viable
products,
but
in
you
know
the
conversations
for
both
connected
udp
and
ip
tunneling.
F
The
plan
for
you
know
kind
of
publicly
saying
we
plan
to
be
able
to
support
extensions.
When
are
we
going
to
do
that
work?
What
kind
of
what
are
we
going
to
delay
on
and
make
sure
that
it
informs
the
work
that
we
are
doing
in
connect
udp
when
we're
deciding
things
like
the
flow
id,
etc?
To
make
sure
that
we
are
thinking
about
that,
and
we
know
what
our
plan
is
also.
I
would
like
to
just
bring
up
for
this
group.
F
If
anyone
wasn't
at
int
area,
there
was
a
kind
of
a
large
confusion
in
which
there's
a
whole
quick,
proxying
work
that
was
brought
up
there,
that
really
really
overlapped
with
mask,
and
I
think
there
was
a
sense
there.
I
I
don't
know
how
exactly
the
sense
came
about,
but
a
sense
that
oh
mask
is
really
focused
on
some
tight
use
cases
and
can't
be
used
for
this
particular
use
of
proxing
and
therefore
they
need
to
go,
do
it
in
interior
or
do
it
somewhere
else
and
looking
at
it.
F
It
seems
extremely
similar
to
what
we
are
talking
about
right
here
with
the
ip
requirements,
but
I
think
the
fact
that
this
problem
has
occurred
in
communication
means
that
it
would
behoove
us
to
have
some
public
statement
either
in
the
charter
or
from
the
chairs
or
the
ads
saying.
Here's
our
plan
about
extensibility,
if
you
are
doing
work
that
wants
to
do
proxy
over
quick
here,
is
how
you
play
with
this
and
invite
them
in
to
not
necessarily
be
the
core
documents
but
to
participate
in
the
extensibility
of
it.
C
C
Interior
had
a
couple
of
presentations
about
about
quick
tunneling
that
that
made
some
things
that
looked
a
lot
like
connect
and
the
the
discussion
that's
been
happening
since
then
is
very
much
one
of
now
is
the
the
a
really
good
time
to
come
and
let's
talk
about
use
cases
and
we're
currently
sorting
out
our
own
set
of
use
cases
and
requirements,
and
that
that
this
is
a
propitious
time
for
for
the
folks
presenting
in
interior
to
to
join
that
discussion
and
and
have
everyone
talk
about
that
together,
myriad,
you
have
like
60
seconds,
and
then
I've
got
a
couple
more
things
to
talk
about
at
the
end,
yeah.
H
It
takes
a
six
second,
I
just
want
to
add
on
the
extendability
point,
I
think,
like
we've
seen,
that's
really
important
to
have
that
ready.
However,
it's
a
little
bit
too
easy
to
just
say,
like
we
leave
this
one
for
an
extension
later
on,
because,
for
example,
for
the
ecn
case,
there
are
two
different
ways
there
might
be
per
packet
information
that
you
need
or
more
like
easy
encounters,
which
are
more
event-based
signaling
mechanism
whatever.
H
So
we
also
need
to
make
sure
that
we
have
the
right
extendability
mechanisms
in
place,
and
for
that
it
does
probably
make
sense
to
talk
a
little
bit
or
think
a
little
bit
about
details
more
and
to
make
ensure
that
we
have
the
right
extendability
mechanisms.
K
Yeah,
so
somebody
asked
about
the
charter,
I
mean,
I
think
the
charter
is,
is
not
super
specific
about
exactly
what
bits
of
udp
and
ip
proxy
need
to
be
in
there,
and
I
think
that's
fine
and
I
think
it's
premature
to
over
index
over
what's
an
extension
what's
not
and
how
many
physical
drafts
there
are
by
all
means
like
let's
figure
out
what
we
want
to
address
in
this.
K
Let's
get
consensus
we
want
to
address
in
this
take
and
whether
there's
like
technically
an
rfc
that
has
like
basic
connect,
udp
and
then
there's
another
rfc
with
a
couple
of
extensions
or
it's
all
just
glommed
into
one
draft
is
like
an
editorial
matter,
but
I
think
we
just
have
to
reach
group
groups
as
well.
So,
what's
worth
addressing
in
this
take,
I
don't
think
the
charter
is
particularly
destructive.
There.
C
C
Let's
make
sure
that
we
try
to
focus
on
the
use
cases
that
we
believe
we
really
need
to
support
and
try
to
gain
some
agreement
on
that
and
the
requirements
that
that
follow
from
that
more
so
than
the
the
particular
solution
that
that
we
want
to
deploy
and
we'll
also
try
to
go
schedule
an
interim
so
that
we
can
get
together
and
drive
some
of
the
resolution
forwards
on
those
issues.
But
in
the
meantime,
let's,
let's
try
to
see
how
far
we
can
get
the
conversation
there.