►
From YouTube: IETF111-MASQUE-20210726-2300
Description
MASQUE meeting session at IETF111
2021/07/26 2300
https://datatracker.ietf.org/meeting/111/proceedings/
A
I
I
ca.
I
can
absolutely
watch
the
chat
session
with
somebody
honestly
tell
people
to
put
at
mic
or
something
like
that.
B
A
C
C
E
C
B
Pixelated
yeah,
I
think
we
can
get
started
so
welcome
everyone
to
the
the
mask
meeting
for
the
week.
Yeah
excited
to
have
you
here,
I'm
sorry
for
those
who
you
know.
Perhaps
this
doesn't
align
with
the
best
hour
of
the
day
but
such
as
life.
I
guess
next
slide.
Please.
B
As
usual,
this
is
being
recorded.
Everyone
who's
here
has
likely
used
me
echo
before
so.
If
you
want
to,
you
know,
speak
at
the
mic
or
in
the
jump
in
the
queue
just
use
the
little.
B
You
know
handy
tool
down
the
left
hand
side
to
enter
shelf
of
the
mic,
we'll
try
to
call
on
you
in
order
that
you
appear
just
so
everything's
done
in
an
orderly
fashion,
for
those
people
who
well
specifically
watson,
who
volunteered
to
take
notes
who
may
not
be
looking
at
the
queue
or
may
not
recognize
your
voice
be
helpful.
If
you
just
say
your
name
before
you
start
speaking
just
so,
we
can
note
it
down
next
slide.
Please.
B
This
is
the
notewell.
If
you
have
not
seen
this
before,
I
encourage
you
to
just
take
a
moment
to
read
it
here
or
either
online,
just
a
friendly
reminder
to
be
respectful,
courtesy
to
others
during
the
meeting,
and
hopefully
this
will
be
productive
and
useful
to
everyone.
B
Here's
some
useful
links
that
might
help
you
along.
We
have
a
link
to
the
agenda
here.
You
can
also
find
it
on
the
data
tracker
link
to
the
notes
in
the
java
room,
which
is
also
relayed
here,
thanks
for
clarifying
that
to
whoever
did
that
if
anyone
wants
to
help
out
with
notes,
you
know
to
add
more
detail
or
whatnot
feel
free
to
also
you
know,
jump
in
and
help
watson
out.
B
He
took
notes
during
an
earlier
session
during
the
day,
so
I'm
sure
he
could
use
a
little
bit
of
a
break
next
flight.
Please
all
right
on
the
agenda.
We
have
a
number
of
things.
B
First
up
is
to
go
through
updates
to
connect
udb
and
http
3
datagrams
david's,
going
to
talk
about
the
interrupt
status
that
took
place
last
week,
a
reminder
of
which,
on
the
quick,
dev
slack
channel,
there
is
a
or
server
there
is
a
mask
channel
during
which
we're
sort
of
organizing
the
interop
or
during
which
in
which
we're
discussing
the
interop.
So
if
you
want
to
participate,
you
know
send
eric
or
myself
in
email
to
get
added
to
the
server
or
anyone
who's
in
there.
B
I
think
anyone
can
add
anyone.
I
don't
remember
the
details
and
we'll
get
you
squared
away
and-
and
you
can
dive
right
and
get
going,
would
also
talk
about
draft
updates
and
some
open
issues
after
that
we're
gonna
pop
over
to
you
know
the
second
sort
of
leg
that
this
work
group
focuses
on
and
that
is
connect
ip
we're
gonna,
quickly
revisit
and
review
where
we
are
with
the
requirements.
Documents
just
basically
nailing
down
we're
confirming
what
has
been
nailed
down.
B
We're
going
to
talk
about
the
two
proposals
that
are
on
the
table.
The
both
hopefully
called
connect
ip,
so
we'll
just
refer
to
them
as
proposal,
one
and
proposal
two
in
no
particular
order,
and
then
we're
going
to
have
some
discussion
afterwards,
hopefully
to
help
you
know,
decide
on
a
path
forward
or
decide,
sort
of
or
figure
out,
what's
missing
and
what's
not
and
what
have
you
all?
This
is
as
time
permits
based
on
how
much
progress
we
make
with
the
connect
udp
and
http
datagram
stuff.
B
So
you
know
that,
as
as
usual
in
mass
conversations,
you
know
we
tend
to
run
over
with
certain
things,
so
the
connect
ip
stuff
may
be
truncated
and
so
well,
we'll
just
play
it
by
ear
when
we
get
there
and
then.
Finally,
if
you
know
after
all
that
time
still
remains
and
lucas
we'll
talk
about
some
hp3
data
around
the
priority
stuff,
so
I
do
apologize
advanced
lucas.
If
you
get
bumped,
I
assume
you're.
B
Okay,
with
that
before
proceeding
any
further,
does
anyone
have
any
questions
comments
or
want
to
make
any
changes
to
the
agenda.
B
All
right,
if
not,
let's
eric,
can
you
do
the
magic
to
share
things
with
david.
B
A
C
E
Crazy
for
me.
C
Very
nice,
okay,
should
I
just
get
started,
I
guess
so
all
right,
good
morning
afternoon
evening,
middle
of
the
night,
everyone.
So
my
name
is
david
kanazi
and
let's
chat
about
mask
http
datagrams
and
connect
udp
next
slide.
Please
ooh!
I
have
the
buttons
myself
so
previously
on
mask
so
quick
recap
of
where
we
are
today.
If
you
haven't
been
paying
attention
so
big
item
in
our
charter
is
building
connect
udp,
so
it's
connect,
but
not
for
tcp.
C
It's
for
udp
and
some
of
the
requirements
that
we
picked
up
along
the
way
is
that
it
needs
to
work
over
all
versions
of
http,
so
one
two
and
three
and
across
http
intermediaries,
and
that
becomes
really
funny
when
our
the
intermediary
is
operating
on
one
leg,
with
one
version
of
http
and
with
another
version,
but
we'll
get
into
details
about
that
later
and
another
important
thing
and
reason
that
we're
doing
connect
udp
today
and
not
20
years
ago
is
when
we're
going
over
http
3.
C
So
that
said,
there
were
other
working
groups
and
people
interested
in
using
http
datagrams
without
connectudp,
so
in
particular
one
itf
effort
is
web
transport.
So
we
decided
to
kind
of
split
the
connect
udp
draft
into
two
where
the
bottom
is
an
http,
datagrams
layer
and
connect
udp
kind
of
sits
as
a
user
of
that,
and
that
way
web
transport
can
have
a
dependency
on
http
datagrams
without
depending
on
connect
udp.
C
So
we
had
a
mask
interim
in
april
of
this
year,
mainly
on
the
talking
about,
should
be
datagrams.
We
kind
of
pause
the
connect
qdp
layer
above
until
we
kind
of
solve
some
design
questions
there,
and
at
that
meeting
we
kind
of
pretty
much
redesigned
everything.
And
after
discussing
this
on
the
list
and
reviewing
and
on
github,
we
merged
some
prs
and
submitted
some
new
revisions.
So
let's
go
into
details
as
to
what
has
changed
between
itf
110
and
this
week's
itf-111.
C
C
So
we're
very
excited
and
another
point
that
I
want
to
really
highlight
apple
shipped,
a
really
cool
thing,
called
icloud
private
relay
tommy
gave
a
cool
presentation
in
perg
earlier
today,
and
but
what
that
means
for
mask
is
all
this
is
built
on
a
double
mask
proxy,
which
is
based
on
connect,
udp,
so
apple
and
its
mysterious
cdn
partners
that
I'm
not
allowed
to
talk
about,
but
that
are
clearly
in
the
room
and
whose
ips
are
fundable
by
who
is
all
have
connect
udp
deployed
in
production.
C
C
So
what
what
changed
between
last
time?
And
this
time,
so
a
big
change
is
that
we
decided
to
strongly
associate
datagrams
with
the
http
request
that
created
or
that
is
associated
with
them.
So
what
that
means
is
we
kind
of
removed
the
flow
id
which
was
the
single
variant
at
the
start
of
the
datagram
for
demultiplexing,
and
we
replace
it
by
the
stream
id
of
the
associated
request
and
since
in
http
3
requests
are
on
client
initiated
bidirectional
streams,
which,
in
quickview
1,
are
divisible
by
four.
C
We
just
encode
a
quarter
of
that,
because
that
means
we
can
save
some
bits
in
the
warranty
coding,
and
these
datagrams
can
also
carry
a
context
id
which
is
optional
and
the
idea
there
is
for
applications
that
need
it.
C
You
can
have
a
second
multiplexing
layer
with
some
negotiation
or
declaration
capabilities
that
allows
you,
for
example,
if
you
have
an
ip
tunnel
on
one
context
and
you
want
to
compress
the
ip
header
or
the
ip
addresses
and
some
of
them
these
can
coexist
on
the
same
conceptual
requests
down
the
same
so
datagrams
with
the
same
quartus
stream
id
field
and
we're
gonna
go
into
more
detail
about
how
you
communicate
these
encodings
to
your
peers.
C
So
they
know
the
format
of
the
datagrams
you're
sending
so
another
thing
is,
since
we've
agreed
as
a
working
group
that
we
need
to
support
versions
of
http
that
before
three
so
that
go
over
tcp.
C
We
need
a
way
to
send
datagrams-
and
you
know
in
this
case
of
connectudb
udp
packets,
over
streams,
and
so
that
was
originally
done,
using
something
called
stream
chunks
which
were
a
sequence
of
tlvs
on
the
data
stream.
So
what
I'm
calling
the
data
stream
is
the
in
in
http,
2
and
3?
It's
what's
in
data
frames.
C
It
should
be
one.
It
was
like
the
only
thing
that
was
there
some
details
there,
but
anyway
and
the
problem
there
is
the
original
design.
We
were
just
thinking.
Well,
we
just
can
just
put
everything
in
data
and
that
way
the
intermediaries
don't
need
to
think
about
it,
and
so
the
problem
is
what
happens
in
the
scenario
that
we
have
a
diagram
here
for
where
the
intergary
is
speaking.
C
Http
3
to
the
client
on
one
side,
http
2
to
the
server
on
the
other
and
a
and
some
stream
chunks
are
flowing,
and
then
a
datagram
frame
comes
in.
The
intermediary
needs
to
kind
of
inject
that
kind
of
between
two
tlvs.
So
he
needs
to
pick
a
moment
in
the
stream
to
inject
it.
C
But
in
order
to
do
that,
it
means
that
it
needs
to
be
parsing
the
entire
stream
of
tlvs
and
that
kind
of
completely
breaks
down
the
architectural
purity
we
had
of
okay,
the
data
stream
is
something
that
interpretaries
don't
touch
so
because
of
this,
we
decided
to
switch
to
a
new
approach
which
is
capsules
thanks
ben
for
the
name,
even
though
I
know
ben's
not
too
excited
about
the
name,
and
so
the
idea
there
is,
if
the
data
stream
isn't
great,
how
do
we
get
information
end
to
end
between
the
client
and
the
server
in
the
presence
of
intermediaries,
because
you
can't
just
use
http,
2
or
gp3
frames,
because
these
are
hub
by
hop
if
a
frame
arrives
at
an
intermediary,
it
only
has
meaning
from
there.
C
C
It's
just
like
it
is
a
new
type
of
frame,
but
it
has
a
new
semantic,
which
is
when
intermediary
receives
a
capsule
it,
even
if
it
doesn't
know
what
this
capsule
is
it
copies
it
and
forwards
it
onto
the
stream
that
it
would
forward
the
data
on,
and
that
gives
you
kind
of
a
new
extension
point
to
http
that
allows
defining
new
capsules,
but
you
don't
need
to
change
the
interpreter
every
time
you
only
modify
the
intermediary
once
and
then
the
way
we'll
define
this
for
h2
is
kind
of
probably
use
upgrade
and
define
a
new
protocol.
C
That
is
a
sequence
of
capsules,
but
we'll
cross
that
bridge
when
we
get
there.
Let's
kind
of
agree
on
this
design
first,
because
we
had
some
traffic
on
the
list
and
just
wanted
to
make
sure.
Let's
kind
of
pause
and
have
this
conversation
is.
Is
that
what
is
the
best
way
here?
Kind
of
so
stream
chunks
works
in
the
data
stream
capsules
work.
C
One
difference
that
makes
me
kind
of
prefer
capsules
is
that
it
keeps
the
data
stream
open.
You
could
use
it
for
something
else,
but
apart
from
that,
they
both
are
very
similar.
They
both
mess
up
kind
of
the
existing
http
semantics,
so
they
become
an
extension
to
the
semantics
depending
on
how
you
think
about
it.
But
then
it
becomes
an
architectural
discussion
which
means
we're
at
itf
because
both
work
week
in
bike
sheds.
So
martin,
please
tell
me
what
you
think.
G
I
think
with
with
is
not
that
they're
a
new
frame
type
or
whatever,
or
not,
that
you're
inventing
in
well.
Actually
it
is
it's
that
you're
inventing
a
new
end-to-end
semantic
for
for
the
protocol
and
I'd
like
to
see
a
little
more
motivation
than
both
would
work
for
doing
that,
because
this
is
a
fairly
major
thing
to
do.
G
If
you
don't
need
or
the
h3
stuff,
and
that's
probably
something
that
I'm
interested
in
starting
out
with
with
mask,
maybe
not
initially,
but
we
can
get
something
working
and
demonstrating
that
it
works
just
by
I
have
an
existing
stack.
I
tell
it
that
connect,
udp
or
connect
ip
does
whatever
it
does,
and
then
I
can
handle
the
the
contents
according
to
the
protocol.
C
So-
and
I
think
you
know
the
not
having
data
grams
kind
of
becomes
the
crux
of
the
issue
at
the
end
of
the
day,
because,
like
that's
the
motivation
of
why
we're
doing
this
like
it's?
Because
quick
is
the
way
it
is
that
we
have
more
need
for
be
able
to
proxy
udp
and
we
have
the
opportunity
of
proxying
udp
efficiently.
And
if
we
like,
I,
my
relevant
take,
is
to
focus
on
the
version
with
datagrams
get
that
working
the
best
in
the
world.
C
And
then
you
know
earlier
version
of
http
should
be
supported,
but
not
quite
as
a
first
party.
So
that's.
G
Yeah,
I
I
think
that's
probably
fair,
but
if
you
imagine
that
your
your
api
is
is
is
only
widened
to
include
the
ability
to
send
datagrams
related
to
a
stream
which
is
essentially
what
the
the
datagram
draft
does.
Then
you
you
get
that
capability
without
significant
additional
increase
in
the
surface
area
of
your
application.
You're
not
talking
about
writing
new
http,
2
or
http
3
frames.
In
order
to
get
these
things
working,
you
are
just
okay.
G
C
C
C
I
think
the
client
that's
going
to
be
deploying
this
is
going
to
be
doing
datagram
work,
so
they're,
already
kind
of
performing
surgery
on
their
quick
stack,
either
way
with
either
of
these,
and
then
it
becomes
interesting
on
the
intermediary
I
and
like,
maybe
for
folks
who
are
at
other
companies
and
have
other
deployment
models.
I
like
to
hear
them
as
well.
At
google,
we
have
a
front
end
that
speaks
http
3
to
the
clients
and
then
versions
over
tcp
to
the
back
end.
C
So
that
split
one
is
kind
of
my
personal
main
focus
and
for
those
with
either
one
I'm
going
to
have
to
perform
some
deep
surgery,
because
it
doesn't
have
the
ability
to
look
into
data
frames
and
it's
actually
less
work
to
go.
Look
at
http
3
frames
because
we
kind
of
recently
built
that
parser
and
it's
pretty
pretty
extensible,
but
like
you're
saying
you
know
it's
if
you're
focusing
on
a
different
one,
then
the
sets
of
priorities
varies.
H
H
I
kind
of
question
putting
them
in
the
h3
datagram
draft,
because
there's
nothing
specific
to
datagrams
about
them.
It's
just
the
first
customer,
and
so
if
we
actually
need
that,
I
almost
feel
like
it's
something
we
should
ask
http
for
or
send
them
a
draft
or
something,
but
I'm
also
so
the
question
that
I
had-
and
I
think
you
just
answered
it,
but
I
still
want
to
raise
it
in
the
discussion.
H
H
You
said
your
implementation
has
constraints
that
it's
not
able
to
parse
data
frames
and
that
I
think,
having
that
constraint
on
a
particular
implementation,
is
an
argument
for
capsules.
I
don't
know
if
we
should
design
around
that.
One
implementation,
though
so
I'd
kind
of
like
to
know
whether
there
are
whether
other
implementations
have
that
same
constraint
or,
if
looking
at
it
as
terminate
connect,
udp
and
service
it
by
making
another
connect.
Udp
request
lets
us
get
away
with
frame
types.
C
Thanks
that
that
makes
sense,
let's
hear
from
the
other
implementers
tommy.
I
So
I
was,
I
got
on
here
to
riff
off
martin's
comments
because
just
coming
from
the
implementation
perspective
alone,
not
looking
at
the
dock,
I
I
am
sympathetic
to
that,
and
I
do
think
there
are
things
about
using
the
data
stream
that
would
be
attractive
from
the
implementation
standpoint.
So
like
the
way
that
we
built
mask
in
is
as
a
layer
on
top
of
the
http
protocols
that
you
can
go
on
top
of
h2
or
h3,
and
it
just
handles
all
of
the
logic
around
the
proxy
and
it
so
for
datagrams.
I
I
So
I
do
think
that
you
know
having
yet
another
flow
of
data.
So,
like
you'd
have
like
the
stream
data,
your
datagram
data
and
then
capsules,
it
does
make
it
a
more
complex
abstraction
that
now
you're
asking
a
more
generic
http
layer
to
implement.
I
So
I
do
think
the
question
comes
down
to
like
is
connect
udp,
just
layering
on
top
of
normal
semantics,
or
are
we
saying
that
we
do
need
a
new
semantic
in
all
of
http,
and
is
that
something
that
we
expect
kind
of
all
these
http
apis
to
build
in
ways
to
do
capsules,
and
not
just
think
about
this
use
case?
So
I
do
think
that
if
we
want
to
go
that
road
go
down
that
road,
we
may
want
to
bring
it
into
hq
bis
to
talk
about
the
overall
implications
on
the
architecture.
I
C
So,
and
I
think
that
without
points
that
martin
was
making
so
yeah
to
be
very
clear,
both
of
these
would
work
and
that's
kind
of
why
we
end
up
in
these
trickier
conversations,
because
if
only
one
solution
worked
for
everything,
then
we
wouldn't
be
discussing
it.
It's
and
yeah
the
data
stream
is
definitely
doable
and
if
folks
do
prefer
that
we
can
go
back
to
it.
I
think
defining
the
how
I
think
it
makes
sense
that
the
http
datagrams
document
defines
how
to
convey
http
datagrams
over
http
2
over
http1.
C
The
there
is
value
in
having
using
datagrams
over
multiple
versions
of
http
and
that's
true
for
connect
gdp,
but
that's
also
true
for
web
transport
and
I'm
sure
there'll
be
more
because,
like
it'll,
be
like,
I
think,
widely
deployed
when
the
client
will
use
quick
data
grams
to
go
to
the
first
top
in
german
area
and
then
often
over
the
back
end.
It's
fine,
if
you're
using
h1
over
tcp
like
you're
on
an
over
provision
data
center
network
there.
So
you
don't
like
the
benefits
of
quicker
way
smaller.
C
So
it's
possible
there
if
we
say
that,
that's
why?
For
me,
it
makes
sense
to
have
like
capsules
or
if
we
want
to
call
them
stream
chunks.
Whatever
inside
the
hp
datagrams
document,
I
had
initially
brought
that
document
to
the
http
working
group
and
to
say:
if,
like
should
we
have
this,
there
and
kind
of
the
response
was.
This
is
a
new
kind
of
semantic,
that's
cool,
but
that
we
don't
need
to
have
there
so
go.
Do
it
in
mask
and
please
come
back.
C
You
know
when
you
were
a
working
group.
Last
call-
and
you
know
a
lot
of
the
htp
enthusiasts-
are
in
the
room.
So
I
I
don't
think
you
know
that
where
which
room
the
the
work
the
document
lives
in
is
is
like
the
most
important
part
alex.
D
Hi
thanks
david.
I
just
wanted
to
add
some
color
from
our
experience
implementing
cubone.
It
was
built
in
the
same
binary
that
david
was
referring
to
earlier.
However,
one
of
the
things
that
we
did
is
that
we
didn't
have
the
constraints
of
wanting
to
interrupt
with
http
stack
on
top
of
quick,
and
we
actually
in
fact
ripped
all
that
out
and
we
replaced
it
with
our
own
data
stream
that
wasn't
http
and
we
use
that
to
exchange
what
we
sort
of
call
control
data.
D
And
one
of
the
things
that
david
mentioned
of
like
well,
we
we
don't
want
this
particular
type
of
intermediary
to
inspect
over
the
data
stream,
because
that's
that's
not
good,
actually
is
exactly
that
mingling.
D
So
in
having
these
separate
capsules
as
a
separate
first
class
http
data
type,
it
means
that
we
can
have
a
logical
separation
as
to
what
is
actually
in
http
versus
what
is
actually
one
of
these
higher
level
protocols.
And
it
means
that
we
avoid
like
reinventing
new
protocols
and
multiplexing
strategies
on
top
of
http.
D
Like
one
of
my
personal
goals
for
ip
proxying
is,
I
don't
want
to
come
up
with
yet
another
way
of
exchanging
tlvs,
along
with
intermixed
data
frames
of
some
sort,
and
I
would
like
us
to
have
a
way
to
convey
both
the
control
data
and
the
datagrams,
be
they
unreliable,
reliable,
delivered.
And
what
I
really
like
about
the
capsule
proposal
over
the
stream
trunk
proposal
is
that
it
helps
at
least
for
me
mentally
fit
better
into
what
is
http
and
what
is
some
higher
level
data.
C
Yeah
that
makes
sense
and
then
to
to
to
add
to
that
kind
of
briefly
one
because
data
in
general
is
kind
of
you
know
for
most
of
http
is
the
message,
context
content,
and
so
we
consider
http,
as
you
know,
like
the
semantics,
which
should
be
our
request
response,
where
there
is
a
message
sent
up
in
data
frames,
followed
by
a
message
coming
down
in
data
frames
in
whatever
we
built
here
stream
chunks
for
capsules.
C
You
kind
of
have
this
bi-directional
flow,
and
some
of
these
you
know,
given
that
we're
kind
of
giving
it
to
the
application
to
the
side
could
potentially
be
server
initiated,
for
example,
and
that's
true
of
stream
checks
that
have
capsules
and
they're
features
that
can
rely
on
that.
So
we'll
discuss
that
in
the
connect
ip
section
at
some
point
and
that's
why,
like
it's
just
kind
of
strange
to
me
to
put
in
data
frames
because
it's
not
those
semantics
is
something
different,
but
again
it
would
work.
Martin.
J
Hi
as
an
individual,
I
don't
have
I'll
say
I
don't
have
a
strong
opinion
on
this,
but
I
do
want
to
push
back
on
the
fourth
point
that
because
I
think
there
are
intermediaries
in
their
intermediaries,
they're
people
where
you're
trying
to
do
like
datagram
transition
to
to
h1
or
whatever-
and
yes
absolutely
in
that
case,
you
have
to
change
it
anyway,
but
there's
certainly
plenty
of
boxes
out
there
that
might
be
in
the
path
that
currently
do,
h2
to
h1
or
h3
to
h1
or
whatever,
that
don't
support
datagram.
J
That
could
absolutely
pass
stuff
in
the
in
data
frames
without
any
difficulty
and
translate
them
between
protocol
versions.
But
if
you
have
some
random
new
frame,
it's
just
going
to
drop
them,
so
it.
I
think
it
is
a
barrier
to
deployment
that
we
would
have
to
overcome
thanks.
C
I
I
don't
have
a
good
intuition
for
how
common
these
boxes
are,
but
you're
totally
right
about
them.
I
agree.
J
Well,
for
instance,
it
like
a
big
ip
or
a
ninja
next
load
balancer
today,
you
know
supports
quick
in
hp,
3,
but
not
datagram,
and
so
it'll
absolutely
drop
frames.
They
don't
recognize.
G
At
the
point
that
I
really
like
originally,
which
is
that
this
is
really
about
the
difference
between
building
on
top
of
http
and
building
on
top
of
the
version
specific
versions
of
http,
so
h3
or
h2.
Now
I
realize,
of
course,
that
the
real
value
here
is
when
we
can
build
on
specifically
http
three,
because
the
other,
the
others
don't
have
datagrams,
but
at
the
same
time,
if
there
is
a
conceptual
layering
on
top
of
http
that
we
can
exploit
there's
a
lot
of
advantage
here.
G
There
is
one
point
that
I
think
we
haven't
gotten
to
yet,
which
is
the
flow
control
for
the
control
messages
that
you're
talking
about
exchanging
here
could
actually
become
critical,
particularly
when
you
look
at
the
connect
ip
scenario
where
you
have
to
you
start
a
transaction,
and
you
have
a
bunch
of
routes
that
you
add,
and
then
you
end
the
transaction.
You
are
expected
to
commit
all
of
those
things
at
once.
There's
some
buffering
requirements
and
and
flow
control
probably
has
to
apply
there.
C
Clarifying
question
about
flow
control
so
for
either
of
these
proposals,
they'll
be
on
top
of
a
quick
stream
or
an
h2
stream,
which
has
its
own
level
of
flow
control.
And
is
that
what
you're
referring
to
and
that's
sufficient?
Or
are
you
talking
about
flow
controlling
in?
Let's
say,
number
of
capsules,
chunks,
which
neither
proposal
has
today
at
least.
G
G
That
is
a
good
point,
and
so
things
get
complicated
unnecessarily.
I
think
when
you,
when
you
start
start
to
invent
new
things
and
then
of
course,
the
whole
extension
semantics
and
and
all
those
sorts
of
other
things,
so
my
preference
would
be
to
look
at
the
http
semantics
as
much
as
possible
and
then
then
extend
from
there
and
and
that
might.
C
L
Hi,
you
cannot
hear
me
cannot
hear
me.
I.
L
Okay,
wonderful,
I'm
not
going
to
repeat
the
points
that
was
said.
I
think
that
I'm
definitely
leaning
towards
using
existing
data
as
well.
But
I
think
one
to
one
point
that
you
said
earlier
that
you
went
to
http
and
they
kicked
you
over
to
mask
saying.
Maybe
go
solve
this
for
mask
if
it's
a
local
problem.
What
I'm
seeing
on
the
chat
is
that
it's
not
a
local
problem
that
it's
shared
potentially
with
the
transport
as
well
and
sorry
web
sockets
as
well.
C
I'm
also
on
our
channel,
specifically
the
I
think,
datagram
like
if
we
forget
about
this
capsule
stream
check
for
a
second
datagram
itself.
What
is
like,
I
think,
no
matter
how
we
slice
it
a
new
kind
of
http
semantic
and
that
like
was
very
clear
that
they
were
saying
like
that's.
What
mask
is
for,
like
you,
don't
need
all
http
semantics
to
live
in
the
http
working
group.
That's
what
I
what
the
http
chair.
So
if
they
want
to
jump
in
and
say
something
go
right
ahead,
but
that's
what
they
were
saying.
C
L
You
don't
see
it.
It
doesn't
seem
to
me
like
from
your
from
your
slide
here.
It
doesn't
seem
to
me
that
you
see
this
being
a
deployment
hurdle,
basically
introducing
a
new
capsule,
a
new
frame
type
here
for
hdb,
but
I'm
hearing
that
it
is
a
potential
hurdle.
L
I
don't
know
what
what
you!
What
do
you
think
about
that?
Because
I'm
I'm
trying
to
understand
I'm
trying
to
break
this
down
in
terms
of
the
the
difficulty
of
deploying
both
of
these
things,
and
it's
not
clear
to
me,
it
seems
clear
to
me
that
capsules
would
be
much
harder
to
deploy
because
a
new
chunk
type
and
a
new
frame
type.
Oh,
my
god,
I'm
getting
all
of
my
nomenclature
wrong
today,
anyway,
that
that
may
be
that.
Maybe
that
is
the
argument
for
not
being
capsules,
because
it's
confusing
yeah.
C
But
I
mean
yeah,
so
I
was
working
with
a
set
of
assumptions
kind
of
a
little
bit
specific
to
to
our
implementation,
but
I'm
getting
a
clear
sense
in
the
room
that
folks
seem
to
prefer
data
frames.
So
I
mean
that
I'm
I'm
happy
to
go
back
to
my
implementation.
Give
that
a
try
see
if
there
aren't
any
like
complete
roadblocks
there,
and
then
you
know,
maybe
we
we
switch
back
to
something.
That's
I
mean
that's
on
the
table.
Obviously
yep
fair
enough.
Thank
you.
C
The
there
is
one
question,
though,
in
general,
because
we
kind
of
as
often
with
you
know
how
these
things
go.
We
multiple
changes
happen
at
the
same
time,
and
so
we
were
mainly
focusing
on
a
new
frame
capsule
versus
using
data
frame
and
then
stream
chunks
so
far,
we're
on
inside
the
data
stream
so
sounds
like
there's.
A
strong
preference
here
for
data
frames
so
happy
to
switch
back
to
that.
C
The
other
change
that
happened
around
the
same
time
was
moving
this
from
connect2dp
into
into
the
http
datagram
document,
and
I
want
to
make
sure
that
folks
are
okay
with
that
and
the
reason
it
was
moved
as
well.
Kind
of
around
the
same
time
is
when
we
did
the
split
from
flow
id
to
stream
id
plus
context
id
you
needed
a
way
to
negotiate
context
id
and
that
kind
of
had
a
requirement
on
something
that
went
across
so
stream
chunks
or
capsules.
Hence
why
it
moved
down.
So
are
folks.
C
Okay
with
that.
Still
that
part,
which
is,
let's
say,
the
stream
chunks
living
in
the
http
datagrams
document,
because
I
think
that
even
if
we
switch
to
data
frames,
that
part
makes
sense
to
me.
But
I
want
to
make
sure
that
I'm
like
I'm
not
in
the
minority
here
so
lucas,.
E
F
This
off
yeah-
I
I
don't
have
much
to
add,
I
think,
just
to
the
question
you
asked.
I
entered
the
key
before
that,
but
I
think
it
is
the
right
thing
to
have
these
located
in
this
document.
Connect
qdp
now
is
quite
a
simple
document.
F
I
think
for
people
coming
into
mask
and
like
what's
this
connect
qdp
thing
it's,
it
would
just
build
on
top
of
other
stuff
that
people
have
implemented,
because
it's
general
purpose,
but
what
I
was
going
to
say
is
having
taken
an
implementation
that
we
did
last
time
for
the
interrupt
and
tried
to
change
that
to
be
capsule
frames.
F
I
kind
of
fell
into
this
trap
of
treating
them
like
full
hp,
3
frames,
and
I
got
stuck
because
I
couldn't
parse
them
properly
and
actually
what
I,
what
I
probably
need
to
do
is
treat
them
like
data
frames
that
they're
opaque
bytes
that
I
would
throw
up
to
the
application
and
it
would
be
responsible
for
parsing
their
capsule
contents
and
deciding
what
to
do
and
then
driving
my
library
again.
So
that's
kind
of
where
I
got
stuck
and
why
my
interrupt
entries
weren't
there,
because
I
like
I,
couldn't
bootstrap
any
connect
udp
effectively.
F
It
would
be
sad
to
have
to
go
back
from
all
the
work
we
just
did
on
capsules,
but
that
was
part
of
the
question
that
we
answered
in
going
to
a
dual
layer
model
right
and
I
think
actually
we
we
could.
If
we
had
to
do
this
on
data
stream,
but
maintain
that
dual
layer
context
id
stream
id
stuff
like
that,
and
that
we,
my
feeling
is,
we
still
have
consensus
of
keeping
that
part
of
the
design,
even
if
not
capsules
so.
F
C
Wow,
sorry,
everyone
all
right.
I
yeah.
Where
did
I
start?
Oh
yeah,
so
the
sense
I'm
getting
is
that
folks
do
like
a
lot
of
folks
prefer
using
data
frames.
So
let's
switch
back
to
that,
but
I
don't
think
folks
are
suggesting
kind
of
reverting
everything
that
we
did
along
the
way.
So
I
think
keeping
this
two-layer
and
also
keeping
the
fact
that
http
datagrams
now
work
across
all
layers
and
define
the
stream
chunks
in.
C
D
Thanks
david,
I
mostly
wanted
to
ask
the
question
of
making
sure
that
we're
continuing
to
make
progress
here,
because
one
of
the
things
I'm
a
little
bit
nervous
about
is
that
the
capsule
proposal
came
out
of
people
being
kind
of
unhappy
with
the
multiplexing
that
we
were
doing
over
the
data
stream
and
now
that
we
have
this
proposal.
People
are
now
unhappy
that
we
have
a
new
frame
type
and
I'm
sort
of
wondering
which
is
the
one
which
is
more
impure.
D
That
we
need
to
agree
is
worse
than
not
do
and
I'm
not
currently
sure
that
we're
thinking
about
it
that
way
we're
instead,
just
looking
at
the
current
rules
and
saying
you,
we
don't
like
that,
the
other
one
was
probably
better
and
then,
if
we
have
another
meeting
three
months,
three
or
four
months
from
now,
we
might
change
our
minds
again.
So
what
can
we
do
to
make
sure
that
we
don't
keep
flip-flopping
here.
C
Oh
okay,
I'm
unmuted,
so
thank
you
alex.
I
think
that's
a
very
good
point,
because
when
we
switched
to
capsules
this
was
discussed
on
the
list
and
we
had
quite
a
few
people
comment
in
support,
and
now
it
was
kind
of
strange
to
be
like.
Oh
now,
everyone's
against
did
I
miss
a
meeting,
so
I
I
agree
with
you.
C
It
would
be
I'm
totally
fine
going
back
here,
but
it
would
be
great
to
not
keep
flip-flopping
for
the
next
decade
because
you
know
we
have
people
who
want
to
ship
this
stuff.
C
I
Just
to
that
last
point
to
alex
like
I,
I
think
this
is
progress
I
think
seeing
it.
Both
ways
is
important
and
then
people
can
make
a
better
judgment
on
it,
and
if
you
want
to
cement
it
down,
I
mean
we
should
ask
for
a
consensus
call.
I
don't
think
it
should
be
in
this
meeting.
It
should
probably
be
on
list,
but
that's
how
you
move
forward
right.
Regarding
david,
your
question
about
you
know
what
we
keeping.
What
are
we
going
back
to
yeah?
Don't
revert
everything.
I
I
I
But
this
is
not
going
to
apply
to
a
get
or
a
post
like.
There
are
ways
that
it
will
not
work,
so
you
could
find
it
in
the
methods
themselves,
but
that's
not
necessary
for
the
case
of
web
transport.
I
just
want
to
understand
like
how.
C
On
can
I
answer
something
on
that
one.
So
I
the
way
I'm
thinking
about
it,
and
this
is
kind
of
very
fresh
just
from
this
meeting,
so
I'm
probably
forgetting
about
some
things,
but
one
part
of
okay
is
this
in
this
document.
In
that
document
sure
duplication
of
text
not
the
end
of
the
world
and
then,
if
we
put
it
in
http
agram,
you
would
say:
okay,
this
is
what
a
capsule
data
stream
means,
or
you
know
we'll
find
a
cool
name
for
it,
and
then
x2dp
would
say.
C
I
choose
my
method
to
use
a
capsule
data
stream
and
boom.
You
use
it.
The
I
think,
the
the
one
difference
that
actually
matters
between
having
it
live
in
http,
datagram
versus
having
it
live
in
connect,
udp
and
connect
ip
is
the
capsule
types
in
registry.
C
I
Yeah,
but
that's
fine,
I
mean
having
it
in
a
common
place.
If
we
want
to
use
the
same
semantics
and
the
same
registry
between
connect,
udp
and
connect
ip
is
fine
like
I
guess
it
could
be
its
own
third
document,
but
let's
not
go
there
and
then
for
web
transport,
because
I
know
web
transport
wants
to
use
datagram.
Does
it
want
to
use
stream
chunks
too
and
how
remind.
K
Okay,
so
the
comment
I
was
going
to
make
is
approximately
yes
that
now,
if
we're
running
the
capsules
of
our
data,
now
we
are
in
a
position
where
your
method
basically
has
to
use,
trim
trends,
and
it
has
to
use
trim
strings
if
it
wants
to
use
context
and
that's
a
solvable
problem,
because
you
can
move
context
out
of
datagram
into
connect
or
something
else.
K
K
K
The
session
is
closed
or
session
level
go
away,
which
is
like
all
requested
features
for
which
we
had
consensus,
that
we
should
implement
them,
and
that
involves
some
form
of
stream
of
chunks
on
connectstream,
and
I
was
when
that
was
opened
like
in
march,
I
was
going
to
write
a
new
thing
and
if
h3
datagram
provides
that
I
will
not
have
to
so.
From
that
perspective,
that
is.
C
I
K
I
C
Yeah,
let's
do
it
awesome,
yeah,
and
I
think,
on
the
question
of
like
you
know,
having
this
like
unified
registry
doesn't
mean
that
you
definitely
find
data.
You
know
a
stream
trunk
for
datagram
or
diagram
capsule.
Only
once
which
I
find
pretty
appealing
all
right.
I
think
we
we
have
a
path
forward,
I'll
I'll
write
up
a
pr
for
this.
C
That
kind
of
moves
back
to
dataframe,
but
without
reverting
anything
else,
and
I
do
ask
that
people
like
really
spend
the
time
to
think
about
it
and
look
into
it
on
the
list.
So
we
don't
have
to
go
re-revisit
this
at
the
next
atf.
But
I
think
we've
made
some
good
progress
and
I
totally
understand
that
you
know
it
took
actually
seeing
a
draft
with
capsule
to
decide
what
we
liked
or
not
all
right
and
now
in
the
13
minutes
I
have
left,
I
will
go
through
the
next
10
slides.
C
Obviously,
since
this
is
was
not
necessarily
what
I
predicted,
the
slides
are
going
to
keep
talking
about
capsules,
but
let's
just
say
that
they're
still
capsules
but
they're
going
over
data
frames
now
and
just
do
that
mental
substitution.
So,
in
order
to
carry
datagrams
over
http
one
and
two,
you
need
a
datagram
capsule
and
that's
kind
of
all.
There
is
to
it
it
also
for
the
rare
applications
that
want
the
ability
to
reliably
deliver
a
capsule
to
reliably
deliver
a
datagram
over
http
3.
C
It's
simple,
then
kind
of
context,
so
that
was
an
addition,
since
the
last
atf,
where
with
what
we
were
kind
of
calling
the
two
layer
design
as
opposed
to
just
having
a
flow
id,
now
we
have
the
stream
id
which
tightly
couples
to
a
request
and
then
an
optional
context,
id
that
gives
you
a
second
layer
of
multiplexing
for
cases
where
you
want
to
do
different
compression
contacts
on
the
same
connection
again-
and
here
comes
the
protocol
police,
so
the
namespace
of
context
id
is
again
a
warrant,
so
62
bits
we
shouldn't
run
out
and
similar
to
other
things
in
quick,
the
even
ones
are
for
clients.
C
The
odd
ones
are
for
servers.
That
means
you
don't
need
any
synchronization
to
build
your
own,
and
this
is
what
we
discussed
at
the
interim.
All
of
these
contexts
can
be
used
bi-directionally.
So
let's
say
if
the
client
says
I'm
going
to
use
context
zero
for
foo.
It's
start
sending
data
grams
for
with
it
for
with
the
server
can
also
send
datagrams
product
zero
for
foo
and
registration
is
kind
of
a
unilateral
declaration
of
hey.
I'm
just
gonna
do
foo
with
zero.
That
is
what
that
means.
C
You
don't
get
to
decide
like
zero.
Is
I'm
the
client
I
own
zero?
So
I
get
to
send
this
and
the
way
you
do
that
is
with
a
register
capsule
and
then
we
also
added
a
closed
endogram
context,
capsule.
C
So,
for
example,
if
let's
say
you're
doing
a
compression-
and
you
say
okay,
I
want
to
register
context
id
number
four
and
we've
associated.
This
is
the
iip
header
that
I'm
gonna
compress
and
you
start
sending
and
after
a
while,
the
server
is
like.
Okay,
I
am
like
really
low
on
memory.
I
want
to
save
some.
You
haven't
been
sending
any
datagrams
on
this.
I
need
to
garbage
collect
all
right,
just
fyi.
I
have
now
closed
this
context.
C
I'm
not
going
to
be
I've
flushed,
all
my
state,
so
if
you
send
with
it
those
going
to
get
dropped
on
the
floor,
so
we
added
that
then
so.
Here's
that
example
that
I'm
mentioning
where
let's
say
you're
on
so
you
have
your
connect
ip
request
on
stream,
44
and
so
you're
saving
datagrams,
with
your
course
room
id
44
divided
by
4,
which
is
11,
and
you
just
say:
okay,
conex
id
0,
I'm
not
sending
any
extensions.
C
That
is
just
a
raw
ip
packet
and
you
send
for
that
and
then,
after
a
while
you
say
well,
maybe
I
should
compress
because
it
turns
out
that
this
user
just
created
a
tcp
connection
to
this
specific
host
and
it's
sending
a
lot
of
data.
Maybe
let's
compress
the
ip
addresses
tcp
ports.
However,
you
want
to
do
your
encoding
scheme,
but
you
use
a
separate
context
id
which
is
two
and
you
when
you
register
it.
You
use
this
extension
mechanism
to
say
let's
these
are.
C
This:
is
the
format
slash
the
semantics
of
datagrams
with
this
context
id?
Which
means
that
the
your
peer
is
going
to
use
that
information
to
decompress
the
packet
and
then
shove
it
back
into
its
stack,
so
kind
of
switching
gears
to
connect
udp
here,
so
the
draft
was
pretty
much
on
hold
while
we
were
redesigning
http
datagrams
to
the
point
where
I
let
it
expire
for
a
few
days.
My
apologies
drafts
shouldn't
expire,
but
that's
a
different
question.
C
Now
that
we've
kind
of
moved
some
of
this
functionality,
http
datagrams
and
like
decided
that
it
should
be
datagrams
to
support
all
versions
to
be
the
connect2dp
draft
is
way
shorter.
It
kind
of
just
says:
hey
use,
http
datagrams,
a
udp
packet
matches
a
udp
asp,
datagram
done,
and
then
there
are
some
semantics
there,
but
it's
kind
of
a
lot
cleaner
and
that
felt
really
nice
being
able
to
rip
out
so
much
text
in
that
draft
and
have
something
pretty
simple.
C
Now
for
everyone's
favorite
activity.
In
the
eight
minutes
left,
we
have
left.
Let's
see
how
many
github
issues
we
can
discuss
so
on
the
topic
of
extensibility.
So
when
I
was
saying
for
this
ip
extension,
you
you
need
a
the
ip
compression
the
this.
These
register
capsules
have
a
way
to
do.
Extensibility,
that's
kind
of
nebulous
and
the
issue
is
we
have
some
examples
here
in
the
documents,
but
mainly
from
the
issues
and
the
lists.
C
A
few
folks
were
like
how
do
I
use
this
because
it's
true
the
documents
themselves
have
this
extension
joint,
that's
not
really
used,
and
so
right
now
it
has
a
format.
That
looks
really
I
mean
it's
just.
C
I
stole
it
from
quick
transfer
parameters
which
is
this
is
a
sequence
of
opaque
tlvs
and
then
the
t's
are
registered
in
iona
registry
and
tnl's
or
variants
done
that
allows
you
to
encode
just
about
anything
which
is
great,
but
do
we
need
that
much
some
folks,
I
forget
who
were
saying
pretty
reasonably
like
if
you're
defining,
if
this
means
like
this
is
the
format
of
my
datagram,
because
you
know
for
context
is
like
in
order
to
send
datagrams
with
that
context.
You
don't
need
two
formats,
you
only
need
one.
C
C
Let's
say
you
have
connect
udp
and
you're,
sending
udp
packets,
someone
writes
an
extension
that
says:
hey,
I'm
going
to
add
a
timestamp
right
before
my
packet.
So
if
this
contest,
if
I
register
my
extension,
it
means
that
there's
eight
bytes
of
timestamp
before
the
udp
payload,
all
right,
that
makes
sense.
Let's
say
someone
does
the
same
thing
for
a
completely
different
extension
that
does
a
byte
with
ecn
bits.
For
example.
C
What
do
you
do
if
you
want
to
actually
and
also?
How
do
you
order
them?
Is
that
something
we
want?
Is
that
something
we
don't
want?
Please
discuss
line
up
at
the
mic.
Martin
go
ahead.
C
No
sorry,
I
forgot
to
say
that
context
are
very
much
end
to
end,
so
the
that
was
one
of
the
tweaks
in
the
two-layer
design.
The
stream
id
is
very
much
hot
by
hop
the
context.
Id
is
very
much
end-to-end.
C
G
Right
so
in
a
scenario
where
you
have
an
intermediary,
who
is
maybe
taking
things
from
datagrams
and
putting
them
on
the
stream
or
taking
from
the
stream
and
turning
them
into
datagrams,
they
don't
need
to
know
about
this
stuff.
This
is
something
that's
negotiated.
End-To-End.
C
Completely
yeah
and
the
and
the
big
feature
there
was,
it
allows
you
to
deploy
extensions
to
connect,
udp
or
connect
ip
by
only
modifying
the
client
into
the
server
without
having
to
modify
any
of
the
intermediaries
along
the
way.
G
Yeah,
so
inherently
you
have
the
ability
to
ensure
that
the
the
datagrams,
whatever
whatever
they
are,
however
they're
expressed,
get
get
there
end
to
end.
So
why
does
this
need
to
be
an
extension
to
an
existing
message
and
not
just
a
new
message?
G
C
So
the
I
mean
that
makes
sense
the
way
I
was
thinking
about.
It
was
kind
of
a
layering
thing
where
at
the
http
datagram
layer,
it
doesn't
know
anything
about
the
format,
and
it
just
has
a
way
to
say
here.
Is
a
data
grant
tell
me
to
send
a
datagram
and
with
what
context?
And
here
tell
me
what
context
it
is
and
what
that
format
means,
and
I
will
kind
of
shove
that
bag
of
bytes,
if
every
single
thing
needs
to
define
its
own
register.
G
Have
to
but
it
could
so
there's
there's
a
potential
point
in
the
future.
Where
you
go.
Oh
well,
there's
the
combinatorial
explosion
that
we're
starting
to
see.
Well,
let's
just
define
an
extensible
one
and
and
then
you
have
an
extensible
register
context
id
you
don't
necessarily
have
a
close
necessarily
that
would
be
extensible
in
the
same
way,
and
so
that
gives
you
a
bit
of
flexibility
without
having
to
fully
anticipate
all
of
the
necessary
extensions
that
someone
might
want.
C
Yeah
I
mean,
but
both
I
totally
see
that
I
think
both
of
them
work.
I'd
have
to
think
about
it.
Some
more
do
you
have
thoughts
on
composability.
C
C
Just
registers,
whatever
the
method
said
it
does
by
default
and
then,
if
let's
say
someone
wants
to
build
connect2dp
with
timestamps,
they
would
define
a
capsule,
a
separate
capsule,
which
is
register
datagram
context
for
connect2udp
with
timestamp,
or
actually
you
can
even
forget
the
first
one
like
connect2dp
would
have
to
define
a
register
register
context,
which
means
just
plain
old,
udp,
payload
and
then
anytime,
you
have
a
new
format.
You
would
define
a
new
capsule
type.
G
That
would
work,
and
that
would
the
number
of
the
number
of
things
that
you're
looking
to
add
here
are
relatively
small
and
constrained.
Based
on
what
I'm
I'm
saying,
there's
there's
the
the
work.
That's
been
done
for
ip
compression,
potentially
there's
the
stuff
we're
using
potentially
in
in
quick
land
for
for
removing
connection,
ids
and
other
sort
of
things
that
would
be
redundant,
and
so
I
think,
there's
an
opportunity
here
to
just
just
simplify
a
little
bit.
That's
all.
C
But
that
makes
sense
I'll
have
to
like
kind
of
look
at
all
the
use
cases
we
have
and
one
by
one
and
see
if
it
works,
but
my
intuition
is
that
it
does
and-
and
I
agree
with
you-
that
fewer
inna
registries
is
a
good
thing-
not
just
for
that,
but
you
know
fewer
things
to
maintain
in
general.
Anyone
else
have
thoughts
on
this
all
right.
All
right,
I
guess
not
and
I'm
pretty
short
on
time.
So
all
right
lucas
go
ahead.
F
Just
quickly
to
say,
I
think
what
martin
proposed
sounds
very
similar
to
what
we
can
do
today,
but
cleaner
and
that
tidying
up
clothes
and
making
that
easier
is
sounds
like
a
good
thing
to
me.
C
Cool
thanks,
given
that
we
only
have
a
minute.
C
I'm
gonna
pick
one
issue
because
we
kind
of
already
discussed
a
little
bit
so
right
now
we
have
kind
of
a
weird
thing
where
so
you
know:
connect
udp
and
web
transport
have
things
in
common
they're
kind
of
our
first
two
main
use
cases
for
http
datagrams
and
one
of
them
uses
connect
udp
as
in
a
brand
new
method
and
the
other
uses
extended,
connect
which
is
regular
connect,
but
with
the
protocol
pseudo
header,
which
is
reminding
me,
how
do
we
do
that
for
http
one
and
so
both
of
those
work?
C
But
it's
kind
of
odd
that
we're
doing
different
things.
Should
we
do
something
about
that?
Is
it
fine.
M
K
K
Endpoint
is
a
proxy
connect
extended
connect
redefines
connect,
meaning
that,
instead
of
acting
as
a
proxy,
it
is
acting
as
an
actual
resource,
that
is
to
say
the
reason
it
is
called
connect
is
originally.
It
was
defined
for
websockets
and
you're
kind
of
proxying
to
your
like
real
websocket
server,
but
you
don't
have
to
be
proxying
like
this
is
a
resource
ss.
K
So
from
that,
this
is
the
reason
web
transport
uses
extended.
Connect
is
because
web
transport
is
also
that
kind
of
resource.
At
least
that
is
my
perspective
and
the
reason
I
wrote
the
original
draft
like
that.
C
That
makes
a
lot
of
sense
thanks
all
right
cause
zuho
go
ahead,
but
I
think
we
should
stop
after
because
we're
over
time
for
this
presentation
go
ahead.
N
Kazuo
my
point
that
I
made
in
the
previous
interview
that,
with
connect2dp,
we
have
a
interruption
with
existing
intermediaries
that
buffer
all
the
requests
prior
to
processing
it,
whereas
extended
connect,
goes
around
that
issue.
So,
regarding
the
interrupt
interoperability,
I
think
extended
connective
superior.
C
Okay
thanks:
let's
oh
I'm
realizing
we
don't
have
an
issue
number
for
this
specific
one,
yet
so
I'll
go
and
file
one.
Let's
keep
the
discussion
going.
There.
C
C
And
I
think
I'm
done
with
this-
let's
see.
B
Like
eric
nigrin
was
trying
to
talk,
I
don't
know
if
he
still
wants
to
or
not
he
was
popping
in
and
out
of.
C
O
Go
ahead,
eric
yeah,
I
was
just
gonna
say
that
the
it
looks
like
issue.
23
has
a
bunch
of
that
discussion
in
it
and
I
think
there
was
a
it
seemed
to
be
leaning
fairly
strongly
in
the
direction
of
using
something
more
like
an
extended
connect
and
and
and
actually
having
a
putting
more
of
the
information
in
the
path
rather
than
the
the
authority.
O
Pointing
out
that
that
it
would
actually
not
be
valid
http
to
do
to
to
use
connect
udp
the
way
the
draft
currently
specifies.
C
That
that
makes
sense
all
right.
So
let's
then
issue
23
it
is,
and
while
we're
there,
we
can
figure
out
the
the
scheme,
because
that
is
generally
required
as
well.
So
everyone,
if
you
have
thoughts,
please
jump
to
issue
23.
B
All
right,
thanks
david,
so
surprisingly,
on
time,
we're
gonna
now
transition
over
to
the
connect
ip
section
in
the
meeting,
I'm
gonna
try
and
join
or
share
the
chair
slides
one
moment.
B
C
B
Okay,
so
between
the
last
meeting
and
this
meeting
we're
trying
to
nail
down
specifically
what
problem
we're
trying
to
solve
with
the
connect
ip
piece
of
this
whole
working
group,
we
did
a
working
group
last
call,
and
you
know
solicited
external
reviews
from
various
areas,
for
you
know
just
the
purposes
of
getting
more
eyes
on
this
particular
document,
and
the
outcome
was
mostly
consensus
on
the
contents.
B
Therein,
with
a
couple
of
exceptions
in
particular,
there
was
one
use
case
that
was
sort
of
a
lack
consensus
across
everyone
who
chimed
in
and
then
there
was
one
additional
requirement,
I'm
forgetting
exactly
which
one
offhand-
but
I
probably
should
have
noted
here,
but
there's
one
additional
requirement
that
was
also
rather
or
didn't,
have
a
very
clear
consensus.
So
as
a
next
step
to
make
sure
that
we
have
sort
of
a
stable.
B
B
It
and
that'll
be
useful
for
us
and
trying
to
assess
or
just
make
sure
that
we
what
we
are
trying
to
solve
when
we
actually
embark
upon
you
know
the
assessment
of
the
ip
solutions
is
in
line
with
what
we
previously
agreed
upon.
B
With
that
said,
today,
we
have
two
proposals
on
the
table.
Both
helpfully
named
connect
ip
or
a
new
method
for
connect.
Ip
alex
is
going
to
talk
about
one
I
believe
mary's
going
to
speak
about
the
other
and
due
to
the
fact
that
these
are
very
similar.
Obviously,
in
terms
of
what
they're
trying
to
solve
the
the
hope
is
that
we
can
have.
You
know
two
just
two
presentations,
each
of
which
are
time
box.
B
Similarly,
similarly,
and
each
of
which
questions
for
will
be
restricted
to
or
ideally
restricted
to
sort
of
technical
clarification,
we
just
want
to
make
sure
that
we
have
sort
of
a
shared
understanding
of
the
proposals
on
the
table
and
then
afterwards,
when
we
sort
of
open
up
the
discussion
to
evaluate
sort
of
what
was
just
presented
and
to
figure
out
a
path
forward,
you
know,
then
we
can
start.
B
You
know
asking
more
high-level
questions
in
particular
eric,
and
I
would
like
to
encourage
folks
to
keep
in
mind
sort
of
two
very
high
level
general
questions
when
these
presentations
are
happening
in
partic,
first
of
which
is,
you
know,
which
of
the
options
a
or
b
or
both
satisfy
the
desired
use.
Cases
that
are
in
the
requirements
document
that
have
gone
through
that
has
gone
through
working.
B
Your
best
call,
the
second
of
which,
which
what
set
of
features
that
are
presented
are
essential
in
order
to
you
know,
satisfy
those
particular
requirements
and
those
use
cases
versus
optional
or
things
that
can
be.
B
You
know,
pulled
out
into
extensions,
and
what
have
you
and
we'll
once
the
presentations
are
done,
we'll
come
back
to
the
slide,
to
sort
of
again
help
frame
the
discussion,
but
I
I
imagine
there
will
be
very
lively
chatter
afterwards,
so
with
that
I'm
going
to
well
actually
with
that,
are
there
any
questions
about
sort
of
the
the
way
this
is
going
to
go.
B
B
Okay
hearing
none
I'm
going
to
stop
sharing
and
then
ask
that
alex
request
to
share
his
slides.
D
Hello,
everyone.
Can
everyone
hear
me?
Yes,
I
can
hear
you
so
for
people
who
don't
know
me,
I'm
alex
schranhofsky,
I
work
at
google
and
with
david
snydez
and
a
bunch
of
other
folks.
I
was
hoping
that
dallas
mccall
who's
worked
a
lot
on
the
ip
proxy
requirements
would
be
here
today.
D
But
to
my
knowledge,
he
had
other
commitments
and
could
not
be
I'm
here
to
present
a
draft
that
the
three
of
us
have
put
together
on
connect
ip,
which
is
our
instantiation,
that
we
are
proposing
of
taking
the
ip
proxy
requirements
that
we
had
been
working
on
for
the
last
few
sessions
and
trying
to
actually
start
an
implementation.
D
So
a
little
quick
overview
of
what
connect
ip
is.
The
goal
is
to
create
an
ip
tunnel
between
some
endpoints
and
this
itself
can
be
used
in
a
couple
of
different
ways.
One
example
would
be
sort
of
a
consumer
vpn
if
you
probably
have
watched
a
video
online.
You've
probably
seen
lots
of
people
talking
about
things
like
nordvpn
or
surfshark,
which
people
use
in
order
to
move
their
internet
connection
somewhere
else
use
it
while
traveling.
D
You
could
also
use
it
for
a
point-to-point
ip
tunnel.
So
this
is
something
where
you
might
imagine
having
containers
on
a
whole
bunch
of
different
nodes
that
want
to
securely
talk
to
each
other,
potentially
with
a
protocol
which
doesn't
inherently
have
its
own
security.
So
this
would
be
sometimes
called
an
overlay
mesh.
D
Another
useful
use
case
would
be
a
point
to
network
ip
tunnel
like
a
corporate
vpn,
where
you're
trying
to
go
and
connect
to
a
secure
environment.
For
your
for
your
work,
and
the
last
case
is
a
network
to
network
iptunnel
also
called
a
site-to-site
vpn,
where
you
might
have
multiple
parts
of
a
network
that
need
to
securely
connect
to
each
other.
Once
again,
with
protocols
which
may
not
have
inherent
security,
a
lot
of
these
use
cases
come
from
the
ip
proxy
requirements
draft
and
we're
not
going
to
spend
too
much
more
time
on
them.
D
So,
let's
sort
of
dive
into
what
we
think
we
need
for
our
solution.
Fundamentally,
we
believe
we
need
datagrams.
So
we
think
that
the
ip
packets,
sorry
nothing
we
we
are
spending
out
for
the
ip
packets
to
be
conveyed
using
http
datagrams,
either
the
quick
datagram
frame
or
from
the
previous
conversation
we
were
just
having
the
datagram
capsule.
D
D
Instantiation,
the
payload
will
be
a
full
ip
packet,
starting
from
the
ip
version
field
up
to
and
including
the
last
byte
of
the
ip
payload,
but,
of
course,
that
isn't
set
in
stone
any
extension
that
wants
to
support
additional
formats,
such
as
vip
compression
use
case,
which
has
been
described
a
couple
of
times,
can
register
these
additional
formats
using
the
registered
datagram
context
field
that
we
have
been
describing
in
http
datagram.
D
But
in
order
for
this
to
actually
work,
we
need
to
briefly
go
and
talk
about
forwarding
packets.
So
the
mental
model
here
is
that
connect
ip
endpoints,
effectively
act
as
ip
routers,
so
that
basically
means
that
when
they
receive
an
encapsulated
packet
in
the
mode
of
operation
where
we're
not
doing
anything
other
than
conveying
the
full
ip
payload.
So
obviously
this
would
be
subject
to
small
tweaks.
D
If
we
do
have
extensions
which
change
that
they
would
need
to
parse
the
ip
header,
they
would
need
to
check
any
local
policy,
such
as
source
address
validation,
which
is
to
say,
don't
allow
packets
or
something
like
that,
and
then
finally,
we
transmit
it
using
an
implementation
specified
mechanism
such
as
raw
sockets
and
in
the
reverse
direction.
If
we're
receiving
a
packet
which
is
bound
to
one
of
these
connect
ip
tunnels,
we
would
need
to
do
the
same
checks,
but
in
reverse,
rather
than
source
address
validation.
It
would
be
destination,
address,
validation,
for
example.
D
D
So,
in
order
for
this
to
be
functional,
though,
since
one
of
the
capabilities
that
we
have
is,
in
fact
ip
packets,
one
of
the
things
that
we
need
to
do
is
be
able
to
have
ip
addresses.
D
D
These
messages
are
pretty
straightforward:
they
merely
include
the
ip
version,
the
actual
bytes
and
the
prefix
length,
if
necessary,
the
prefix
length
is
allowed
actually
so
that
that
way,
this
address
request
could
actually
be
an
address
range
request,
which
is
particularly
useful
for
ipv6.
If
we
wanted
to
be
able
to
natively
support
things
like
ipv6
with
privacy
extensions,
we
could
support
requesting
an
entire
slash,
64
range
and
have
normal
ipv6
work
as
usual.
D
Obviously,
ipv4
address
is
scarce
and
I
suspect
that
almost
all
the
times
the
ipp
fixed
length
would
be
the
maximum
32
bits
there
and
by
the
way,
one
thing
which
we
do
explicitly
state
in
this
draft
is,
I
don't
believe
we
say,
there's
any
requirement
that
this
be
request
response.
The
address
assignment
could
be
immediately
responded
and
granted
by
the
server.
D
It
does
not
need
to
wait
for
the
client
to
request
for
it
ecker,
I
believe,
you're
in
the
queue.
M
I
just
want
to
note
like
I
don't
think
this
is
an
invalid
thing
to
do,
but
I
want
to
note
that,
like
it's,
what
the
reason
you
acquire,
it
is
because
you're
attempting
to
bridge
through
networks,
not
because
you're
attempting,
because
in
the
in
their
vpn
use
case
where
what
I
want
to
do
is
like
you
know,
is.
I
got
a
client
and
I
want
to
like
just
conceal
my
ip
address.
M
You
don't
need
to
do
that
because
you're
just
matt
so,
and
I
think
that
that
that
actually
tells
you
that
you
also
need
so
I
sort
of
like
like
register
that
point,
and
that
tells
you
you
definitely
need
a
range
because,
like
lots
of
network
bridging
cases
where,
like
you,
don't
have
a
single
ip
address,
we
have
a
whole
block.
So
I
just
want
to
like
just.
D
Like
clarify
that
point,
thank
you,
I
believe
that's
true,
but
I
I,
if
that's
specifically,
if
understood
correctly,
you're
talking
about
the
presence
of
the
prefix
length,
not
necessarily
the
presence
of
the
requests
and
assignment
messages.
I
believe
we
know
what.
M
D
Oh,
I
understand
I
think
in
that
mode
of
operation.
If
that's
all
you
want
to
do,
I
would
actually
suggest
that
you
not
use
connect
ip,
but
instead
use
connect,
udp
or
regular
connect,
because.
D
D
I
Yeah
just
just
to
comment
a
bit
on
what
ecker
was
saying
like
in
your
response.
I
do
think
that
for
that
use
case,
yes
using
connect
and
connect
udp,
it's
great!
That's
why
that's
what
we're
using
for
private
relay
and
stuff
like
that
right
now,
however,
you
know
there
is
a
good
use
case
for
doing
connect
ip.
I
Even
in
that,
let's
say
you
know,
I
wanted
to
be
able
to
say
you
know
ping
this
host
name,
and
in
that
case
I
really
do
not
care
what
address
I
have
or
even
the
address
of
the
other
side.
So
I
I
think,
that's
where
having
a
mode
in
which
we
are
not
required
to
request
an
address
and
assign
an
address.
Maybe
there's
just
a
default.
You
put
there,
maybe
there's
a
mode
where
it's
always
compressed.
I
think
that's
kind
of
what
the
other
draft
gets
to.
D
Okay,
I
I
think
I
see
the
the
point
you're
making
there
and
I
personally
feel
that
if
we
want
to
allow
a
mode
where
a
specific
implementation
is
always
overwriting
the
ip
header
to
provide
a
specific
address,
we
can
do
so.
I
don't
think
that
what
we
are
currently
proposing
here
precludes
that
we
simply
would
just
say:
don't
use
these
messages.
D
Perhaps
we
would
probably
want
to
add
another
message
to
say
that
you
intend
to
operate
in
this
mode
so
that
you
know
what
values
to
write
in
there,
I'm
personally
a
little
bit
worried
about
making
sure
we
get
the
os
security
correct
there,
because
normally
things
like
icmp
are
done
with
net
raw.
D
D
I
don't
think
there's
anyone
else
in
the
queue,
so
I'm
going
to
move
on.
One
of
the
other
things
that
we
believe
we
need
is
specifically.
If
you're
going
to
be
doing
something
like
a
vpn
corporate
vpn
or
consumer
vpn.
Is
you
need
to
know
what
destinations
you
can
you
can
reach
using
this?
One
pretty
typical
mode
is
that
you
want
to
go
and
put
most,
but
not
all
of
the
traffic
into
into
this
mode.
D
So,
for
example,
for
a
consumer
vpn
you're
not
going
to
want
to
tunnel
the
vpn
traffic
itself,
because
then
it
would
not
break
sorry
would
break,
and
you
also
presumably
don't
want
to
tunnel
the
local
rfc
1918
addresses
of
the
home
network
itself,
since
you
might
have
smart
devices
that
you
might
want
to
continue
to
work.
So
we
we
have
the
set
of
messages
for
route
advertisement,
route,
rejection
and
route
reset,
which
is
to
allow
the
peers
to
communicate,
which
routes
they're
willing
to
accept
the
endpoint.
D
It
does
not
need
to
actually
accept
these
routes.
They
could
choose
to
ignore
it
and
can
apply
any
sort
of
local
policy
here
so
like,
for
example,
if
a
client
wanted
to
say
to
a
server
hey,
I
want
to
go
and
announce
for
8.8.8.8
server
probably
can
and
should
reject
that
purge
local
policy,
since
we
probably
don't
want
to
allow
those
sort
of
hijacks.
D
So
what
do
these
messages
actually
sort
of
look
like
they're,
pretty
similar
to
the
ip
request,
ip
response
ones
that
we
had
before?
I'm
sure
you're
all
very
surprised
here.
Once
again
we
have
the
ip
version,
the
ip
address
and
the
prefix
length.
Here
we
need
it
to
be
a
prefix
like,
since,
in
fact
you
could
go
and
and
announce
that
you
are
willing
to
relay
traffic
on
behalf
of
a
portion
of
the
internet.
So,
like
one
potential
example
way
that
you
could
do
this.
D
D
I'm
not
going
to
convey
any
of
this
traffic,
so
you
could
go
and
have
these
two
advertisement
and
rejection
messages
in
that
order
and
implement
the
message:
exchange
required
for
consumer
or,
potentially
even
commercial
vpn.
So
that
sort
of
probably
brings
up
this
question
of
well.
D
Why
do
we
also
have
this
route
reset,
and
the
answer
for
that
is
that
internet
routes
change
over
time,
and
we
want
to
be
able
to
allow
these
long
lived
connections
to
take
these
updates,
with
the
way
that
we
currently
have
these
messages
structured,
a
rejection,
explicitly
says:
don't
route,
this
and
sort
of
undoes
the
route
advertisement
for
a
particular
range,
and
it
we
just
basically
added
the
route
reset
as
a
shortcut
rather
than
having
to
explicitly
say,
go
and
reject
any
previous
thing
that
we
have
had
which
allows
the
server
to
not
have
to
keep
track
of.
D
It
means
that
there
wouldn't
be
a
period
of
time
where
we
start
sending
like
internal
network
bound
traffic
to
one
of
these
mask
endpoints,
because
those
rules
would
be
installed
in
a
routing
table,
quote-unquote
atomically,
where
atomic
leaves
needs
to
be
implementation
defined.
Obviously
I
know
that
some
routing
engines
can't
install
such
rules,
but
in
terms
of
like
software
logic,
how
we
want
it
to
work,
that's
that
is
how
we
want
it
to
work.
D
Then
we
have
a
convenience
capsule,
which
is
just
shut
down,
which
is
to
help
provide
pure
information
as
to
why
we
are
telling
it
to
go
away.
This
is
analogous
to
the
go
away,
support
that
we
have
had
in
quicker
http
in
previous
iterations,
so
it's
primarily
intended
for
debugging.
So,
for
example,
you
could
imagine
a
server
going
and
saying
here:
server
is
going
away
or
for
for
maintenance,
or
maybe
connection
was
idle
too
long.
I
just
have
a
nice
convenient
thing
for
debugging
here.
D
So
now
I
think
it's
sort
of
time
to
talk
about
extensibility,
since
we
have
talked
about
not
too
many
different
capsules
or
potentially
steam
trunks.
If
we
go
back
to
that,
so
there's
a
couple
different
ways
that
we
can
go
and
extend
connect
ip
in
this
proposal
we
can
use
http
headers,
we
can
use
the
capsule
types
or
we
can
use
the
datagram
context,
extensions
and
there's
a
couple
different
ways
of
doing
this.
D
This
port
put
that
in
for
me
when
we
go
and
send
these
payloads
and
that
sort
of
allows
us
to
do
all
sorts
of
different
things
using
sort
of
these
existing
mechanisms
we're
not
in
connect
ip
at
least
inventing
another
extensibility
point.
We
intend
to
use
the
ones
which
we've
already
been
discussing.
D
B
B
P
Okay,
let
me
try
to
rearrange
my
slides
here
in
a
useful
way:
okay
yeah.
So
this
is
the
other
proposal,
and
the
main
change
we
did
with
our
latest
update
is
that
we
now
have
two
kind
of
modes:
one
we
call
tunnel
mode
and
the
other
one
we
call
flow
forwarding
mode
and
tunnel
mode
is
to
support
the
case
where
the
vpn
case,
or
also
maybe
the
network
network
case
where
we
actually
have
a
full
packet
with
the
ip
header
that
we
forward.
P
Then
the
proxy
only
inspects
the
tcp
packet,
the
ip
packet,
sorry
and
and
checks
the
source
and
ip
address
the
source
and
the
destination
ip
address
confirms
that
this
is
allowed
for
the
trusted
client
and
then
just
forwards,
the
packet
as
it
is,
and
then
in
the
the
second
mode
we
have
is
the
flow
forwarding
and
that's
the
mode
that
we
already
had
in
the
draft
before
and
that's
where,
like
the
client,
actually
requests
a
connect
ip
basically
on
a
per
flow
basis,
but
it
actually
doesn't
have
to
be
like
one
street
end
to
end
connection
could
be
multiple,
but
the
idea
is
that
you
send
one
connect
ip
request
per
flow
and
you
so
that
means
you
provide
like
one
specific
target
server
that
you
want
to
send
this
to.
P
So
this
means
also
that
it's
not
possible
to
establish
this
flow
from
outside.
It
has
to
be
the
client-
and
in
this
case
it's
it's
super
easy
because
it's
also
very
similar
to
connect
udp
effectively
and
it's
easy
to
reduce
the
overhead
by
by
creating
the
ip
header
at
the
proxy.
So
this
is
now
the
two
modes.
We
propose
to
go
a
little
bit
more
into
detail.
P
P
But
the
idea
of
what
we
have
currently
in
the
draft
is
that
in
tunnel
mode,
the
client
would
send
a
connect
ip
request
and
providing
the
ip
address
of
the
proxy
here
in
the
authority
field
and
there's
one
ip
header
that
is
required,
which
is
providing
the
ip
version
and
then
in
this
example
the
the
client
didn't
request.
A
certain
ip
address,
or
I
appear
address,
range
to
be
used,
and
so
the
proxy,
in
his
its
require,
will
actually
provide
the
the
assigned
ip
address
to
the
client.
P
P
P
P
For
example,
we
have
an
additional.
We
also
propose
in
the
draft
an
additional
header
which
is
called
ip
address
handling,
so
this
header,
for
example,
can
if
you,
if
you
open
a
second
connect
ip
request
for
another
flow,
for
example,
you
could
tell
the
proxy
that
it
should
use
the
same
out
facing
ip
address
for
that
or
a
different
one,
and
then
we
also
have
another
optional
header
defined
in
the
draft,
which
is
called
con
id,
and
this
is
to
provide
additional
information
for
flow
mapping.
P
So,
instead
of
just
using
the
source
and
ip
address,
if
you,
you
know,
have
multiple
flows
to
the
same
target,
you
can
actually
provide
another
field
that
could
be
used
for
mapping.
So
that
could
be,
for
example,
the
quick
connection
idea.
It
could
be
port
numbers
or
whatever
it's
actually
a
part
to
the
proxy,
but
it
makes
the
mapping
easier.
P
So
this
is
like
how
the
two
methods
basically
work.
We
have
much
more
details
on
the
draft,
but
this
is
just
like
the
rough
overview
about
these.
These
two
modes.
We
have
a
little
bit
of
text
about
ic
icmp
handling
for
flow
forwarding
mode
because,
as
you
as
you
don't
provide
the
ip
header
in
this
case,
you
actually
need
to
use
context
ids
for
providing
icmp
messages
and
we
don't
provide
all
the
details,
but
we
discuss
how
to
use
context
ids
for
that.
So
that's
like
one
really
nice
use
case
for
context
ids.
P
We
didn't
specify
it
fully
because
we
were
not
sure
about
the
negotiation
and
how
all
the
details
work.
So
there's
more
work
to
be
done
and
then
another
example
for
a
use
of
context.
Ids
is
ecn
support.
This
is
also
something
we
discuss
a
little
bit
in
the
draft,
but
actually
for
ecn
support.
P
M
P
Q
Q
M
So
just
to
see,
if
I
okay
so
just
to
see,
if
I
can
recap
like
I
say,
give
me
an
ip
address,
it
gives
me
an
external
external
ip
address
that
is
selected
and
yeah,
and
I
put
that
in
all
my
packets
right,
yeah.
Okay,
thank.
P
You,
okay,
so
yeah,
so
to
maybe
just
like.
What's
the
main
message
here
is
that
what
we
propose
right
now
is
the
connected
pimento
that
can
can
have
these
two
different
modes
and
therefore
support
different
use
cases
in
different
ways,
most
appropriately
and
the
tunnel
mode.
P
We
in
the
draft
say
this
requires
more
trust
to
the
client,
so
the
assumption
is
really
that
the
client
is
known
to
the
proxy
and
the
client,
and
the
proxy
knows
like
if
the
client
requests
a
certain
ip
address
or
peer
address
range
that
the
client
is
allowed
to
use
that
we
don't
have
any
kind
of
route
negotiation
here,
because
the
assumption
is
also
that
the
proxy
might
know
which
which
targets
the
client
is
allowed
to
to
to
connect
to
and
like.
P
We
just
assumed
that
this
information
is
currently
that
this
information
is
like
negotiated
outside
the
protocol
or
pre-known
pre-configured
or
whatever,
or
it
could
be
an
extension
in
the
future.
But
it's
not
here
in
the
base
version
of
the
draft
so
and
in
flow
forwarding
mode.
This
is
actually
very
similar
to
connect
udp,
just
like
just
like
for
other
traffic
as
well.
P
Not
only
for
udp
traffic,
and
so
this
is
how
we
propose
it,
because
it's
like,
if
you
have
connect
udp
like
you,
have
mostly
implemented
this
already,
and
it
actually
can
produce
packet
overhead,
and
so
basically,
what
you
need
in
addition
to
to
connect
udp
is
just
knowing
what
the
protocol
layer
number
is
and
that's
it,
and
then
you
use
the
same
methods
as
for
connect.
Udp,
basically,.
C
Clarifying
question:
thanks
for
the
presentation,
so
in
terms
of
like
what
what
the
chairs
were
saying,
we,
we
got
some
consensus
in
the
working
group
to
that.
We
needed
to
solve
the
first
three
use
cases
described
in
iproxy
requirements,
that
was
consumer,
vpn,
point-to-point
connectivity
and
point-to-network
connectivity.
C
C
How
does
your
draft
address
that
use
case?.
P
So
that
would
be
the
classical
tunnel
mode.
Basically
this
rate,
so
you
just
connect
to
the
proxy.
You
open
a
tunnel,
you
don't
provide
any
kind
of
target
information
or
whatever,
and
you
can
and
you
get
a
sign,
get
an
ip
address
assigned
by
the
proxy
which
is
the
out
facing
ip
address
and
everything
and
you
can
just
send
to
any
endpoint
on
that
network.
The
the
proxy
is
connected
to
and
anything
that
gets
sent
to
this
ip
address
is
also
forwarded
to
you.
C
P
C
That
I
mean
that's
not
what
point
to
net
any
point
to
network
solution
does
today,
if
we're
talking,
you
know
ipsec
or
things
like
that,
so
that
that
seems
like
a
miss.
But
okay,
thanks
for
the
thanks
for
the
answer.
M
So
I
think
I
mean
could,
could
you
motivate
the
the
the
flow
forwarding
from
each
a
little
bit
more
like
is
this
primarily
about
you
know,
is
primarily
about
like
packet
size
like
what's
the
sort
of
like
like
primary
renovation.
For
this.
P
So
it's
wait.
This
slide,
as
I
said,
it's
just
very
similar
to
connect
udp,
and
so
it
it
needs
like
a
minor
additional
information,
and
then
you
can
use
that
and
you
get
the
the
packet
reduction.
So
it's
not
it's
like.
Why
not
doing
it
right
and
it's
for
all
those
use
cases
where
you
actually
want
to
handle
things
on
a
per
flow
basis
or
on
a
connection
on
a
per
target
basis.
That's
it.
M
Yeah,
I
think
I
think
so
maybe
maybe
arguing
so
like
I'll,
try
one
more
time,
but
then
I'll
stop
like
I,
I
guess,
as
an
implementer
of
this,
I'm
just
trying
to
understand
how
to
like
like
like
why
why
it's
why
it's
beneficial
to
me,
like
you
know
if
like
if,
like
what
I'm
doing,
is
like
an
ip
doodad
and
I
don't
want
to
use
connected
udp,
I
mean
I,
I
was
a
discussion
I
guess
earlier
like
about
like
like,
if
I'm
not
using
connected
udp,
what
why
like?
I
P
R
Hi,
I
have
a
quick
clarification
question:
do
you
need
to
maintain
connection
status
on
the
proxy.
P
P
The
out
facing
ip
address
of
the
proxy
should
bring
you
to
the
right
proxy,
and
if
you,
if
you're
in
tunnel
mode
and
you
use
an
ip
address
of
your
choice,
then
you
should
only
open
that
tunnel
to
one
proxy.
I
guess.
I
My
next
thank
you.
Yes,
so
just
to
reply
to
ecker's
point
and
mary.
Let
me
know
if
this
is
correct
for
thinking
about
the
flow
forwarding
mode,
because
actually
the
flow
forwarding
mode
sounds
very
attractive
to
me
for
kind
of
like
the
client
privacy
proxy
mode.
I
You
know
not
not
a
full
vpn,
I'm
trying
to
get
on
my
internal
corporate
network,
so
one
difference
I
do
see
here
is
that,
unlike
a
vpn
and
unlike
the
case
where
I
have
to
get
assigned
an
ip
address
like
I
may
not
want
to
have
a
single
ip
address
assigned
to
my
client
because,
like
I
may
not
want
to
have
inbound
connections
for
security
reasons
or
like.
I
I
don't
want
this
to
be
a
new
way
to
get
to
me
and
like
what
we're
doing
for
connect,
udp
and
connect
with
our
private
relay
like
we
are
sharing
an
ip
address
between
many
many
clients
intentionally
to
have
better
anonymity.
When
we're
doing
things
so
being
able
to
say,
I
just
want
to
connect
to
target.example.com,
and
please
put
me
on
an
address
that
other
people
can
use
that
I
have
no
claim
over
is
an
attractive
property.
So
I
don't
want
to
lose
the
ability
to
do
that
and
then
so.
I
But
let's
say
that,
like
I'm
picky
about
my
congestion
control
end
to
end
or
I'm
trying
to
do
some
new
tcp
option,
then
I
could
just
do
connect
ip
and
put
tcp
frames
over
it,
but
I
think
realistically
I
would
use
this
mode
for
if
I
do
want
to
be
able
to
use
ping
or,
like
you
know,
right
now,
our
system,
apis,
we
let
people
do
custom
ip
protocols
and
maybe
that's
esp,
but
maybe
it's
something
else,
and
it's
not
really
a
fully
fledged
solution
for
how
you
want
to
access
external
sites
until
you
allow
those.
P
Yeah,
that's
exactly
one
of
the
use
cases
and
the
the
point
also
about
using
this,
which
is
like
very
similar
to
connect
udp
and
not
using
the
traditional
connect
is
like,
as
you
say,
it's
like
a
complete
end
to
any
connection.
So
maybe
you
have
different
controls
about
congestion,
but
it's
also
it's
like
very
similar
in
the
way
you
use
it.
So
it's
very
easy
to
just
switch
from
one
to
the
other.
P
C
Cool
yeah
thanks
so
I'm
I
mean
it
is
somewhat
of
a
clarification,
but
I
think
maybe
a
segue
into
discussion.
I'm
I'm
very
confused,
so
the
tunnel
mode
you
describe
is
kind
of
like
doesn't
seem
fully
specified
in
your
document.
C
It's
good
that
you
added
that
in
the
last
revision,
but
it
really
sounds
like
your
document's,
focusing
on
the
sorry
on
the
flow
on
the
flow
mode,
and
that's
like
the
majority
of
the
text
in
your
document,
and
I
have
a
hard
time
understanding
what
problem
the
flow
mode
solves,
because
I
think
like,
for
example,
tommy's
idea.
There
just
sounds
like
what
you
want
is
a
mat
and,
from
you
know,
the
implementation
of
every
kernel
on
the
planet.
C
It's
a
lot
easier
to
have
like
rfc
1918
space
from
you
to
the
vpn
server,
and
then
in
that,
that's
like
how
everything
works
these
days
and
if
you
don't
have
apple's
crazy
users
paid
networking
stack,
that's
kind
of
what
you
have
to
do
so,
maybe
help
me
understand
like
if
we,
you
know,
maybe
up
level
the
conversation
a
bit
of
what
use
cases,
what
things
that
we
you
know
are
in
ip
proxy
requirements.
Does
the
payload
mode
solve
specifically.
P
Sorry,
yeah
yeah,
so
it's
it's
an
ad
functionality,
but
this
gives
you
control
about
it
right.
Usually
it's
not
the
client
that
can
actually
select
the
app
address
or
provide
any
kind
of
hints
about
which
address
they
want
to
use
or
not.
So
this
gives
you
control
about
it
and
also
having
a
way
to
handle
per
flow
flows
and
flows
on
a
per
flow
basis
means
you
can
actually
provide
additional
signaling
or
optimizations
for
each
flow,
if
requested.
So
that's
some
of
the
use
cases
that
are
very
interesting
for
us.
O
C
What
I
so
that
I
can,
I
have
a
hard
time
understanding
these
cases,
but
especially,
are
those
in
the
list
that
we've
been
discussing
at
the
as
a
working
group
in
ip
proxy
requirements.
Are
those
something
separate
that
you're
interested
in?
I
think
that's
fine,
but
I
just
that's
what
I'm
asking
to
clarify.
P
C
I
mean
so
you
know,
I
guess
the
point
that
I'm
getting
to
is
like
we.
If
we're
discussing
about
you,
know
picking
a
proxy
solution
where
we're
going.
I
think
you
know
the
focus
should
be
on
the
use
cases
that
we
agreed
on
as
a
working
group.
C
But
that's
why
you
know
in
our
draft
there
are
things
about
network
to
network
that
we
decide
as
working
wasn't
to
focus,
so
that
makes
sense
that
I'm
all
right,
you
know
backing
up
on
those
things,
but
it
sounds
like
for
you
for
your
doc
unless
I'm
misunderstanding
and
that's
why
I'm
asking
these
questions,
which
maybe
I
am
it's
like
the
use
cases
that
you
really
are
describing
that
you
care
about
the
most
sounds
like
things
that
aren't
in
like
what
we've
been
agreeing
to
work
on.
Unless
I'm
listening,
I
don't.
P
C
The
point-to-point
use
case
isn't
what
you're
describing
point-to-point
use
case
in
ip
requirements
is,
when
you
have
think
ipsec
the
opposite
of
tunnel
mode,
I'm
blanking
on
it!
Sorry,
where
your
your
end-to-end
connections,
let's
say
your
tcp
is
from
your
ipsec
client
to
your
ipsec
server.
There's.
C
P
It
would
be
a
modified
version
of
this
consumer
would
be
end
use
case,
but
you
could
see
it
like
this.
If,
if
that's
where
you
want
to
move
in
future
right,
so
it's
it's.
It
provides
you
an
ability
to
connect
to
targets
outside
in
an
outside
network,
but
it
provides
some
flow
awareness
to
the
proxy
which
allows
you
to
provide
additional
optimizations
at
the
proxy.
If
requested,.
C
P
I
I
just
want
to
comment
on
this.
You
said
like
most
of
the
text
in
the
draft
is
about
this
flow
mode,
so
you're
right
that
we
just
added
the
tunnel
mode.
So
there
are
like
maybe
a
bunch
of
details
missing,
but
it's
also
the
case
that
for
the
flow
forwarding
mode,
I
think
we
have
a
lot
of
redundancy
with
the
connect
udp
draft.
So
it's
not
like
it's
more
com.
It's
it's
in
some
sense
more
complex.
I
All
right,
I
guess
david,
I
I
I
think,
you're
getting
a
little
bit
hung
up
on
the
process
here,
and
I
I
get
that
you
want
to
defend
kind
of
the
approach
your
draft
is
taking.
So
one
thing
I
would
say
is
for
the
full
tunneling
perspective.
I
That's
very,
very
good.
We
don't
want
to
lose
that
at
the
same
time,
it
has
a
very
it's
adding
a
lot
of
complexity.
I
You
could
build
with
a
more
complex
negotiation
where
I
have
to
get
an
address
assigned
to
me
and
it
happens
to
be
a
private
address
and
I
hope
the
thing's
doing
in
that
for
me
and
then
I
do
all
these
other
steps,
but
it
would
be
great
because
when
we're
not
talking
about
just
requirements,
but
we're
actually
talking
about
the
protocol
solutions
to
be
able
to
have
a
version
of
the
solution,
that
does
look
more
like
the
flow
forwarding
mode
for
the
clients
that
want
the
simpler
just.
I
want
to
forward
through
a
nat.
I
Being
able
to
connect
to
something
by
a
hostname
not
have
to
do
a
dns
lookup
not
have
to
wait
for
an
rtt
of
getting
assigned
an
address
in
order
to
be
able
to
send
a
query
like
those
are
very
important
things
for
reducing
latency,
and
maybe
those
didn't
show
up
in
the
requirements
document.
But
they
are.
I
You
know
important
for
the
real
world
usages
of
this
when,
when
this
flow
is
not
a
full
vpn,
but
maybe
it's
just
a
very
short,
live,
I'm
doing
a
ping
to
somewhere.
So
I
guess.
L
I
But
let's
not
just
dismiss
what
the
simplicity
of
this
flow
forwarding
case,
because
otherwise
I
think
you're
making
this
more
complex
and
losing
out
on
a
lot
of
things
that
I
actually
that's
the
main
use
case.
I
would
find
attractive
to
adopt
far
more
than
any
of
the
other
stuff.
C
I
C
We
decided
to
do
with
this
working
group
like
I
would
have
been
fine
jumping
into
solution
building.
We
decided
to
do
this
requirements
and
we
landed
and
had
some
consensus
here
and,
like
you
know,
I'm
the
last
person
to
throw
process
on
the
table.
But
you
know
if
we
decided
to
do
this
exercise
together,
there's
a
reason
for
that.
So
I'm
just
trying
to
understand
what
this
specific
adds
over
connect
and
connect
udp,
but
you
know
happy
to
take
it
offline.
I
just
please
don't
I'm
not
trying
to
be
dismissive
here.
P
Yeah,
I'm
really
just
also
hoping
that
we
converge
here
to
a
common
document,
rather
than
just
like
adopting
one
solution.
It's
running
either.
N
D
I
actually
just
checked
with
ecker,
because
I
want
to
answer
tommy
directly,
and
he
said
I
could
so
one
thing
tommy
that
I
I
do
want
to
say
is
in
in
the
uk
that
you
described.
It
is
unfortunate
that
we
did
miss
it
when
we
were
doing
the
requirements
gathering.
I
would
definitely
like
to
better
understand
what
you
would
like
to
do
and
the
sort
of
flow
that
you
were
describing,
because
I
think
that's
actually
different
than
the
way
we
were
previously
envisioning,
the
flow
mode.
D
That
myriad
is
describing
and
I
do
see
value
in
supporting
it.
The
thing
which
I'm
a
little
bit
unsure
about
in
understanding
how
it
fits
in
is
usually
things
like
these
pings
and
whatnot
are
done
by
os
kernels.
D
I
very
much
would
like
to
know
how
we
can
support
it,
because
one
of
the
things
which
I
believe
we
have
done
well
in
the
draft
that
from
the
google
side
have
been
presenting
here,
is
actually
the
complexity
is
fairly
limited.
D
I
think
that
the
messages
and
we
described
in
the
capsules
there
like
they,
don't
actually
enforce
a
particular
flow,
and
I
think
that
we
actually
do
have
the
flexibility
to
build
a
solution
which
provides
the
capabilities
that
work
well
for
tunneling
and
flow
forwarding
if
we
also
understand
these
latency
requirements
and
what's
generating
these
packets
and
just
in
general,
how
we
expect
it
to
work.
I
very
much
understand
and
appreciate
the
desire
to
have
a
like
shot
flight
mode,
which
gets
all
this
done
and
I
believe
we
can
build
it.
M
This
is
actually
a
clear
front
question,
I
hope,
and
maybe
a
comment
so
if
I
just
I'm
sorry
to
be
going
back
to
this
point
I
asked
earlier,
but
so
if
I
just
want
to
do
a
ping
right,
I
do
not
actually
need
the
assigned
ip
address
correct,
so
I
just
say:
connect
ip
to
wherever
the
heck
I
want
to
go
and
I
can
chase
that
with
the
ping
directly
and
I
don't
take
a
run
trip.
Does
it
and
the
ipad
address
is
like
just
informational
acting
indoors?
Is
that
correct.
M
Well,
I
mean
I
think
this
is.
This
is
a
really
important
question,
because,
because,
if
I
take
a
round
trip
in
order
to
in
order
to
do
this
and
as
much
as
attractive,
so
I
think,
like
it's
important
understand
whether
or
not
like
do
I
have
any
like
do
I
like.
Do
I
have
to
format
like
like?
Do
I
have
any
useless
ip
address?
If
I
don't
care
what
that
what
it
actually
is.
P
So
in
flow
forwarding
mode,
you
definitely
can
send
zero
rtt
data
and
you
can
just
send
your
ping
out
directly.
I
guess
you
could
also
in
even
internal
mode.
You
could
send
out
data
directly
if
you
write
the
ip
address
depending
on.
I
don't.
D
So
ecker,
I
think
my
question
is:
what's
processing
the
ping
response.
If
it's
a
host
kernel
in
in
today's
operating
systems,
the
ip
address
is
required
in
order
to
be
able
to
associate
that
this
is
an
I
icmp
ping.
Responsive
is
destined
to
you
if
it's
some
sort
of
user
space
stack,
which
is
what
tommy
was
implying-
and
there
is
some
work
on
the
proxy
which
is
ensuring
that
only
the
response
which
is
destined
for
you
is
coming
back
to
you
then.
Yes,
I
agree.
D
It
is
possible
to
not
need
to
care
about
the
ip
address,
but
at
that
point
what
we
were
basically
creating
is
something
which
is
less
connect
ip
and
more
like
connect
pain,
which
we
could
do.
But
that's
sort
of
why
I
was
saying
earlier.
I
want
to
better
understand
what
network
stack
is
producing
these
things.
M
Well,
I
think
I
think,
there's
the
question.
Maybe
I
was
just
being
strong,
but
not
caring
about
it,
but
I
I
guess
you
know
the
case.
M
What
I'm
trying
to
avoid
is
taking
an
extra
round
trip
in
order
in
order
to
do
this,
because
it
seems
it
seems
to
me
it
seems
to
me
like
if
I
look
at
these,
if
I
look
at
these,
if
I
compare
these
mechanisms
right,
it
seems
to
me
that
the
the
the
thing
tommy
was
advocating
for
was
the
ability
to
guarantee
that
you're
you're
having
a
unc
unlikable
ip
address
for
this
transaction
from
previous
transactions,
and
that
is
not
a
and
that's
not
a
present,
and
that
isn't
saying
that
is
guaranteed
by
a,
but
by
sort
of
a
classic,
like
you
know,
pin
up
a
vvn
unless
you
have
some
like
some
some
configuration
setting.
M
That
says
you
know
that
says
I
want
this
and
then
you
have
to
identify
which
flow
is
which
right.
So
that
seems
like
the
attractive
property,
but
if
I
have
to-
and
so
if
it's
one
thing
to
be
like
it's
one
thing
to
be
like
well,
the
iphone
will
come
back
pretty
soon
and
it'll
probably
beat
the
ping,
and
if
not,
I
can
like
hang
on
a
thing
for
a
little
while
and
it's
quite
another
to
be
like,
I
gotta
absorb
a
full
run
trip
with
marketing
instead
of
backup.
M
Those
are
like
two
really
different
things
right,
so
I
I
I
guess
so
that
now
I
am
in
comment
mode.
You
know-
and
I
think
I
I'm
gonna
I'm
sort
of
like.
I
guess
I
think
we're
really
out
of
out
of
time
so
like,
but
you
know
the
chairs,
I
think,
need
to
do
some
work
here.
M
Well,
I
do
not
want
to
spend
the
next
next
six
months
with
everybody
taking
the
pieces
that
they
are
attracted
from
their
proposal
and
ending
up
two
proposals,
they're
very,
very
similar
and
then
it's
having
to
like
like
go
on
back
and
forth.
That
is
an
awful
outcome.
It
seems
to
be
that
people
recognize
that
there
are
pieces
of
each
puzzle,
some
more
developed
than
the
other,
and
you
know
so
perhaps
you
can
find
a
way
forward.
E
Right,
we
are
cheerfully
at
time.
Thank
you
all
for
a
really
nice
discussion
there.
I
expect
we
will
want
to
continue
that
significantly
on
the
list
and
one
of
the
other
things
that
we're
gonna
start
a
discussion
about
on
the
list
is
how
we,
as
a
group,
would
like
to
go
around
kind
of
moving
forwards
with
merging
solutions
here
or
picking
one
or
the
other,
and
and
making
sure
that
we're
all
happy
with
with
the
criteria
by
which
we
move
things
forwards,
so
we're
gonna,
we're
gonna
start
some
discussions
on
that.
E
Please
continue
discussing
this
on
the
list.
Sorry
lucas,
for
our
time
not
permitting,
but
that
is
the
permitting
part,
feel
free
to
send
a
summary
or
anything
like
that
to
the
list.
I
suspect
folks
would
be
interested
in
in
some
of
the
content
that
would
in
your
slides,
having
looked
through
them
briefly
myself,
and
with
that,
thank
you
all
for
coming
and
we
will
see
you
on
the.