►
From YouTube: IETF115-MASQUE-20221109-0930
Description
MASQUE meeting session at IETF115
2022/11/09 0930
https://datatracker.ietf.org/meeting/115/proceedings/
A
A
B
B
B
A
A
A
Welcome
to
mask
at
ietf
115.,
this
is
yet
another
session
that
is
being
recorded
at
this
point
in
the
week.
You
probably
know
how
to
do
this,
but
if
you
don't
use
the
QR
code
over
there
to
bring
up
the
on-site
tool
if
you're
in
the
room,
if
you're
not
in
the
room
and
you're
hearing,
this
you've
already
figured
that
much
out
and
you
can
enter
the
queue
by
raising
your
hand,
leave
it
by
lowering
your
hand
and
when
it's
time
to
speak,
please
do
speak,
State
your
full
name
before
speaking.
A
A
A
We're
then
going
to
work
our
way
towards
discussing
some
proposed
text
for
a
recharter
and
on
the
way
to
that
we're
going
to
run
through
a
fairly
long
list
of
other
proposed
extensions
and
additional
work
and
part
of
the
goal
of
this
is
to
take
a
look
at
these
items
and
say:
where
do
we
draw
this
line?
Where
do
we
say?
A
Now
some
of
them
are
new
before
we
do
that,
however,
connectip
is
our
last
remaining
item,
because
our
first
two
items
are
now
actually
rfcs,
so
huge
congratulations,
9297
is
HTTP
datagrams
in
the
capsule
protocol
and
92.98
is
connect
IP,
which
we
named
proxy
and
UDP,
and
IP
and
http
so
very
nicely
done.
Thank
you
to
everybody
for
all
of
the
awesome
feedback
and
super
hard
work
and
yeah.
Let's
give
ourselves
a
hand.
A
With
that
Alex
I
believe
you
are
up
with
connect
IP.
C
Hello,
everyone
can
you
hear
me:
okay,
excellent
I
am
Alex
tremachowsky
I'm,
one
of
the
co-authors
of
the
mass
connect
IP
draft
I
expect.
None
of
you
are
surprised
to
see
that
we
are
presenting
this
today,
because
we've
been
talking
about
it
for
the
last
couple
of
sessions
next
slide,
please
so
I
wanted
to
start
out
by
talking
about
our
progress
from
the
hackathon.
C
This
is
very
cool.
Unfortunately,
our
friends
at
Apple
did
not
have
a
server
implementation
for
us
to
test
against,
which
is
why
the
Apple
column
is
all
gray
boxes,
but
you
know,
given
the
fact
that
we
had
three
clients
and
two
servers.
I
think
this
is
amazing.
Progress.
C
So
what
actually
enabled
us
to
get
here
is
if
you
actually
go
and
look
at
the
GitHub
issues
prior
to
this
session
at
the
end
well
sort
of
two
weeks
after
ietf
114
in
Philadelphia,
we
had
about
seven
issues
that
were
open
and
we
were
discussing
as
a
result
of
that
meeting
and
I
am
very
pleased
to
say
that
all
seven
of
them
are
currently
closed,
meaning
that
there
are
no
outstanding
issues
on
the
draft,
so
I'd
like
to
go
through
and
detail
what
all
of
these
different
changes
were
next
slide
please.
C
So
the
first
thing
was
around
MTU.
One
of
the
things
which
is
very
interesting,
of
course,
is
that
MTU
tends
to
be
both
a
hop
by
hop
but
also
end-to-end
property,
and
when
we
add
all
of
these
different
layers
of
encapsulation,
we
are,
of
course
are
taking
away.
The
MTU
IPv6
of
course
specifies
that
we
want
to
have
a
minimum
of
1280
byte
MTU.
So
we
have
some
interesting
questions
about
what
to
do.
C
If
you
cannot
cannot
support
that,
so
one
of
the
things
that
we
added
was
some
text
that
clarified
that
the
icmpv6
method
that
we
described
that
was
previously
optional,
must
be
used
when
intermediaries
are
in
use.
Unless
you
have
out-of-band
information,
but
the
path
MTU
is
sufficient.
We
also
added
a
bit
of
text
that
says
that
you
must
abort
a
connect,
IP
stream,
if
the
quick
MTU
does
not
allow
sending
1280
bytes
if
you're
using
IPv6,
so
this
basically
clarified
a
whole
bunch
of
different
edge
cases
that
previously
were
there.
C
Of
course,
if
you
want
to
use
streams,
that
would
be
fine.
You
just
can't
do
this
over
datagrams
next
slide,
please.
We
also
clarified
some
details
around
some
icmp
errors.
So
previously
we
just
had
a
small
paragraph
in
the
document
that
said:
go
look
at
RFC
4443
and
didn't
really
provide
any
additional
information
as
to
how
you
would
actually
use
the
information
in
4443
in
these
contexts.
C
So
after
working
group
pointed
this
out,
we
went
back
and
added
some
text.
That
said,
you
know,
go
look
at
792,
look
at
4443
and
here's
some
specific
guidance
on
which
error
codes
to
use
when,
for
example,
you
get
an
invalid
Source
address
or
an
unwritable
destination
or
practice
cannot
fit
inside
the
MTU.
C
We
also
added
another
clarification,
which
is
one
that
came
up
from
Philadelphia
last
session,
which
was
what
happens
if
you're
using
iproto
scoping
with
connect
IP
and
you
haven't
asked
for
icmp
packets
we've
said
well,
you
probably
should
you
should
ask
for
icmp
and
we
also,
but
you
also
need
to
be
prepared
to
also
receive
them.
If
you're
not
using
any
route
advertisement
capsules,
then
there
are
some
recommendations
in
the
text
for
how
they
connect.
C
C
Another
feature
that
was
added,
which
was
found
when
we
were
working
through
this
as
a
previously
connect
IP.
The
address
request,
capsule
basically
provided
a
mechanism
for
you
to
say,
I
want
this
specific
IP
address
or
this
specific
subnet,
but
it
didn't
have
a
way
for
easily
specifying
we'll
just
give
me
an
address,
but
it
turns
out.
This
was
already
something
we
had
planned
ahead
for,
but
we
had
just
forgotten
to
write
text
on
you
basically
go
and
request
the
all
zeros
address
with
a
subnet
mask
of
the
desired
size.
C
So,
for
example,
if
you're
an
ipv4
and
you
want
an
entire
slash,
24
subnet,
you
would
ask
for
0.0.0.0
24
and
the
server
would
give
you
back
some
slash
24.
If
it
had
one
available.
This
is
obviously
much
more
usable
in
IPv6
land
than
it
is
an
ipv4
land.
But
hey
you
can
ask
for
individual
addresses
the
same
way
as
always
a
mass
connect.
Ip
Server
doesn't
need
to
respond
to
you
successfully.
With
this
request,
it
is
always
allowed
to
say
well.
C
C
Another
issue
which
was
quite
contentious
at
114
was
the
cross
product
of
the
fact
that
you
can
have
unsolicited
address
assignment
capsules
be
sent,
but
also
that
we
don't
necessarily
guarantee
a
reply
to
any
sort
of
IP
address,
request,
capsule
and
also
what
happens
if
you
need
some
address
which
you
do
in
order
to
send
any
amount
of
packets
and
Martin
Thompson
rightly
pointed
out
that
this
probably
means
you
have
to
wait
for
a
timeout
in
the
current
scheme
in
order
to
be
able
to
start
sending
your
first
flight.
C
So
after
a
lot
of
back
and
forth,
we
concluded
about
the
best
way
to
fix
this
was
to
add
requests
and
response
IDs
to
these
capsules,
so
that
that
way
you
can
tell
which
address
assignment
response
correlates
with
the
different
requests
that
you
send.
So
now
you
can
easily
tell
apart.
Oh,
the
server
sent
me
an
unsolicited
address,
assigned
that
I
didn't
ask
for
so
I
can
only
start
using
it.
It
might
not
be
the
one
I
asked
for,
but
hey
I
can
do
something.
C
Next
slide,
please
another
thing
that
was
brought
up
was:
do
we
want
to
split
the
address
request
and
address
assigned
capsules
which
currently
support
both
V4
and
V6
fields?
In
two
separate
capsules,
and
after
a
bunch
of
discussion
amongst
contributors
and
the
editors
of
the
draft,
we
basically
concluded
that
they
didn't
seem
to
have
any
benefit
to
do
the
split,
so
we
decided
to
leave
it
as
is
next
slide,
please.
C
So
at
this
point
you
probably
realize
that
we
went
through
this
presentation
fairly
quickly,
because
no
one
has
come
up
to
the
queue
and
asked
questions
which
means
I
have
a
question
for
the
working
group
which
is
do
we
think
we
are
ready
to
proceed
to
working
group?
Last
call
I
personally,
think
that
we
have
made
excellent
progress.
We
have
no
open
issues
and
I'm
not
sure
what
else
we
could
do
so
if
anyone
else
would
like
to
go
into
the
queue
and
offer
an
opinion,
I'd
love
to
hear
it.
D
David
schenazi
mask
Enthusiast
with
an
opinion
the
yeah,
the
the
draft,
was
in
good
shape.
We
made
like
really
good
progress
at
the
last
ITF
and
we
were
all
thinking
well
yeah.
D
The
text
wise
this
seems
good,
but
you
know,
let's
see
if
it
actually
works
before
we
go
any
further,
and
it
was
quite
great
at
the
hackathon
this
weekend
to
see
that,
like
some
of
the
design
choices
that
we
made
ended
up
being
even
better
than
we
thought
so,
for
example,
the
like,
let's
just
use
icmp
version,
we
realized
that
we
got
that
feature
for
free
because
we
have
the
kernel
taking
care
of
that
for
us,
so
that
was
kind
of
nice
of
like.
Why
are
you
sending
me
this?
D
Oh,
oh,
that's
an
icmp
packet.
Oh
great!
We
don't
need
to
implement
anything.
That's
automatic
things
like
that
and
the
oh
what's
going
on
here
with
anyway,
so
we're
pretty
I'm
personally
very
happy
with
where
things
at
I
think
maybe
the
editors
can
do
an
editorial
pass
before
we
launch
the
working
group
last
call,
but
maybe
that
but
I
think
that's
the
only
thing
there
aren't
any
open
issues
and
that'll
be
a
good
way
to
motivate
people
to
to
read
the
draft.
C
And
I
will
also
say
the
hackathon,
almost
all
of
the
issues
that
we
ran
into
on
interop
weren't
on
connect
IP,
they
were
like.
Oh
you,
screwed
up
your
Linux
routing
firewall
or
oh
your
certificate's,
not
a
valid
x509
search,
which
is
you
know
the
best
kind
of
problems
to
have
things
that
we
should
have
been
able
to
fix
going
into
it
anyway.
D
E
Google
and
maskady,
thanks
for
your
to
everyone
for
the
diligent
work
on
this
seems
like
you're
very
efficiently.
You
know
solving
the
resulting
issues,
I
wonder
if
this
might
be
a
good
time
since
you've
figured
out
how
to
spell
everything
to
maybe
do
it
early
into
area
review
So.
To
avoid
issues
coming
up
in
ietf
last
call
I
mean
I'm
fairly
optimistic
that
it'll
be
fine,
but
it's
always
a
good
thing
to
get
it
done.
E
F
Lorensically,
the
Android
so
I
haven't
read
the
draft.
I
was
just
reading.
It
now
yes
shoot
me
now,
but
that
gives
me
a
unique
perspective
of
being
able
to
ask
a
generic
question.
The
question
is
this:
it.
F
This
feels
like
a
really
sort
of
like
the
level
thing
low
layer
thing,
and
one
thing
that
we
have,
unfortunately
in
Android
is
that
applications
use
the
BSD
sockets
API
very
extensively
and
there's
a
lot
of
warts
in
there
like
dual
stack
sockets
and
you
know
automatic
assignments
on
buying
a
lot
of
assumptions
that
apps
make.
My
question,
which
is
super
generic,
is:
has
anyone
looked
a
little
bit
at
how
to
map
the
sort
of
semantics
of
the
system?
Calls
that
apps
use
like
bind
or
connect
to
this?
This
is
very
packet.
Oriented
right.
C
Thank
you
very
much.
That
is
an
amazing
question.
So
there's
two
ways
to
use
connect,
IP,
the
first
of
which
is.
This
is
more
like
a
traditional
VPN
with
a
virtual
Network
device
where
the
individual
applications
don't
have
to
worry
about
this,
and
in
the
case
that
we
have
today,
which
is
I,
think
how
you
know,
one
of
the
Google
implementations
that
we
interoperated
with
worked
it
like
literally
brought
up
Linux
10
devices
on
the
client
side.
C
C
The
other
way
of
using
it
is
when
you're
doing
more
direct
flows
yourself,
which
is
where
a
lot
of
Ip
protocol
scoping
and
a
whole
bunch
of
other
things
happen
where,
for
example,
if
you
have
a
user
space
stack
which
is
already
doing
packaging
such
as
a
quick
stack-
and
you
want
to
do
some
sort
of
interesting
tunneling,
you
can
use
that
mode
directly
and
you
don't
necessarily
need
a
ton
device.
We
implemented
that
as
well,
where
we
know
we
were
going
and
doing.
C
Fetches
of
you
know:
example.com
directly
encapsulated
through
a
mass
connect,
IP
stream,
but
that
usually
requires
that
your
application
is
actually
aware
of
that
mode.
Oh
yeah,
so
it
wouldn't
be
great
for
TCP.
You
would
need
to
have
like
a
user
space.
Dcp
stack
if
you
want
it
to
work
that
way,
but
but
this
is
by
Design.
Oh.
F
Sort
of
wondering
how
yeah
I
guess
in
the
second
mode,
I
guess
the
first
mode
yeah
it
makes
sense.
I
guess
the
second
mode,
I'm
wondering
is
look,
you
know.
Do
we
have,
for
example
like
how
do
we
know
that
anything
using
a
BSD,
sockets
API,
that
this
protocol
is,
is
expressive
enough
to
to
support
that?
F
C
Yeah
so
the
short
answer
is
we
didn't
do
exactly
what
you
what
you
were
suggesting,
but
we
are
running
like
a
quick
stack
over
that
mode
and
like
it
was
fairly
easy,
at
least
on
the
Google
implementation,
I'm,
not
sure
on
the
Apple
or
Ericsson
ones,
because
I
wasn't
working
on
those
to
go
and
have
an
encapsulated
packet
writer
that
went
and
did
all
the
things
without
any
sort
of
difficulty.
G
H
All
right,
I
think
I'm
next
up
so
just
to
the
question
here,
I
think
yeah.
We
could
do
last
call
on
this
I
think
we
could
do
it
on
the
current
version.
I,
don't
I,
don't
think
we
need
another
pass,
necessarily
and
definitely
agreed
that
doing.
Indaria
review
in
parallel
would
be
good.
H
One
thing
I
wanted
to
mention
here
just
for
the
interop
was
that
this
was
also
a
really
good
opportunity
to
I.
Think
for
the
first
time
between
a
lot
of
these
stacks
do
a
real
capsule
interop,
with
non-trivial
capsules
back
and
forth.
You
know,
I
know
we
already
shipped
the
capsule
protocol
RFC,
but
at
least
I
was
not
aware
of.
You
know
this
level
of
really
using
capsules
in
some
of
these
protocols.
H
So
I
think,
if,
for
nothing
else
doing
the
connect
IP
work
is
a
good
way
to
exercise
that
and
prove
that
that's
part
of
the
stack
works
and
then
to
Lorenzo's
question
I
just
wanted
to
mention.
So
the
testing
that
we
did
from
the
Apple
client
was
all
the
like
per
flow
stuff,
not
the
interface
level
VPN.
H
So
you
know
we
we
do
have
our
kind
of
like
quote-unquote,
modern,
socket
replacement
apis
that
have
a
user
space,
IP
stack,
and
so
they
could
easily
work
with
this
directly
and
then
on
Apple
platforms
for
BSD
sockets.
We've
had
a
way
to
bridge
those
for
quite
a
while,
as
like
an
application,
Level
VPN
and
divert
those
over
to
a
process
that
can
do
a
modern
proxy
stack.
H
D
David
scanazi
mask
Enthusiast,
first
off
Tommy.
Thank
you
for
starting
your
day
at
1.
30
a.m.
To
be
here
really
appreciate
it.
D
So
some
some
thoughts
on
this
Lorenzo,
the
the
oh
well,
first
to
Tommy's
point:
we
had
some
non-trivial
interoper
for
capsules
with
web
transport,
so
we
had
that
before
we
shipped
that
RFC
and
we
kind
of
helped
us
establish
that,
at
least
in
the
Google
implementation
of
chrome
and
with
somewhat
transport
servers
like
twitch,
if
I
recall
correctly
but
anyway,
having
more
is
always
better
back
to
the
connect
IP
and
the
mapping
to
BSD
apis.
D
The
way
I've
been
thinking
about
it
is
Connect
ipfits
into
a
suite,
and
if
you
look
at
the
BSD
API,
which
is
you
know
in
practice,
what
apps
use-
or
you
know
the
for
the
other
more
modern,
better
apis
like
what
Apple
has
they,
you
know
inherited
the
security
properties
of
the
BSD
API,
which
is
an
app
running
on
your
phone,
can
open
a
TCP
socket
again
or
a
TCP
connection.
D
It
can
open
a
UDP
Association,
but
it
can
do
create
completely
a
raw
socket,
and
so
the
idea
is,
if
you
want
to
map
that
which
you
know
for
Mass
privacy
proxies
that
we've
been
like
are
looking
at
implementing.
The
idea
is
if
the
app
wants
to
open
a
TCP
socket,
that
gets
mapped
to
connect,
which
has
the
very
the
very
same
semantics
as
TCP,
and
you
can
do
that
with
a
collaborating
app
where
the
app
just
calls
an
API.
That
does
that
or
you
can
do
it
in
a
non-collaborating
app.
D
If
you
have
kernel
apis
that
allow
you
to
hook
in
at
the
flow
level,
so
Android
doesn't
have
those
pretty
please.
That
would
be
a
great
feature
to
have
any
Linux
kernel
hackers
around,
but
apple
has
a
way
where
you
just
hijack
the
flow
and,
like
you,
get
the
calls
and
user
space
directly
from
the
socket.
It
doesn't
involve
the
TCP
stack
at
all,
which
is
a
great
way
to
hook
from
a
TCP
socket
of
a
non,
an
app
that
doesn't
want
to
do
this.
D
You
can
just
drag
it
kicking
and
streaming
in
a
way.
That's
really
efficient
because
you
don't
have
to
involve
the
atcp
stack
at
all
and
same
for
UDP.
You
can
use
connect2dp
and
connect.
Ip
is
kind
of
the
pan
at
the
bottom
to
catch
everything
else.
So
if
the
app
like
wants
to
do
icmp,
for
example,
on
bsdos's,
you
can
do
ping
as
a
non-root
user
and
I'm
sure
other
use
cases
connect.
Ip
is
for
those.
D
F
Yeah,
thank
you.
I
I
actually
I
try
to
click
the
button
to
lower
my
hand,
but
it
didn't
work
so
I'm
still
in
the
queue.
So,
but
maybe
you
can
boot
me
up,
but
I
guess
one
one
sort
of
concrete
question
I'd
ask
is,
for
example,
like
the
BSD
sockets
API
has
a
concept
of
being
able
to
bind
to
a
port,
and
it
provides
certain
guarantees
like,
for
example,
unless
you
go
out
of
your
way
to
say
that
they
can
no
other
app
can
bind
to
that
Port.
F
So,
in
the
town
scenario,
fine,
you
know
that
the
kernel
deals
with
all
of
that
you
just
you
know
that
the
kernel
stack
will
deal
with
that,
but
in
the
sort
of
more
direct
access
and
I,
don't
know
what
you
call
it,
but
you
know
an
app
would
be
able
to.
F
You
know
it
sounds
like
it
would
be
able
to
like
send
their
arbitrary
IP
diagrams
right
and,
and
then
in
that
case,
right
like
how
do
you
provide
a
device
like,
let's
say,
a
phone
with
egress
to
the
internet
without
requiring,
like
you
know
like
how
do
apps
collaborate
like
do?
You
need
to
give
every
different
app
its
own
IP
address,
for
example,
because
you
don't
have
you
know
Port
mapping
things
so.
C
Yeah,
so
there's
there's
a
couple
different
ways
to
do
this,
so
one
way
to
do
this
would
be
some
additional
extensions
which
we
we
have
discussed
in
the
past
and
haven't
yet
decided
to
do
to
allow
carving
up
the
port
range
spaces.
C
We
basically
decided
in
the
working
sorry
in
the
design
team
beginning
of
this
year.
I
think
it
was
the
beginning
of
this
year
that
we
were
going
to
basically
handle
when
connect
IP.
Initially
anything
would
just
in
the
IP
header
and
not
anything,
we're
using
the
TCP
or
UDP
headers
Downstream,
but
it
is
totally
possible
to
design
an
extension
to
allow
carving
up,
for
example,
the
port
range
saying
so
you
can
say
I
can
request
ipro.tcp
and
then
have
a
request.
You
know
Port
wrench,
10
000
to
11
000.
C
that
doesn't
exist
today.
That's
definitely
something
that
someone
they
were
excited
about.
It
could
write
up
the
other
way
of
doing
it
is
imagine
you
can
do
a
link
local
IPv6
address
and
then
you
know
Nat
on
the
connect
IP
proxy
service
word.
You
say
that
like
so
you
don't
necessarily
have
to
egress
with
the
same
IP
which
is
assigned
to
the
inside
of
the
tunnel.
F
Yeah,
okay,
no,
that
that
I
understand
that
I
want
one
point
to
David
to
your
point.
Much
as
I
would
like
it
to
be
different:
the
Android
sort
of
Kernel
timelines
or
seven
to
ten
years.
It's
depressing!
But
that's
how
it
is
so
in
terms
of
you
know
getting
a
feature
to
to
the
fleet,
so
yeah
I'm,
relying
on
that
to
to
to
deploy.
F
This
is
maybe
not
gonna
but
anyway,
yeah
so
anyways
that
that
it
sounds
like
the
primary
case
was
like
out
of
the
tongue
case,
which
seems
like
well
specified
and
basically
functional
at
this
point
and
a
sort
of
like
a
single
tenant
kind
of
thing,
where
you
give
a
an
app
an
IP
address,
and
so
for
V6,
you
could
have
where
you,
whatever
50
apps
on
the
phone.
They
could
each
have
their
own
IP
address
and
they
could
use
IP
connectivity
for
V4,
yeah
I!
C
The
other
thing
I
quickly
like
to
add,
is
to
emphasize
something
that
David
said
earlier,
which
is
that
connect
IP
is
like
you
know
the
catch-all
for
when
you
want
to
do
something
that
is
not
already
handled
by
connect
or
connect
UDP.
We
expect
that
99
of
the
different
use
cases
of
an
app
wants
to
do
something.
Tcp
related
or
UDP,
related
scope
to
a
specific
Port
is
going
to
be
handled
by
those
existing
specifications
that
we
have
so.
C
Based
on
drafts
we
have
today,
yes,
you
can
bind
to
a
specific
point,
I
believe
I,
don't
think
we
have
listened
yet,
but
I
think
that's
actually
on
the
agenda
for
this
week.
Thanks.
A
I
will
decline
that
request,
then
cool
all
right,
so
it
sounds
like
we're.
Gonna
spend
a
couple
of
weeks
doing
a
quick
editorial
pass
and
then
we
will
go
for
a
working
request,
call
as
well
as
requesting
interior
view
in
parallel.
Wonderful,
thank
you
so
much.
Thank
you
so
much
all
right.
Next
up
we
have
proxim
listener
UDP
and.
A
I
I
All
right,
hi
everyone,
my
name-
is
zabi
Singh,
Google
and
I'll
be
presenting
the
connect
UDP
listener
today.
I
So
since
our
last
presentation
that
iitf114
we've
made
a
few
changes,
but
most
of
them
are
editorial
ones
next
slide.
Please.
I
So
what
connect
UDP
is
right
now
is:
it
enables
connected
udb
sockets,
so
the
proxy
can
send
and
receive
from
a
single
Target
specified
in
the
path
field
of
the
connect
header.
But
what
if
we
wanted
more
tuples
next
slide,
please.
I
Take,
for
example,
webrtc
like
in
this
basic
topology,
the
clients
are
paying
a
stunt
server
next
slide.
Please.
I
And
then
a
peer-to-peer
connection
is
established
here
between
Bob
and
Alice,
so
they
can
have
a
very
important
discussion
about
their
favorite
cat
videos.
Next
slide,
please
so
the
same
topology
of
the
proxy
would
look
something
like
this
next
slide,
please
and
in
the
in
an
Ideal
World.
Hopefully
the
proxy
would
relay
the
the
discussion
about
the
cat
videos
to
Alice
next
slide.
Please.
I
Now
the
question
is:
why
not
just
to
use
connect
multiple
connect,
UDP
connections,
that
could
work
right.
That
could
help
us
get
multiple
five
pupils
next
slide.
Please
now
now
here's
the
catch,
because
it's
we're
running
HTTP
proxies
two
individual
requests:
they're
on
guaranteed
to
be
served
by
the
same
server
instance,
so
the
IPS
that
get
exposed
at
the
end
of
the
proxy
might
be
different,
and
so
so
so
this
breaks
ice.
I
So
if
this
sounds
familiar,
it's
kind
of
like
what
we
have
a
like
symmetric
mats
but
I
think
like
using
current
servers
to
support
this
seems
very
unnecessary
and
expensive
when
we
could
still
support
peer-to-peer
next
slide.
Please.
I
So
connect
presenting
connect,
UDP
now
with
listener
support,
and
so
one
connect
GDP
connection
infinitely
as
many
UDP
targets
next
slide.
Please.
I
So
how
does
it
work
I
mean
so
in
the
header,
as
you
can
see
like,
we
specify
the
paths
with
asterisks
meaning
can
have
as
many
targets
as
we
like
and
so
in
the
in
the
quick
frame.
You'll
see,
there's
a
connect,
udb,
listen
section
with
the
IP
address
next
slide.
Please.
I
So
what
this
IP
field
is
so
when,
when,
when
the
connectivity
datagrams
are
sent
from
the
client
to
the
proxy,
they
represent
the
target
IPR
Port,
that's
that
it
should
be
forwarded
to,
whereas
on
the
other,
in
the
other
direction,
when
the
proxies
receiving
and
sending
it
back
to
the
client,
it
would
represent
the
source
IP
from
which
the
proxies
received
these
packets.
I
So,
but
here
there
is
an
open
question:
like
does
the
proxy
validate
Source,
packets
and
I
guess
this
is
where
we
would.
We
would
need
like
turinx
people
who
have
expertise
with
webrtc
turn
next
slide.
Please
so
I
would
like
to
open
the
question
like
are
we
are
we
interested
in
adoption?
Of
course,
we'll
need
some
security
considerations,
like
I
mentioned,
like
Eddie,
anyone
who
has
like
webrtc
or
turn
expertise
that
would
be.
That
would
be
quite
helpful
next
slide,
please,
and
that
would
be
it.
A
Wonderful
all
right,
our
queue
is
currently
booting,
but
Lorenzo
is
first.
A
Lorenzo
is
no
longer
first,
it
does
work
all
right,
keep
walking
Lorenzo,
so
we
have
a
timer
on
screen.
We're
gonna
try
to
keep
our
comments
within
that
time,
so
the
two
things
that
we
want
to
talk
about:
Are
One,
technical
feedback,
clarifying
questions.
Anything
like
that
as
long
as
we
keep
it
super
short
and
the
other
is.
Is
this
the
kind
of
thing
that
we'd
like
to
include
in
our
Charter?
Is
this
useful?
Is
this
necessary
for
real
world
deployments
that
kind
of
thing
all
right,
Lorenzo.
F
I
guess
Tommy
was
performing,
but
is
this
useful
I
think
it's
necessary?
If
you
want
to
do
anything,
you
know
more
complicated
than
just
a
client
server
interaction,
so
it
does
seem
useful
from
a
technical
feedback
perspective.
F
Usually
apps
will
bind
to
an
empty
address,
and
so
that's
one
thing
to
consider,
and
there
are,
you
know
again
like
to
my
earlier
point
about
mapping
this
to
sockets
apis.
They
they
do.
Things
like
you
know,
bind
connect
and
then
call
get
sock
name
to
figure
out
what
their
local
address
is
and
so
on.
So
that's
those
are
like
things
that
they're
accustomed
to
doing
that.
If
you
want
to
Port
an
app
to
use
this,
such
as
webrcc,
you
might
want
to
think
about
those
semantics
and
replicating
them
a
little
bit.
F
Things
like
get
sock
name
is
are
actually
you
know
and
get
pure
name
error
often
used.
The
other
thing
that
I
would
say
also
is,
is
a
complexity
that
you
need
to
think
about
is
the
dual
stack
sockets.
So
often
an
app
won't
know
if
a
connection
is
coming
in
on
B4
or
V6
and
it'll
just
like
bind
to
a
to
a
V6
address,
AFI
net
six
empty
and
then
it
will.
You
know
the
kernel
will
deal
with
V4
traffic
on
that
socket
using
mapped
addresses
and
so
on.
That's
it!
F
H
I
would
say
this
is
the
main
pain
point
for
the
browser
use
case
when
using
a
mask
proxy
and
we've
been
running
within
deploying
these
for
like
two
years
now,
and
this
is
kind
of
like
the
main
Gap
that
we
need
to
fill
so,
please,
let's
do
it.
Let's
adopt
it
here.
I
also
think,
if
any,
if
anything
is
in
scope
for
this
group,
this
should
be
because
this
is
kind
of
like
a
clear,
like
bug
fix
essentially
in
the
whole
connect
UDP
ecosystem.
H
G
D
D
Thanks
Abby
for
waking
up
at
4
30
a.m
and
joining
us
today.
This
time
zone
is
rough
for
the
U.S.
This
time
around
I
just
wanted
to
answer
Lorenzo's
question
as
co-author
the
kind
of
spiritual
war-
that's
not
the
right
word.
The
conceptual
way
to
think
about
this
is
so
connect.
Udpg
unextended.
The
current
version,
that's
published
is
a
connected.
Udp
socket,
and
this
is
a
non-connected
UDP
socket.
D
So
you
you
do
bind,
and
then
you
you
get
on
every
packet
that
comes
in
the
receive
packet
info
and
and
then
you
can
send
to
to
a
bunch
of
places.
So
like
get
pure
name,
it's
not
because
it's
not
connected
there
and
the
the
call
for
getting
your
local
name
like
that's
the
one
that's
like
not
defined,
but
if,
if
you
want
to
fit
that
you
would
say,
here's
a
1918
space
address,
that's
fake,
because
that
address
doesn't
exist
in
this
space.
D
It's
like
imagine
like
I'm,
realizing
the
more
and
more.
We
think
about
this.
More
and
more
masks
feels
like
a
gnat,
that's
running
over
HTTP,
which
is
kind
of
ironic,
because
the
old
name
for
Nat
was
masquerade,
but
that's
kind
of
what
this
is
where
like.
If
you
have,
if
you
you
can
give
your
app
an
address,
but
it'll
be
fake.
Just
as
an
address,
that's
private
to
your
side
of
the
NAT
is
fake.
D
One
thing
that
folks
have
talked
about
that
we
can
decide.
If
we
want
it
to
be
in
this
draft
or
not,
is
you
can
you
could
also
add
an
option
to
to
use
Mass
to
say,
hey,
here's,
the
public
address
that
the
proxy
is
using
for
this
connection
on
the
outside
in
case,
that's
useful
to
facilitate
things
like
ice
and
all
that
yeah
yeah.
So
that
could
be
a
useful
I.
Wouldn't
say
you
need
it
because
with
a
Nat
like
the
you
don't
have
that
you
don't
have
a
way
to
tell
the
NAT.
D
What's
my
public
address
today
and
things
still
work
because,
like
we've,
it's
done
you
can
do
that,
but
it
sounds
like
a
useful
feature.
Maybe
we
can
use
that,
but
I
think
it
fits
into
the
shape
of
what
you're
describing.
D
Yeah
I
know
for
sure
for
sure
it's
just
a
way
to
think
about
it.
I
hate
Nats
as
much
as
the
next
person.
A
All
right,
thank
you
very
much
sounds
like
we've
got
quite
a
bit
of
interest.
Let's
move
on
to
our
next
topic.
D
A
K
I'm,
Eric,
Rosenberg,
Apple
I'm,
going
to
be
talking
about
quick,
aware
proxying
using
HCB,
which
is
an
extension
to
connect
UDP
when
quick
is
being
proxied
next
slide.
Please.
K
K
Additionally,
when
using
connect
UDP,
you
may
notice
that
there's
MTU
loss
for
each
proxy
that
you
use
by
encapsulating
inside
of
http
datagrams,
and
this
may
not
be
a
big
deal
when
using
a
single
connect,
2D
proxy.
But
if
you
start
to
chain
these
proxies,
this
MTU
loss
can
be
quite
consequential
even
to
the
point
of
maybe
not
being
able
to
run
quick
over
those
nested
tunnels
and
then
finally,
there's
the
processing
and
send
and
receive
overhead
associated
with
connect2dp
that
you
would
expect,
and
there
are
some
opportunities
to
to
Short
Circuit.
K
Some
of
that
work
when
you
know
that
quick
is
being
proxy
next
slide,
please.
K
So
what
is
quick,
aware,
proxying
well
essentially,
the
client
who
is
is
speaking
quick
to
some
Target-
is
able
to
tell
the
proxy
some
information
about
the
quick
connection.
K
That's
being
proxied,
and
specifically,
the
client
is
sharing
the
connection
ideas
for
the
inner
quick
connection
with
the
proxy
using
the
capsule
protocol
and
immediately
with
that
information,
what
the
proxy
is
able
to
do
right
off
the
bat
is
it's
able
to
reuse
Target
facing
ports
for
these
connect,
UDP
tunnels,
so,
instead
of
having
to
create
a
a
new,
unique
socket
that
might
be
a
new
port
for
each
connect,
UDP
request.
If
it
knows
that
it's
quick,
it
may
be
able
to
reuse,
sockets
and
distinguish
traffic
based
on
connection
ID.
K
On
top
of
that,
if
a
client
in
proxy
agree
that
they
want
to
support
a
forwarded
mode
of
proxying,
they
may
skip
the
encapsulation
of
the
quick
packet
for
the
inner
quick
connection
inside
of
an
HTTP
datagram
for
short
header
packets.
And
this
is
what
we
call
forwarded
mode
where
the
client
is
generating
a
quick
packet
for
the
client,
Target,
quick
connection
and
instead
of
encapsulating
it
inside
of
an
http
datagram,
it
can
send
it
directly
to
the
proxy
over
UDP
and
using
this
forwarding
mode,
helps
eliminate
the
MTU
loss
associated
with
encapsulation.
K
And
one
other
thing
to
note
about
this.
Forwarding
mode
is
that
the
the
connection
ID
bytes
on
The
Wire
between
the
the
client
and
the
proxy
are
different
than
the
connection
ID
bytes
on
The
Wire
between
the
proxy
and
the
Target
and
I'll.
Explain
more
about
that
and
why
it's
necessary
in
a
moment
next
slide.
Please.
K
So
I
introduce
a
little
bit
about
how
the
client
shares
connection
IDs
with
the
proxy
and
it's
fairly
straightforward
how
the
proxy
might
be
able
to
take
advantage
of
that
for
Port
reuse.
The
forwarded
mode
requires
a
little
more
consideration
so
before
getting
into
too
much
more
detail
about
that.
When
is
this
actually
interesting?
K
Well,
as
I
said
before,
if
if
this
MTU
loss
makes
a
difference
to
you,
if
you're
interested
in
chaining
proxies
forward
in
my
forwarded
mode
might
be
applicable,
and
then
it's
also
worth
noting
that,
when
using
forwarded
mode,
we're
not
encapsulating
inside
of
an
HTTP
datagram,
and
so
the
quick
packet
contents
that
are
on
the
wire
between
the
client
and
the
proxy
and
the
proxy
and
the
target
are
largely
identical,
and
so
this
is
not
preventing
traffic
analysis.
Pipe
servers
of
both
sides
of
the
proxy
next
slide.
Please.
K
K
But
if
we
for
a
moment
consider
if
we
didn't
have
virtual
connection
IDs,
if
the
packet
between
the
client
to
proxy
were
identical
to
the
packet
between
the
proxy
and
the
target,
the
proxy
receiving
these
forwarding
mode
packets
would
be
receiving
quick
packets
that
have
connection
ID
bytes,
that
it
did
not
choose,
and
if
that
proxy
were
sitting
behind
some
load,
balancer
or
other
routing
infrastructure.
K
That
depends
on
being
able
to
encode
routing
information
in
these
connection,
ID
bytes,
it
may
not
arrive
on
the
right
server,
and
so
by
introducing
virtual
connection
ideas,
we
have
an
opportunity
for
the
proxy
to
choose
the
connection.
The
connection
ID
bites
for
quick
packets
that
it
receives
on
this
forwarding
mode.
The
proxy
then
translates
or
replaces
that
ritual
connection
ID
with
the
real
connection
ID
before
forwarding
it
on
to
the
Target.
K
Another
good
example
of
where
a
virtual
connection
I
use
are
useful,
is
connection
migration,
so
assume
that
we
have
a
client
that
is
migrating
its
network
path
with
the
proxy,
depending
on
whether
or
not
the
target's
interested
in
issuing
more
connection
IDs
and
cooperating
with
using
new
connection
ideas,
the
client
may
wish
to
migrate
and
also
have
those
forwarded
mode
packet,
connection,
ID,
bytes
change
as
the
network
path
changes
and
so
by
introducing
virtual
connection
ideas,
we're
able
to
change
the
connection
ID
bytes
on
The
Wire,
independent
of
any
change
with
the
real
connection.
K
So
we've
run
the
kind
of
regular
connect,
PDP
implementation
that
we
have
as
well
as
our
quick
aware,
connect2dp
implementation
in
our
lab
and
there's
certainly
I,
expect
that
quick
implementations
are
going
to
mature,
and
this
is
our
tunneling.
Implementation
is
only
going
to
get
better
by
what
we've
seen
so
far
is
that
when
we
leverage
quick
aware
forwarding
forwarding
of
these
quick
packets
essentially
requires
an
insignificant
amount
of
CPU.
So
it's
an
extremely
efficient
thing
to
to
do.
K
It
is
a
very
lightweight
way
of
proxy
and
quick
next
slide.
Please
so
I
mentioned
earlier
that
we're
using
the
capsule
protocol.
There
are
about
six
capsule
types
that
are
part
of
this
exchange.
K
I
could
come
back
to
to
this
slide
about
the
details
of
each,
but
it
might
be
more
interesting
to
jump
to
a
sequence
diagram
where
they're
actually
used
so
next
slide.
Please,
okay,
so
consider
that
we
have
a
client
it's
sending
a
connect,
UDP
request,
it's
indicating
that
it
wants
to
do
this
forwarding
mode
which
is
optional.
K
K
K
H
K
Have
a
forwarding
rule
in
both
directions:
Target
to
client,
client
to
Target,
and
after
acknowledging
the
receipts
of
this
target
connection
ID
information,
the
client
is
able
to
use
this
forwarding
mode
where
it
generates
a
quick
packet
for
the
client
Target,
quick
connection
it,
instead
of
encapsulating
that
inside
of
an
http
datagram,
it
replaces
the
connection
ID
bytes,
with
the
virtual
Target
connection,
ID
bytes
sends
it
over
UDP
to
the
proxy.
The
proxy
recognizes
these
connection.
K
K
So
that
is
quick,
aware
of
proxying,
using
HTTP
very
interested
in
folks
reviewing
the
draft
and
providing
some
feedback
and
gauging
interest
from
the
working
group.
Thank
you.
E
K
Oh
yes,
this
is
cloudflare
based
on
cloudflare,
okay,.
E
E
One
is
first
of
all,
the
virtual
CID
thing
is
like
a
great
idea:
I'm
wondering
if
it's
correct
to
bind
those
one
to
one
to
to
the
real
cids
I'm,
having
a
lot
of
trouble,
reasoning
about
the
threat
model
of
of
like
linkability
versus
like
the
proxy
anonymity
of
if
you're
I
mean
clearly,
you
need
to
change
the
virtual
cids
on
in
the
on
the
proxy
between
the
proxy
and
the
client.
E
But
do
you
actually
want
to
change
the
CID
that
comes
out
of
the
proxy
to
the
Target
and
I
I?
Think
the
answer
is
no,
but
that
might
be
wrong
similarly
and
I.
Think
I
brought
this
stuff
on
GitHub,
but
the
interesting
property
I
realized
about
this
is
that
if
you
were,
if
the
proxy
client
connection
consists
entirely
of
these
sorts
of
forwarding
mode
things,
that
you
can
essentially
have
no
AC
feedback
on
the
mass
connection,
which
is
a
very
weird
situation
for
transport.
E
There's
there's
an
idle
idle
time
issue
which
people
have
thought
about,
but
there's
other
things
like
a
lot
of
congestion
controllers
will
like
kill
their
congestion
window
after
a
while.
If
they
don't
get,
you
know
if
it's
if
it's
allegedly
idle,
Etc
and
so
I
I.
Would
you
know
one
nice
thing
about
this?
E
Being
the
transport
area
is
like
maybe
some
of
the
right
people
here
to
think
about
that
really
hard
and
make
sure
we
eliminate
a
lot
of
those
foot
guns,
at
least
with
some
advisory
texts,
but
just
thinking
if,
if
there's
something
more,
we
need
to
do
here
some
way
to
like
collect
the
acts
of
these
well,
you
can't
act
them
because
they
have
no
packet
number.
So
it's
another
way.
Thinking
of
it
is
sort
of
it's
just
it's
a
it's.
E
K
Yeah,
thank
you
just
to
address
the
first
comment.
I,
don't
think
that
the
virtual
connection
ID
and
the
real
connection
you
have
to
be
one
to
one.
K
We
still
need
to
kind
of
flesh
out
the
details
of
of
the
protocol,
but
the
idea
is
that
the
virtual
connection
ID
can
change
and
still
be
mapped
to
the
same
real
connection.
Id
and.
F
K
Yes,
for
for
accommodating
for
there
not
being
traffic
on
the
regular
client
to
proxy
connection.
Thus
far,
we've
been
leveraging
keep
lives
to
keep
that
in
that
stream
alive.
E
J
I
think
this
is
a
an
important
problem
solve
I
think
the
draft
is
a
very
elegant
way
of
doing
it,
even
if
there
are
some
details
to
be
worked
out
also
in
the
in
the
real
world,
often
you're,
not
using
this
just
for
one
connection
that
you
set
up
a
tunnel
and
then
never
touch
the
control
Channel
again,
you're,
usually
also
still
using
it
for
other
traffic
for
other
connections
that
are
coming
in
going
at
the
same
time.
J
G
I
agree
like
this
as
clear
benefits,
so
it's
it's
something
we
should
work
on
and
do
I
have
a
question
about
virtual
cids
and
I
think
this
is
maybe
something
we
discussed
in
the
past,
but
I
understand
how,
like
you
described,
how
that
works
between
the
client
and
the
proxy,
but
I
think
we
would
have
the
same
problem
between
you
know
the
Target
and
the
proxy
and
having
to
Route
Pockets
based
on
proxy
chosen
CID
again
between
the
Target
and
the
proxy.
K
Yeah,
thank
you.
I
think
we'd
have
to
I'd
have
to
understand
a
little
bit
more
about
exactly
what
you're
talking
about
their
their
virtual
connection,
ideas
in
both
directions,
one
that
the
proxy
chooses
and
one
that
the
client
chooses
and
it's
the
receiver
that's
deciding,
and
the
receiver
in
this
case
is,
is
the
client
so
from
packets
that
are
coming
from
the
target
to
the
proxy
for
now
have
have
the
real
connection
ID
to
to
make
sure
that
we
don't
require
any
cooperation
from
the
target.
K
G
Right
so
so,
I
I
think
the
problem
being
in
a
situation
where
you
require
routing
quick
packets
based
on
connection
ID.
That
proxy
would
have
to
to
ever
say
in
what
the
connection
ID
is
in
the
case,
thanks.
L
Hey
Lucas
part
of
your
cloudflare
I
think
this
is
a
clear
use
case
for
this.
It's
got
clear
benefits.
It's
not
just
a
micro,
optimization,
there's
like
some
some
strong
properties
that
can
provide
the
technical
details.
Yeah.
We
need
to
to
hammer
out
some
of
the
the
edge
cases
or
thought
guns
here
earlier
draft
didn't
quite
fit
the
needs
of
like
Alessandro
to
Saluda
to
load
balancing
concerns
the
later
draft
with
virtual
SIDS
there's
a
much
clearer
path.
L
Toraco
Mark's
point,
I,
think
there's
ways
we
can
mitigate
stuff
via
controlled
channels
or
other
stuff
like
we.
We
should
do
this
work
here,
I
think
so
that
we
can
actually
get
Collective
View
and
different
deployments
like
same
technology.
Different
deployments,
different
concerns,
let's
try
and
and
come
up
with
Technical
Solutions
to
this.
So
thanks
for
doing
the
work
and
I'm
always
happy
to
review
and
give
feedback
thanks.
L
M
Mom
all
right,
pardon
me
yeah.
It
got
short
the
the
thing
that
bothers
me
about
this
design.
Aside
from
all
of
the
questions
that
Alessandra
had,
which
I
also
agree
with
I'm
just
going
to
keep
going.
M
Is
the
traffic
analysis
here
is:
is
trivial
and
I
I
think
what
this
design
really
needs
is
re-encryption
at
the
proxy
as
well,
in
both
directions?
I
realize
that's
unfortunate
and
maybe
less
efficient,
but
the
Privacy
properties
of
the
protocol
are
not
that
great
until
you
do
that
so
I'd
I'd
like
to
at
least
consider
that
yeah
I
think
echo's
raised
this
point
in
the
past.
M
It's
just
concretely
not
biting
so
I
will
continue
because
racist
pointed
before
I
think
he
raised
it
in
in
terms
of
saying:
what's
your
threat
model,
which
is
a
nice
way
of
saying,
I,
don't
like
this
design.
So
please
consider
that.
D
A
D
Microphone
stand
is
impaired,
David
schenazi,
ask
Enthusiast,
so,
unsurprisingly,
I
think
like
yeah
I
agree
with
people,
there's
there's
a
useful
there's
a
need
for
this.
It
really
solves
something.
There
are
a
lot
of
details
to
hammer
out
but
yeah
I
work.
D
This
working
group
seems
like
the
right
place
to
do
that
so
plus
one
to
chartering
recharging
the
working
group
in
such
a
way
that
this
fits
in
and
then
adopting
this
I
think
Martin
and
Eric
are
operating
with
different
threat
models,
which
is
fine,
so
we
might
need
you
know
multiple
modes
of
operation,
one
of
the
really
nice
properties,
if
you
don't
re-encrypt,
is
that
it
allows
you
to
implement
the
forwarding
mode
and
ebpf
fully
on
the
neck
without
ever
touching
the
CPU,
which
is
pretty
banana,
pants,
awesome
and
so
I
think
Eric
has
done
that
which
is
crazy,
awesome,
great
work
and
so
I
think
for
some
use
cases.
D
That's
what
like
that
makes
a
huge
difference
and
allows
you
to
scale
way
more
and
for
other
use
cases
that
Martin
has.
Maybe
we
don't
so
maybe
we
have
another
mode
where
we
do
we
encrypt,
which
are
both
valid
things.
We'll
have
to
talk
about
that
more,
but
I
think
the
working
group
is
the
right
place
for
this.
A
N
Okay,
hello,
everybody:
this
is
Ben
Schwartz
from
alphabet
I,
guess,
and
this
is
I
changed
the
title
to
access
service
description,
URI,
okay.
So
what
what
am
I
talking
about?
What
is
an
access
service?
N
I
came
up
with
some
kind
of
definition
for
what
I
mean
by
this.
Basically,
it's
a
thing
you
use
to
access
the
internet
using
http
I
mean
these
things.
We
have
all
these
things
now
in
HTTP
that
allow
you
to
access
the
internet
over
HTTP,
and
so
this
presentation
is
about
this
draft
is
about
how
do
I
turn
it
on.
N
So
here's
the
like
status
quo
of
how
you
choose
your
proxy
server,
you
like
put
in
an
FTP
proxy
or
something-
and
this
is
how
you
configure
a
VPN
server
so
like
I
guess,
if
we
want
to
activate
connect
IP,
it
goes
in
here.
Maybe-
and
this
is
how
you
choose
your
dough
server.
I
I
wrote
some
of
this
code,
so
this
is.
This
is
the
status
quo
and
so
like
how
many
different
times
are
we
going
to
ask
users
to
enter
the
config
information?
N
How
many
different
times
does
the
user
need
to
authenticate?
This
connects
to
something
I
heard,
David
scanzi,
say
a
few
minutes
ago
that
that
it's
easy
to
imagine
Services,
where
there
are
there's
a
UDP
proxy
service,
there's
an
IP
proxy
service.
Maybe
there
are
other
proxy
services
and
and
any
given
connection
is
uses,
one
of
them
as
appropriate,
based
on
how
that
app
happens
to
be
implemented.
Based
on
what
transport
protocol
it's
using.
N
N
So
that's
one
problem
and
the
other
problem
is
authentication.
How
many
times
does
the
user
need
to
authenticate
to
all
of
these
different
Services?
You
know
these
are
different.
Http
endpoints,
there's,
no,
potentially
even
on
different
Origins,
there's
like
no
necessary
rule
that
they
all
need
to
be
authenticated
in
the
same
way.
N
So
the
goal
of
this
draft
is
to
enable
a
world
where
the
user
just
enters
one
magic
string,
a
URI
into
one
user
interface
somewhere
to
activate
this
thing,
this
access
service
and
the
users
authenticate
to
that
once
and
that's
that's
all.
They
need
to
worry
about.
N
So,
like
here's,
a
very
detailed
rundown
of
how
this
all
would
work,
but
basically
there's
a
URL.
The
user
has
the
URL.
They
plop
it
into
some
user
interface
that
which
then
the
client
fetches
it
you
know
periodically
when
it
expires
and
fetches
it
again
and
and
the
thing
it
gets
back,
tells
it
all
the
different
Services
sub
services
that
are
available
and,
crucially
the
the
authentication
is
done
on
the
access
service,
description,
URL
and
then
those
that
authentication
information
transfers
to
all
these
different
services.
So
we
don't
need
to
authenticate
them
separately.
N
So,
what's
at
this
URL
I
mean
it
doesn't
the
exact
format
doesn't
matter,
but
you
could
call
this
a
placeholder,
but
fundamentally
it's
just
a
trivial
structure
containing
the
the
templates
for
all
these
different
things.
Some
of
you
may
note
that,
in
addition
to
the
connect,
UDP
connect,
IP
and
and
do
templates
here,
there's
also
some
other
stuff
for
TCP
and
HTTP.
N
I
have
five
minutes,
maybe
at
the
end
of
the
session,
to
talk
about
that.
So
that
would
be
like
a
connect.
Tcp
thing.
If
we
wanted
to
do
that,
so
this
sort
of
imagines
a
world
where
we've
we've
fully
transitioned
to
this
kind
of
template,
driven
description
of
proxies,
and
so
we
have
this
nice
parallel
construction
for
all
of
our
different
Protocols
are
described
the
same
way.
N
So
this
was
I
presented
this
at
the
last
session,
but
a
bunch
of
things
have
changed
here,
so
there's
the
those
template
driven,
TCP
proxies
and
such
and
I've
removed
any
normative
mention
of
oblivious
HTTP
from
this,
which
previously
some
oblivious
HTTP
stuff
was
mixed
in
here
it
seemed
like
that
was
not
popular
so
now,
instead
of
having
key
configs
in
here.
None
of
that
the
key
configs
can
be
described
by
some
other
object
that
Tommy
Polly
has
a
draft
for,
and
I
added.
N
This
discussion
of,
authentication
which
I
hadn't
been
talking
about
yet
I
want
to
highlight
that
what
I
really
think
would
be
even
more
interesting
here.
It's
not
in
the
draft
is
a
vanity
URI
scheme
for
this.
So
you
just
you
know,
replace
https
colon
with
mask
colon,
and
now
you
can
imagine
saying
you
know:
okay,
how
do
I
activate
an
access
service
for
my
device?
We
just
click
on
a
mask
colon
hyperlink
and
this
is
very
dangerous.
N
But
it's
very
powerful
and
basically
I
have
faith
that
the
very
small
number
of
implementers
who
actually
have
to
think
about
this,
because
it's
only
basically
operating
systems
and
browsers
would
would
think
very
carefully
and
maybe
not
support
it.
But
if
they
did
support
it
would
would
put
up
suitable
barriers
to
make
it
safe.
N
So
that's
my
very
simple
proposal
and
I'd
like
to
see
this
adopted
in
mask.
Presumably
after
some
kind
of
retardering
discussion.
O
P
Yeah
overall
I
I,
like
this
I,
want
to
see
it
happen
somewhere
at
least
something
along
these
lines,
but
I'm
not
completely
convinced
this.
This
fits
for
a
potential
retire
in
this
group,
but
skimmed
into
preview
discussion.
We're
going
to
have
here
at
the
end
of
this
meeting,
but
assuming
the
plan
is,
we
want
to
retire
this
group
to
be
focused
tightly
to
one
down
after
finishing
up
the
necessary
work,
then
I
think
we
should
leave.
P
This
group
focused
on
proxying,
UDP
and
IP
and
similar
stuff
around
this,
and
this
is
this
proposal
is
more
of
just
a
general
proxy
and
thing.
So
if
we
return
a
lot
of
stuff
like
this,
where
taking
the
big
risk
of
returning
this
working
group
into
becoming
just
a
general
proxy
working
group
and
kind
of
afraid,
that's
too
much
scope,
that's
apply
that
will
lead
to
this,
be
a
permanent
working
group
and
I.
Don't
know
if
that's
the
greatest
idea
so
I
want
this
to
happen.
P
H
All
right,
so
thank
you
for
updating
this
I
I
do
think
this
is
better
and
clearer
than
the
previous
proposal,
I'm
still
on
the
fence
about
the
exact
details
here
and
like
when
I
imagine
in,
like
the
short
term,
how
the
configuration
is
going
to
work
for
these
types
of
things.
I
I
see
two
kind
of
main
paths
for
configuring,
like
one
kind
of
like
you
like
you're,
alluding
to
we
have
these
Legacy
proxy
configuration
boxes
somewhere
in
an
OS
or
browser
settings
UI
and
in
those
cases,
the
user.
H
Just
like
types
in
a
name
of
something
for
those
cases
you
know
connect
Works
already
and
for
connect.
Udp
connect,
IP,
we
defined
a
well-known
URI,
specifically,
so
that
you
know
we
could
just
try
those
and
have
a
well-known
location
off
of
a
name.
So
that
case
seems
to
have
a
short-term
solution
that
works.
Okay
and
then
the
other
model
is,
you
know
we
could
either
have
a
application
or
you
know
we
have
like
MDM
profiles.
H
I
mean
like
you
could
have
a
more
complex
language
for
describing
all
your
different
urls
that
could
come
in
some
other
format,
so
I
think
what
you
have
here
definitely
enables
more
automatic
use
cases,
but
I
think
I'd
want
to
see
more
and
I
think
it
just
requires
more
discussion
among
this
group
or
another
group,
more
broadly,
to
understand,
like
what's
the
exact
kind
of
user
flow
and
who's
going
to
need
to
get
this
information
that
can't
either
get
it
from
a
well-known
URI
or
can't
have
a
richer
configuration
profile
described
in
another
way.
N
C
Hi
hi
Alex,
journalhowsky,
Google,
Ben
I
think
this
is
very
cool
and
I
think
you're
on
to
something
here,
but
I
think
I
still
would
like
to
better
understand
what
the
user
story
here
is
because
one
of
the
things
that
I'm
having
a
hard
time
wrapping
my
head
around,
is
how
we
envision
people
using
this
and
I
think
that
wouldn't
really
inform
the
specific
design,
which
sort
of
leaves
me
to
say
that
I'm
not
sure
that
we're
necessarily
the
right
group
here
and
then
second,
the
messages
in
the
zulip
of
taking
us
a
dispatch
but
I
think
definitely
we
need
to
better
understand
how
we
envision
users
using
this
I,
can't
personally
think
of
the
last
time
I
used
the
proxy
UI
to
configure
something
other
than
when
I
was
developing,
so
I'm
I'm,
not
sure
if
the
solution
and
the
problem
quite
match
up
yet.
N
Yeah
I'll
say
you
know
we
don't
really
use
these
uis,
they
exist
but,
like
you
know,
I
think
the
vastly
more
people
install
VPN
apps
from
their
app
store
then
use
these.
These,
like
ipsec
configuration
uis,
that
every
platform
carries
and
I
think
that's
a
bad
thing.
I
think
that
that's
a
failure
of
standardization
and
we
should
be
trying
to
Define
standards
so
that
we
don't
have
separate
apps
for
all
of
these
things
that
when
we
can,
we
can
standardize
it
end
to
end.
M
Yeah
Martin,
Thompson,
I,
suggested
dispatch,
I
think
there's
a
really
difficult
question
here
about
scope.
You've
talked
about
doe,
you've
talked
about
Ojai,
you've
talked
about
a
bunch
of
other
things.
If
I
imagine
all
of
those
things
falling
under
this
umbrella.
There's
an
interesting
sort
of
question
that
are
very
concerned.
Internet
citizen
might
ask
about
in
the
interest
of
users
about
centralization.
N
Thanks
I
I,
don't
see
a
I,
don't
actually
see
a
significant
centralization
concern
here.
I
think
that
these
you
know,
if
anything,
this
makes
it
a
lot
easier
to
spin
up
new
new
competing
access
Services
by
lowering
the
barrier
to
creating
new
ones
right
now,
the
the
barrier,
the
the
amount
of
technical
work
required
to
to
get
started
is,
is
much
more
significant.
Yeah.
D
I
I
think
there's
something
here
like
there's
something
in
this
space.
I
agree
that,
like
it's,
not
100
clear
to
me
like
what
the
UI
flow
is
and
kind
of
what
the
boundary
is
of.
This
is
so
like
how
many
things
do
we
have
in
here
and
that
that
brings
a
question
to
Scopes,
so
I
think
I
I
want
to
see
this
work
happen
to,
or
at
least
get
a
little
bit
further
down
the
road
to
like
really
understand
where
we're
going
with
it.
D
A
H
All
right,
hello,
everyone,
so
this
is
a
pretty
minor
little
addition
and
it's
this
one
straddles
the
boundary
between
mask
and
just
generic
HTTP
for
proxies,
but
generating
sharing
it
here,
because
it
really
has
to
do
with
this
forward
proxy
privacy
proxy
use
case
all
right.
So
first
some
background
we're
talking
about
a
addition
to
proxy
status.
So
what
is
proxy
status?
H
This
is
defined
in
a
recent
RFC
9209.
It's
a
new
header
field
that
lets
proxies,
tell
clients
extra
information
in
their
responses.
It
includes
the
list
of
identifiers
of
the
different
proxies
that
handle
the
given
request.
H
That's
not
super
interesting
for
this,
but
it
also
includes
an
extensible
list
of
parameters
that
can
include
errors
and
Upstream
details
Etc.
So
why
is
this
relevant
for
mask
I?
Don't
think
we've
talked
about
it
in
this
group,
but
in
practicality.
It
is
very,
very
useful
for
connect,
connect,
UDP
and
connect
IP
proxies.
It's
also
useful
for
reverse
proxies
too,
and
in
the
case
where
we
are
currently
using
mask
for
private
relay.
H
So
as
an
example,
you
may
get
back
a
proxy
status
that
says:
hey
your
example:
proxy
hit
a
DNS
error
and
that
error
was
an
X
domain,
and
so
now
you
know
that
you
were
trying
to
reach
a
domain
that
doesn't
really
exist,
at
least
on
the
public
DNS,
so
to
see
how
that
works
out,
clients
doing
connect
UDP
to
an
or
connect
or
connect
UDP
to
a
bad.example.com.
The
proxy
will
try
to
resolve
that
get
to
NX
domain,
says:
hey
sorry,
502,
here's
the
error,
so
that
works
fine,
okay.
H
So
what
is
missing?
What's
the
problem
that
we're
trying
to
solve
so
in
the
successful
cases
for
being
able
to
actually
connect
to
a
server
over
the
proxy
and
actually
having
DNS
work,
there
isn't
a
parameter
to
communicate
any
DNS
response
details.
H
But
that's
not
really
the
same
as
saying
you
have
DNS
response
details,
and
why
would
you
want
DNS
response
details?
So
there
are
many
different
reasons,
but
the
one
I'm
concerned
about
here
is
the
fact
that
clients
can
use
DNS
responses,
including
like
a
cname
chain,
as
well
as
the
resulting
IP
address
that
you
connect
to
to
detect
cname
cloaking
or
IP
cloaking.
H
So
this
is
a
case
where
I'm
going
to
what
looks
like
a
benign
domain,
but
it's
actually
being
C
named
to
a
name
that
maybe
I
want
to
apply
special
policy
towards,
because
it
is
a
endpoint
that
is
doing
a
lot
of
tracking
or
data
collection
or
something
that
the
user
wants
to
block
for
some
other
reason
or
wants
to
apply
some
policy
to,
or
even
maybe
a
case
where,
instead
of
using
a
cname,
it
is
directly
going
to
an
IP
address.
H
That
is
a
known
tracking,
endpoint
or
some
other
concerning
IP
address
that
we
want
to
be
able
to
apply
policy
towards,
and
you
could
solve
this
by
having
clients
always
do
their
own
DNS
lookups
before
they
use
the
proxy
or
you
know,
do
dough
or
something
else
through
the
proxy
itself.
H
But
that
definitely
is
a
lot
less
performant
than
what
we're
able
to
do
with
the
normal
connector
connect.
Udp,
and
it's
not
I,
think
a
good
trade-off
to
say
that
in
order
to
be
able
to
apply
cname,
cloaking
prevention
or
IP,
cloaking
preventions
that
you
need
to
lose
a
lot
of
the
performance
wins
that
make
going
through
a
proxy
viable
for
a
browser
use
case.
H
H
So
the
concerning
case
is,
let's
say
this
is
a
cname
or
IP
cloaking
and
I'm
happily
going
to
example.com,
but
now
it's
being
c-named
to
tracker
dot
example,
and
it
has
an
IP
address
that
is
somehow
concerning
to
me
potentially,
and
that
response
looks
exactly
the
same.
I
cannot
tell
what's
going
on
there,
so
the
proposal
is
very,
very
simple.
H
It's
just
to
add
one
new
parameter
currently
calling
it
DNS
used,
and
that
is
essentially
the
the
DNS
answer
and
chain
of
aliases
that
was
used
to
create
this
connection,
and
so
a
client
would
be
able
to
read
this
and
apply
whatever
policy
it
has
in
the
browser.
This
is
going
to
be
about
preventing
cookie,
sharing
or
potentially
blocking
a
resource,
and
the
proxy
status
parameter
for
DNS
use
is
very
simple.
H
So
this
particular
proposal
is
very
limited
and
very
minimal.
It's
intentionally
that
way
to
be
a
very
simple
to
add.
Proxies
can
add
this
with
whatever
information
they
have.
It
doesn't
require
any
extra
negotiation
and
it's
just
extra
useful
information
and
it
solves
a
real
problem
that
we
have
for
our
browser
and
I.
Think
when
we
discuss
this
on
list.
Other
people
mentioned
that
they
would
have
use
for
similar
information.
H
H
Those
cases
require
more
active
work
on
a
proxy
to
say.
Please
also
request
these
things
and
give
me
the
responses,
and
we
would
want
more
complicated
negotiation.
Maybe
we
could
use
capsules
for
those,
maybe
they're
other
headers
Etc,
so
I
think
there's
work
to
do
in
that
area,
but
I
would
encourage
us
to
split
up
the
different
problems
and
I
think
we
can
have
incremental
usefulness
with
a
parameter
like
DNS
used.
H
D
David
schenazi
thanks
Tommy
I
think
this
is
useful
and
I.
Think
the
space
of
more
information
about
the
DNS
through
an
HTTP
proxy
makes
a
lot
of
sense.
D
So
I
I
want
to
see
things
like
this
happen
in
terms
of
where
to
do
the
work.
My
my
gut
feeling
is.
This
applies
to
more
than
mask.
It
makes
sense
for
other
HTTP
things,
so
perhaps
it
makes
more
sense
in
HTTPS,
but
like
not
horribly
strongly
on
that
one.
M
G
M
Know
that
we
have
a
more
General
problem
sitting
right
there,
you
you
point
out
it
at
in
the
last
slide.
I
would
prefer
to
explore
those
other
Solutions
before
deciding
to
do
the
narrow
thing,
I
think
there's
there's
too
many
cases
where
the
client
needs
more
information
about
what
was
done
in
terms
of
the
DNS
queries
that
may
be
the
right
place
to
do.
This
work
is
ADD
instead.
H
Sure
yeah
I
I
definitely
agree
that
we
should
do
the
bigger
stuff
too,
but
yeah
I
think
I
do
think
there
is
incremental
value,
we're
doing
the
small
thing.
It's
it's
a
useful
hint
anyway.
N
Ben
hi
benchworts,
I
I,
don't
know
that
I
believe
in
the
cname
cloaking
use
case
really,
but
but
I
do
want
this
just
just
to
be
to
to
Lorenzo's
point
about
supporting
the
posix
apis.
This
is
very
useful.
If
you're
trying
to
emulate
get
Adder
info,
which
does
surface
the
cname
results
at
least
optionally,
so
just
for
the
sake
of
being
able
to
get
it.
Implement
get
Adder
info.
I
think
this
is
useful.
N
J
O
A
Q
Hello,
so
I'm
going
to
talk
about
a
very,
very
small,
proposed
extensions
about
adding
numbers
to
http
datagrams.
So
next
slide,
please
so
some
background
why
we
want
to
do
this.
3Gpp
are
working
on
a
study
called
atss.
It's
a
study
on
access
traffic
steering,
switching
and
splitting
supporting
the
5G
system
architecture.
So
it's
basically
solutions
for
steering
traffic
across
3gpp
and
non-3dp
accesses.
There
are
various
ways
of
doing
that:
different
steering
modes.
One
of
these
steering
modes
is
called
traffic
splitting,
where
you
basically
do
bandwidth
aggregation.
Q
There
are
already
Solutions
defined
in
release
16
of
3gpp,
where,
where
mptcp
is
used,
now
we're
looking
at
other
solutions
for
non-tcp
traffic,
and
there
have
been
various
proposals
for
how
to
do.
The
multi-pass,
steering
and
MP
quick
has
been
decided
as
one
of
the
potential
Solutions
and
that
could
be
used
together
with
mask
now
these
atss
endpoints.
When
you're
splitting
traffic,
they
would
like
to
be
able
to
support
limited
reorder
reordering
of
the
receipt
packets
to
be
able
to
compensate
for
path
delay
differences
of
the
different
axises.
Q
So
when
we
use
Quick,
we
can
either
send
data
as
streams
or
as
in
datagrams.
The
problem
is:
when
you
send
data
in
streams,
you
get
full
reordering.
You
get
a
lot
of
delay
Jitter
you
need
to
handle
re-transmissions
and
whatnot.
If
you
send
data
as
pure,
quick
datagrams,
you
get
no
reordering
at
all.
You
get
a
lot
of
out
of
order,
delivery
of
packets.
You
get
a
lot
of
potential
duplicate,
acknowledgments
and
things
like
this
also
have
problems
with
performance.
Q
So
to
be
able
to
do
like
some
partial
reordering,
the
atss
study
proposes
to
extend
HTTP
datagrams
with
a
sequence
number
so
that
you
can
perform
limited
reordering
based
on
based
on
the
differences
between
the
path
delays.
Next
slide,
please.
So
it's
a
very
simple
extension
to
mask
that
is
being
proposed.
You
just
add
a
new
type
of
a
payload
format,
so
we
have
a
sequence
number
datagram
that
has
a
sequence
number
followed
by
some
payload
next
slide.
Q
Please
to
indicate
support
for
this
we're
proposing
to
use
a
capsule
first,
you
can
indicate
support
using
a
HTTP
header.
Then
you
can
register
the
use
of
sequence
numbers
for
your
datagrams.
By
sending
a
capsule,
the
capsule
would
indicate
the
size
of
the
sequence,
number
used
a
context
ID
and
also
indicate
what
payload
format
there
is
of
the
inner
payload.
Q
And
if
you
have
multiple
inner
payload
formats
like
you
can
have
UDP
payload
or
in
Connect
IP,
we
might
have
IP
payload
as
the
normal.
It's
the
normal
inner
payload,
but
we
might
have
other
extensions
coming
up
with
compression
of
Ip
and
such
so.
You
might
have
multiple
context:
IDs
existing
in
parallel
we're
also
looking
at
how
you
can
register
new
context,
IDs
for
sequence,
number
datagrams.
Q
That
would
wrap
different
types
of
inner
payload
formats,
and
this
is
what
we're
proposing
we're,
posing
to
use
two
different
kinds
of
capsules
for
this:
one
to
register
the
use
of
sequence,
packet,
sequence
and
another
one
to
basically
register
context:
ID
aliases
for
the
same
packet
sequence,
so
that
we
can
support
multiple
inner
payload
formats,
and
this
is
pretty
much
it.
What
we're
posing.
Q
B
Q
There
has
been
quite
some
discussion
and,
to
my
knowledge,
there
is
there's
an
agreement
that
MP
quick
will
be
used,
but
it's
not
agree
that
might
be
the
only
solution.
There's
also
mpdccp
considered
and
I'm
not
fully
up
to
date
with
the
latest
and
I
think
there's
a
meeting
next
week
that
will
clarify
even
more.
D
David
schenazi
thanks
for
presenting
this
I
I'm,
still
not
convinced
that
this
is
a
good
idea,
the
the
concept
itself
of
partial
reordering
on
the
proxy,
because
this
starts
to
smell
like
a
TCP
accelerator
and
those
have
been
great
for
ossification
and
making
performance
worse.
I
have
numbers
for
that,
one.
D
So
on
that
I'm
not
sure
it's
good.
To
answer
your
specific
question
of.
If
we
want
to
do
this,
or
if
this
is
happening,
where
should
it
happen?
I
personally
believe
it
should
absolutely
absolutely
not
happen
in
the
3gpp
and
we
shouldn't
not
encourage
them
to
Run
With
Scissors,
because
that's
how
you
can
hurt
yourself.
D
R
Hello
I'm
from
Huawei
I
think
it's
actually
a
good
idea
to
do
a
reordering
in
the
proxy
that
you
have
the
end
point
I
have
some
kind
of
weakened
Point
yeah,
but
there
is
a
whole
lot
of
discussion
regarding
the
protocol
ossification
that
kind
of
stuff
yeah.
So
we
can
I
think
we
need
to
find
the
middle
ground
for
for
the
function
between
the
proxy
and
the
endpoint.
S
So
if
I
record
correctly,
it
has
been
an
intentional
Choice
within
the
quick
working
group,
do
not
expose
the
sickest
number
of
packets
being
sent
and
based,
and
that
was
based
on
the
understanding
that
doing
exposing
that
would
actually
do
decrease
the
performance
of
a
multi-stream
transport
protocol
that
doesn't
always
have
the
head
of
lamp
working
problem.
S
L
L
It's
kind
of
just
sat
in
the
background.
I've
not
been
doing
that
much
with
it.
Give
it
a
little
spruce
up
about
four
months
ago
and
kept
things
quiet,
maybe
trying
to
do
some
chatting
in
the
hallways
and
then
I
got
ill
and
couldn't
do
it.
So,
let's
go
with
some
background.
Very
briefly:
we've
got
RFC
9000,
quick,
saying:
let's
stream
multiplexing
has
a
significant
effect
on
application
performance,
but
quick
doesn't
provide
a
mechanism
providing
for
exchanging
any
prioritizing
eggs.
L
Prioritization
information,
so
you
know
your
implementation
is
probably
going
to
do
some
stuff.
If
it
cares
about
doing
this
application
performance,
maybe
it
doesn't.
Maybe
it
doesn't
matter,
but
the
signaling
of
what's
important.
What's
not
is
kind
of
punted.
So
hp3
is
an
application
protocol.
It
could
have
had
signals
for
stream
prioritization,
but
we
had
some
issues
during
that
process.
So
we
punted
it,
then
we
have
Roc
9218,
which
kazoo
and
I
worked
on
for
extensible
prioritization,
mainly
for
hb3,
and
now
we
we
backported
it
to
work
over
hb2
as
well.
L
Each
one
doesn't
really
have
the
problem,
because
it's
not
multi-streaming
so
whatever,
then
we
have
quick
datagram
frames
which
we
defined
in
quickland.
They
don't
have
a
transport
multiplexer
identifier,
so
you're
sending
messages
you
know,
but
you
probably
want
to
send
different
datagrams
for
different
kinds
of
information
flows
within
a
connection.
So
in
this
group
we
came
up
with
HB
datagrams
and
the
capital
protocol,
which
is
another
RFC
and
also
proxying,
UDP
and
HP.
L
Also,
if
we
should
be
familiar
with
here,
which
is
great,
the
first
time
I
wrote
this
draft
a
lot
of
those
things,
weren't
quite
rfcs,
yet
so
we're
hedging
our
bets,
but
now
they
are
which
I
think
makes
this
discussion
a
bit
more
clear.
L
You
could
say:
datagram
information
flows,
multiplexing
like
what
would
be
the
use
case
for
that
mass
processing
is
one
maybe
quicker
where
prompting
negates
that
a
bit
I
don't
know
web
transport
potentially
two
depending
on
who's
using
web
transport.
To
do
what
we're
seeing
some
proposals
in
a
mock
working
group
about
not
using
datagrams
and
still
achieving
the
kind
of
low
latency
video
goals
that
they
would
like
to
to
do
without
datagram?
So
maybe
we
don't
need
this
thing.
I,
don't
know
what
I'm
trying
to
figure
out
is.
L
Is
there
any
interest
in
this
document?
It
could
be
done,
but
should
we
do
it
and
if
we
did,
where
might
we
do
it
next
slide,
please
so
yeah?
This
is
the
the
Venn
diagram
of
all
of
the
the
rfcs
that
we
have
and
the
different
working
groups
that
have
done
and
things
that
are
HTTP
datagrams,
possibly
could
have
been
done
in
HP
working
group,
but
we
did
them.
E
L
So
just
a
very
quick
recap
about
what
this
extensible
priority
scheme
is:
it's
for,
signaling
between
clients
and
servers
and
then
there's
other
thing
where
you
might
be
a
reverse
proxy
and
you
want
to
have
an
origin,
or
maybe
some
code
within
your,
like
maybe
CDN
world,
that
can
also
influence
the
prioritization.
L
So
it's
a
kind
of
two-way
thing,
but
it's
all
in
the
RFC,
but
we
have
two
signals
effectively:
urgency
which
is
between
zero
and
seven,
it's
kind
of
like
buckets
of
wheat
or
whatever,
and
this
incremental
thing
which
talks
about
how
the
the
responses
in
HTTP
can
be
processed.
But
really
it's
about
you
know.
Is
he
streaming
the
important
bytes
of
content
that
you
care
about
how
much
they
be
used,
which
influences?
L
Maybe
you
want
to
send
all
of
the
one
thing
in
one
go
and
then
move
on
to
the
next,
or
maybe
it's
useful
to
have
bits
of
things
coming
kind
of
as
closely
in
parallel
as
possible,
because
you
can
render
them
something
like
a
progressive
jpeg
or
something
like
that.
So,
in
addition
to
the
signals
we
give
some
scheduling
guidance-
it's
not
mandatory
but
effectively
it's
there,
so
we
can
articulate
broadly
like
expectations.
L
So
if
you're
going
to
use
the
signaling
scheme,
it's
useful
to
know
how
the
other
end
might
operate
on
that,
but
we
can't
mandate
things
because
scheduling
and
resource
usage
is
always
within
the
control
of
the
the
other
side
that
is
sending
and
scheduling
data.
So
next
slide
very
quickly.
If
you
follow
that
guidance,
you
might
end
up
with
this
kind
of
thing.
I
don't
have
the
time
to
go
into
it.
Unfortunately,
next
slide,
but
when
you
come
to
datagrams,
you've
got
these
Multiplex
flows
using
quarter
stream.
L
Ids
there's
this
all
one
big
bucket.
So
how
do
you
schedule
that?
Maybe
fifo
second
stuff
is
a
bit
basic?
It
could
work,
but
maybe
it
wouldn't
next
slide.
L
So
then
you
combine
that
with
screens
and
you've
got
this
one
bucket
of
one
thing
and
these
multiple
weights
of
other
stuff.
It's
kind
of
a
mess
that
slide.
L
So
there's
this
thing
and
it
adds
a
thing
for
datagram
emergency,
but
basically
accommodate
datagrams
within,
like
a
compatibility
mode
that
would
just
fit
and
fit
within
extendable
priority
scheme
and
its
extension
mechanisms
and
there's
all
to
do
with
how
you
might
share
the
bandwidth
between
datagrams
and
streams.
Next
slide.
L
Yeah
there
we
go,
look
magic
next
slide.
Is
it
a
problem?
I,
don't
know
like
in
the
in
the
web
transport
World
in
w3c.
There's
like
these
big
long
threads
of
issues
they
just
go,
go
like
wow.
L
Maybe
we
can.
Maybe
we
don't-
please,
please,
let's
figure
this
out
and
just
resolve
it,
because
it's
been
dragging
on
way
too
long.
The
next
slide
yep
and
we
had
another
one
to
our
Venn
diagram,
the
w3c
at
the
bottom.
They
need
to
occur
to
next
slide
yeah.
So
what
do
we
do
everyone's
pointing
at
each
other?
Can
we
just
put
this
to
bed?
Please.
A
D
Thumbs
up
but
I'll
just
add
when
we
wrote
HTTP
datagrams
the
privatization
for
HTTP
the
extensible
one
wasn't
ready
yet
so
we
decided
to
punt
to
not
delay,
but
if
you
had
been
there,
we
probably
would
have
put
it
in
there.
So
this
seems
like
the
right
thing
to
do
thumbs
up.
Thank
you
inside
mask.
N
L
It
would
depend
on
the
implementation.
You
know
if
you're
doing
something
like
quick.
You
probably
want
to
send
a
flight
of
packets
effectively.
If
that's
what
you're
doing
in
a
processing
model,
so
you
would
have
maybe
a
batch
of
10
things.
You
send
it
one
time
and
you're
building
up,
you
know
multiple
say:
connect,
UDP
streams
that
are
coming
in
and
you're
trying
to
dispatch
them
as
quickly
as
possible.
I
agree
and
they
should
just
be
in
and
out,
but
you
might
build
up
a
cues
there's
no
flow.
N
Control
I'm
sure
yeah
I,
don't
yeah
I,
don't
really
understand
where
the
queue
is.
But
if
the
queue
is
on
the
sender
side
on
the
on
the
inside,
that's
sending
from
the
client
to
the
proxy
from
the
proxy
to
the
client,
then
this
doesn't
seem
like
the
right
layer.
You
want
the
the
place
where
you
want.
These
priorities
is
on
the
outside
of
the
packet,
so
you
can
tell
the
kernel
to
schedule
the
delivery
or
adjust
it's.
N
It's
buffering
in
some
way,
but
I
I,
guess
I,
don't
really
get
the
use
case
separate
from
that
I
want
to
separate
from
that
I
want
to
say
in
general
in
mask.
We
have
an
interesting
problem
with
these
extended
context,
things
which
is,
we
have
a
way
to
define
these
formats,
but
we
don't
have
any
way
to
explain
to
the
counterparty
when
they
should
use
it.
N
So
I
can
I
can
define
a
format
or
a
context
ID
for
you
to
be
able
to
express
priorities
back
to
me,
but
I
have
no
way
to
tell
you
whether
I
actually
want
you
to
do
that
or
how
often
I
want
you
to
do
that.
I.
Think
that's
a
puzzle
same
with
sequence,
numbers
same
with
all
the
extensions
that
we've
talked
about.
I.
A
Think
that's
all
right
before
we
go
too
deep
into
that
this
timer
Ben
is
your
time
for
the
next
set
of
slides
if
you'd
like
to
do
them.
So
we
can
talk
more
about
priorities.
If
you
want
to
take
us
on
a
quick
tour
through
your
last
set
of
slides,
that
also
works
great
or
we
can
go
into
retarding.
N
Okay,
well,
then,
to
be
very
brief,
this
is
I'm
also
going
to
be
mentioning
this
at
the
HTTP
working
group,
but
like
this
is
how
mask
looks
right,
you've
got
a
template
and
then
you
use
extended,
connect
with
colon
protocol
so
like.
Could
we
just
do
that
for
the
old
HTTP
request
proxy
and
TCP
proxies,
so
the
TCP
proxies
are
an
obvious
parallel
to
UDP,
but
actually
I.
N
Think
there's
also
a
parallel
in
HTTP
request,
proxies
and
and
I
claim
that
this
that
this
solves
some
some
real
problems,
because
these
old-fashioned
proxies
they're
like
completely
impossible
to
Virtual
host
and
also
the
TCP
proxies,
don't
really
work
well
with
happy
eyeballs.
N
So
the
specific
proposal
in
the
draft
has
a
bunch
of
intriguing
intriguing,
edgy
technical
bits,
but
the
bottom
line
is
like:
should
we
do
this?
Where
should
we
do
this?.
H
Yeah
I
find
the
TCP
use
case
a
bit
more
compelling,
and
certainly,
if
you're
trying
to
have
a
new
format
for
the
you
know,
normal
HTTP
proxy,
that
should
be
done
in
HTTP
and
not
in
mask
I
want
to
make
sure
that
if
we're
doing
any
of
this
we're
actually
getting
enough
new
functionality,
for
example,
you
know
if
for
TCP
we
defined
the
ability
to
do.
You
know
start.star
to
have
a
TCP
listener
like
that
would
be
like
a
compelling
New
Edition.
A
There
we
go
so
this
is
a
proposal
and
I'm
showing
it
this
way
instead
of
a
diff
view,
because
the
diff
gets
messy
when
you
move
things
around
this
much,
but
the
main
difference
between
our
current
Charter-
and
this
is
this
paragraph
that
I've
highlighted
part
way
down.
So
this
is
a
somewhat
provocative
text
in
the
sense
that
it
pulls
in
a
whole
pile
of
stuff
that
we
had
previously
said
was
out
of
scope.
A
So
the
intent
here
is,
as
we've
just
been
talking
about
a
number
of
documents,
I
think
we've
sorted
at
least
one
over
to
dispatch.
We
have
some
DNS
conversations
of.
Do
we
want
to
have
that
in
HTTP
or
add
or
DNS
Ops,
or
continue
to
talk
about
that
in
mask.
Whatever
we
decide
there,
we
will
certainly
be
coordinating
with
all
of
the
relevant
other
working
groups,
and
we
have
some
text
about
that
at
the
bottom
of
the
charter
as
well.
A
So
we
can
add
other
groups
to
that
list
and
we
also
had
a
set
of
things
where
it
looks
like
we've
got
quite
a
good
bit
of
energy
and
some
really
good
ideas
around
what
we
want
to
do.
So
with
that.
The
my
client
is
open,
Let's
tear
this
apart
or
decide
that
we
love
it
Lucas.
L
Clarifying
questions,
could
we
what
what
do
you
mean
by
call
documents
here,
the
stuff
we
defined
only
in
mask
or
the
things
we
depend
on
from
other
groups,
our.
L
D
Happen
to
me
next
I
I,
think
of
Lucas's
datagram
priority
as
an
extension
to
http
diagrams,
even
if,
like
you're
right
when
you
like
get
down
to
the
details,
they
might
not
necessarily
be
so
I
I
would
phrase
this
in
such
a
way
that
it's
in
scope.
D
This
seems
a
bit
so
now
to
make
my
personal
Point.
This
new
paragraph
feels
a
bit
too
broad
to
me
good
yeah,
the
I'm
sure
our
isg
overlords
don't
want
us
doing
too
much
stuff,
but
conceptually
I
think
it
would
make
more
sense
for
us
to
focus
on
extensions
to
our
core
documents.
You
know
some
wording
needed
here
because
of
private
previous
point,
so
extensions
to
connect
UDP,
to
give
it
more
features
that
we
think
are
useful
extensions
to
http
datagrams.
D
So
I
would
like
to
see
that
tightened,
but
I
like
the
concept,
let's
not
go
crazy
into
like
hypotheticals
like
let's
keep
it
real
and
then,
where
I
then
draw
the
line
at
kind
of
close
like
narrowing.
The
scope
would
be
to
say
that
if
something
applies
to
hcp
more
generically,
it
shouldn't
be
in
scope.
Here
it
should
be
in
scope
of
http.
D
The
the
remaining
thing
that's
still
here
is
Discovery
and
configuration
I
I'm,
not
sure
that
should
be
in
scope,
at
least
because
so
far
all
the
proposals
we've
seen
in
the
space
are
not
specific
to
mask
and
kind
of
more
General
to
http
and
encompassing
things
like
doe
or
high,
or
all
that
so
I
would
perhaps
maybe
explicitly
Mark
that
as
a
out
of
scope
as
something
that
is
not
tied
to
our
code
documents.
So
I
would
take
a
chainsaw
and
probably
remove
three
quarters
of
this
paragraph.
A
Beautiful
thank
you
so
previously
we
had
also
discussed
splitting
Discovery
and
configuration,
and
one
of
the
reasons
I
mentioned
this
is
being
provocative.
Is
we
previously
had
a
sentence
that
said?
Discovery
is
explicitly
out
of
scope,
and
this
pulls
it
back
in,
and
one
of
the
questions
for
our
folks
who
are
in
the
queue
now
is:
is
that
something
we
want
or
do
we
want
to
keep
Discovery
out
of
scope?
So
next
up
we
have
Eric.
P
P
I
think
the
big
danger
here
of
just
being
too
broad
is
this
work
is
if
we
let
this
working
group
essentially
become
the
general
proxy
and
working
group,
so
I
think
we
really
need
to
make
sure
that
whatever
we
have
written
here
is
focused
on
only
proxying
for
connect,
UDP
and
connect
IP.
If
it's
relay
or
an
extension
to
those
specific
topics,
I
think
very
broad
scope
is
good
configuration
discoverability
extensions.
P
All
that
stuff
is
good,
but
I
think
we
really
need
to
focuses
on
proxying,
UDP
or
IP,
make
sure
and
possibly
explicitly
leave
out
anything
that's
General
to
proxying
that
includes
proxy
and
TCP
and
all
that
stuff.
Anything
that's
in
that
area
is
this.
Working
group
is
just
going
to
become
permanent
if
we
just
allow
anything,
that's
proxying
related
foreign.
H
Right,
hello,
yeah,
I,
agree
with
what
I've
heard
so
far.
H
I
I
think
the
text,
maybe
rather
than
saying
core
documents,
should
be
very
specific
and
talk
about
enhancements
to
connect,
UDP
and
connect
IP
or,
however,
you
want
to
call
them
and
be
very
specific
about
saying
we
should
be
doing
work
that
adds
missing
functionality
that
you
know
prevents
some
use
cases
or
is
about
improving
performance,
or
you
know
text
like
that
for
some
of
the
other
things
I,
don't
think
this
should
include
authorization
I'm,
not
sure
what
transparent
modification
of
proxied
content
means,
I'm,
also
I
I
think
maybe
rather
than
Discovery
and
configuration
maybe
another
way
to
put.
H
It
would
be
to
talk
about
coordination
between
different
resources
like
some
of
what
Ben
was
getting
at.
Was
you
know
recognizing
that?
Oh
this
one
server
does
connect
udpa
and
connect
IPA
and
connect
and
I
think
there
are
also
their
functionality
use
cases
that
could
be
related
to
saying
Hey
I
want
to
connect
UDP
that
has
the
same
local
address
as
my
connect
IP
to
bundle
them
together.
So
maybe
talk
about
more
how
we
are
coordinating
these
different
resources.
H
I.
Don't
have
a
specific
test
for
that
right
now,
but
that
may
cover
the
configuration
but
narrowly
scope
it
and
then
the
last
comment,
I
I,
think
it's
fine
to
say
that
we
don't
include
the
TCP
stuff
and
that
goes
to
http.
E
The
the
current
consensus
I
would
say:
is
that
we're
not
also
not
going
to
be
mask
m
and
I
I
feel
like
this
like
we
are
open
for
any,
and
all
extensions
to
connect
star
is
like
not
is
like
a
mass
gem.
Charter
now
I
mean
you
know,
that's
not
written
in
stone.
We
can
decide
that
we
want
to
ask
the
ITF
to
cup
mask
M,
and
if
so,
you
know
great,
if
there's
that
much
work
to
do,
but
maybe
we
could
scope
this
to
actually
some
actual
problems.
We
were
trying
to
solve.
E
We
ran
a
little
proxy
dispatch,
which
is
fine
and,
like
some
things,
I
think
have
already
more
or
less
been
booted
there,
but
not
today,
but
like
over
the
next
few
months,
we
can
figure
out
like
a
set
of
plausible
problems
that
would
be
put
in
scope
and
if
we
choose
later
not
to
adopt
them,
it's
okay
to
not
deliver
all
the
all
the
all
the
things
that
are
in
the
charter,
and
then
we
will
have
a
nice
stopping
point
to
then
reevaluate
rechartering.
A
Thank
you
yeah,
so
my
follow-up
question
to
that
which
I'd
written
down
earlier
was:
do
we
actually
want
to
mention
explicit
documents
and
I?
Think
mentioning
the
explicit
use
cases
we
can
always
swap
out.
Documents
may
be
a
nice
balance
that
we
want.
E
C
Google
one
of
the
things
which
I
found
really
interesting
about
the
discussion
today
is
sort
of
the
overlap
between
some
of
the
different
things
that
we
had
like
I'm,
not
proposed
to
service
Discovery
per
se,
and
it's
useful
in
some
cases
where
you
wanted
to
offer,
for
example,
like
a
doe
endpoint
on
your
mass
proxy,
so
I'm
particularly
interested
in
figuring
out
how
to
put
in
scope
a
lot
of
these
like
layer,
breaking
things
that
actually
would
help
us
make
a
high
performance
useful
service.
C
M
To
type
this
point
earlier
about
the
scope
of
this,
this
can
be
very
broadly
interpreted
and
I
think
this
needs
a
very
specific
exclusion
Clause.
Following
all
of
this
saying
that
the
work
will
not
do
generic
blah
blah
blah,
because
otherwise
this
is
going
to.
M
Yes,
you
want
to
do
all
those
things
related
to
proxying,
but
you
also
don't
want
to
go
out
and
Define
new
HTTP
authentication
mechanisms
or
all
of
those
sorts
of
other
things.
So
I'd
like
to
see
that
worked
on.
D
D
One
thing
that
I
just
thought
of
that
I
might
want
to
add
and
well
we'll
take
it
to
the
list,
is
I've
been
trying
the
idea
of
writing
a
document
that
it
that's
that
answers
the
question
of
what
is
a
mask
proxy,
because
I
that
comes
up
a
lot
of
work
at
work
where
people
I
hear
someone
telling
someone
else
well
just
use
mask,
and
then
someone
says
what
does
that
mean?
And
we
don't
have
a
great
answer
to
that
today.
D
I
think
that
goes
into
like
the
discussion
that
we
had
with
Lorenzo
earlier
of
how
connect
connect
UDP
connect
IP,
how
all
these
pieces
fit
together
and
there
might
be
space
for
an
informational
document
and
I.
Don't
know
if
that
should
be
done
inside
this
working
group
or
I
can
just
go
dump
my
thoughts
to
the
ISE.
But
that's
that's
what
we're
discuss
question
I'd
like
to
have
a
working
group
if
we
want
to
do
it
here
or
not,
and
our
recharger
is
the
right
time
to
have
that
discussion,
perhaps
on
the.
A
F
Yeah
I
just
wanted
to
say,
I
think
trying
to
figure
out
what
mask
is
going
to
offer
I
mean
to
me
it's
it's
the
ability
to
basically
proxy
at
individ
at
the
fine
grain
IP
level
can.
Can
we
basically
say
that
that's
the
goal
and
like
all
things
that
everything
that
is
in
pursuit
of
that
goal
is
basically
how
can?
A
Yeah,
thank
you
all
right.
This
is
excellent.
We
have
gotten
lots
of
really
good
input
there.
We
will
follow
up
on
the
list
with
some
links
to
very
specific
proposed
text
as
we
go
through
that
I
think
we're
hearing
a
good
consistency
between
the
last
meeting
in
this
meeting
in
terms
of
the
scope
of
what
people
are
interested
in
working
on
and
also
super
importantly,
we've
got
lots
of
really
good
energy
from
folks
who
actually
are
providing
really
awesome
input.
So
thank
you
all
very,
very
much
for
that
and
with
that.