►
From YouTube: IETF113-MASQUE-20220321-1330
Description
MASQUE meeting session at IETF113
2022/03/21 1330
https://datatracker.ietf.org/meeting/113/proceedings/
A
A
A
A
A
C
C
C
B
B
B
We
didn't
quite
get
interrupt
in
the
room,
but
we
did
amusingly
with
the
latest
drafts,
since
they're
wire
format
compatible
with
the
previous
ones.
Assuming
you
just
disabled
contacts,
we
already
have
a
drop
which
I
copied
the
matrix
from
last
time,
so
we're
already
in
good
shape
implementation
wise,
even
those
those
are
pretty
new,
only
came
out
two
weeks
ago,
but
let's
do
a
quick
recap
of
where
we
are
so.
B
So
over
the
course
of
the
last
year
and
a
half
we
redesigned,
I
think
a
total
of
four
or
five
times
I
lost
count
after
a
while.
The
core
design
of
this.
So
since
we
were
kind
of
going
in
circles,
we
decided
to
go
with
another
approach.
We
formed
a
design
team
which
met
a
few
times
and
we
came
out
with
an
output
at
an
interim
a
few
weeks
ago
and
got
consensus.
B
B
If
there
are
any
intermediaries
in
the
middle
and
any
method
can
choose
to
use
it
or
not,
connect
udp
does,
and
so
that
allows
it,
for
example,
to
to
send
datagrams
and
there's
a
little
header
that
we
added
as
well.
So
you
can
tell
in
terminaries
that
the
capsule
protocol
is
in
use-
it's
not
mandatory,
but
it
exists
and
intermediaries
are
able
to
translate
between
versions
of
http
like
they
do
for
other
methods
and
for
http
datagrams.
B
The
difference
between
those
and
the
quick
datagram
frames
is
that
the
http
datagrams
are
associated
with
a
currently
open,
http
request
stream.
So
what
that
means
is
they're
always
tied
to
an
open,
client-initiated,
bidirectional
stream,
and
so
you
can
still
send
them
kind
of
think
of
it
as
a
sidecar,
but
datagrams
don't
exist
in
a
vacuum.
They're
always
tied
to
a
request,
and
so
the
formatting
is
there
on
the
right.
B
So
when
you
send
a
quick
frame
that
is
the
quick
datagram
frame,
it
has
the
quarter
stream
id
in
it,
followed
by
the
http
diagram
payload.
So
we
divide
it
by
four,
because
all
the
client
initiate
bidirectional
stream.
Ids
are
multiples
of
four
and
we
also
introduce
a
datagram
capsule,
so
capsule
being
a
sequence
of
tlvs,
the
t
have
an
inn
registry
and
we
define
a
single
one
which
is
which
means
datagram.
So
if
you
receive
one
of
those,
it
means
the
same
thing
as
receiving
this
datagram
quick
frame
and
quick.
B
B
So
when
it
comes
to
hdb
datagrams
we're
pretty
much
done,
we've
resolved
all
the
issues
we'd
like
to
move
forward
because
that
unblocks
other
working
groups
like
web
transport-
and
I
think
we're
ready
for
working
group
last
call
so
I'd
like
to
kind
of
pause
here
and
ask
like
the
chairs
what
they
think
or
anyone
on
the
floor.
If
they
have
thoughts
or
comments.
C
I
think
we'd
generally
be
aiming
to
initiate
a
last
call
for
this
on
the
list
after
this
meeting,
but
that
is
also
a
massive
thanks
to
a
whole
lot
of
folks
who
have
put
a
lot
of
time
and
effort
into
this,
especially
before
our
previous
interim
and
a
lot
of
that
stuff.
So
a
thank
you
for
that,
and
now
that
the
slate
is
looking
pretty
clean,
we're
probably
going
to
go
and
start
a
last
call
right
after
this
meeting
wraps
up.
B
F
G
Awesome
all
right
yep,
so
I
I
definitely
think
we're
ready
for
working
for
last
call.
I
would
just
note
as
hgbis
chair
that
when
we
send
that
out,
let's
also
send
a
note
to
the
http
group
to
also
review
since
there
may
be
some
folks
in
there
who
haven't
been
paying
super
close
attention,
and
it
would
be
great
to
get
their
review
kind
of
alongside
the
rest
of
working
group.
B
B
B
So
that,
in
this
case,
is
the
capsule
protocol
in
http,
2
and
http
3
hp
upgrade
tokens
are
used
for
something
called
extended,
connect
where
you
send
a
method
of
connect
and
a
protocol
of
connect
udp-
and
this
is
documented
for
http,
2
and
rfc8441,
and
we
have
a
draft
for
the
same
thing:
http
3
that
has
already
been
approved
by
the
asg.
So
we
have
a
normative
dependency
on
that,
but
we
see
this
draft
as
happening
before
connect2dp
anyway,
so
we
don't
see
a
problem
there.
B
So
if
you
look
at
the
wire
format
image
here
on
the
right
after
the
quarter
stream
id,
which
is
part
of
the
http
datagram
layer,
you
have
a
context
id
also
a
variant,
quick,
rfc,
9000
variable
length,
integers
and
we
define
a
specific
meaning
to
context
id
0,
which
means
udp
payload.
So
every
time
you
see
one
that
has
zero.
You
put
that
in
your
udp
socket
and
vice
versa.
B
When
you
receive
a
packet
on
that
socket,
you
put
it
in
a
datagram
and
send
it
back
to
the
client
and
all
other
numbers
exist
for
extensibility,
and
we
decided
that
they
are
dynamically
allocated,
which
means
that
each
like
both
the
client
and
the
server
have
a
way
to
generate
new
numbers
that
haven't
been
used
before
the
simplest
one.
Is
you
just
keep
a
counter,
so
you
start
at
two
and
you
return
two
and
then
four
and
then
six
on
the
client
and
same
with
odd
numbers.
B
But
we
don't
mandate
exactly
how
you
do
that,
for
example,
if
some
future
implementation
wants
to
reserve
the
low
warrant
numbers
which
only
take
one
byte
encoding
for
some
things,
they
can
do
that
and
give
them
out
of
order.
So
that's
kind
of
all
we
do
to
specify
them
and
from
the
thoughts
that
we've
had
for
our
extensions.
This
seems
to
be
powerful
enough
to
enable
any
extension
that
we
thought
of,
because
you
can,
for
example,
create
an
extension
that
adds
information
to
udp.
B
B
And
so
we
we
introduce
in
this
draft
the
concept
of
registration,
which
means
that
we,
when
an
endpoint
decides
okay,
I've
picked
number
four
and
number
four
means
this:
that's
how
it
informs
the
peer
of
that
format
of
those
formats
or
that
format
in
those
semantics,
and
we
don't
specify
registration
exactly.
We
say
that
you
can
use
http
headers.
We
say
that
you
can
use
new
capsules,
because
headers
are
kind
of
simpler,
you're
guaranteed
to
have
them
like
during
the
request
response
cycle.
B
Capsules
are
more
powerful
if
you
need,
for
example,
for
something
like
compression
where
you
don't
necessarily
know
what
the
value
is
at
the
request
response
time,
you
can
add
them
later,
so
you
have
the
option
to
do
both,
but
we
don't
define
how
to
do
it.
We
say:
okay,
we
leave
this
as
an
exercise
for
future
extensions,
and
I
kind
of
want
to
pause
on
here,
because
I
know
some
folks
had
thoughts.
B
H
D
D
That
ben
was
alluding
to
so
that
somebody
who
wants
to
say:
okay,
I'm
gonna,
I'm
gonna,
do
this
with
an
http
header
knows
how
it
works,
and
somebody
who
decides
that
they
really
need
a
capsule
knows
that.
Well,
I
need
all
of
the
things
that
are
in
that
plus
whatever
the
capsule
needs,
but
that
also
means
I'm
defining
extension
as
the
cost
of
my
going
off
the
base
spec.
Now
I
I
would
actually
say,
for
the
reasons
you
already
elucidated,
that
htv
headers
would
be
the
one
I
would
put
into
the
graph.
B
Thank
you.
I,
my
personal
preference
is
to
keep
it
in
a
different
document,
because,
oh
I
see
ted
gives
me
a
thumbs
up,
because
the
use
case
that
we
have
for
actually
putting
this
in
production
doesn't
need
extensions
just
yet
and
it'll
be
easier
to
interoperate
with
folks.
If
we
have
a
standard
for
like
that,
what
we
need,
but
having
a
draft
for
this,
that
we
start
right
away,
sounds
great
to
me
honestly.
I
Okay,
so
I'm
going
to,
I
feel
somewhat
hypocritical,
because
the
h3
draft
does
kind
of
say
you
have
to
figure
it
out,
but
it
gives
you
a
suggested
mechanism
which
is
sending
a
setting
and
defining
a
setting.
As
part
of
your
extension,
you
don't
really
have
settings
here,
so
I'm
not
sure
how
you
would
how
you
would
hand
wave
this
away.
I
feel
like
it
needs
to
be
defined.
J
I'm
wondering
how
extensions
compose
you've
already
mentioned,
ecm
bits
and
in
the
draft
there's
a
example
extension
for
timestamps,
so
you
would
have
one
context
for
the
ecnbits
one
context
id
for
timestamps.
What
happens
if
I
want
to
send
both
ecnbits
and
timestamps?
Do
I
need
another
context
id
for
that.
B
That's
a
great
question,
so
when
we
talked
about
it,
that's
how
you
would
do
composibility
of
extensions
is
say.
If
I
want
to
send
both
the
ecn
bits
and
the
timestamp
I
define.
I
use
this
to
be
defined
negotiation.
To
say
this
context.
Id
means
a
udp
payload
with
first
ecn
bits
and
then
the
timestamp
and
then
the
udp
payload
martin,
duke.
K
Martin,
duke
google,
as
an
individual,
so
like
obvi
headers,
you
know
requested
responses
are
a
pretty
obvious
extension
joint,
but
I
will
say
the
downside
of
that.
Is
that
you
can't
you
can't
use
the
extension
necessarily
in
the
first
flight
depending
on
you
know
the
specific
extension,
if
I,
if
I
send
a
if
I
want
to
send
a
request
with
this
extension
negotiation
and
then
immediately
send
datagrams
with
this
thing,
like
I
don't
know
the
cert
that
the
server
can
accept
them.
So
it's
a
downside.
B
So
that's
a
very
good
question
and
we
actually
have
a
solution
to
that.
I
think
in
the
draft
and
I
need
to
double
check
that
if
that's
written
down
or
just
in
the
back
of
my
head-
but
all
we
need
to
say
is
that
you
drop
context
ids
that
you
don't
know,
and
so
you
can,
let's
say
as
a
client
yeah.
We
called
this
zero
rtt
extensibility
in
previous
meetings.
If
anyone
remembers,
but
the
idea
is,
if
you
want
to
send
something
in
your
first
flight,
you
can
like
send
your.
B
I
want
to
use
this
extension
in
the
header
and
in
in
another
header,
say
context.
Id4
means
this
new
extension
and
then
you
send
a
datagram
on
context
id4.
If
the
server
supports
it,
it
says
with
its
server
response:
headers
yep.
I
support
this
and
then
it
processes
the
datagram,
and
if
it
doesn't
that
header
gets
ignored,
the
datagram
gets
ignored
and
it's
it's
lost.
Oh.
B
K
So
I
mean
I
guess
okay,
so
I
mean
the
ecn
case
is
the
one
that
that
you
know.
I
certainly
have
my
mind
and
that
certainly
sounds
fine,
but
what
you're
describing
is
also
a
an
attempt
to
use.
Your
rtt
essentially
gives
you
a
1rtt
penalty,
which
also
is
not
great
and
I'm
pointing
at
problems.
Here
I
don't
have
a
solution,
but
I'd
encourage
you
to
like
think
a
little
more
about
if
there's
some
way
to
like
a
more
robust
system
for
this.
B
So
there
used
to
be
in
the
draft,
and
the
kind
of
consensus
of
the
design
team
was
that
this
was
sort
of
too
complicated,
so
it
was
removed
and
that's
kind
of
we
ended
up
with
the
current
design.
I
I
personally
want
preferred
that
feature,
but
I
think
I
kind
of
agree
in
hindsight
with
the
rest
of
the
working
group
that
you
know
keeping
this
simple,
even
though
we
might
have
some
edge
cases
like
that
is
probably
worth
it
in
the
long
run.
L
B
L
Yeah
hard
for
me
to
get
much
closer
without
like
having
my
face
attached
to
my
camera,
so
on
the
topic
of
you
know
having
accessibility
in
the
first
flight.
You
know,
as
I
understand
the
mechanics
inspiration
you
either
have
to
that's
great.
I
have
the
echo
on
your
title:
did
you
guys
echo
cancellation.
L
Well,
it's
not
helping,
so
I
understand
the
mechanics
of
the
xero
rtd
sensibility
here
unless
you
have
mandatory
extension,
even
if
these
sensors
are
self-describing,
you
can't
use
them
guaranteed
in
the
first
flight
if
they're
aside
might
reject
it
and
so
as
a
practical
matter,
the
most
you
could
possibly
do
is
announce
them
in
the
first
flight
and
then
have
and
then
still
have
the
in
your
behavior
that
you
described
here.
I
suppose
you
could
have
extension
persistent
from
previous
handshakes.
L
The
way
you
are
those
your
rtg
features,
but
I,
as
far
as
I
can
tell
physics
in
the
situation
just
dictate
that
there's
no
way
to
be
absolutely
sure
the
attention
would
be
acceptable
in
the
first
flight
and
start
using
it
for
anything
that
is
critical
path
and
will
cause
disaster.
If
it
fails,
am
I
correct
about
that.
B
I
wouldn't
say
it's
a
disaster.
If
it
fails,
I
would
say
the
datagram
gets
lost.
So
if
it's
something
critical,
let's
say
you
want
to
send
your
quick
initial
in
a
udp
packet
for
this,
and
you
want
to
send
it
with
ecnbits
and
the
server
the
proxy
doesn't
support
the
ecn
extension
it's
going
to
drop,
that
datagram,
tell
you
and
then
you're
going
to
back
so
you're
going
to
lose
a
round
trip
for
that
connection,
establishment
and
that's
pretty
bad.
L
B
B
What
we
do
instead
for
connect
udp
and
the
connect
ip
draft
for
that
matter,
copies
that
as
well,
is
we
put
in
a
uri
template,
and
so
it's
kind
of
a
thing
that
looks
like
a
uri
which
has
these
magic
variables
target
host
and
target
port
that
anytime,
the
client
wants
to
do
a
connect,
udp
request
it
swaps
them
out
for
the
actual
host
and
part
that
it
wants
to
talk
to.
So
here
are
three
examples
on
the
slide.
Uri
templates
are
a
little
bit
complicated.
B
We
added
some
text
pretty
recently.
I
forgot
if
it
got
into
the
last
draft
two
weeks
ago,
or
I
think
I
might
have
landed
that
pr
before
after
the
draft
caught
off
so
sorry,
I
added
a
paragraph
that
tightens
up
the
rules
on
the
ui
templates,
so
you
can't
use
some
of
the
really
crazy
and
hard
to
parse
syntax
in
there,
and
I
think
that
makes
it
a
lot
more
wieldy.
B
So
the
draft
defines
something
called
a
default
uri
template,
which
is,
if
your
ui
kind
of
has
this
limitation,
here's
the
uri
template
you
should
use.
So
it's
pretty
simple.
You
just
use
the
proxy
host
call
in
the
proxy
port
and
three
slashes
with
the
target
sword
and
target
post
there,
and
I
think
it
was
eric
nygren
who
filed
an
issue
and
saying
well,
should
this
use
dot
well
known?
I
don't
personally
care
much.
Does
anyone
have
opinions
on
which
way
we
should
go
here?
B
B
M
Yes,
one
point
that
I
have
is
in
many
cases
a
lot
of
intermediary
hosts,
especially
proxies
and
cdns,
to
have
some
special
handling
logic
for
well-known,
which
we
already
use
for
a
number
of
other
protocol
activities.
So
do
you
think
this
might
you
know
be
something
that
interacts
badly
with
existing
rule
sets
around
the
taught,
well-known
path.
B
So
I
don't
know
so
thanks
for
your
question,
I
don't
know
if
I
have
a
great
intuition
for
that,
my
gut
feeling
is
you
probably
want
well
you're
going
to
need
some
special
handling
for
this
path
if
you're
doing
connect
udp
like
this
is
fairly
different
from
most
http
existing
http
methods,
so
probably
having
that
well
known,
maybe
makes
that
easier.
But
in
our
implementation,
like
we,
don't
have
any
specific
rules
that
tie
to
the
well-known
prefix
so.
M
The
problem-
maybe
some
text
in
the
draft
around
the
fact
that
this
might
be
something
that
interacts
with
existing
rules
and
implementers
should
you
know,
maybe
just
keep
an
eye
out
for
such
interactions
could
be
part
of
the
draft.
Just
as
a
warning
to
people
who
are,
you
know,
implementing
functionality
around.
B
H
N
B
P
If
we,
if
we
followed
this,
it
would
at
least
at
least,
if
there's
caveats
drawn
out
in
caches
for
websocket
today,
they
could
still
look
at
the
upgrade
header,
even
if
they
didn't
look
at
the
content
and
just
say:
oh,
you
know
this
isn't
cacheable,
even
though
it
probably
is
in
this.
With
respect
to
the
connect.
You
know,
the
it's
connect
is
just
weird
and
trying
to
build
something
new
on
top
of
it
with
1.1.
B
B
So
the
idea
is,
if
you're
talking
to
and
granted
it's
an
odd
scenario.
Let's
say
you
set
your
proxy
settings
to,
I
don't
know
davidskenazi.com,
I
don't
support
connect
udp
on
there.
Yet
the
same
server
runs
mask.that's
different
and
you
try
to
do
this.
You're
gonna
get
some.
You
don't
want
the
proxy
to
catch
fire.
You
want
it
to
properly
say
nope.
B
L
Oh
okay,
I
I
feel
like
my
response
to
this.
As
to
every
other
concern
about
proxies,
did
not
speak.
This
problem
is
don't
do
that
you
don't
accidentally
get
connected
to
a
proxy
which
has
the
wrong
semantics.
You
mistyped
or
you're
misconfigured,
so
I
actually
do
not
care
the
proxy
and
the
process
you
shouldn't
catch
fire
with
any
data
sent
to
it.
L
B
M
B
M
M
Okay,
great
so
just
moving
a
little
closer
to
the
mic,
so
I
I
was
just
making
a
point
that
a
lot
of
you
know:
network
transition
and
edge
devices
like
firewalls
or
intercepting
proxies
have
traditionally
had
very
different
conceptions,
and
you
know
security
rules
around
gets
and
connects
because
of
the
way
they've
been
used.
Like
you
said
traditionally,
1.1
and
you
know,
prior
connect
has
always
been
something
that
was
a
tunneling
system
and
it's
a
very
different
security
handling
than
any
request
with
the
get
you
know
method.
R
Eric,
I
think,
is
it
theoretical.
I
think
what
really
comes
into
play
is,
if
you
start
having
multi
multi-tenant
services.
So
if
you
have,
for
example,
a
cdn
node
that
wants
to
be
handling
various
things,
is
it
the
traditional
connect
method
does
not
have
good
multi-tenancy
support
and
becomes
really
messy
and
having
the
connect
method
have
different
semantics
between
extended
connect
and
non-extended
connect,
especially
in
a
multi-tenant
environment,
gets
extra
messy.
B
Oh,
my
only
problem
with
post
is
then
I
can't
resolve
this
with
a
coin
flip
anymore.
I
need
a
like
three-sided
dice.
How
do
people
feel
about
post?
That's
fine
by
me,
because
I'm
think
I'm
very
squarely
in
the
eckers
camp
of
this
will
never
happen
and
at
least
speaking
for
myself-
and
I
think
quite
a
few
others
we're
never
going
to
actually
implement
this
over
h1
we're
going
to
use
h2.
B
We
have
to
implement
h2,
because
some
networks
block
udp
and
quick
and
h3,
but
h2
or
h1,
is
inside
tls,
so,
like
the
only
place
where
this
will
probably
be
used
over
h1
is
inside
someone's
network
between
their
front
end
and
their
back
end
and
if
they're
implementing
this
they're
going
to
fix
their
network
to
their
firewalls
to
make
it
work.
So
I
really
don't
care
about
the
answer.
Let's
just
pick
one.
Does
anyone
object
to
post.
N
B
I
I
H
H
So
the
the
server
is
always
within
its
rights
in
principle,
to
say,
never
mind
your
upgrade.
I'm
going
to
answer
the
request
as
you
sent
it,
and
if
we
send
a
connect
method
with
a
thing
that
follows
it
that
isn't
a
host
and
port,
then
the
the
server
that
tries
to
do
the
thought
that
ignores
the
upgrade
header
is
faced
with
a
malformed
request,
which
seems
kind
of
ugly.
H
B
Okay,
thank
you.
That's
that's
helpful,
because
at
the
end
of
the
day,
a
lot
of
these
considerations
remember
this
is
upgrade
so
an
http
upgrade.
You
no
longer
have
like
the
similar
things
that
you
would
expect
from
the
rules
so
upgrade
like
connect
or
like
weird
abnormalities
in
http
land-
and
you
know
just
thinking
about
this
more
like
these
problems
exist
for
websockets
like
it's
not
like
days
haven't
been
solved
like
if
someone
wants
to
deploy
websocket
today,
they
need
to
fix
this.
B
P
Hello,
lucas
again,
just
I
guess,
adding
more
flavor
to
my
not
liking
connect.
It's
that
you
know
the.
If
you
read
the
spec
that
defines
the
connect
method,
it
says
this
is.
This
is
how
you
should
handle
it,
and-
and
this
is
what
you
do
and
if
you're
a
server
that
doesn't
want
to
do
that,
then
you
you
don't
and
you
reject
it
and
you
might
even
just
say
anything
that
has
the
connect
verb
in
in
this
part
of
the
the
bytes
that
form
the
request.
P
G
All
right
yeah,
I
just
got
in
cued
to
say
that
I've
been
convinced
by
this
discussion
that
we
should
just
go
with
get
connect
clearly
as
problems
and
as
I
mentioned
in
the
chat,
I
don't
think
the
overhead
of
trying
to
use
a
new
method
or
even
using
a
method
other
than
get
which
isn't
being
used
with
upgrade
today
is
worth
the
effort.
Considering
that
we
don't
really
expect
this
http
one
use
case
to
really
ever
be
used
in
the
wild.
So
it's
not
worth
going
through
allocations
or
paving
new
ways
for
it.
B
K
Very
briefly,
like
I
will
just
like
say,
get
because
of
the
wisdom
of
the
agents
who
did
it
with
websockets,
and
maybe
there
was
a
good
reason
and
beyond
that.
Just
like
be
consistent
with
the
approach
we
have,
but
more
than
that,
this
is
starting
to
smell
like
a
bike
shed.
Since
everyone
agrees,
it's
a
corner
case
that
may
never
actually
come
up
we're
spending
an
awful
lot
of
time
legislating
this.
Maybe
we
can
take
it
to
the
list
if
there's
other
stuff.
S
No,
I'm
not
muted,
I'm
on
the
wrong
microphone.
We
can
hear
you
what
we
can
do,
I'm
just
wondering
why
you're
doing
1.1
at
all
I
mean
if
you,
if
you
think
this
is
a
corner
case.
You
think
it's
you
know.
You've
got
a
complicated
enough
spec
already.
Why
not
just
get
rid
of
it.
If
people
need
to
downgrade
let
them
sort
it
out.
B
B
So
what
I'm
getting
from
this
discussion
is
that
the
folks
who
were
against
gets
seemed
to
at
least
some
of
them
seem
to
have
been
convinced
that
get
seemed
fine
and
a
lot
of
whatever
we
don't
care.
Please
move
on
this
hurts
and
I
would
like
to
not
have
to
take
out
the
hat
of
consensus
because
that
always
works,
so
I'm
gonna
propose
we
go
with
connect.
Can
anyone
like
really
really
not
live?
Sorry
with
get
with
get
sorry,
whoops.
B
B
Okay,
then
we
shall
go
with
get.
Thank
you
very
much
for
our
traditional
mask
bike
shed
of
the
of
the
week
and
was
my
next
light
button,
not
working
so
fun.
Fact
that
was
the
last
issue
on
the
connect
udp
draft.
That's
why
we
spent
so
much
time
on
it,
even
though
it
wasn't
very
interesting,
and
so
this
is
my
favorite
slide,
because
it's
fun
we've
managed
to
resolve
all
remaining
open
issues
on
connect
udp.
B
C
C
No
worries
thinking
that
a
last
call
is
probably
appropriate
for
this
as
well.
Let's
try
to
wrap
up
kind
of
the
issues
that
we're
resolving
here
today
and
get
that
out
for
folks
to
to
look
at,
but
I
think
is
you
know
when
we
are
rapidly
approaching
the
point
of
having
nothing
more
to
do
for
this
one,
and
it
would
be
good
to
get
that
stamped
and
wrapped
up.
B
B
G
G
I
can
say
for
my
own
implementation:
this
is
again
still
a
to
do
to
really
get
ready
for
interop,
but
if
you're
interested
in
doing
that,
let's
talk
collectively
about
that
and
prepare
for
a
checkpoint
at
some
interim
or
at
least
by
the
next
ietf
meeting,
so
that
we
can
get
some
good
experience
with
this
protocol
all
right.
So,
let's
dive
into
those
open
issues.
G
People
need
to
think
about
it
for
connect
udp,
but
this
is
really
an
interesting
problem
for
connect
ip
specifically
and
the
problem
which
was
raised
in
an
issue
that
david
wrote
up,
is
that
you
can
have
cases
where
you
have
a
small,
quick
packet
size.
That
is
the
actual
kind
of
tunnel,
and
it
may
be
too
small
to
actually
hold
the
minimum
mtu.
G
G
G
So
this
is
really
an
open
question
and
I'd
love
to
hear
people's
opinions.
I
don't
have
a
particularly
strong
opinion
here
of
what
should
we
do
when
we
run
into
this
case,
you
could
have
a
failure
on
the
request
stream,
essentially
saying
if
you
are
trying
to
do
a
connect,
ip
request
and
you're
using
ipv6,
and
the
other
side
knows
that
it's
effective
mtu
is
too
small.
It
will
generate
an
error.
G
D
H
H
You
know
be
very
clear
about
about
the
issue
here
and
and
essentially
note
what
is
required
to
ensure
that
the
inner
stream
is
ipv6
compliant
and
not
attempt
to
solve
the
problem
of
of
stuffing
oversized
packets
in
in
the
case
where
the
mtu
doesn't
fit.
I
I
do
think
that
we
should
solve
that
as
a
working
group,
but
we
should
solve
that
as
an
extension
to
connect
ip.
G
L
L
Seriously,
I
think
again,
if
you
advertise
yourself
that
you're
an
ipv6
carrying
tunnel,
then
you
have
to
carry
then
you
have
to
carry
a
minimum
to
use
by
packets.
Everything's,
just
gonna
fall
apart,
so
the
so
I
think
that's
right.
Question
number
comes
and
what
what
do
we
do?
You
know
I'm
not
a
huge
fan
of
experimentation.
Reassembly.
I
I
think
you
know
you
know
I
I'd
like
to
be
sure
of
correction
and
we
actually
need
that
in
practice
before
before
we
do
it.
L
So
I
think
really,
the
question:
is
you
know,
distribution
between
so
between
these
you
know
between
between
these
options.
You
propose
right.
The
first
is
kind
of
like
I
mean
I
guess
I
guess.
Maybe
you
can
imagine
doing
that
if
you
say
like
well,
I
can
only
negotiate
1100,
so
I'm
gonna
allow
ipv4
and
not
v6.
It's
not
like
a
totally
crazy
thing
to
say,
though
they're
pretty
gross
the
I.
I
don't
think
we
should.
I
don't
know
the
adding
capsules
is
the
right
answer.
L
So
I
think
you
know
this
last
point
is
really
an
implementation
point.
You
know,
I
think
I
think
I
guess
what
I
would
say
is
that
we
should
say
if
someone
asks
for
ipv6
and
you
can't
do
you
know
1280
and
you
ought
to
reject
it
and
then
you
must
reject
it
and
like
we
strongly
advise
you
to
like
use
it,
and
and
so
it's
your
job,
to
negotiate
up
to
the
right,
the
right
size,
whatever
that
size
is,
and
we
strongly
advise
you
to
do
that
by
using
large
initials.
L
But
otherwise
it's
going
to
take
additional
round
trips.
So
I
think
that
the
only
the
only
mandatory
piece
is
that
it
is
that
you
must
reject
if
you
can't
carry
the
ipv6
minimum,
but
then
some
personalize,
with
strong
advice
about
how
to
get
to
the
point
where
you
are
carrying,
where
you're
able
to
carry
that
minimum.
G
F
R
F
Something
is
it.
Is
it
a
doubter
attack?
Is
it
a
downright
attack
if
the
if
the
network,
because
like
the
network
you're
visiting,
could
be
intentionally
sending
a
you
know,
I
don't
know
right
like
hey.
My
network
is
1280,
so
you
can't
use
connect
ip
on
my
network,
my
network,
my
rules,
do
you
want
that?
I
don't
know.
R
F
F
If
you
don't
want
to
do
number
one,
which
I
think
you
you
basically
is
a
downgraded
attack,
then
you
basically
need
to
have
a
fallback
mechanism,
and
the
question
really
is
like:
once
you
have
the
fallback
mechanism,
then
why
do
the?
Maybe
you
can
do
the
fallback
mechanism
first
and
use
the
last
one
as
an
optimization?
I
don't
know,
but
you
don't
have
a
good
solution
either
way.
G
G
Do
the
last
line
have
a
way
to
fail
it,
as
with
the
default
of
this
draft
does
but
then
to
ben's
point.
You
know,
allow
an
extension
and
another
document
to
describe
if
you're,
in
an
adversarial
situation
or
if
you
really
need
to
get
this
packet
through
because
you're
on
a
tiny
link.
But
you
also
need
to
do
ipv6.
M
D
M
You
know
it
basically
ends
up
getting
dropped
because
of
a
complete
means
somewhere
that
I
don't
have
control
okay
and
it's
not
happening
at
the
initiation
of
the
connect
that
I
can
take
off.
Am
I
negotiating
an
mpu
with
my
path
to
the
remote
because
my
path
may
not
be
starting,
so
I
think
the
correct
handling
for
this
really
should
be
allow
the
connection
you
know
where
a
parked
mtu.
M
You
know,
issue
crops
up,
wherein
we
don't
fit
in
it
to
allow
segments
to
fragment
and
reassemble
up
that
opens
its
whole
whole
can
of
worms
but
probably
pair
that,
along
with
some
sort
of
error,
signaling
saying:
hey,
your
packets
are
being
fragmented.
Maybe
at
you
know,
you
may
even
want
to
put
in
a
hop
count
or
whatever
else,
but
the
idea
is
to
have
the
stender
get
some
notification
that
yes,
there's
fragmentation
happening.
M
And
it's
up
and
it's
up
to
the
end
point
to
say:
okay,
if
I
see
fragmentation,
maybe
I
I
make
a
decision
as
one
of
the
tunnel
endpoints
to
drop
the
tunnel
and
initiate
a
new
negotiation
to
see.
If
I
can
probably
get
the
mtu
back
up,
maybe
maybe
a
new
connect,
you
know,
bypasses
some
connection
tracking
gets
onto
a
different
link.
You
know
cross
your
fingers
and
hope,
but
the
point
is
that
a
running
session
may
degrade
because
of
an
mpu
shrinkage,
but
it
should
not
fail.
M
That
would
work
that
that
should
work.
You
know
again,
you
know
the
question
should
be.
I
I
believe
that
having
a
flag
might
be
useful.
If
someone
wants
to
explicitly,
you
know
disable
it,
but
I
still
believe
it
should
be
the
default
option.
Our
default
should
always
be
try
to
get
the
traffic
through.
You
know,
as
best
you
can.
M
G
I
N
G
B
David
gennazi,
google,
my
thinking
here,
is
that
a
network
with
an
mtu
kind
of
that
that
low
is
for
the
outer
one
is
kind
of
barked
right
and
we
know
how
to
handle
those
networks
that
are
borked
another
example
of
a
borked
network.
It's
one
that
doesn't
allow
udp.
When
that
happened,
we
switched
to
connect
ap
over
http
2..
B
So
I
like
that
last
approach
of
saying
you
know
if
you
want
to
do
ipv6
over
connect
ip
yeah
just
have
initials
big
enough
that
if
the
network
is
worked,
we
don't
use
it
that
way,
and
that's
just
really
simple
in
practice.
That's
what
I
think
I'll
implement
and
everyone's
happy,
like
figuring
out
other
things
seemed
like
really
complex
and
given
how
much
time
we
spend
on
simple
issues,
I'm
terrified
at
the
idea
of
how
much
time
we'd
send
on
complex
ones.
So
let's
keep
it
simple.
T
T
T
Second
thing:
the
third
thing
is,
as
you
go
down
these
numbers,
especially
with
ipv4
and
udp
you're,
going
to
hit
barriers.
So
if
the
path
changes,
it
will
change
that
mtu.
If
you
start
getting
into
the
bigger
numbers,
so
you've
got
a
problem
there
as
well.
The
past
might
not
stop
working
later
on,
so
we
have
to
detect
that
somehow
and
if
detecting
it
simply
means
it
doesn't
stops
working
then
maybe
that's
a
good
signal
to
the
app.
G
K
Yeah
all
right,
martin,
duke
google,
as
an
individual,
so
this
strikes
me
is
like
not
a
new
problem.
I
mean
ipv6
or
ipv6
tunnels
have
it
and
I'm
not
like
an
interior
guy
at
all,
but
presumably
there's
some
sort
of
received
wisdom
on
how
to
handle
this
sort
of
case,
and
maybe
we
should
maybe
we
should
take
it.
Secondly,
like
this,
certainly
quite
a
cute
connect
ip.
This
also
exists,
I
think
is
somebody
already
said:
connect
udp
and
I'm
I'm.
K
G
What
one
comment
I
would
have
about
solutions
at
other
layers
of
tunneling
is
you
know
there
is
something
we
need
to
do
here,
just
because
with
a
connect,
ip
request
stream,
it
is
a
bit
more
stateful
as
a
proxy
here,
and
we
do
need
to
just
know.
How
do
we
spell
the
semantics
of
the
error
handling
in
http
right.
Q
B
K
B
K
G
K
Yeah,
that's
the
simplest
example
I'll
try
and
generalize
it,
but,
as
I
think
about
it,
maybe
that
doesn't
work
but
nevertheless
yeah
so
clearly
they
connect
udp
use
cases
where
it's
just
plain
old
gdp
running
like
tiny
little
packets
and
you
don't
care,
but
there's
still
a
problem
here
as
we're
looking
here
to
all
tunnels.
When
you
know
sometimes
the
tunnel
will
break
your.
E
Mia
coolevin,
I
would
like
to
at
least
see
or
work
on
a
solution
that
uses
capsules.
We
have
these
capsules,
we
have
this
reliable
streams
and
just
putting
some
ip
packets
on
that
doesn't
mean
that
it's
ip
fragmentation
for
me.
I
think
it
should
just
work.
I
don't
think
it's
as
complicated
as
we
think,
and
if
it's
easy,
we
should
do
it.
G
F
F
If
you're
implementing
you
want
it
to
work
the
same
way
all
the
time,
regardless
of
what
happens
to
you
and
so
like
rajiv's
point
earlier,
was
like
yeah,
the
network
can
send
you
a
packet
too
big
at
any
time,
and
now
the
ip
stack
is
obliged
to
send
a
smaller
packet.
What
do
you
do
to
that
connect?
Udp?
Do
you
fail
it
suppose?
You
return
an
error
to
the
to
the
app,
but
that's
that's
also
pretty
bad
right.
It's
kind
of
even
like
a
denial
of
service
vector
right.
F
G
G
G
F
J
F
F
L
Yeah,
I'm
like
super
yeah
about
putting
it
over
a
little
bit
more
reliable
that
changes
the
entire
conduction
dynamics
once
you
accept
it
like.
We
took
the
packets
now
now
you've
dual
conditioning
hole
made
out,
so
that
seems
like
extraordinarily
undesirable,
unnecessarily
reduction,
control
for
google
engine
systems
now
right.
This
is
sort
of
an
issue
for
udp,
as
people
are
saying,
but
every
mvp
system
I
know
either
either
assumes
a
minimum
I
mean
so.
L
First
of
all,
like
you
know,
people
don't
build
gdp
systems
to
play,
work
or
ipv6,
because
that
would
be
silly
and
so
so
every
udp
system
that
I'm
familiar
with
has
to
be
able
to
handle.
You
know
packet
sizes
that
that
go
down
the
ball
because
you
have
to
like
still
I
mean,
or
you
have
to
just
say,
I'm
going
to
fail
over.
I
can
people
people
small
ipv4
links
right
so
like.
If
you
look
like
these,
you
see
a
lot
handshake.
L
For
instance,
it's
willing
to
negotiate
download
below
below
a
thousand
the
I'm
gonna
say
if
you,
if
you
don't
do
that,
you're
like
operating
at
like
you
know,
risk
of
life.
The
thing
that's
not
working
in
general,
right,
the
I
mean,
I'm
I'm
not
on
the
long
run,
fragmentation
it's
my
knowledge.
The
problems
of
fragmentation
are
largely
due
to
attempts
to
do
passive
packet
inspection
by
by
stateful
ip
inspectors
and
that
and
because
we're
encrypting
things-
that's
largely
not
the
case
here.
L
So
I'm
I'm
most
concerned
about
that.
I
guess
I
would
also
observe
that,
like
this
is
putting
them
in
castles
in
fragmentation.
It's
like
this
is
a
different
form
of
fragmentation
that
treats
them
in
infrastructure.
I
mean
it's
inherent
in
a
quick
stuff
in
any
kind
of
like
any
kind
of
system
that
breaks
them,
puts
it
back
together
again
whether
it
has
retransmission
or
not.
R
L
So
if
I
think
the
question
we
have
to
ask
is:
can
the
system
ship
at
all
without
having
some
mechanism
for
handling
in
this
case,
and
I
think
the
question
and
then
the
question
becomes,
I
think
you
know
how
bad
is
it
you
know
so,
as
we've
already
just
described
it's
possible
to
discover
at
the
beginning
whether
your
path
handles
this
and
the
question
becomes.
Can
your
path
shift
in
a
way
that
you
do
not
have
you
no.
R
L
G
I'm
getting
a
lot
of
echo
the
the
case
of
doing
fragmentation
over
capsules,
which
I
fully
agree
is
fragmentation.
It's
just
like
fragmentation
with
re-transmissions
is
essentially
the
exact
same
behavior
that
you
would
have
in
the
case
that
david
mentioned
of.
If
I
start
big
and
I
have
to
fall
back,
I'm
falling
back
to
http,
2
and
http
2
for
connect
ip
only
ever
sends
them
over
reliable
capsules.
G
L
Well,
I
think,
with
the
argument.
I
guess
you
could.
I
get
a
fair
enough,
although
I
think
I
turn
the
argument
around
and
say,
if
you're
going
to
bother
to
absorb
the
pain
of
like
having
his
wrist
and
logic
in
this
case,
why
not
just
use
h2?
I
guess
one
question.
One
question
I
think
you
know
it's
like
we're
worth
asking
about,
I
mean
is,
you
know,
is
let's
distinguish
between
detection,
and
you
know
I
mean
it's
like
I
guess
like
for
one
of
your
taxes.
L
What
does
this
actually
look
like?
So
so
I
think
you
know
so
so
so
you
see
so
someone
says
you.
A
packet
looks
like
at
the
bear,
which
is
at
the
very
limit
before
and
now
and
now.
For
some
reason,
books
of
the
past
shift
is
no
longer
it's
bollard
or
limited
right,
and
so
packing
gets
wrapped
along
the
wire
somewhere
right.
L
You
know
induces
a
should
be
a
quick
packet
right
and,
and
so,
and
so
so
I
mean
just
to
recap
what
I'm
saying
you
think
the
mtu
that
you're
running
over
is
1300,
but
actually
it's
going
down
to
12.95
right,
and
so
you
send
a
packet,
that's
1297
and
it
gets
dropped
right
and
so
now
so
so
you
know
so
so
now
what
right?
You
know
you
know
so
so
you
have
to
detect
that
case
and
you
have
to
fall
back
to
small.
L
L
That
case
is
by
repeatedly
not
getting
acts
or
packets
right
at
the
bare
limit
right
and
so,
and
unless
you
want
to
do
some
sort
of
goofy
gtossy
thing
like
somebody
gtls
does,
is
you
know
when
it
starts
it
like
says
like
well
started,
like
you
know
at
like
1280
and
said
like
two
or
three
times,
and
then
it
wouldn't
work.
That's
too
big!
L
So
I
guess
I
guess
I
guess
I'm
talking
myself
back
into
like.
I
think
we
should
just
like
fail
because,
like
I
think
that
the
situation
otherwise
is
going
to
be
an
enormous
other
time
to
respond
and
the
response
is
going
to
be
kind
of
a
pain,
yes,
and
by
the
time
you
already
lost
a
lot
of
packets
right,
I
mean
you
may
not
have
lost
actually,
but
you've
lost
them
operationally.
E
Yeah
me
again,
so
I
think
there
are
possibilities
to
use
unreliable,
datagrams
and
define
a
context
or
whatever,
where
you
have
like
a
dependency
between
different
datagrams,
and
you
can
only
develop
them
if
you
have
them
all
or
whatever.
That
is
possible,
but
I
think
that
would
definitely
be
an
extension.
We
have
reliable
capsules
here.
I.
E
G
N
M
You
know
out
of
the
blue,
because
if
some
network
change
it
has
nothing
to
do
with
either
of
the
endpoints
right
so,
which
means
I
probably
have
no
visibility
on
when
a
tunnel
may
completely
just
rip
out
and
die
under
me
and
all
the
you
know,
error
handling,
p,
connect
all
that
logic
now
has
to
be
borne
by
the
application
end
of
things.
Okay,
so
you
know,
while
it
might
be
interesting
to
target
simplicity
here,
there
should
be
some
level.
F
Yeah,
just
just
always
do
everything
in
capsules,
I
mean
there's
not
even
a
problem
traditionally,
if
you
retransmit
something
reliable,
you
have
like
a
compounded
re-transmits,
but
if
you
you
know,
unless
you
have
like
really
really
really
aggressive
timers
above
you,
the
app
will
just
see
no
loss
and
it
won't
retransmit
it's
a
simpler
code
path.
It
runs
it's
the
same
all
the
time,
it's
the
same
as
udp,
probably
simplify
the
implementation
and
it'll
work
all
the
time
and
again,
like
the
reduce
point
as
well
like.
F
If
you,
if
you
fail
it,
you
can't
just
fail
at
the
big
and
you
have
to
fail
in
the
middle
and
you
you
basically
are
introducing
the
the
possibility.
The
app
will
see
an
error
halfway
through
just
when
it
happens
to
send
a
large
packet
or
whatever
or
if
the
routing
changes
it's
super
unfriendly
to
the
app
and
it
like
increases
the
complexity
of
the
overall
system
right
it
should.
I
think
it
should
just
work
all
the
time
which
means
yeah.
Just
just
do
the
same
thing.
All
the
time
put
them
in
capsules,.
L
Okay,
sorry,
but
I
feel
like
after
nothing
like
that
that
doesn't
solve
the
problem,
because
the
problem
is
discovering
when
you
have
to
think
more
datagrams,
and
so
just
putting
them
in
the
capsules.
Isn't
enough
in
the
answer
you
need
an
answer
for
when,
for
when
the
quick
connection
decides,
it
has
to
do
with
duty
discovery
or
something
to
go
back
to
our
datagram,
and
so
I
can
kill
someone
personally,
I
feel
like
like
this
is
not
like
the
app.
G
Right
I
mean
you
could
certainly
do
something
where
you
know,
like
let's
say
I'm
doing,
quick
migration
and,
like
I
know
I
changed
mtu
and
like
the
tunnel
has
like
a
very
clear
event.
Then
you
could
easily
say:
okay,
now
I'm
going
to
switch
but
yeah
it's
it's
the
things
that
a
quick
implementation
wouldn't.
L
L
Otherwise,
like
someone
just
took
four
on
trip
times
and
like
not
how
you're
happy
about
that,
and-
and
I
know
about
like
and
the
rediscovery
I
mean,
the
retracement
timers
on,
like
retired
timers-
are
pretty
fast
like
on
these
end
points
once
you
have
established
the
run
trip
time
so,
like
you
know,
so,
if
we're
going
to
take,
you
know
if
we're
going
to
take
four
rtt's
to
discover
this,
like
the
other
side,
is
going
to
return
that
time
period.
Yeah.
G
Okay,
I
think
we
have
drained
the
queue
we
don't
have
consensus,
but
we
do
have
a
lot
of
good
input.
So
thank
you
for
all
of
that.
I
think
it's
a
very
useful
discussion,
there's
a
lot
of
good
stuff
on
the
chat
too.
So
hopefully
we
have
the
notes
that
we
can
go
back
to
in
the
video
we
can
go
back
to
and
we
can
come
up
with
a
proposal
for
next
time
and
hopefully
also
we
can
have
implementation
experience
and
actually
try
some
of
this
out.
G
G
G
N
G
G
Because
but
it
allows,
I
think,
the
the
person
receiving
the
icmp
to
do
a
very
simple
thing
of
you
know.
Let's
say
they've
implemented
their
quick
stack
behind
like
a
virtual
interface
such
so.
The
application
actually
doesn't
have
any
idea
that
it
is
going
through
a
proxy
like
it's
you're,
using
it
as
like
a
vpn
tunnel.
G
B
E
Yeah
me
again,
I
agree
to
that
like
if
we,
if
you
want
to
use
icmp,
we
maybe
give
a
recommendation,
but
we
don't
have
to
say
much
because
that's
like
not
our
business,
I
I
wonder
if
there's
any
benefit
of
silently
dropped
because,
like
silently
drop,
seems
to
be
an
option
when
there
is
kind
of
a
security
risk
or
attack
risk
or
whatever.
I
don't
think,
that's
something
we
have
in
this
tunnel.
E
B
Well,
that's
fair,
but
we
shouldn't
preclude
it.
I
mean
just
like
for
ip
routers.
There
are
many
different
cases
where
you
don't
necessarily
want
to
signal.
Let's
say
you're
under
load.
So,
like
you
know
giving
guidance
seems
reasonable
to
me,
but
at
the
end
of
the
day,
we're
sitting
on
the
shoulders
of
many
hundreds
of
pages
of
ip
specs
no
need
to
reinvent
those.
E
Yes,
if,
if
you
have
a
have
a
reason,
that's
covered
by
icmp
to
drop
it,
you
can
use
icmp.
We
don't
have
to
care
about
it's,
not
our
business
if
you
actually
drop
it,
because
that's
not
what
you
requested
in
in
the
connect
request
and
like
I'm,
providing
you
a
connect
service
and
I'm
I'm
believe
that,
like
you're,
not
doing
what
what
you
asked
me
to
do
or
like
what
I'm
providing
to
you.
Maybe
it's
good
to
say
this
explicitly.
P
N
M
Either
in
terms
of
trying
to
protect
the
network
integrity
under
either
attack
or
high
load
solutions,
you
know
that
makes
a
lot
of
sense,
but
in
the
context
of
a
tunnel
environment
which
we
are
talking
about,
this
is
a
much
more.
You
know
collective
use
case
of
general-purpose
ip
routing
stuff.
You
you've
actually
got
an
environment
where
you
have
a
stable
endpoint
at
both
ends.
Okay
and
you've
already
negotiated
some
amount
of
you
know,
connection
semantics
before
you've
started
traffic
at
this
point
deciding
to
silently
drop
smash.
G
L
The
way
that,
whatever
those
other
documents
saying
you
want
to
do
says
you
want
to
do
so.
I
guess
I
would
I
would
I
would
kind
of
like
to
so
I'm
in
particular,
say
invalid
source
requests
like.
Why
isn't
this
just
like
you
know,
addressable
for
like
ordinary
ip
address,
folder
right,
so
you
know
it's
pc,
56
right
so,
like
you
know
why
can't
we
just
say
behave
whatever
that
has
to
do
so.
You
know.
G
K
Well,
like
I
mean
close,
the
stream
like
if
people
people
are
are
ignoring
what
the
proxy
told
them
to
do,
then
I
mean,
I
think
that's
I
mean
quick
is
a
different
layer,
but
in
quick
like
any
time
you
you
violated
the
spec,
we
just
we
just
kill
you
and
I
think
that
seems
totally
appropriate.
Here
I
mean
icmp
is
a
different
world.
K
Where
you
know
you
don't
have
these
pre-negotiated
things
or
the
the
context
for
icmp
is
a
network
a
wild
west
where,
like
you,
don't
really
know
where
the
pact
came
from
and-
and
you
don't
know,
what's
authorized
and
what's
not
but
like
here,
all
this
stuff
is
pre-negotiated.
The
client
is
authenticated
if
the
client's
misbehaving
just
kill
the
kill,
the
stream,
if
not
the
connection.
G
I
mean
there
are
certainly
other
cases
where
you
are.
You
know
the
other
side
knows
what
you're
assigned
like
an
ipsec
tunnel
can
assign
you
something,
but
also
your
router
will
know
what
addresses
you
can
send
from
that
they've
registered.
So
there
are
other
cases
where
you
could
receive
icmp
errors.
K
E
E
O
Philip
says:
inventing
a
new
mechanism
makes
the
world,
especially
in
regulated
environments,
more
complicated,
so
icmp
inside
the
channel
is
a
good
guidance
still
if
we
want
to
signal
bad
behavior
with
respect
to
the
tunnel
configuration
sending
the
error
as
a
capsule
as
a
protocol,
error
makes
sense
and
turn
it
into
an
icmp
on
the
client
side.
Make
sense.
M
G
L
K
L
While
having
like
any
any
misbehaving
device
that
which
I
assure
you
there
are
many
potentially
quite
connection,
be
torn
down
yeah,
so
that's
like
you
know
in
particular,
you
know
you
know
in
an
imagination
where
you're
actually
proxying
like
like
a
customer
network,
and
you
know-
and
now
you
have
like
thousands
of
devices,
that
you
don't
control
and
then
one
of
them
delicious
or
non
maliciously
generates
a
focus.
Ip
and
the
whole
thing
is
torn
down.
L
That
just
doesn't
like
it's
going
to
have
all
situations,
so
I
don't
think
I
think
again.
This
is
like
some
situation
where
we're
standing
on
the
shoulders
of
giants
and
we
ought
to
like
steal
from
those
giants,
and
we
know
how
to
like.
I
mean
like
this.
This
is
like
building
a
transit
network
so
like
she
behaves
the
same,
but
that
same
one.
L
So
I
I
don't
think
I
think
it's
I
think
you
know
it's
one
thing
to
think
like
if
this
is
like
the
version
where
it's
like
the
customer
vpn,
in
which
case
I
could
agree
with
like
martin
but
like
the
customer
bps
are
generating
bogus
things.
You
know
because
he's
like
going
and
going
to
euro
netflix,
then
maybe
you
can
tear
him
down,
but
I
just
don't
think
I
think
that
they're
all
matter.