►
From YouTube: IETF107-MASQUE-20200324-2144
Description
MASQUE meeting session at IETF 107
2020/03/24 2144
https://datatracker.ietf.org/meeting/107/proceedings
B
Importantly
also
restricting
yourself
unless
recent
video
off
as
well
to
make
sure
that
everyone
has
a
good
experience
and
if
you
haven't
done
so
already,
there
is
a
link
to
the
blue
sheet
in
the
chat
which
is
etherpad
please
up
over.
There
fill
out
your
name
to
make
sure
that
we
track
everyone
who's
here
next
slide.
Please.
B
Right
so
quickly
we're
just
going
to
go
over
the
plants
of
us
and
how
we
expect
to
you,
know:
I
can
be
up
meeting
and
then
we'll
hop
right
into
the
meat
and
potatoes
of
the
session
starting
with
math.
So
if
you
go
to
the
next
slide,
we
have
the
agenda
specifically.
So
we'll
start
with
the
problem
statement
and
the
sort
of
initial
framework
that
was
proposed
by
David's
canonically
sort
of
laying
the
foundation
for
everyone
to
make
sure
were
kind
of
on
the
same
page.
B
Well,
then,
dump
into
some
use
cases
that
have
been
discussed
on
the
list
and
in
various
channels,
sort
of
leading
to
this
this
meeting
today.
This
is
better
not
that
for
ongoing
for
a
couple
years
now,
as
far
as
I
know
a
little
bit
more
intrepid
in
some
circumstances
or
in
some
companies,
and
it
we're
going
to
sort
of
air
those
and
talk
about
them
and
other
relevance.
B
Masks
mission,
then
we'll
sort
of
from
those
use
cases
talk
about
the
requirements
that
have
been
extracted,
sort
of
helping
us
scope,
the
work
of
the
potentially
proposed
working
group
and
then
go
right
into
the
Charter.
Just
text
that
falls
out
of
that
set
of
requirements
and
then
we'll
get
into
the
e
list
of
both
questions,
sort
of
trying
to
get
a
sense
of
whether
or
not
folks
Hank
we're
moving
in
the
right
direction,
and
this
is
something
that
has
been
added
to
succeed
next
slide.
Please
right
so
reiterate
it
again.
B
Each
section
that
was
laid
out
on
the
previous
slide
of
the
agenda
will
be
and
will
end
with
a
particular
a
brief
pause
for
questions
related
to
that
particular
section.
And
so,
if
you
can,
please
hold
any
of
the
quote:
I
need
to
clarifying
questions
you
have
until
we
get
to
that
point.
So
we
can
all
the
presenters
can
get
through.
That
allows
us
to
sort
of
batch
up.
B
You
know
the
questions
and
hopefully
work
through
any
technical
oddities
that
we
may
experience
along
the
way
and
ultimately,
at
the
end,
give
us
more
time
to
speak
about
the
Charter
and
the
ultimate
buff
questions.
So
with
that
said,
Inc
get
started
with
next
slide
right,
so
David
I
will
hand
it
off
to
you.
You
have
20
minutes,
I.
Think
correctly
sounds.
C
C
C
So
in
today's
world
and
Internet
there
are
times
where
proxies
have
really
beneficial
value.
In
some
cases,
for
example,
they
can
connect
disjoint
networks.
Let's
say
if
you
have
two
IP
networks
that
aren't
reachable
key
IP
layer,
but
you
have
an
application
gateway
proxies,
can
also
a
decryption
and
just
to
clarify
here
when
I
say
proxy
I
use
that
term
very,
very
loosely.
C
Sometimes
this
can
increase
performance
and
so
little
diagram
to
illustrate
what
I'm
talking
about
the
client
will
send
its
traffic
to
a
proxy
server
and
through
that
to
an
eventual
destination,
so
that
can
be
a
web
server
or
all
sorts
of
things
with
an
interconnection
that
can
be
in
some
cases
tunneled
in
and
out
of
connection
next
slide,
please
all
right.
So
what
do
proxies
look
like
today?
E
C
Also,
the
proxy
can
see
everything
that
you're
requesting
and
all
the
responses
which
today's
world
is
pretty
much
a
non-starter
for
most
cases.
Http
also
has
the
connect
verb,
which
allows
you
to
tell
the
proxy
I
want
a
plain,
TCP
connection
to
the
server
IP
M
port.
This
is
particularly
useful,
for
example,
if
you
want
to
do
TLS
end-to-end,
so
that
works
really
well,
it
protects
your
data
from
the
proxy,
but
it
only
supports
TCP.
C
It
really
requires
you
to
be
route
on
the
proxy,
which
is
not
always
possible
for
every
deployment
and
transparent
TCP
proxies
in
some
scenarios.
Called
TCP
accelerators
are
devices
that
are
on
path
and
can
muck
with
your
TCP.
In
some
cases,
they
can
even
improve
the
performance,
but
the
client
really
doesn't
have
a
say
on
whether
to
use
this
or
not,
which
is
great
next
slide.
Please.
C
So
why
is
this
landscape
starting
to
become
a
problem
today,
quick
in
HTTP,
three
are
becoming
a
thing:
we're
going
to
publish
that
RFC
sometime
soon,
I
swear
and
a
lot
of
the
web
is
going
to
start
using
this.
So
this
is
a
lot
of
traffic
going
on
the
internet
that
is
now
running
over
quick,
an
HTTP
three
and
quic
has
a
lot
of
great
properties
such
as
Kilis,
encryption
being
mandatory
or
encrypting
the
transport
layer
information.
C
So
the
acknowledgments
and
sequent
numbers,
and
all
that
which
break
a
lot
of
the
existing
proxy
mechanisms
and
also
quick,
is
built
on
top
of
UDP
and
not
TCP,
so
the
proxies
that
require
TCP
don't
work
with
anymore,
so
we
have
a
growing
need
for
these
use
cases
where,
before
they
use
one
of
the
existing
processes,
but
today
with
HTTP,
3
and
quick,
we
need
something
else
next
slide.
Please.
F
C
Also
providing
us
with
the
solution,
so
what
if
we
used
quick
and
HTTP
3
to
build
the
new
proxy
protocol,
so
one
of
the
great
features
that
quick
provides
I
can
help.
Here
is
multiplexing
streams,
so
inside
a
given
quick
connection,
you
can
have
multiple
independent,
reliable
streams.
At
the
same
time,
you
can
also
use
Datagram
frames,
which
is
a
quick
extension
to
send
things
unreliably,
which
means
that
they're
not
retransmitted.
C
So
if
you're,
let's
say
tunneling
like
rocky
packets
or
something
over
quick,
not
having
them
retransmitted,
this
layer
can
significantly
improve
performance
in
some
cases.
Additionally,
HT
p3
brings
us
like
decades
of
work
in
HTTP,
so
a
request
response
mechanism,
caching,
existing
authentication
mechanisms
and
all
this.
So
all
of
these
combined
give
us
a
lot
of
the
tools
we
need
and
extensibility
for
a
new
proxy
protocol.
C
C
Then
you
can
use
all
these
things
inside
the
correction
without
having
to
negotiate
them.
So
another
important
property
here
is,
if
you're
a
client
device,
not
all
of
your
traffic
will
prefer
the
same
proxy
protocol.
So,
for
example,
if
what
you're
trying
to
do
is
a
TCP
flow,
then
maybe
you
just
use
HTTP
connect
inside
this
HTTP
3
connection.
That
already
exists
that
you
know
you
don't
even
need
mask
for
that.
But
that
gives
you
a
lot
of
what
you
want
with
very
low
overhead.
But
let's
say
you
also
want
to
do
quick.
C
This
should
be
connectors
and
support
that.
So
what
if
we
built
an
application
that
allows
you
to
proxy,
quick
and
also
one
of
the
properties
of
quic,
is
packets
to
have
redundant
information
from
one
packet
to
the
next,
like,
notably
the
connection
IDs,
and
also
the
IP
address
and
port
of
the
server
you
want
to
reach
on
the
other
side.
So
what
if
we
compress
those
away,
so
we
don't
have
to
send
them
on
every
single
packet
to
really
reduce
overhead.
C
Your
quic
connection
has
a
higher
available
and
to
you
and
then
for
things
that
aren't
any
of
those.
In
some
cases
you
just
want
to
be
able
to
proxy
raw
IP
packets.
What
if
you
could
proxy
those
in
the
same
connection
and
those
have
overhead,
but
it's
just
for
those
types
of
traffic
that
couldn't
fit
into
the
previous
ones,
and
all
of
this
is
inside
one
quick,
encryption
boundary
which
allows
you
to
save
performance
by
not
redoing
key
changes
all
the
time,
but.
F
C
There
is
a
potential
strongman
for
how
we
could
build
this,
and
the
goal
here
is
not
necessarily
go
into
too
much
detail
into
how
that
works,
just
to
say
that
it's
possible
to
solve
this
problem.
So
the
way
a
current
it's
currently
set
up
is
the
mast.
Negotiate
has
a
negotiation
step
using
HTTP
POST.
A
A
F
C
Oh
currently,
like
the
mask
framework
itself,
doesn't
make
those
assumptions
I
would
put
those
inside
the
individual
applications.
So,
for
example,
one
thing
that
Christian
and
I
collaborated
on
was
a
version
of
quick
proxying
that
only
needs
one
port
open
on
the
server,
but
maybe
for
different
use
cases.
We
build
different
ones.
So
I
think
this
would
be
in
each
application
to
determine
things
like
that
as
part
of
negotiation.
For
example,
the
server
could
tell
you
well
I
only
allow
you
to
have
this
many
concurrent
connections
or
sorry
come
back
later.
I
C
So
yes,
I,
would
say
like
at
this
point
in
time.
It's
been
a
well
I
need
a
request
response.
This
seems
like
a
natural
way
to
fit
it.
I
would
love
to
get
more
feedback
from
folks
from
the
HTTP
working
group
about
if
there
are
better
ways
to
do
this,
but
just
to
be
really
clear.
This
is
a
detail
of
the
individual
proposal.
I
have
not
of
like
masks
in
general,
so
I
wouldn't
want
to
get
into
those
details
too.
Much
today
understood.
E
And
I
really
appreciate
the
none
of
the
protocol.
Bits
are
set
in
stone.
Piece
I'd
like
to
understand
a
little
bit
about
your
thoughts
on,
on
which
one
of
the
many
applications
you
have
is
critical
and
which
ones
maybe
are
so
important.
You've
got
quick.
Relaying
you've
got
TCP
relaying
you've
got
UDP
and
IP,
there's
a
whole
bunch
of
things
in
there,
which
one
of
those
is
most
important
to
you.
C
I
think
personally,
having
a
quick
relaying
will
make
a
big
difference,
because
over
like
rod,
Peter
shoveling
raw
trotty,
packets
back
and
forth,
it
will
be
a
significant
performance
difference
which
might
be
a
deal
breaker
as
in
like
this
will
make
it
viable.
So
that's
one
that
I
focused
on
so
far
and
implemented
after
that
I
think
having
the
IP
one
is
important
as
well,
because
that
is
kind
of
the
bottom
level
capture,
all
of
it
for
the
for
the
VPN
use
case.
C
A
C
A
K
J
Spencer
Dawkins,
thank
you.
The
we
are
having
a
chat
in
the
in
the
jabber
room
about
whether
this
is
a
more
like
a
proxy
or
more
like
a
relay
or
more
like
a
watt,
and
it
seems
like
we
don't
need
to
talk
about
that
now.
But
just
so
we
don't
get
to
the
end
and
then
everybody's
surprised
when
somebody
says
something
about
that,
because
I
think
that
is
a
relevant
point.
C
Absolutely-
and
that
is
clarifying
so
one
of
the
downsides
here
is
every
single
networking
term
has
been
overloaded
more
than
12
times
so
I
totally
agree
that
some
of
these
terms
aren't
the
best
and
I'm
open
to
suggestions,
especially
in
the
documents,
for
example,
in
some
cases
mask
applications.
Other
folks
have
told
me
they
prefer
to
call
them
services,
which
sounds
reasonable.
The
mass
server
calling
it
a
proxy
or
not,
if
yeah
we're.
C
D
D
Yes,
we
have
basically
a
diagram
very
similar
to
what
you've
seen
from
David's
talk
right
now,
where
you
have
the
client,
the
master
server,
and
in
this
case
the
master
server
is
to
use
to
connect
to
more
than
one
target
server,
and
the
benefit
you
get
here
is
by
having
a
tunnel
between
the
client
and
the
math
server
that
any
kind
of
Platt
on
path
observer
between
the
client
and
the
master.
Server
really
just
sees
your
quick
tunnel
and
doesn't
see
what
happens
inside.
D
It
doesn't
see
what
kind
of
connections
you
you're
having
inside,
in
which
service
you
connect
to.
So
this
provides
so
the
tunneling
provides
just
an
additional
layer
of
encryption,
every
kind
of
VPN
death
and
that
it
also
hides
any
kind
of
traffic
from
the
observer,
and
the
goal
here
is
really
also
to
make
this
traffic
not
stick
out
what
other
traffic
that
this
observer
would
see
on
the
path.
So
it
should
not
be
easy
for
the
observer
to
identify
this.
This
is
masked
traffic.
D
It
would
also
not
reveal
to
anybody
else
that
it's
a
master
server
and
another
benefit
with
kind
of
this
kind
of
setup
is
also
that
it
might
increase
the
privacy
of
the
clients
towards
the
servers,
because
the
masked
server
has
to
put
his
IP
address
as
the
source
IP
address
in
there
to
make
sure
that
the
back
traffic
is
routed
over
the
master
server,
and
so
it
will
also
hide
the
IP
address
of
the
client
from
the
different
servers.
So
this
is
kind
of
the
basic
set
up.
D
It's
this
is
still
kind
of
the
the
same
setup,
but
but
just
talking
about
some
additional
things,
the
math
server
could
provide
to
you.
So
you
could
also-
because
you
have
this
channel
this
quick
connection
between
the
client
and
the
math
server.
You
can
also
use
this
connection
to
talk
to
the
math
server
directly
and
figure
out.
If
am
a
server
offers
any
kind
of
service
to
you.
That
could
be
helpful
like
in
this
diagram.
D
It
just
shows,
as
an
example,
service
that
the
math
server,
for
example,
could
resolve
some
some
ENS
addresses
for
you,
because
you
might
not
have
access
to
your
favorite
DNS
server
or
you
would
like
the
math
server
to
resolve
this
address
from
its
location,
which
might
be
close
to
you
or
not
the
important
part.
In
this
images.
We
use
this
yellow
line
here,
which
is
the
communication
channel
and
which
just
means
you
can.
You
know,
ask
additional
service
to
the
math
server
or
the
math
server
can
provide
you
some
additional
information.
D
For
example,
if
the
math
server
is
located
in
your
access
network,
the
math
server
might
be
able
to
give
you
additional
information
about
the
current
network
status
yep.
So
next
slide-
and
this
light
we
put
in
here-
because
there
is
a
related
proposal
in
the
quick
working
group,
which
is
called
quick
tunneling
and
they
focus
on
a
very
specific
use
case
where
the
client
is
multihomed.
D
So
usually
today,
you
have
a
lot
of
mobile
clients
who
have
a
Wi-Fi
connection
and
a
5g
connection,
and
the
goal
would
be
here
to
leverage
both
connections
at
the
same
time
and
in
their
draft.
You
find
this
picture
here
on
the
slide
where
they
have
some
kind
of
something
that
is
called
a
concentrator
in
the
network,
which
makes
it
possible
to
aggregate
the
traffic.
This
can
be
done
by,
for
example,
having
two
quick
connections
that
are
used
as
tunnels
on
the
different
network.
D
Legs
and
like
all
want
to
say
here,
is
that
this
concentrator
is
basically
kind
of
a
very
similar
to
math
server
and
a
math
server
can
provide
them.
Potentially
such
a
functionality
as
well,
and
the
point
here
really
is
to
to
standardize
and
to
work
on
a
common
proxy
control
protocol
that
can
cover
a
whole
set
of
use
cases
in
front
instead
of
trying
to
just
like
address.
Every
use
case
separately
with
a
different
approach
and
I
think
at
this
point,
I
give
back
to
the
chairs
right.
A
A
H
Hi
everyone,
my
name,
is
Alex
Aronofsky
I
work
on
Google
Google,
global
cache,
which
is
Google's
content,
delivery
network
and
I'm
here
to
talk
about
cubone,
the
quick
based
overlay
Network
environment,
which
is
effectively
a
VPN
that
we
built
in
order
to
help
manage
the
Google
global
cash
machines.
So
the
problem
which
we're
trying
to
solve
is
that
we
have
CDN
nodes
all
around
the
world
and
many
of
them
expose
management
services
which
we
want
to
reach
from
Google
data
centers
or
the
data
centers
exposed
services
that
we
want
to
reach
from
these
machines.
H
But
for
security
reasons
we
really
don't
want
to
expose
all
of
these
services
on
public
IP
addresses
using
regular
ports.
So,
in
the
past,
we've
hidden
this
traffic
through
HTTP
proxy,
and
this
has
not
worked
particularly
well.
What
we
really
like
to
be
able
to
do
is
provide
seamless
native
connectivity
to
allow
services
like
G,
RPC
or
other
TLS
authenticated
things
to
work
directly.
So
we
were
challenged
with
this
deployment.
Environment
in
which
is
P
is
basically
filter,
their
networks
very
heavily.
So
we
knew
things
like
IPSec
or
unlikely
to
be
available
to
us.
H
So,
after
looking
at
a
whole
bunch
of
different
solutions,
we
decided
to
leverage
quick,
which
we
had
already
shown,
that
we
could
serve
from
our
machines
towards
users
to
build
a
VPN
and
actually
be
able
to
hold
IP
frames.
This
current
diagram
shows
what
the
overall
architecture
here
looks
like
so
on
one
of
the
machines
in
an
isp
network,
we
run
a
user
space,
VPN
client,
which
itself
is
providing
a
tapper
ton
device
to
the
Linux
kernel
and
sets
up
IP
routing
rules
to
allow
native
IP
traffic
to
flow
through
it.
H
This
itself
establishes
a
quick
tunnel
through
regular
load,
balancing
techniques
to
a
so
called
VPN
Terminator,
which
is
living
inside
of
a
Google
Data
Center
Network,
which
also
has
the
ability
to
program
some
Software
Defined
Networking
routing
rules.
In
order
to
ensure
that
the
response
traffic
makes
it
back
to
the
VPN
terminator.
This
allows
us
to
have
seamless,
IP
connectivity
wrapped
in
a
quick
connection,
next
slide,
please.
H
So
why
quick
there's
a
couple
of
reasons
which
robusta
quick
over
IPSec?
The
first
was
the
pluggable
congestion
control.
This
meant
that
we
could
turn
it
off
for
the
tunnel
packets,
avoiding
the
standard
tcp
over
tcp
problem
meant.
We
also
had
pluggable
reliable
delivery.
We
could
turn
it
off
because
we
don't
need
retransmission,
because
the
inner
TCP
congestion,
control
and
reliable
delivery
should
take
care
of
that
as
well.
H
We're
looking
forward
to
working
with
the
mask
working
group
that
will
hopefully
be
formed
today
to
see
how
our
experience
can
help
feed
the
masked
rats
and
also
we're
looking
forward
to
taking
back
that
feedback
and
moving
our
changes
that
we
did
too
quick
to
be
able
to
use
the
standardized
form.
Thank
you.
B
B
So
I'm
not
going
to
reiterate
these
again:
it's
not
everyone.
Just
having
talked
about
them,
but
I
just
want
to
drive
the
point
home
that
we're
aiming
for
something
that's
sort
of
or
flexible
and
that
it
can
support.
You
know
Park
same
for
both
datagrams
and
possibly
stream
based
applications,
something
Isaac
sensible.
They
can
for
support
other
services
as
needed.
You
know
either
in
the
working
group
or
in
some
future
recharging
or
the
working
group
and
potentially
with
some
other.
You
know
knobs
bells
and
whistles
if
folks
think
they
are
truly
necessary.
B
B
So,
ideally,
the
solution
does
not
check
out
the
connection
setup
base,
not
in
the
connection
use
phase
later
on.
So
things
like
traffic
analysis
that
take
place
or
that
might
hurt
on
an
active
connection.
That's
proxying,
like
IP
datagrams
or
something
else
is
sort
of
not
something
that
we're
trying
to
hide
or
putting
into
being
in
to
requirements
right
now.
The
second
one
is
that
the
use
of
a
proxy
is
sort
of
explicit
by
a
client.
It's
not
something
that
you
know.
Clients
can
be
just
sort
of.
B
This
just
has
a
requirement
that
falls
out
of
that
as
sort
of
Jonah
to
tie
to
the
next
slide,
which
is
another
requirement
face,
it
means
it's
like
there
will
be
some
way
to
sort
of
bootstrap
and
discover
these
proxies,
but
we're
kind
of
considering
that
problem
out
of
scope
for
the
initial
our
group,
vertex
focus
specifically
on
the
the
mask
protocol
itself
and
the
framework
that
David
outlined
the
third
one.
This
basically
aims
to
say
that
each
service
or
application
that
one
might
use
over
mask
is
you
know,
unique
and
its
own
way.
B
It
might
have
its
own
semantics
and
then
that
negotiated
use
of
that
particular
service
via
UDP
proxying.
Something
simple
like
that
or
a
DNS
resolution
like
earlier
is
configurable
during
the
quote
negotiation
phase,
so
clients
and
servers
can
exchange
parameters
that
control.
How
of
the
this
particular
application,
or
this
particular
service
will
be
used
as
the
framework
for
protocol
should
support
that
for
just
reiterating
something
that
is
common
to
all.
B
The
security
of
that
does
not
depend
on
the
fact
that
you
Istanbul
it
over
mask
or
through
it
a
quick
connection
and
I
apologize
from
now
articulating
that
well,
but
basically,
the
point
is
that
they
are.
They
are
separate
protocols,
they're
not
meant
to
be
sort
of
joined
at
that.
So
if
you
can
move
forward
to
next
slide,
please,
like
I
said,
require
non
requirements.
Explicitly
otoscope
is
building
a
discovery,
bootstrapping
mechanism.
We
will
assume
that
one
exists,
be
it.
You
know
some
kind
of
static
configuration
one.
B
That's
you
know
Tenafly
an
authenticated,
dctp
option
or
you
know,
delivered
by
a
carrier
pigeon
or
whatever,
but
actually
laying
down
the
specifics
for
the
it's,
not
something
we'll
discuss
and
I
mean
it
may
influence
certain
protocol
things
or
decisions,
but
again
we're
not
going
to
try
to
work
specifically
to
focus
on
building
that
and
so
next
slide.
That's
questions
right.
So
I
don't
know
where
the
queue
start.
I
did
yep.
B
There
is
no
document,
however.
I
will
simply
take
my
understanding
of
the
remodelers
and
David
can
chime,
then
if
he
thinks
it's
wrong
or
different
or
whatever,
effectively
we're
assuming
a
very
trivial,
simple,
passive
adversary,
someone's
typing
very
loudly
between
the
client
and
the
math
server,
whose
only
ability
is
to
basically
look
at
what's
sent
in
clear
text
on
the
wire
and
things
like
any
sort
of
traffic
analysis.
That's
more
complicated
beyond
that
is
assumed,
not
feasible,
perhaps
incorrectly,
so
so
that
that's
like
I
should
know
for
not
claiming
it's
correct.
B
But
that
was
what
influenced
that
particular
decision,
and
the
idea
was
that
the
guy
was
trying
to
articulate
the
configuring
of
a
particular
mask
and
actually
would
not
use
like
an
al
viento
again.
Something
simple
like
that,
may
take
place
over
HP
or
whatever
something
inside
in
Greenville,
so
David
alternatives.
C
Oh
hey,
if
I
may
jump
in
David
nickens
as
here,
so
these
right
now
in
terms
of
documents,
we
kind
of
have
two
things:
we
have
the
Charter
that
we'll
discuss
later
and
then
we
have
kind
of
a
multiple
individual
proposals,
so
I
can
answer.
At
least
this
is
somewhat
discussed
in
my
individual
proposal.
So
this
is
not.
C
You
know
tied
to
the
Charter
by
any
means
yet,
but
the
idea
there
is
that
we
would
want
for
an
observer
on
the
path
to
let's
say
if
you
just
talked
to
a
random
web
server
to
not
have
an
obvious
way
of
knowing
that
this
is
proxy
traffic.
It
would
be
nice
if
it
would
look
like,
like,
let's
say
all
the
clear
text
bits
today:
the
s
and
I
the
ILP
and
things
like
that.
Look
like
web
traffic.
C
The
traffic
analysis
is
definitely
a
huge
concern
and
will
want
to
do
what
we
can
to
address
that,
but
at
least
I
it
would
be
important
to
catch
the
low-hanging
fruit
of
like,
let's
not
leave.
Anything
in
the
clear
text
then
make
this
a
big
blinking
light.
Oh,
this
is
proxy
traffic.
You
should
block
it.
B
E
A
A
L
Aside,
just
to
clarify
maybe
assumption
or
our
restrictions
around
network
topology
of
client
and
server
are
those
in
the
traditional
sense
that
the
client
can
be
netted.
But
the
server
must
not
be
must
be
a
publicly
reachable
by
the
proxy
I've
heard
at
one
point
you
say
something
like
the
proxy
may
also
provide
like
address
resolution
services,
not
just
name
resolution,
but
is
that
is
that
partly
intent
to
to
provide
stun
technicality
for
the
clients.
C
If
I
could
jump
in
here,
these
alligators
sure
yes
good,
so
the
the
goal
here
is
not
to
replace
done.
Tara
nice.
All
these
things,
I
think
the
at
least
my
current
thought
of
this,
and
maybe
it's
not
written
down
because
I
just
worked
with
that
assumption,
is
that
the
mask
server
is
not
behind
any
kind
of
net,
and
it's
just
a
box
that,
from
wherever
the
client
is
they
can
connect
to
yep
like
and
resolve
the
name
of,
and
similarly
the
what's
on.
A
L
B
B
C
I'll,
add
to
that
that
yes
and
I,
or
or
encrypted
s
and
I
or
encrypted
client
hello,
are
definitely
things
that
could
make
this
better.
But
currently
it
does
not
have
a
dependency.
It
does
not
have
requirement.
The
only
dependencies
right
now
are
quick
and
the
quick
Datagram
extension
if
I'm,
not
forgetting
anything,.
H
A
A
B
B
We
have
updated
it
slightly,
based
on
the
last
version
that
Eric
near
floated
on
the
list.
Thank
you
Eric
for
putting
that
together.
Again,
that's
very
helpful.
So
right
now,
I'd
like
to
is
just
kind
of
go
through
each
of
the
three
main
sections
of
the
proposed
charter
and
then
open
the
floor
to
discussion
for
refined
questions
in
discussion.
So
John.
If
you
could
move
ahead.
B
Right
so
the
first
thing
that
we're
trying
to
address
in
the
Charter
is
why
this
is
a
particular
problem,
so
this
is
effectively
motivating
we're
drawing
on
the
motivation
that
they
lean
out
and
his
earlier
slides
thing
that
practicing
is
useful
and
that
just
lost
two
different
technologies
it'd
be
nice.
Basically,
if
there
was
one
new
one
that
had
all
the
the
properties
of
all
these
existing
technologies,
so
hot
there
can
move
on.
B
So
that
I
level
won't
just
walk.
Quick
is
a
canon
protocol
compact,
which
should
be
fairly
familiar,
those
who
are
involved
in
the
development
of
quick
and
who
are
here
today.
So
I
don't
think
we
need
to
really
talk
specifically
about
the
send
more.
The
next
one
will
be
interesting,
so
go
to
the
next.
B
B
The
non
requirements
specifying
things
like
how
discovery
are
specific
discovery
mechanism
is
explicitly
otoscope
the
retarder
you
may
happen
later
on
to
sort
of
if
we
feel
the
need
to
pull
that
in
I'm
not
going
to
speculate
about
the
future,
certainly
if
it
does
require
any
dependencies
on
other
protocols
like,
for
example,
if
we
decide
that
we
need
to
have
hard
to
pendency.
On
echo
with
details,
pretty
group
and
the
relevant
workgroups
to
sort
of
make
our
artists,
you
know
see
that
come
to
a
completion
in
a
quick
and
expedient
manner.
B
B
Effectively
it
we
have
not
laid
out
a
particular
set
of
starting
documents
from
which
the
proposed
burn
group
start,
although
the
documents
said
have
already
been
discussed
in
particularly
the
core
protocol
mass
protocol,
that
David
has
does
look
at
the
fit
we're
going
to
be
a
good
place
to
jump
on
from
and
it
you
know.
It
says
due
to
some
of
these
use
cases.
B
Of
course,
I
don't
want
to
send
too
much
times
out
on
the
talking
about
the
specific
solutions
I'd
like
to
hear
from
people
who
are
queuing
up
in
the
mic
as
to
whether
or
not
this
is
heading
in
the
right
direction.
Are
there
things
that
should
change,
etc,
etc.
So,
with
that,
let's
I'm
recently
Chad
that
we
act
that
we
skipped
over
Tommy,
so
yeah.
B
Want
to
add
to
our
question
sure,
if
that,
if
that's
okay,
it
had
a
little
bit
more
to
do
with
the
requirements.
I
think
it's
also
somewhat
relevant
for
the
Charter
discussion.
Great
specifically
and
I
know
I'd.
Actually,
you
know
seen
the
requirements
list
before
and
we
had
the
item
that
was
out
of
scope
for
the
group,
which
was
how
do
we
bootstrap
this
I
just
wanted
to
ask
for
clarification
with?
B
How
much
is
that
out
of
scope?
Do
we
think
that
something
that
is
going
to
be
out
of
scope,
like
always
or
just
for
this
initial
charter,
and
specifically,
if
I,
think
about
how
we
look
at
other
things,
have
worked
like
dough?
That
was
a
group
that
didn't
describe
how
you
discover
it
and
right
now
we're
having
you
know
all
this
work
in
ad
D
about
how
to
do
that.
But
luckily
dough
did
define
in
the
URI
template.
B
How
do
we
communicate
about
a
dough
server
such
that
at
least,
if
I
have
other
discovery
mechanisms
like
DHCP,
like
DVDs
or
whatever?
We
have
a
way
to
communicate
it?
So
do
we
want
to
at
least
talk
about?
How
do
we
describe
a
mask
server
and
so
that
we
can
embed
bit
in
other
technologies
that
allow
its
discovery?
B
A
I
Potentially
did
it
right
and
in
the
right
coordinates
on
the
previous
discussion.
Doing
it
in
a
generic
way
that's
used.
Another
HP
traffic
would
be
a
real
benefit
instead
of
doing
in
a
way
that's
specific
to
this
protocol.
If
you
want
to
call
it
that
and
so
I'm
wondering
if
it
you
know,
if
that's
the
case,
whether
we
should
just
be
waiting
for
that
generic
mechanism
to
surface
hopefully
soon
then
describe
how
to
apply
to
connect
because
connect
is
frankly
a
bit
of
a
mass.
It's.
I
It's
got
some
issues,
because
it's
somewhat
personal
specific
and
we're
trying
to
sort
those
out
curly
in
the
core
work
and
the
result
would
be
probably
a
fairly
small,
spec
I.
Think
you'd
focus
mostly
on
you
know.
What
is
the
the
payload
in
the
headers
of
the
connect
and
the
response
to
negotiate
some
application?
Specific
metadata
I'd?
Be
really
interested
to
hear
I
guess
David's
response
to
that.
C
C
Kennedy
here
so
I
think
for
some
parts
of
this
this
could
be
solved
at
the
HTTP
layer,
but
I
think
kind
of
conceptually.
But
the
goal
here
is
not
to
change
in
any
way
shape
or
form
like
HTTP
semantics,
as
in
like
you
still
can
do
the
same
things
with
HTTP
but
like,
for
example,
one
open
question
and
like
some
of
the
drafts
address,
that
is
well
for
unreliable
things
like
datagrams.
C
Even
if
you
know
we
were
to
define
something
for.
Let's
say
you
know
downloading
a
video
unreliably
that
would
probably
use
quick
datagrams
inside
an
HTTP
connection,
but
it
would
still
require
TP
semantics
and
which
is
normal
and
I
would
expect
a
should
be
working
group
to
work
to
provide
us
with
that.
But
here
I
think
there
are
cases
for
things
that
are
nowhere
near
HTTP.
So,
for
example,
let's
say
I
want
to
transmit
a
ICMP
over
this
or
just
a
raw
UDP
packet
of
some
custom
UDP
protocol.
C
D
Can
I
yes
miracle
into
it
kind
of
jump
in
as
well.
So
I
do
agree
with
you
that,
like
disconnect
method,
could
provide
very
similar
mentality
but,
to
be
honest,
I
mean
HTTP
connectors,
really
a
heck
right.
It's
not
really
part
of
me
or
it's
not
like
the
HTTP
protocol,
using
it
pretty
just
something
to
indicate
forwarding,
and
that
is
very
similar
to
what
we
but
I
think
some
of
the
use
cases
we
have.
I
D
D
C
L
C
F
I
Okay,
then
I
guess
from
my
perspective,
I'll
end
with
to
me
before
something
gets
chartered.
It
seems
really
fundamental
that
you
define
whether
or
not
you
define
in
a
new
application
protocol
on
top
of
quick
or
you
defining
an
extension
to
an
existing
protocol.
Let
I
don't
think
you
can
charter
without
doing
that.
I.
A
C
Good
yeah,
I,
know
and
I
totally
agree
with
mark.
There.
I
see
this
as
a
different
protocol,
given
that,
like
the
use,
cases
and
constraints,
are
very
different
and
like
that's,
why
I
think
it
would
make
sense
to
have
it
in
its
own
working
group,
because
the
questions
asked
would
be
pretty
different
from
the
ones
in
in
the
HTTP
working
group,
but
I
mean
part
of
the.
Why
we're
here
in
this
valve
is
to
figure
that
out.
M
Mark
just
to
like
put
you
on
the
spot
there.
If
you
look
at
the
last
paragraph
on
this
page
right,
it
says
if
it
requires
extensions
to
any
existing
protocols.
I,
like
this
group,
should
coordinate
with
a
group.
Does
that,
like
you
know,
kind
of
answer
at
least
some
part
of
your
question
that,
like
you
know,
if
you
have
to
do
some
extensions,
we
go
back
to
where
this
needs
to
happen.
I
think
the.
M
J
I
Potentially,
yes,
my
concern
that
you're
hearing,
probably
behind
what
I'm
asking,
is
that
going
and
doing
things
like
redefining
connector
and
defining
you
know
new
methods
and
things
are
fairly
invasive
changes
to
http
and
there's
a
lot
of
faults
there.
So
it
would
have
to
be
a
very
close
coordination.
Okay,.
A
E
I
have
to
read
might
have
to
reload
I
apologize
if
I
drop
out,
so
the
first
line
of
the
charters
says
the
property
is
good,
but
it
doesn't
say
why
it's
good
and
I
think
saying
why
it's
good
would
be
very
important
in
this
context.
Understanding
water,
what
properties
we're
looking
for
out
of
proxying
is
would
be
I,
think
critical,
I
think
we're
looking
for
the
privacy
aspects
of
it,
but
that's
not
clear
from
the
Charter.
E
A
C
Eric
rajala
so
Marc
said
some
of
what
I
was
going
to
say:
I
guess
I,
when
I
first
heard
about
this
I
envisioned.
This
is
like
super
connect,
ie
connect
with
unreliable
and
maybe
we'd
like
clean
up
some
of
the
semantics.
That's
something
I'm
quite
interested
in
you
know.
We
have
things
that
use,
connect
and
we've
all
been
being
reliable,
I'm
much
less
enthusiastic
about
sort
of
this.
You
know
application
specific
stuff
like
quick
and
DNS
I
think
like
we
should
just
to
offer.
C
L
F
C
Puzzles
clear,
like
a
h2
retention,
it's
not
like
some
quickie
thing,
so
I
never
be
a
good
idea.
Now
that
I'm
no
longer
an
ad
I'm
like
I'm
like
allowed
to
be
so
late,
but
what
about
whether
it
is
an
HTTP
dis
or
in
working
group,
quick,
but
I,
think
that,
like
it's
relatively
small,
so
you
know
it
should
be
done
quickly.
No
matter
what
this
and
me,
if.
C
To
a
curb
I,
so
yeah,
this
kind
of
goes
back
to
semantics,
where
I
I
totally
agree
with
you
that
it's
not
that
much
work
to
add
these
things
and
if
we
end
up
building
it
as
like,
the
current
mass
proposal
or
if
we
end
up
building
it
as
like
new
a
new
HTTP
verb,
for
example,
I
think
that's
something
that
we
should
decide
as
a
mask
working
group
hypothetically,
if
it
were
formed.
I
understand
that
for
your
use
case,
the
like
UDP
Connect
is
completely
sufficient,
but
I'm
not
sure.
C
F
C
C
Is
good,
obviously
I
suppose
a
good
feature
on.
However,
it's
not
totally
something
we
can
put
today,
because
if
you
read
the
Charter
text,
it
strongly
implies
that
we
build
a
quick,
specific
and
ACP
quick,
specific
service
and
that's
actually
something
I,
don't
think
we
should
do
and
so
I'm
not
prepared
to
have
a
charter
with
that
in
the
Charter.
So
Edgar
could
I
ask
you
to
clarify
why
you
think
we
shouldn't
do
this,
so
you
don't
have
a
use
for
it,
but
some
other
folks
might
I.
C
I
guess
I
I
guess
so
I
mean
this
goes
back.
I
think
to
some
concern.
Processes
are
high
back
and
forth
in
Java,
in
a
sense
that,
for
many
of
the
cases
we're
interested
in
you
know
you
can
just
like
get
by
like
term
would
do
the
job
right.
I
mean
this
in
some
respects
they
like
term
with
different
spelling,
and
so
in
what
way?
N
Bernard
you
next
Hey
I'd
like
to
follow
up
on
some
of
what
occurs
just
talked
about
I.
Think
there's
a
about
scope
here.
We've
talked
a
lot
about
the
framework,
but
I
have
some
questions
about
the
overall
protocols
that
we're
looking
at
support
down.
The
road
I
think
it
has
to
be
relatively
clear
what
the
overall
scope
is,
because
it's
very
difficult
to
answer.
For
example,
some
of
the
questions
that
occur
asked
about
this
threat
model.
N
C
C
You
know,
after
a
recharter
still
in
a
purview
of
this
working
group,
to
define
new
ones
and
but
be
like
security
model
of
mask
itself
should
be
really
seen
in
the
light
of
just
the
framework
and
have
like
just
a
security
model,
that's
well
defined,
and
then
the
applications
would
then
decide
if
their
requirements
are
met
by
the
security
model.
If
they
want
to
build
something
on
top
of
masks,.
C
A
C
Web
transport
is,
you
know,
a
pretty
specific
proposal.
You
know
OSHA
q3c
and
the
IETF
I
want.
It
provides
a
message.
Oriented
transport
I
just
want
to
put
IP
datagrams
in
in
those
boxes
and
ship
them
back
and
forth.
It's
you
know
it's
such
a.
It's
so
simple.
It
almost
doesn't.
You
know
it's
like
a
three-word
RFC.
C
F
C
Jump
in
to
answer
that,
one
as
mask
enthusiast
and
also
chair
of
web
trans,
so
there
is
definitely
a
lot
of
similarities
between
mask
and
web
track
transport.
Absolutely
they're,
both
hey.
How
do
we
ferry
stuff
on
top
of
quick
there's
this
new
quick
thing?
We
should
do
cool
things
with
it,
but
the
requirements
are
very
different,
and
so
the
goal
of
web
transport
very
clearly
is
to
have
something
that
is
accessible
to
the
web.
So
the
focus
is
the
web
security
model
and
taking
taking
things
from
WebSocket
and.
C
That
in
the
world
of
quick,
so
let's
say
how
do
we
do
WebSocket,
but
with
UDP,
but
the
goal
there
is
to
make
it
accessible
to
the
web
and
by
that
I
mean
JavaScript
running
in
a
browser.
If
what
you're
trying
to
do
with
IP
here
is
a
VPN
client
on
you
can't
do
that
from
inside
a
browser,
and
you
really
shouldn't
trust.
C
Where
that's
interesting,
but
it's
not
that
it's
not
the
use
case.
We're
focused
on.
But
my
point
is
mostly
that
as
a
at
the
protocol
level,
ignoring
essentially
ignoring
the
w3c
components,
looking
solely
at
the
IETF
components
of
web
Transport,
that
you
could
just
throw
some
IP
packets
on
top
of
it,
and
that
would
fit
the
bill
here.
And
so
we
can.
C
We
can
invent
some
more
stuff
if
we
want,
but
there
are
some
essentially
reusable
components
that
we
can
just
stick
together
and
call
today
and
I
brought
this
up,
partly
as
a
counterpoint
to
what
Mark
Nottingham
was
mentioning,
where
I
just
have
some
difficulty,
believing
that
the
HTTP
working
group
is
really
going
to
standardize
a
component
of
HTTP
itself.
That
will
let
us
ship
an
arbitrary
IP
Datagram
to
an
arbitrary
IP
destination.
J
If
you
go
to
the
charter
text
on
slide,
26
that
describes
the
motivations
that
have
work
I,
don't
believe
it
actually
motivates
any
of
the
work
that
would
have
the
the
proxy
deliver
services
outside
of
sort
of
wrapping
and
unwrapping
packages
at
one
end
of
the
spectrum
and
acting
as
an
HTTP
connect
proxy
at
the
other
and
I.
Think
if
you
go
back
to
28,
sorry
to
ask
you
to
flip
around
Jonah,
if
you
go
to
the
section
that
says,
specify
mask
server,
discovery
is
out
of
scope
of
the
group.
I.
J
J
It's
going
to
ship
IP
packets,
to
whoever
it
was
told
to
ship
them
to
on
the
inner
part
of
the
tunnel
and
call
it
a
day.
You
have
what
Lukas
has
talked
about
in
the
jabber
chat,
which
is
essentially
an
HTTP
proxy
for
atv-3,
and
you
have
this
sort
of
generalized
thing
where
it's
offering
services
to
to
the
endpoint
of
over-over,
quick,
which
might
be
DNS.
So
it's
not
it's
not
acting
to
go
back
to
the
figure.
J
It's
not
a
blue
line
where
the
client
tells
the
proxy
server
go
to
this
DNS
server
and
ask
this
question:
ask
this
traffic
to
that
DNS
server,
but
instead
is
asking
it
to
do
the
resolution
and
I
realized
what
the
Turner
is
saying.
Is
it
once
I
build
a
framework
but
I
think
at
this
point,
you're
asking
it
to
deliver
both
chalk
and
sheets
and
building
a
framework
that's
going
to
deliver
both
of
those
may
not
be
the
most
effective
way
to
do
that.
J
If,
in
fact,
you've
got
three
different
goals,
three
different
documents
and
three
different
approaches:
maybe
the
right
way
to
resolve
this
and
I
think
the
Charter
needs
to
be
really
clear
in
its
selection.
Of
what
its
primary
use
case
is
because
what
I'm
reading
in
sort
of
the
side
channel
here
is
that
there's
a
pretty
fundamental
disagreement
about
whether
this
is
a
you
know,
everything
over
mask
type
BBN
or
whether
this
is
in
fact
an
HTTP
proxy
that
works
with
with
quick
and
I
think
much
of
the
presentations
up
to
this
point
kind
of
assumed.
J
D
D
We
actually
tagged
it
that
at
the
same
solution,
because
the
basic
mechanism
of
the
basic
assumption
you
need
here
is
with
you
just
forwarding
and
everything
else
you
can
build
on
top
of
that
and
the
endpoint
is
here:
it's
not
the
kind
of
forwarding
you
have
with
Sox
o
or
ever
today,
where
you
have
to
open
a
different
connection
for
every
thing
you
want
to
forward.
It's
really.
You
have
already
this
outer
Creek
tunnel
and
it
is
there
and
you
can
just
use
it
and
you
can
build
things
on
top
of
this
forwarding.
D
Given
you
have
a
direct
connection
between
the
client
in
the
proxy
and
I
think:
that's
the
big
benefit
here,
to
not
go
and
in
separate
and
build
like
three
times
the
same
protocol,
but
trying
to
actually
have
one
protocol
that
can
address
many
of
the
use
cases
and
can
be
flexible
and
extendable.
So
it
can
actually
also
cover
future
use
cases.
A
J
Yeah
or
to
start
thank
you
all
for
bringing
this
proposal
forward
and
I'd
really
like
to
thank
people
on
focusing
on
the
you
know
different
use
cases
the
people
were
thinking
about,
because
I
think
that
really
got
us
out
of
the
we're
hiding
all
of
our
product.
All
of
our
servers
place
that
this
kind
of
started
and
turned
this
into
something
that
a
lot
more
people
can
work
on.
J
I
think
that
getting
to
be
really
crisp
about
what
this
is
most
like,
because
you
know
I,
think
people
are
kind
of
seeing
this
is
this
is
a
relay,
or
this
is
a
tunnel
in
you
know
timely
mechanism,
or
this
is
a
proxy
or
something
like
that-
and
you
know
I
think,
is
so
I
think
ditching
a
certain
amount
of
the
first
paragraph
or
you
know
it's
like
yeah.
These
are
kind
of
these
are
kind
of
middle
boxes,
so
you
know
yeah
those
what
those
were
middle
boxes.
But
what
are
we
really
going
to
do?
J
I
think
that
that's
going
to
be
important,
I
think
that
that
was
one
number
two
on
the
thing
on
discovery
and
having
that
be
out
of
scope,
for
this
would
make
me
feel
better
if
we
had
some
idea
of
where
that
was
headed
like
it
was.
Are
there
mechanisms
that
we
could
point
to
now
and
things
like
that
they
would.
That
would
make
us
feel
better
about
this.
You
know
I
mean
you
know.
I
just
didn't
want
this
to
turn
back
into
host
text
as
a
way
of
configuring.
This
go.
J
J
Think
that,
because
you
know,
we've
got
the
thing
in
the
in
the
Charter
about
we
punt
to
the
other
working
groups,
but
just
if
we
can
be
if
we
go,
if
we're
going
into
this,
knowing
that
we're
that
we
have
gaps
being
real
clear
about
that
upfront
would
be
helpful,
also
and
I'll.
Stop
by
saying
I,
don't
know
that
we're
going
to
have
another
face-to-face
IETF
this
year,
so
I
definitely
work
work.
J
A
A
G
Reason
what
you
don't
want
to
I'm
sorry,
Cara
Kartal,
and
this
overdoing
just
quick
inside
quick,
is
the
compression.
But
am
I
misunderstanding:
is
there
like
an
additional
round
trip
between,
like
there's
an
additional
mass
negotiation
that
has
to
happen
before
quick
right?
So
is
that
are
you
like
trading
off
time
for
bandwidth
or
latency
for
bandwidth
or
am
I
missing,
something
like
an
additional
benefit
of
mask
so
for
quick
inside
quick,
so.
C
G
C
D
Yeah
I
would
like
to
here's
a
miracle
of
and
I
like,
would
like
to
add
that
I,
don't
think
it
necessary
had
to
have
to
add
another
round-trip
time.
It
depends
on
how
we
design
this
kind
of
negotiation
protocol
and
the
negotiation
protocol
might
be
only
the
client
instructing
the
server
to
do
something
because
it
already
knows
the
capabilities
of
the
server.
So
you
could
basically,
in
the
same
amount
of
time,
instruct
the
server
to
do
something
and
send
the
data
in
order
forward.
C
So
I
guess
my
I
mean
I
certainly
have
the
concern.
I
think
somebody
mentioned
this
on
the
job
or
this
will
be
an
xkcd
9:27
problem.
So
I
guess
my
question
is:
to
what
extent
would
you
know
turnover,
quick
and
over
socks
six
over
quick
or
possibly
either
of
them
over
WebTrends
meet
the
requirements
and
to
what
extent
will
they
not
because
I'd
rather
you
know,
there's
a
I
think
a
sacrament?
Is
it
a
lot
of
existing
semantics
worked
on
which
you
know
it's
better,
not
to
reinvent
things.
C
So
I
so
I
apologize.
This
is
what
I
try
to
address
this
in
my
slides.
Oh,
we
have
a
bunch
of
wheels
but
quick
kind
of
showed
up
and
like
kind
of
proved
to
us
that
a
lot
of
those
wheels
don't
fit
the
bill
anymore.
So
something
needs
to
be
done
and,
honestly,
the
output
of
the
mass.
What
you
doesn't
need
to
be
you
know
a
brand-new
shiny
protocol
with
its
own
name.
You
know
as
her
and
I'm
not
we're
saying.
If
this
ends
up
being,
let's
say:
I,
don't
know
methods
in
HCP.
C
N
What's
matter,
Michael
I
have
a
question
that
sprout
might
be
a
relatively
narrow,
buy
it's
about
the
impact
of
congestion
control.
I
am
a
su
slides
with
quick
and
quick
to
want
this
only
given
that
the
inner
quick
is
encrypted.
Won't
this
only
really
work.
If
you
have
have
unreliability
of
the
packets
that
you're
sending
those
in
your
quick
packets
in
to
avoid
the
problems
of
TCP
and
TCP,
where
all
sorts
of
bad
things
happen.
D
This
is
me,
included
an
M,
so
it
depends
on
really
what
the
scenario
is
and
that's
why
we
actually
want
to
have
this
different
services
that
you
can
request
from
the
proxy.
But
there
are
scenarios
where
you
can
also
use
this
for
on
a
reliable
stream
for
local
recovery.
If
you
have
a
very
short
little
arts
model,
a
link,
but
it
has
high
high
loss
just
having
a
reliable
channel.
D
C
If
I
could
add
something
there
as
well,
so
for
something,
let's
say
this
is
the
scenario
we're
tunneling
TCP
/
IP
over
this.
For
for
some
reason-
and
yes,
if
you
do
TCP
/
TCP
performance
is
bad.
We
have
an
ample
amount
of
papers
demonstrating
that,
but
the
important
thing
here
is
that
what
makes
this
bad
is
to
thing
is
one
of
two
things
that
are
often
conflated
there.
C
If
you
look
like
a
at
any
router
on
the
Internet
today,
assuming
you're
speaking
to
something
on
the
internet,
that
is
multiple
hops
away.
Your
router
has
a
queue
and
you
can
call
that
queue
management
algorithm
a
type
of
good
for
it,
there's
more
coming
in
on
one
side
than
the
other.
It
will
drop
packets
to
rate
limit
deal
so
having
this
level
of
nested
congestion
control
actually
is
no
different
than
just
having
a
node
or
router
on
your
path.
That
is
dropping
you
if
you're
going
too
fast,
so
I
do
think.
A
B
Alright,
thanks
sorry
for
the
delay
Tommy
Polly.
This
is
going
back
a
little
bit
to
the
comments
that
been
made
about
the
relationship
with
web
Transport.
I.
Think
that's
a
really
interesting
thing
to
bring
up
and
kind
of
merging
the
approach
and
the
protocol
bits
could
actually
make
a
lot
of
sense.
I
do
encourage
to
David's
response,
saying
that
there
are
different
use
cases
and
different
motivations
I
want
to
encourage
that
we
shouldn't
be
defining
things
separately
in
different
groups
and
different
knobs
within
the
same
protocols
h3.
B
Just
because
one
comes
from
VPN
approach
and
one
comes
from
the
w3c
and
JavaScript
they
can
both
rely
on
the
same
protocol.
Knobs.
Of
course,
I.
Think
that
would
add
a
question
of
how
would
supporting
these
interests
affect
the
web
Transport
Charter.
If,
though,
documents
were
to
help
include
some
of
the
hhv
bits
that
were
necessary
for
this
and,
at
the
very
least,
I
think
for
the
purpose
of
this
charter,
you
should
add
a
touch
point
with
web
trends
listed
in
the
groups
that
we
need
to
talk
to.
C
O
C
I
I
O
If
so,
how
do
you
not
bad,
and
all
those
issues
I
think
this,
that
the
Charter
is
very
it's
thinking
about
it
very
much
as
everything's
initiated
from
the
downstream
side,
but
it
doesn't
talk
about
initiation
from
the
upstream
side
at
all.
So
I'd
like
to
see
the
the
Charter
a
little
clearer
in
that
scope,.
C
C
D
I'm
not
sure
I'm
sending
this
kind
of
present
yet
because
so
in
the
in
the
diagram
we
had
I
think
the
term
client
mask
server
and
target
server.
They
were
more
indicating.
You
know
where
the
tunnel
is,
and
we
always
say
the
talent
is
between
the
client
and
the
mask
server,
but
it
doesn't
really
mean
what
the
actual
application
connection
does
do
here.
So
I'm
not
sure
what
what
you're!
Looking
for?
What's
the
scenario
you
have
in
mind
well,.
O
O
C
I,
don't
think
that's
the
goal,
and
that's
thanks
calling
for
isolating
that.
I
think
what
we'll
want
is
to
say
no.
The
client
has
expressed
interest
in
tunneling
to
this
destination.
So
if
you
have
packets
on
the
return
path,
send
it
to
the
client
and
if
you
have
weird
packets,
that
you
don't
understand,
maybe
drop
them
on
the
floor,
but
yeah
that
should
be
clarified.
It
was
kind
of
a
working
assumption
that
we
forgot
to
document.
O
C
D
A
All
right,
I'm,
I'm,
gonna,
move
this
along
I
even
had
one
comment
which
I'm
going
to
relay
one
of
my
other
mic
here.
He
says
we
should
pursue
this
work,
but
we
need
to
determine
whether
it's
so
real,
quick
or
over
HTTP
3
before
creating
the
working
group-
and
this
is
more
for
the
quick
chairs-
this
work
makes
me
think
the
Datagram
may
be
needed
in
quickly
one
or
Garriga
might
be.
This
will
travel
quickly,
one
for
this
work,
and
you
want
to
thoughts
on
that,
but
we're
not
going
to
do
that
discussion
here.
A
A
B
B
G
A
B
Alright,
so
thanks
everyone
on
the
feedback
from
the
Charter
on.
We
will
work
after
this
to
sort
of
clarifies
several
the
key
points
that
were
raised
in
particular
around
throwing
up
motivating
texts
in
the
football
trying
to
suss
out
whether
or
not
this
is
a
new
protocol
or
an
extension
of
a
protocol,
the
quick
vs.
they
should
be
throwing
thing
and
other
issues
that
I've
made
out
of
here.
B
We
both
dissent
of
what
this
is
something
that
we
want
to
go
forward
with
some
air
here
so
now
think
about
questions,
and
so
in
the
interest
of
time,
I
think
the
the
way
we'll
do
this
is
I
will
just
post
a
question.
There
will
not
be
a
home
of
any
particular
type
just
want
to
hear
what
people
think.
So
you
know
please
keep
up
to
the
mic.
You
have
disagreements
with
what's
written
here
or
disagreements
with
what
I'm
saying
right
now.
Thank
you
mark
and
we
can
go
through
there.
Mark
I'll
turn.
B
Okay,
so
I'm
kidding
first,
so
the
first
one
immediately.
There
was
a
lot
of
question
about
the
specificity
in
the
charter
text
as
proposed,
but
I.
Imagine
that's
something
we
could
work
through,
but
in
a
general
at
a
general
level
like
a
know
or
here
from
Oakland
tonight,
you
think
the
effectively
the
scope
of
the
problem
that
we're
trying
to
solve
a
laid
out
in
the
motivating
text
from
Davis
and
the
foremost
case
that
we
described
in
and
the
motivating
Carter
proposed
to
our
text
is
well-defined
and
well
understood.
B
B
C
So
I
guess
I
came
into
this
thinking
that
they
were
well
defined
and
whoa
understood
and
I
thought
that
it
was
basically
what
I
think
you
know.
Colin
would
call
a
symmetric
that,
namely
you
know,
you'd
be
able
to
make
outgoing
connections
with
like
UDP
and
and
like
we
can
fight
about
this
quick
for
JCP
thing
later,
but
basically
be
like
outgoing,
but
on
this
:
points
out,
basically
the
question
whether
there's
going
to
be
server
on
functionality
or
table
functionality
or
raw
IP.
C
I
Mark
Nottingham,
yeah
I
agree
with
whatever
says,
I
think
the
abstractions
that
are
being
boarded
really
need
to
be
nailed
down
to
the
Charter
I.
Don't
agree
that
this
could
be
sort
of
the
working
group
says
people
are
going
to
come
in
with
wildly
different
expectations
and
it's
going
to
cause
a
lot
of
friction.
I
think
it
needs
to
be
defined
personally,
whether
this
is
a
new
protocol
on
top
of
quick
or
whether
it
is
htv-3
extension
or
extensions
or
something
else.
C
Okay,
so
clearly
that
the
scope
is
not
universally
well
understood,
I,
don't
think
that
we
need
to
fully
specify
the
the
layering
I
think.
The
key
requirement
that
I
do
think
we
could
get
consensus
on
here,
for
the
Charter
is
to
say
that
this
protocol
can
run
inside
a
quick
Association
alongside
HTTP
inside
a
quick
Association
that
is
owned
by
HTTP
3.
N
Okay,
I
think
the
scope
of
the
problem.
It
seems
that
there's
a
lot
of
questions
about
whether
or
not
things
like
AI,
whether
just
forwarding
sections
at
connection
layer
or
application
or
IP
layer
and
bla
support.
All
of
those
are
those
all
connected,
so
I,
don't
think
I
think
that's
an
area
that
would
like
to
see
more
clarity
on.
N
Yeah,
so
we're
talking
about
something
like
law
forward,
not
proc
to
GDP,
while
proxy
quick,
we
want
to
proxy
TCP,
we
wanna
proxy
IP.
These
are
all
different
things
and
are
they
all
going
to
be
available?
All
the
time
are
there
going
to
be,
is
going
to
be
serve
a
menu?
Is
it
going
to
be
so?
Are
these
love
layer
on
top
of
each
other?
So
the
way
before
word
quick
is
the
way
before
UDP.
F
A
E
E
E
It's
pretty
hard
of
thing
where
you
use
in
the
in
the
current
set
of
proposals,
but
there
is
your
framework
at
the
moment
for
I,
guess,
discovery
of
capabilities
and
and
so
forth
and
I,
don't
think
that's
very
well
formulated,
but
the
suggestion
well
I
could
extrapolate
from
there
and
say
that
there's
possible
things
that
are
shared
across
quick
proxying
versus
IP
proxying,
those
UDP
proxy
inverse
of
the
TCP
proxying
that
all
require
the
same
sort
of
signaling
and
I'm.
Not
seeing
any
motivation
for
that
and
I
would
rather
see
that
go
okay.
Thank
you.
E
H
C
But
the
idea
was
what,
if
we
allow,
having
multiple
things
inside
this
same
connection
to
my
proxy
in
a
way,
that's
not
visible
to
on
path,
observers
and
I.
Think
that's
for
me
the
main
justification
for
having
what
I
call
the
framework,
which
is
to
be
able
to
have
multiple
of
these.
At
the
same
time,
that's.
A
It
is
actually
useful.
This
is
good
because
I
think
framework
might
confuse
a
lot
of
people.
It's
a
very
general
term
and
being
more
specific
is,
is
something
that
we
could
do
in
the
current
Charter.
That's
one
of
the
pieces
of
feedback
I'm
taking
back
is
that
the
Charter
needs
to
certainly
be
more
closed,
and
this
is
a
very
precise
registry.
K
Fish
if
I
feel
like
there
are
a
lot
of
scenarios
here
and
I'm,
not
sure
that
we
actually
need
to
solve
all
of
them,
because
solving
some
of
them
would
give
you
the
means
to
solve
the
others.
So,
like
you
know,
I
don't
know
that
we
care
about
HTTP
proxy.
If
you
can
do
TCP,
you
can
do
quick
if
there's
h3
support
on
the
other
side,
generic
IP
flus
seem
like
what
you'd
want
for
a
VPN.
B
You
know
thanks
Mike
to
your
first
point.
It
very
well
might
be
that
the
actual
solution
is,
you
know,
ESPO
proxying
protocol
for
UDP
TCP
in
applications,
and
everything
is
built
on
top
of
that.
It
might
have
some
additional
expense
ability
points,
but
I
don't
want
to
get
too
specific
into
with
the
solutions
right
now.
B
So
I
want
to
cut
it
here,
because
we
still
have
a
couple
more
questions
to
get
through.
So
my
understanding
is
that
effectively
that,
despite
sort
of
lack
of
clarity
and
Christmas
with
how
we
supplied
the
problem
and
what
we're
actually
trying
to
solve,
there
is
some
interest,
and
you
know,
sort
of
working
on.
You
know
some
subset
out
there.
Sending
the
challenge
would
be
to
sort
of
articulate
what
that
particular
subset
is
in
a
meaningful
way.
B
B
B
Alright,
great
some
people
are
chatting
and
thank
you
very
much
so
that
brings
to
the
last
question,
particularly
around
the
existing
charter,
the
proposed
charter
member
group
regression.
We
felt
it
was
not
appropriate
to
specifically
ask
if
a
working
group
should
be
formed.
This
charter
text
in
mind,
as
we've
discovered
throughout
the
course
of
this
being
there
are
some
textual
edits
that
could
be
made
to
the
Charter,
as
well
as
some
content
refinements.
That
could
be
made
as
well
to
sort
of
help
us
on
a
trajectory
for
success.
A
Jump
in
there
very
briefly,
because
we
have
about
20
plus
ones
for
the
community
participation
question
so
I
think
it's
safe
to
say
that
there's
a
fair
amount
of
good
question.
A
number
of
them
are
about
contributing
people
willing
to
learn
and
contribute
with
the
work
which
is
excellent,
okay,
so
more
than
20
at
this
point,
so
that
is
very
good
and
just
my
last
question
I
want
to
add
that
let's
be
careful
here,
the
important
thing
here
is
to
this
state.
A
If
you
believe
that
the
work
group
should
not
be
from,
we
have
heard
I
think
the
problem
statement
of
question
of
scope,
as
mentioned
earlier,
is
very
clear.
We
do
need
to
work
on
that
in
terms
of
the
Charter,
but
I
would
like
to
move
on
to
quick
questions
on
the
last
one.
Because
did
you
want
to
say
something
else
know
how
to
move
on
to
questions
on
this?
No.
A
J
It
might
turn
out
that
the
work
belongs
in
an
existing
working
group
like
other
web
transport
or
HTTP.
So
I,
if
you
ask,
does
anybody
feel
like
this
work
should
not
be
done.
I
would
keep
silent,
but
that
a
working
group
should
be
formed.
I'm
much
less
sure,
so
I
would
I
would
currently
say
no
to
that
until
until
we
get
one
answer.
M
Good
enough,
mr.
Strickland,
just
like
cutting
in
Ted.
So
is
your
concern
about
the
actual
mechanics
of
doing
this,
like
so
you're,
okay,
with
like
some
kind
of
work
in
this
space,
but
you
don't
want
to
presuppose
maybe
a
new
booking
group
that
does
it.
Would
that
be
a
fair
summary
of
what
you
wanted
to
say.
J
If
Ed
Hardy
speaking,
yes,
sir
sure,
that's
a
fair
summary,
I
and
I
believe
that
there's
enough
work
here,
it
might
actually
see
some
of
the
work
of
one
group
and
some
of
the
work
go
into
new
group
or
into
a
different
group.
It
just
kind
of
depends
on
how
the
scope
gets
pulled
out.
I
just
think
the
use
cases
may
shovel
is
that
the
work
belong
somewhere
else,
sort
of
the
work
at
least
along
and
something
else
other
than
a
worker.
J
Thank
you
for
queueing
that
up
red,
because
I
think
that
some
so
some
flavors
of
this
work
that
different
people
have
been
talking
about,
I
think
should
be
done.
I
agree
with
Ted's
comment
about,
maybe
not
in
a
new
working
group.
Maybe
not
just
in
one
working
group
and
I
know:
God
loves
the
quick
working
group,
but
it's
not
totally.
I
F
A
That's
I
think
that's
coming
to
loud
and
clear,
and
a
part
of
it
is
just
that
there's
a
good
part
of
it
that
is
figuring
out
how
to
be
more
specific
and
more
precise
and
more
tighter
than
the
Charter,
and
in
doing
that,
exercise.
I
think
we
might
come
out
and
find
something
that
we
don't
know
yet,
meaning
that
maybe
doesn't
require
a
working
group.
But
that's
excellent
feedback
and
we
are
at
time
letting
mark
and
not
in
the
queue
I
mean.
M
E
A
M
So
I
think
yeah.
Thank
you
very
much
for
everybody
for
contributing.
So
there's
like,
at
least
in
the
Charter
there's
like
a
couple
of
issues
that
came
up
and
both
of
them
important,
I
think
one
of
them
is
like
it
was
kind
of
like
underspecified
a
little
bit.
It
is
a
little
bit
big
like
you
know.
What
is
the
scope
of
the
Charter?
M
So
that's
a
positive
thing,
but
I
really
do
think
like
you
need
to
work
a
bit
on
the
Charter
to
scope
it
down
a
bit
specifically
kind
of
like
on
the
same
lines
that
Kullen
an
acre
pointer
out
a
bit
and
also
kind
of
not
presuppose
the
actual
mechanism
and
see
how
things
fall.
So
that's
kind
of
falls
back
more
to
like
you
know
what
Ted
was
saying
and
I
think
like
Mark
was
saying
too
so.
I
think
that's
kind
of
the
directions
like
you
know.
M
We
need
to
go,
and
let's
do
that
on
the
mailing
list
and
personally,
it's
not
clear,
like
you
know
where
this
would
end
up
like
I
picked
it
up,
because
it's
like
a
tunneling
thing
and
interior.
So,
like
we'll
figure
like
I
know
where
it
needs
to
go,
this
work
needs
to
go
once
we
have
a
better
understanding
of
what
needs
to
get
done.