►
From YouTube: IETF103-QUIC-20181107-0900
Description
QUIC meeting session at IETF103
2018/11/07 0900
https://datatracker.ietf.org/meeting/103/proceedings/
B
B
A
A
Good
morning,
this
is
the
note.
Well,
once
again,
you
should
be
familiar
with
this.
It's
the
terms
under
which
we
participate
in
the
ITF,
especially
regarding
your
conducts,
both
here
in
the
room
and
elsewhere
and
intellectual
property.
So
if
you're
not
familiar
with
it,
please
do
so.
You
can
find
it
on
the
ITF
website.
A
F
A
D
A
G
A
A
That
movie
was
on
like
three
nights
ago,
so
we're
gonna
have
a
quick
overview
to
make
sure
we're
on
the
same
page
from
Marcus,
Lars
and
I
are
gonna
set
the
scene
we'll
have
some
discussion
and
some
humming
and
then,
after
that,
we
need
to
reserve
some
time
to
talk
about
the
future
in
the
working
group.
How
we're
gonna
work
together.
A
A
H
A
A
I
B
We
would
we
have
a
series
of
thumbs
that
a
an
earlier
version
of
which
we
outlined
on
the
mailing
list
and
we
have
refined
it
based
on
some
feedback
and
there's
a
slide
on
that
later.
So
the
idea
is
that
we
would
ask
for
clarification.
Questions
on
the
particular
thing:
we're
gonna
ham
on
only
do
a
hum.
If
that
hum
is
inconclusive,
have
a
discussion
try
to
figure
out?
Why
is
it
inconclusive
right
and
if
it's
conclusive,
we
just
move
on
to
the
next
one
discussion.
A
There
does
not
denote
fill
the
mic
lines
for
an
hour.
We
want
to
try
and
avoid
that
if
we
can
so
I
know,
people
are
eager
to
get
this
closed
out
using
chairs
yeah,
but
well.
We
need
to
make
sure
that
we
follow
the
process
here
and
then
have
it.
Let
everyone
have
their
saying
so
with
that
Marcus
come
on
up
and
I'll
get
your
slides
going.
K
J
I'm
Marcus,
Diller,
I'm
sure
summary
of
the
work
that's
been
done
so
far.
So
next
slide,
please
so
just
a
short
recap
of
what
spin
bit
is
it's
basically
using
one
bit
in
the
short
packet
header
and
implements
used
to
implement
a
very
simple
algorithm
that
a
non
path
observer
can
use
to
to
estimate
the
end-to-end
round-trip
times
between
two
end
points.
So
basically,
server
sends
packets.
Those
packets
always
reflect
the
value
of
the
bit
that
is
held.
That's
observed
from
packets
coming
from
the
client.
J
The
client
sends
the
inverse
of
that
bit
instead
when
it
from
practicing
in
the
service
from
the
server.
So
basically,
what
you
get
is
is
sort
of
a
square
wave
that,
with
a
period
corresponding
to
the
end-to-end
RTT.
So
if
you
observe
it
in
one
direction,
you
get
the
end-to-end
RTT.
You
can
also
observe
the
signal
in
two
directions
and
you
can
estimate
the
component
or
duties
between
server
and
or
between
the
end
and
end
point
and
the
measurement
point.
J
Basically,
this
is
very
similar
to
work
that
has
been
done
in
the
IP
PM
working
group,
but
with
some
substantial
differences
that
the
work
in
IP
PM,
the
the
Altmark
work,
is
basically
two
synchronized
boxes
in
the
network
that
that
are
that
are
marking
these
packets
and
then
they
are
agreeing
on
sort
of
the
size
of
this
square
wave
and
so
on.
Here
this
is
the
square
wave
is
interchanged
end-to-end
between
endpoints,
and
you
only
require
one
observation
point
next
slide.
Please.
J
J
You
you
are,
you
have
the
possibility
to
sort
of
determine
which
part
of
the
network
is
generating
the
problems.
Also
not
another
common
use
case
is
what
we
call
quality
monitoring.
Basically,
you
have
a
passive
system,
just
collecting
a
bunch
of
metrics
KPIs
reporting
them
to
dashboards,
etc,
sort
of
giving
you
an
overview
of
the
quality
of
your
network,
and
you
can
associate
it
to
two
different
services
and
so
on
being
able
to
monitor
and
to
an
RTT
and
so
on.
J
It
is
typically
very
common,
very
useful
for
these
things,
as
well,
also
being
able
to
measure
RTT.
You
can
also.
You
can
also
take
this
sort
of
degree
of
buffer,
bloat
and
other
types
of
issues
downstream
in
your
network
and
in
certain
cases
you
could
apply
some
some
mitigation
techniques
based
on
what
you've
observed.
Then
it
is
also
very
common
for
internet
measurement
research
where,
basically,
you
might
not
have
control
over
the
endpoints
which
which
you're
interested
in
in
in
in
your.
J
J
So
there
has
been
some
expressed
intent
to
implement
the
spin
bit,
and
this
is
based
off
on
on.
What's
been
discussed
on
the
list
recently,
if
you
don't
agree,
you
can
come
up
and
say
that,
but
what
I've
seen
on
list
so
far
is
that
we
have
seen
expressed
intent
from
Microsoft
Lightspeed
technologies
and
we
have
the
pker
quick
stack
which
has
implemented
it,
but
has
some
reservations
on
certain
issues
relating
to
to
privacy.
J
J
One
of
these
concerns
was
what
was
called
the
geolocation
threat.
Basically,
the
idea
was
that,
if,
if
you
know,
if
you
have
fixed,
if
you
know
where
a
set
of
servers
are-
and
you
measure
you
measure
the
RTT
from
one
client
towards
the
service,
you
could
somehow
correlate
these
measurements
and
get
an
estimate
of
where
this,
where
this
particular
client
is
residing.
J
This
was
analyzed
by
a
design
team
like
more
than
a
year
ago.
We've
been
doing
this
for
a
long
time
and
basically,
the
conclusion
of
that
design
team
was
that
the
the
RTT
data
that
you
get
when
trying
to
do.
This
is
very,
very
coarse
and
generally
lacks
the
required
precision
to
make
this
make
this
attack
very
useful
and,
furthermore,
quick
without
the
spin,
which
still
lets
you
track
the
handshake
or
TT.
J
So
basically,
if
you're,
tracking,
the
handshake
or
TT
from
a
set
of
connections,
you
basically
get
the
same
data,
because
what's
interesting
here
is,
is
the
min
RTT
and
typically
a
handshake?
Rtt
is
quite
sufficient
to
get
the
minority
and
if
you
have
steady,
state
flow,
etc,
you
you
it's
harder
to
track
the
min
RTT,
basically
so
selectively
open,
opting
out
of
spinning.
J
It
is
another
issue,
so
basically,
if
you
for
summary,
if
all
clients
are
or
if
all
sets
of
endpoints
are
are
spinning
and
you
for
some
reason
do
not
want
to
spin,
then
if
you
opt
out
of
this,
you,
you
sort
of
expose
yourself
as
somebody
doing
something
special,
so
that
that
sort
of
requires
an
anonymity
set
in
order
to
not
not
stick
out.
If
you,
if
you
consciously
choose
to
not
spin,
then
on
application
concerns
basically
the
this.
J
This
is
a
mechanism
that
is
being
being
standard,
we're
aiming
to
standardize
it
for
for
version
one,
but
we
might
want
to
change
the
semantics
of
the
bit
at
that
position
in
a
later
version.
So
basically
that
will
require
that
a
sizable
amount
of
non
endpoints
are
not
spinning
from
from
the
start,
basically,
so
that
we
don't
ossify
on
this
bit
position,
so
we
can
move
on.
J
Then
there
has
been
some
concerns
on
sort
of
the
the
the
robustness
of
this
signal.
I
mean.
How
well
does
it
work,
so
it
has
been
shown
to
work
really
well
under
good
conditions
and
there's
a
great
paper
being
published
by
Pierre,
Miriah,
Bryan,
etc,
where
where
they
show
ya,
some
really
nice
results,
and
they
also
show
that
it's
sort
of
it's
really
susceptible
to
to
high
degrees
of
reordering,
because
these
high
degrees
of
reordering
is
sort
of
causing
noise
in
the
signals.
J
J
Then
there's
also
the
case
on,
if
you're
an
observer,
how
do
you?
How
do
you?
How
do
you
sort
of
filter
out
non-participating
endpoints,
especially
if
these
are
completely
scrambling
the
signal
just
sending
random
noise?
So
basically,
there
are
a
few
solutions
to
these
problems.
What
what
is
being
proposed
in
this
paper
is
is
something
called
valid
edge
counter
that
one
allows
for
very
precise,
but
potentially
low
frequency
sampling.
It
is
using
the
valid
edge.
J
So,
depending
on
how
you
observe
the
spinet
signal
you
can
either
I
mean
you
can
either
observe
it
in
just
one
single
direction:
sort
of
unidirectional
observation,
and
that
is
sufficient
to
give
you
end
to
end
RTT
data,
because
just
observing
this
square
wave,
you
you
get,
you
get
the
you
get
the
antenna
or
TT
the
problem
you
get.
There
is.
If
you
have
reordering
along
the
edges
of
that
square
wave,
you
need
some
form
of
heuristics
to
sort
of
filter.
J
Those
out
those
heuristics
can
can
can
be
sort
of
anything
depending
on
the
level
of
knowledge
you
have
of
expected,
oddities
in
your
network
and
so
on.
So
at
the
ITF
one
or
two
I
implemented
a
simple
heuristic
scheme
at
the
hackathon
where
basically
I
was
I,
was
counting
packets
per
per
per
spin
state
and
then
only
accepting
edges
that
were
that
there
were
at
least
a
fraction
of
the
size
of
the
previous
of
the
previous
state.
Basically,
and
that
was
a
pretty
useful
heuristic,
it
could
filter
out
most
of
the
reordering
problems.
J
But
it's
a
quite
you
know.
It
only
works
on
the
certain
conditions.
So,
but
if
you
have
a
bi-directional
observation
point,
you
can
use
some
more
inputs
to
edge
validation,
and
that
is
basically
utilizing
the
fact
that
that
the
spin
bit
is
really
a
reflection
of
of
an
exchange
of
packets
between
the
server
and
the
client.
J
J
So
I've
just
made
a
simple,
simple
measurement
framework
where,
where,
where
I
have
a
quick
server,
quick,
quick
client
passing
middle
box
where
I
measure
full
end-to-end
RTT,
both
the
sig
from
single
that
originates
from
the
server,
but
also
from
the
client,
then
I
also
measure
the
the
component,
our
duties,
that
that
is
the
RTT
between
the
server
and
the
mailbox
and
the
server
and
the
middle
box
in
the
client.
So
all
of
these
are
then
running
on
home
VMs.
J
In
the
same
system,
so
they
have
synchronized
clocks,
so
I
can
show
some
nice
date
over
time.
Yeah
I
can
show
some
results.
So
basically,
here
we
have
a
link
where
there
is
5%
random
packet
loss.
The
loss
is
sort
of
the
lost
distribution
if
there's
a
lost
correlation
of
30%,
and
here
I
do
in
these
bi-directional
measurements
and
using
adds
edge
validation.
So
what
we
see
in
the
upper
graph
is
is
the
the
end-to-end
RTT
in
read
the
labels.
We
need
to
tell
them
what
the
colors
are.
The
forth
the
lines.
J
J
Orange
is
end-to-end
RTT,
measured
in
the
direction
served
client,
and
then
we
have
green
and
red,
which
is
the
component
or
DT,
which
is
sort
of
the
RTT
between
the
measurement
point
and
the
server
and
between
the
measure
point
and
the
client
the
graph
below
is
the
same,
or
that
is
our
TT
measured
by
the
server.
So
what
I'm,
comparing
against
here
is,
is
what
I
saw
sort
of
called
the
state
of
the
art
of
our
TT
measurements,
because
that
is
sort
of
yeah.
The
server
has
would
have
the
best
information.
J
So
what
we
see
here
basically,
is
is
what
I
want
to
show?
Is
that
on
the
left
on
the
Left
figure?
Here
we
see
that
over
time
we
seemed
like
the
the
spin
bit.
Our
T
measurement
is
similar
to
to
the
server
based
measurements.
We
see
that
there
are
a
bunch
of
delay,
spikes
happening
here
and
there
and
they
seem
to
be
captured
both
by
the
server
and
the
spin
bit
observer.
We
do
see
if
you
look
at
the
sort
of
the
statistical
distribution
of
our
TTS.
J
We
see
that
there
is
a
slight
over
estimation
of
the
rtt
based
on
the
spin
bit
signal
that
can
be
due
to
a
bunch
of
factors:
I'm
still
hypothesizing
a
little
bit
about
it,
but
I.
Think
one
of
these
one
of
these
factors
could
be
that
the
the
the
RTT
measured
by
the
server
it's
sort
of
it
compensates
for
or
reduce.
It
removes
the
the
and
any
sort
of
delayed
if
there's
any
sort
of
delay
in
generating
the
ACK
that
is
removed
from
the
from
the
from
the
RTT
estimates,
because
that
is
information.
J
That
is
signal
in
a
quick
ACK,
but
that
information
is
not
available
to
the
spin
bit
observer
so
that
that
could
be.
That
could
be
one
reason
for
for
for
seeing
these
differences
and
then,
of
course,
the
the
loss
itself
can
also
generate
sort
of
that
that
the
edges
get
a
little
bit
blurry,
because
if
you
have
loss
along
the
edges,
it
might
take
longer
time
to
actually
detect
an
edge.
B
D
J
J
Basically,
this
cost
the
the
the
sender
to
do
a
bunch
of
sort
of
it's
a
bunch
of
spurious
lost
detection
going
on
and
a
bunch
of
congestion
window
reductions.
So
we
also
see
that
we
get
both
of
these
graphs,
the
ones
on
the
previous
slide,
and
this
one
is
the
same
amount
of
data.
But
we
see
that
we
have
a
lot
more
samples
here
and
that's
basically
because
I
guess
the
throughput
got
went
much
lower.
So
we've
got
a
bunch
more
RTT
samples.
J
J
We
see
the
same
phenomenon
here
that
tracks
the
behavior
correctly,
but
there
is
some
sort
of
slight
over
estimation
of
the
RTT,
and
here
with
the
reordering
case,
it
is
important
because
without
without
this
edge
validation,
we
would
have
our
titties
if
the
most
naive
observer
would
have
observed
a
bunch
of
our
titties,
which
were
a
lot
lower
than
the
sort
of
pace
RT
and
then
in
this.
In
these
particular
examples,
the
base
RTT
is,
is
40
milliseconds.
J
So
again
we
see
that
with
very,
very
simple
heuristics,
which
can
be,
of
course
improved
upon
a
lot
if
I
mean
if
you
were
serious
about
doing
measurements.
In
this
way,
we
get
we
get
the
results
that
are
absolutely
good
enough
for
the
purpose
and
I
think
for
me
that
was
important
insight,
because
that
basically
means
we
do
not
require
additional
bits
to
make.
This
signal
robust
and
yeah.
That
was
basically
it
that
was
summary
questions
to
clarification.
Questions
on
own.
L
A
We've
talked
about
this
for
a
while
I
think,
Laura's
expressed
an
ardent
desire
to
kill.
As
this
discussion
out,
we
haven't
had
any
new
information
I
think
for
a
while,
and
it
seems
like
the
analysis,
is
now
pretty
mature,
and
so
we
laid
out
some
questions
on
the
list.
I
think
we
can
try
and
do
the
hums
now
if
people
have
things
that
they
think
we
need
to
think
about
before
we
do
the
hums.
A
We
can
do
that,
but
we're
gonna
time
bound
that
we
want
to
leave
some
time
after
the
hums
to
make
sure
that
if
there's
any
further
discussion,
we
can
do
that.
Does
anybody
need
the
blue
sheets
to
record
your
presence
of
this
important
milestone?
If
we
could
have
them
send
up
to
the
front,
there
seemed
to
be
a
number
of
people's
the
front
I'm.
A
Framed
them
all,
so
we
do
have
it's
not
a
new
bit
of
information,
but
because
it's
not
something
we've
confirmed
yet,
but
we're
currently
just
to
inform
people
in
working
group.
The
chairs
are
now
chasing
up
and
we're
gonna
be
working
with
the
ISG.
There's
a
question
as
to
whether
there's
a
piece
of
IPR
that's
been
disclosed
against
another
draft
in
another
group
that
maybe.
A
B
A
As
with
everything
that
we
do
in
this
working
group,
if
we
become
aware
of
some
IPR,
then
the
working
group
needs
to
figure
out
what
to
do
with
that.
So
once
we're
actually
sure
that
there's
a
disclosure
we'll
follow
that
process
as
well
for
the
purposes
of
today's
discussion,
that
has
not
occurred
yet.
A
So
these
are
the
hums.
We
think
we
need
to
have
we've
inserted
one
since
the
email
that
we
sent
out
to
confirm
that
the
privacy
and
security
aspects
of
spin
are
well
understood
and
acceptable,
and
so
this
is
the
kind
of
series
of
questions
we
intend
to
ask.
The
group
to
people
have
any
questions
or
suggestions
for
this
set
of
questions,
and
do
we
have
any
other
comments
or
discussion
to
have
before
we
do
this.
B
B
We're
gonna
have
a
time
most
discussions
trying
to
figure
out
what
where
the
inconclusive
miss
comes
from,
and
that
is
because
for
many
of
those
at
least
sort
of
Mark
and
I
effort
privately
and
publicly
on
lists
from
enough
people
that
we
believe
there's
actually
a
pretty
sort
of
clear
shape
to
where
the
consensus
lies.
But
we
want
to
confirm
that
without
spending
like
another
two
sessions
on
it,
Christian
Christian.
C
B
But
its
Melanie
don't
cook
light
independent,
so
I
think
in
my
mind
at
least
that
is
it.
So
if
there's
consensus
somewhere
along
these
hums
that
the
spin
bit
will
include
it
and
will
be
included
in
the
spec
in
some
form,
then
I
would
like
to
have
a
brief
discussion
on
whether
we
want
that
mechanism
to
be
part
of
it
and
and
and
if
we
actually
include
it.
I
think
we're
going
to
have
a
like
a
longer
discussion
on
what
exactly
does
that?
N
B
G
It's
a
pretty
friendly
amendment
to
what
Christian
was
saying:
I,
actually
think
if
you,
if
you're
looking
at
your
confirmation,
humps
the
privacy
security
aspects
of
spin,
are
well
understood
and
acceptable.
I
think
that
the
if
you
include
in
that
that
one
of
the
privacy
security
aspects
is
that
you
need
some
mechanism
for
not
spinning
what
that
mechanism
is
and
what
exactly
the
statistical
choice
would
be
if
we're
using
statistical
is
not
there
but
I.
Think
in
that
confirmation
it's
a
requirement
that
we
understand.
G
B
D
O
Hi
there
this
is
Daniel
con
Gilmore.
So
I
do
note
that
while
there
was
a
reference
in
the
earlier
slides
to
ossification
concerns,
there's
no
nothing
here
about
the
ossification
risks
being
well
understood
and
acceptable.
I,
don't
know
if
we're.
If
we're
trying
to
get
as
many
homes
as
possible,
you
might
want
to
add
that.
O
O
P
P
Boehner
I'm
wondering
whether
to
add
to
the
ossification
concerned:
I,
don't
know
whether
it
was
analyzed
like
what
the
differential
treatment
concerned
would
be.
For
instance,
this
is
kind
of
related
Ted's
point
about.
You
must
be
able
to
not
spin.
But
what
happens
if
you
don't
spin
like
how
would
operators
treat
your
traffic
differently
if
you
don't
spend
versus?
If
you
do
spin
wood
is.
Q
Thanks
trying
to
reflect
her
well
in
the
notes,
it
seems
a
little
odd
to
me
to
have
acceptable
in
the
confirmation
question
here,
because,
given
that
Dean
had
we
seem
to
have
made
this
distinction
between
confirming
we
all
have
the
same
understanding
and
then
making
value
judgments.
Based
on
that
understanding,
so
I
think
it
would
make
sense
to
me
to
kind
of
punt
the
acceptable
question
there
to
the
consensus
questions
you
know
to
the
degree
it
needs
to
be
addressed
separately
at
all.
A
A
R
S
It's
mr.
Dawkins,
as
a
individual
participant
in
these
discussions.
Shouldn't
worry
me
that
we're
talking
about
whether
a
sufficient
analysis
has
been
done,
given
that,
knowing
that
you
haven't
found
any
security
because
of
privacy
concerns,
yet
it's
not
the
same
as
knowing
that
they're
our
enemy,
because
so
what
I'm
kind
of
wondering
is?
S
A
B
D
B
S
And
I
was
actually
paying
attention
to
that
part
of
the
conversation
as
well.
So
I
appreciate
the
work.
That's
been
done
up
to
this
point.
I
just
say:
I
just
wanted
to
make
sure
I
understood
what
the
the
parachute
looked
like
if
they,
if
the
answer
was
oh-
and
there
was
this
other
thing
we
didn't
think
of
yet,
although
we
thought
about
it
for
months
right,
I.
A
B
V
B
B
C
There
have
been
two
arguments
for
several
spin
beads:
the
two
teams,
the
work
of
million
Brian
was
effec
bits
and
the
walk
of
the
orange
guys,
who
are
basically
using
additional
bits
to
detect
losses,
correct,
and
so
what
we
are
deciding
when
we
say
single
spin
bit
is
to
say
that
this
kind
of
extension,
such
as
detecting
losses,
are
otoscope
for
v1,
correct
and
might
be
visited
later,
but
they're
definitely
out
of
scope
now
they're,
not
part
of
the
decision
we're
making
today.
Just
for
clarity,
yes,.
A
A
B
A
B
F
I
I
F
F
Yes,
that
I
guess
the
the
point
that
that
was
made
off
mic
was
that
number
five
would
would
speak
to
that
I.
Don't
think
that's
quite
what
I
was
saying
that
it's
it's
really
down
to
the
rates
at
which
people
decide
to
do
this
heuristic
Lee
and
the
number
of
people
who
would
even
consider
doing
it
out
of
the
whole
and
if
I've
been
convinced
that
there's
enough
there.
Okay
thanks.
N
B
K
You
gotta
come
by
so
yeah
were
just
here
to
clarify,
would
fit,
but
purpose
means
because
I
think
initially
initially
it
was
stated
it's
it
provides
everything
that
an
operator
needs
know
obviously
Orange
think
that
if
they
need
something
else
to
but
okay,
so
we
just
focusing
on
so.
Let's
treat
for
purpose
of
art
et
estimate.
Okay,
do.
A
A
B
C
There
are
two
parts
in
it
specifically
not
to
spin.
Okay,
there's
one
part
which
says
I,
can't
wit
a
bit
in
my
implementation,
so
that
the
spin
bit
will
be
set
to
some
kind
of
random
or
constant
value.
That
is
not
spinning
and
that's
one
question,
but
if
we
want
say
possible,
it
should
be
possible
without
ill
effect
and
possible,
with
our
EDA
effect
means
that
there
is
a
sufficient
annuity
said
that
if
I
do
that
are
not
going
to
be
singled
out.
B
Okay,
so
quickly
before
it
had
speaking,
will
insert
something
that
says
the
clarification
question
that
I
have
are.
We
are
we
only
since
we
just
added
this?
Are
we
only
talking
about
the
possibility
for
clients
to
not
spin,
or
are
we
also
talking
about
the
possibility
for
servers
to
not
echo
sir
servers
Christian
says
both
some
people
think
okay,
both.
C
A
G
X
Sanjay
Mishra,
so
on
this,
the
question
I
have
is
that
there
was
some
discussions
in
the
mailing
list
about
how
we
would
specify
if
you
must
spend,
and
so,
however,
the
wording
comes
out
in
the
specification
about
adhering
to
the
protocol.
So
how
does
this
aligns
with
that
thought
that,
if
you,
if
the
spec
requires
you
to
spin,
then
how's,
the
decision
of
spinning
or
not
spinning,
is
going
to
be
resolved
in.
A
B
I
I
B
There
is
an
ASP,
so
opt
out
sounds,
doesn't
sound
to
me
like
a
negotiation
step
is
required
or
should
be
required.
It
sounds
like
it
needs
to
be
unilateral
decision
by
an
endpoint
to
say
I'm
not
going
to
do
this
for
this
connection
or
at
all,
without
a
negotiation
involved
with
the
peer
order.
Network.
W
This
have
not
been
met,
for
example,
by
applying
a
50,
millisecond
RTT
penalty,
to
flows
that
don't
have
this
pin
bit
or
anything
else
dropping
packets
whatever,
and
so
they
could
basically
force
everyone
to
spin
unless,
unless
you
you're
willing
to
accept
that
penalty
and
I'm
not
really
sure
how
we
can
guarantee
this,
we
just
have
to
take
the
network
operators
here
that
they
are
not
going
to
do
that.
So
there's.
B
I
think
it's
Kristin
was
getting
to
that
earlier.
So
there
are
ideas
for
how
you,
even
if
you
are
an
endpoint
that
would
normally
spin
for
a
fraction
of
your
connections,
you
don't
so
to
create
a
set
of
connections
that
are
not
spinning
so
that
there
will
always
be
sufficient
non-spinning
traffic
for
somebody
who
always
opts
out
to
not
stick
out
I
think
that
is
roughly
what
the
ideas.
F
D
B
Right,
while
you're
making
pretty
emojis
next
slide,
the
next
one
I
expect
we're
gonna
have
a
little
bit
of
discussion
about,
which
is
the
confirmation
that
the
privacy,
security
and
ossification
aspects
of
including
the
spin
bit
in
quake
are
well
understood,
and
part
of
this
is
the
output
of
the
design
team
or
part
of
that
relates
to
the
output
of
the
design
team
that
was
done
year
ago.
It's
whoa
no.
A
G
V
So,
like
I'm,
not
I,
think
I
may
agree
with
first
two
and
don't
agree
with
the
third,
so
I
think
you
know
we
did
a
sense
of
analysis
of
the
the
sort
of
impact
on
my
ground
trip
measurement
and
it's
apology,
leakage
and
say:
that's
pretty
well
understood,
I!
Think
we
don't
understand
the
ossification
thing.
The
security
thing
I
think
is
also
fine.
V
If
it's
terrific
narrowly
like
constrain
to
be
like
you
know
the
concept
there
entities
you
or
going
to
try
to
fly
with
look
I
know
I'd,
raised
concerns
about
timing
analysis,
but
I
think
those
have
been
resolved.
But
it's
not
I,
don't
think
we
all
understand
the
suffocation,
a
special.
Nor
do
we
understand
this
point.
Y
I
think
there
has
been
more
privacy
security
as
well
as
ossification
analysis
for
this
one
bit
than
for
any
other
bit
in
quick,
and
my
question
is:
is
this
question
about
it?
Do
we
understand
well
all
those
things
that
we
already
discussed
for
this
bit
or
is
this
also,
you
know
it's
a
question:
are
you
concerned
that
there
might
be
any
other
unknown
risk
that
might
also
exist
for
all
the
other
parts
of
quick
words
that.
B
E
Just
wanted
to
point
out
that
for
the
ossification
concern,
I
think
we
have
done
a
plenty
of
analysis
regarding
where
the
clan
doesn't
zeroes
out
the
bid
or
just
randomizes
the
bit,
but
III
think
we
haven't
discussed
about
whether
about
the
clients
or
servers
send
your
party
of
signal
using
that
bit.
For
example,
if
a
client
sense,
if
an
endpoint
sessile
lost
cut
off
losses
for
the
ease
in
this
bit,
then
it
could
be
misinterpreted
as
a
sample.
B
W
B
W
So,
regarding
the
privacy
aspects
of
the
spin
mode,
there's
been
an
analysis
off
of
the
geolocation
aspects
of
that,
but
it
didn't
include
the
case
of
VPNs
and
it
didn't
include
the
aspect
of
Nats
so
for
VPNs
and
formats
in
the
tcp
case,
all
you
can
get
as
an
observer
is
the
round-trip
time
between
between
the
VPN
endpoint
and
this
server,
and
you
might
get
a
single
measurement
during
the
headshake
in
quick.
You
get.
W
B
W
B
B
W
V
A
G
Teddy
I
wanted
to
comment
on
that,
a
concern
that
Martin
raised
about
the
the
VPN
gateway
or
similar
exposure.
It
is
the
case
that
if
you
are
very
far
away-
and
it
does
turn
out
to
be
very
very
far
away
between
your
VPN
gateway
and
the
and
the
the
service
that
you
may
be
able
to
detect
that
there
is
a
VPN
gateway
present.
G
G
I
wasn't
expecting
so
there
must
be
a
VPN
gateway
here,
but
you
can't
tell
where,
behind
that
gateway,
somebody
is
right,
and
so,
from
from
that
perspective,
it
is
possible
to
determine
that
such
a
gateway
is
present,
but
not
where
it
is
being
not
where
the
end-user
is
as
a
result
of
that.
So
there
it's
distinguishable
from
the
geolocation
case.
In
that
way,
that's
the
bit
of
information,
that's
possible,
as
I
pointed
out
in
the
exchange
with
Kazuo
on
the
list
earlier.
G
I
would
agree
that
if
this
is
a
case
of
concern,
one
thing
that
we
could
do
here
is
make
the
default,
since
it
must
be
possible
to
opt
out
that
one
of
the
cases
in
which
you
opt
out
is
when
you
are
connected
to
an
interface
which
will
have
a
VPN
gateway
like
a
tun,
0
style
interface,
but
I
think
we're
very
deeply
into
the
design
space.
At
that
point.
J
So
if,
if
enough
flows
are
not
spinning,
then
trying
to
penalize
those
flows
would
be
extremely
counterproductive
for
an
operator,
because
the
reason
of
having
the
reason
of
having
these
types
of
mechanisms
is
to
sort
of
allow
for
diagnostics
and
improve
the
performance
of
your
network.
And
ultimately,
you
are
judged
by
by
by
the
consumers
of
your
network
you're,
judged
by
the
the
the
quality
of
experience
they
get.
Now,
if
you
really
don't
want
any,
if
you
really
don't
want
this
to
happen,
you
should
just
lock
quick
as
its
because
then
you
get.
J
I
Generally,
you
go
as
I
as
I.
Listen
to
this
discussion
and
even
before
that
I
think
rephrasing.
The
question
of
the
the
priority
see
securing
ossification
aspects
being
well
understood
is
useful
I,
don't
it's
gone
far
enough.
I
suspect
that
we
may
not
be
able
to
get
to
the
end
of
you.
I,
don't
know
that
we
can
never
say
that
we
understand
everything
here,
simply
because
we
don't,
and
if
shoes
keep
popping
up
every
five
minutes
here
and
then
somebody
says
well,
he
can
fix
it
this
way
and
you
can
fix
it
that
way.
I
I
It
was
yes,
fair
enough.
Okay,
two
months.
Oh
no
one
month.
Sorry,
my
god!
My
point
here
is
that
that
that
there
might
be
more
issues
that
come
up
in
the
future
and
I
want
to
be
clear
that
we
can
still
make
a
decision
on
this.
We
don't
need
to
have
complete
information
before
we
make
a
decision
on
this
for
now,
if
you're
going
to
wait
until
we
have
complete
information
on
this,
if
you're
not
getting
this
done
with
p1,
so
this
is
incomplete.
I
I
expect
it'll
remain
incomplete,
I,
don't
think
we
should
have
any
I,
don't
I,
don't
I,
certainly
don't
expect
to
know
everything
about
what
can
happen.
What
other
issues
can
come
up
even
in
the
near
future,
even
the
next
month,
something
that
that
comes
up
and
says?
Okay,
this
plane
bit
is
going
to
expose
this
other
bit
of
information.
That
is
even
more
critical.
It's
possible
I,
just,
don't
know
it
yet,
because
I
don't
think
that
we
have
enough
experience
in
the
space
and
I'm
gonna
make
my
decision
with
that
in
mind.
N
Z
But
we
just
don't
know
where,
where
exactly
they
connect
the
other
side
of
the
connection
ends
I'm,
afraid
I
haven't
seen
the
analysis
of
what
would
happen
if
an
if,
if
an
a
possible
attacker,
is
able
to
do
BGP,
hijacking
and
say
it
uses
RTT
to
figure
to
to
to
to
limit
the
possible
sources,
and
then
it
enumerates
the
sources
with
with
hijacking
the
BGP
prefix.
That's
the
only
thing
I
can,
you
know,
come
up
with
sorry.
E
I'm
there,
by
confirming
the
third
eyes
you,
we
agree
that
spivot
would
be
an
optional
feature
if
it's
going
to
be
adopted.
So
that
means
that
the
first
issue
that
we
are
discussing
now
means
that
if
we
have
enough
information
about
privacy,
security,
ossification
aspects
to
an
extent
that
we
can
cross
the
stream,
it
does
not
show
element
of
I.
Think
I.
Think
that
way.
Might
you
know
what.
C
Christian
with
imam
I'd
like
to
make
a
remark
about
the
previous
comment
about
BGP
hijacking,
the
spin
beat
is
a
trade
off
between
some
oversee
whisk
and
better.
A
network
management.
Better
managed
network
management
in
particular,
can
detect
BGP
I
checking.
So
that's
basically
well
it's
it's.
Basically,
that's
part
of
the
trader.
So
it's
not.
We
cannot
say
that
when
we
refuse
to
expose,
everything
will
be
better.
C
That
is
not
necessarily
true,
I
mean
if
we
make
the
network
easier
to
manage,
it's
also
easier
to
find
anomalies
in
the
network,
and
it's
a
good
thing
to
be
able
to
find
them.
So
it's
not
that
the
thing
is
black
and
white
and
that,
if
you
were
to
expose
nothing,
you
will
be
better
off.
We
are
asked
to
make
a
trade-off
decision
between
some
risks
and
some
advantages,
and
the
question
here
is
whether
we
have
enough
of
a
grasp
of
the
risks
and
the
existing
mitigation
that
we
can
make.
The
decision.
A
B
I
B
The
concept
sort
of
the
reason
for
the
hum
was
to
make
sure
that
we
don't
have
people
saying
I
couldn't
hum
because
I
don't
I
didn't
understand
this,
and
and
and
this
was
the
I
mean.
This
is
the
main
concern
it
was.
That
was
raised
about
to
spin
the
design
and
then-
and
there
was
a
lot
of
work-
was
put
into
it,
and
so
we
want
to
make
sure
that
people
were
aware
of
the
discussion
and
analysis
that
had
happened
on
this.
I
B
I
B
A
I
F
T
AA
Listening
people
in
the
queue
fluffy,
this
is
Martin
Duke,
f5
networks,
I'm
a
little
I'm
afraid
of
lost
alot,
you
afraid
of
what
I've
lost
the
plot.
So
there
was
a
handshake.
There
was
a
negotiation
thing
that
disappeared
from
this
slide
a
minute
ago.
Yeah
do
we
does?
The
draft
include
a
negotiation
mechanism
that
is
under
to
be
part
of
this,
not
part
of
when
we're
not
there
yet
okay,
yeah,
because
what's
difficult
about
this?
AA
A
A
Fully
get
down
to
the
bit
that
I've
typed
in
the
meantime,
you
know
I
think
what
we're
talking
about
now
is
that
will
document
that
you
should
or
maze
in
and
echo.
But
if
you
do
so,
you
must
opt
out
some
amount
of
your
traffic.
That
seems
to
be
what
we've
been
discussing
today:
I
believe
that
does
not
include
negotiating
using
a
OPN
or
another
mechanism.
A
V
A
collective
you
sure
it's
do
you
well.
I've
lost
the
the
procedure
here.
A
little
bit,
I
was
gonna.
Just
like
this
hung
Aspen's,
you
ask
people
to
come
up
session,
which
is
I.
Do
not
presently
understand
whether
or
not
this
proposed
design
meets
the
third
criterion
which
he
listed
above
and
it
may
it
may
not,
but
I
don't
know
how
to
have
a
patient
right.
Now
that
assess
that.
That's
the
only
question
that
that's
the
only
reason
I
haven't
they.
Okay.
V
V
King
slow
down
just
sure
like
if
you,
if
the
requirement
is
that
traffic
discrimination
invasion,
that's
not
be
possible,
then
we
ask
you
to
look
at
that
problem.
If
they're
prime
now
we
can
remove
that
requirement.
But
if
that's
the
requiring
we
actually
look
at
that
problem
and
like
we
have
enjoyed
that
problem
at
all,
Oh.
M
M
AB
O
There
could
be
different
protocols
that
are
different
different
patterns
of
data
flow
and
since
we
respect
them,
quick
and
we've
been
thinking
about
books,
specifically
for
a
quick
HTTP
which
has
a
specific
mechanism.
I
think
I,
don't
understand
that.
Well
enough.
So
that's
why
I
haven't
in
the
negative
I
agree
with
what
the
chair
said
in
terms
of
what
I
heard
in
the
room,
but
you
wanted
feedback
about
why
people
hum
negative
supply.
I
Jenna
you're
I'm
really
interested
in
getting
to
the
consensus
question
so
I'm
wondering
if
we
need
to
get
a
green
check
on
this
before
we
get
there
or
if
we
can
live
with
the
discussion,
that's
happened.
It
seems
like
we
understand
the
concerns
people
have
concerns.
Instead
of
trying
to
get
consensus
on
this
question,
we
could
leave
it
with
an
orange
mark
and
then
go
to
the
consensus.
Question
sure.
A
I
A
I
A
D
A
AC
A
And
I'm
still
struggling
to
find
an
emoji
to
put
next
to
that
one,
so
just
leave
it
as
it
is
for
typing
finally
intent
to
implement
and
deploy.
We've
asked
this
question
a
few
times
in
various
fora.
We
believe
that
there
are
at
least
a
few
people
who
are
going
to
put
this
into
their
implementations
and
do
it
the.
B
We've
seen
an
email
from
Microsoft
on
the
list
that
stated
that
they
intent
if
this
gets
included
in
the
spec
to
ship
and
deploy
in
both
I
think
edge,
and
was
it
a
sure
so
client
and
server
I
believe
nothing
has
changed
here.
At
least
I
haven't
heard
anything
that
that
would
not
make
that
true
anymore
I'd
be
interested
to
hear
if
there's
other,
either
client
or
server
deployments
that
are
planning
to
to
implement
in
ship.
This.
B
We
also
got
asked
on
the
list
to
ask
whether
middle
box
vendors
would
build
equipment
around
the
bit
for
deployment
in
the
network.
That
is
also
good
information
to
have,
but
it's
not
quite
as
interesting
to
us
as
the
client
and
server
side,
simply
because
those
are
the
ones.
That's
been
the
pits
and
echo
them.
We
kind
of
know,
there's
interest.
AC
Coming
tell
me
Paul
the
Apple,
so
this
is
just
speaking
on
behalf
of
what
we've
discussed
on
the
iOS
and
Mac
client
side.
Our
currently
is
that,
if
this
is
included
that
we
would
use
spinning
on
quite
likely
the
majority
of
connections,
we
would
of
course
have
it
off
on
some
percentage,
but
at
least
over
50%,
probably
as
long
as
everything
goes
low.
So
that's
our
intent.
Thank
you.
Thank
you.
I
know.
AE
AF
AG
AG
G
AH
P
V
I
W
K
B
I
think
this
sort
of
should
inform
people
as
we
go
to
the
decision
at
the
end,
so
be
at.
The
point
was
to
figure
out
whether
there
would
be
an
initial
client
and
server
deployment
such
that
bits
were
spinning
and
echoing,
and
it
sounds
like
we've
heard,
from
at
least
some
clients
and
server
deployments.
That
would
do
so.
If
this
were
included
in
this
back.
It.
A
B
To
discuss
it
in
it
because
actually
saw
on
the
some
traffic
what
there's
actually
a
concrete
proposal
from
from
Christian
that
I
think
Brian
merged
in
the
editors
version
of
the
spin
bit
draft.
That's
I
think
it's
an
eighth
or
something
I
forgot.
What
the
exact
fraction
is,
but
there
are
some
numbers
that
are
more
concrete
than
just
that
we
can
I,
don't
think
it's
practically
hash
them
out
here,
but
this
general
approach
of
opting
out,
something
always
is,
is
of
what
we
should
do
right.
A
F
So
you
still
not
in
thompson.
I
I
just
wanted
to
say
that
what
you
have
here
is
sort
of
a
pressie
of
what's
in
the
email
that
Brian
sent
out
and
I
think
what
Brian
articulated
is
what
we
should
be
talking
about.
He
offered
two
options
and
I'm
wondering
if
we
can
defer
the
question
now
of
whether
we
do
the
negotiated
one
or
the
discretionary
one
until
after
we
make
the
the
sort
of
top-line
decision.
F
C
That
is
actually
really
hard,
because
that's
a
negative
okay
and
you
may
be
fighting
against
artificial
intelligence
measurements,
and
things
like
that.
So
it's
not
clear
to
me
that
we
entirely
know
how
to
build
the
anonymity
set
in
a
foolproof
way.
I
wish.
We
would
with
that
I'm,
not
sure.
That's
something.
B
So
I
would
argue
that
we
don't
necessarily
need
to
have
a
perfect
mechanism,
given
that
the
rest
of
Creek
is
done
exactly
what
I
would
call
perfect,
either
in
version
one
at
least
but
I
think
I
think
the
the
I
did
personally
I
would
I
would
hope
that
we
have
at
least
an
a
sort
of
solid
idea
for
providing
something
that
is
pretty
good
arm
it
for
inclusion
in
the
draft
and
and
and
again
personally,
I
think
the
design
I've
seen
Brian
hash
out
to
me
seem
to
be
pretty
good.
There
might
be.
B
A
A
B
Wording
on
little
case,
the
wording
on
the
third
line
says
said
it
must
be
possible
to
spin
occurring
without
consequence.
This
is
not
the
same
as
you
just
say
that
right
so
in
my
mind
at
least
a
not
spinning
and
therefore
being
part
of
a
larger
than
anonymity
set
protects
you
from
consequences
because,
as
Marcus
has
pointed
out
right,
it's
an
operator
cannot
penalize
half
their
traffic
or
three-quarters
of
their
traffic
or
or
even
ten
percent
of
their
traffic
all
the
time
right,
so
the
the
ability
to
hide
in
animes.
W
N
C
The
the
threat
that
is
mentioned
here
is
a
quality
of
service
threat
by
operators,
and
we
seem
to
believe
that
a
rational
pivot
or
will
not
do
that.
There
is
a
lot
of
hurt,
which
is
books
trying
to
analyze
traffic
and
find
out
anomalies
and
then
having
bad
consequences
for
the
evasion
of
the
traffic.
AA
C
B
B
N
Bumpers,
go
just
state
the
obvious,
as
well
as
exposing
the
spin
bit.
You
expose
your
addresses,
and
so
if
one
set
of
addresses
is
never
spinning
and
other
set
of
addresses
are
sometimes
spinning
you
can
tell
which
a
which,
however
I
would
still
say
an
operator
is
never
going
to
go
to
that
level
of
discrimination.
Okay,.
X
V
Rise
to
say,
let's
hum,
but
that's
the
church,
to
clarify
that
we're
humming
when
you
say
include
this
bit
in
this
occasion,
it's
been
in
a
specification
where
humming
on
this
thing,
this
as
design
here
because
like
I,
want
to
make
sure
we
get
a
crisp
answer
that
general
design
space.
Yes,
knowing
that
we're.
Y
Meuk
11,
so
this
whole
concern
about
operators,
behaving
mood
and
doing
the
friendship
treatment.
The
tool
they
have
is
so
much
like.
If
we
actually
think
that
would
happen,
I
don't
think
that
the
tool
they
have
is
so
much
easier
because
they
can
always
block
quick
traffic
as
a
whole,
because
quick,
isn't
exposing
anything.
So
if
that's
a
question
we
should
discuss,
if
we
want
to
move
on
was
quick
at
all.
Y
A
G
B
A
D
B
People
to
take
a
closer
look
at
that,
because
I
guess
that
would
be
our
starting
point.
Kazuo
has
already
sent
an
email
to
the
list
that
has
some
different
design
and
and
I
only
saw
it
coming.
I
haven't
really
read
it
yet,
but
please
take
a
look
at
what's
currently
being
discussed
and
and
help
us.
You
know
find
the
best
shape
for
this
mechanism
in
quick.
F
F
F
E
And
it
also
provides
us
to
evolve
both
from
end
points
perspective
and
also
from
the
observers
perspective,
because
the
fact
that
observers
looking
at
the
version
number
means
that
we
can
introduce
a
different
behavior
when
you
increment
the
version
number.
But
having
that
said
it's
only
about
burning
one
bit
per
pocket,
so
Island
straw,
I,
wouldn't
strongly
opposed
to
not
using
the
budget
based
negotiation.
S
G
Hardy,
thank
you
very
much
because
for
both
your
message
to
the
list
and
your
willingness
to
compromise
on
this
I
strongly
believe
that
making
this
discretionary
gives
a
better
opportunity
for
the
anonymity
set
to
be
well
constructed.
I
think
it
does
take
some
work
and
I
think
we
will
have
to
spend
some
time
figuring
out
if
there
are
specific
use
cases
where
we
should
suggest
opt
out
like
the
VPN
use
case
that
was
already
discussed
and
that
the
the
discretionary
use
will
give
us
over
time
a
better
result
without
the
risks
of
negotiation
and
blockage.
G
V
Concur
with
Martin
and
Ted:
this
is
the
idea.
I
would
add
that,
in
addition
to
the
points
they
raised,
this
is
just
like
extra
complexity
of
implementations
to
figure
out
what
they
have
to
do
so
I'm,
giving
that
work,
given
that,
like
this,
was
on
the
hairy
edge
of
being,
except
that
the
first
place
is
like
keeping
it
simple.
J
Marc
is
either
just
as
a
consumer
of
the
bit.
Even
if
I
see
the
version
that
says
is
gonna
spin
I
would
not
trust
it.
I
would
still
need
to
do
the
analysis
to
see
that
it
actually
spins
I
could
use
the
signals
to
say
that
this
flow
will
guaranteed
not
spin,
and
that
could
be
a
bit
useful,
but
that's
basically.
A
AE
U
I
B
A
C
Yeah
Christian
Rita
ma
I
will
probably
contribute
another
PR
on
the
actual
determination
of
when
to
opt
out,
because
I
think
that
if
you
take
in
mind
the
need
to
protect
people
that
are
accessing
a
specific
server,
it
drive
a
very
specific
pattern
of
up
to
the
art,
and
we
should
do
that.
Okay,
well.
A
M
A
You're
going
to
the
yes
okay,
so
if
you
go
to
the
working
group
homepage,
quick
working
group,
dot,
org,
oh
dear
I,
don't
think
I
pushed
that
commit.
Sorry
if
you
go
to
github,
if
you
can't
reach
the
table
and
I
will
correct
this
right
after
the
meeting
we
have
an
interim
schedule
and
it's
been
announced
in
the
mailing
list
for
January
in
Tokyo
and
I.
Believe
we
said
that
registration
would
end
on
18
December.
Please
don't
register
at
the
last
minute.
Please
register
a
bit
earlier.
It
would
be
very
helpful.
A
It's
at
Akamai
again,
you
might
remember.
We
had
our
first
interim
there,
so
you
know
it's
a
fantastic
room
in
a
good
location
and
we're
doing
a
dude
two
days
of
inter
up
and
then
two
days
of
working
group
meeting
and
hopefully
we'll
be
that
much
closer
to
getting
done.
So
thank
you.
I
come
I
for
hosting
and
please
register
soon.
B
B
B
You
know
enter
up
around
that
and
and
make
sure
we're
finding
all
the
boxes
and
all
the
anchor
in
accuracy
is
in
the
spec
that
will
probably
take
a
few
months.
So
I
think
the
current
plan
is
that
we
would
push
back
those
milestones
to
let's
say
july
2019,
which
means
that
we
have
made
the
january
interrupts.
B
We
have
prague,
ITF
104
and
then
we
have
Montreal
I
think
is
the
next
value
F
and
we
can
decide
whether
we
need
another
Interop,
slash
interim
I
guess
at
least
an
interrupt
might
be
useful,
but
it's
not
clear
whether
we
need
a
working
group
in
November.
Build
will
see
but
sort
of
wrapping
up
the
RFC's
based
on
implementation
and
ideally
deployment
experience,
but
that
time
I
think
is
what
we're
going
for.
B
B
B
One
thing
that
we
discussed
you
might
not
have
so
the
working
group
might
have
some
more
time
while
the
implementations
are
going
on
in
the
spring,
specifically
maybe
at
the
IDF's
for
us
to
have
a
little
bit
of
a
discussion
around.
What
do
we
want
to
do
next
for
quick,
so
this
leads
us
to
the
rich
are
during
part,
I.
Think
we've
heard
quite
a
bit
of
interest
in
to
things
that
are
not
currently
part
of
the
Charter.
B
One
is
multi
path,
the
other
one
is
partial
reliability
and-
and
there
might
be
other
topics
that
people
want
to
discuss
for
version
two,
so
I
think
we
were
probably
gonna
start
allowing
those
discussions.
We
have
pushed
back
pretty
quickly
and
you
guys
have
been
very
good
by
not
constantly
asking
for
them,
but
I
think
next
year
we
can
start
a
discussion
of
what
that
might
look
like
personal
comment.
I
know
every
least
like
four
different
designs
for
multi
path
and
I
know
of
several
for
partial.
AG
B
B
Is
the
intent?
It's
real,
we'll
see
whether
it's
it's
you
know
good
enough
frankly
to
to
do
that,
but
or
whether
we
need
an
18
but
I
think
the
intent
is
that
we
would
17
is
intended
to
be
the
the
last
version
where
we
make
sweeping
changes
that
are
you
know,
architectural
or
design
that
aren't
based
on
implementation,
issues
that
were
found
or
deployment
issues.
AG
But
note
that
he
used
the
word
intents
there.
So
of
course,
of
course,
I
I
understand
I
just
wanted
to
clarify,
especially
for
everyone
else,
in
the
room
that
other
people
who
have
implementations
you
know
this
is
certainly
what
I'm
driving
towards
and
I'd
like
to
see
other
people
moving
in
that
direction.
AA
A
A
I
think
the
current
plan
is
we're
going
to
look
at
those
in
Tokyo,
and,
if
you
know,
and
in
the
lead-up
to
Tokyo
and
in
come
decisions
about
those
knowing
that
that
we're
you
know
trying
to
lock
things
down
at
the
same
time,
if
it
doesn't
have
one
of
those
two
labels,
we
need
to
look
through
them
and
figure
out
what
the
disposition
is.
Okay,.
AA
A
N
B
A
F
I
just
want
to
go
out
answer
muttons
question
there,
which
was
pretty
much
what
what
Mark
said,
but
to
add
to
that
I've
gone
through
all
of
the
parked
and
v2
issues
a
number
of
times
recently,
and
it's
my
view
at
least
that
we,
we
can
have
a
pretty
short
sharp
discussion
about
a
lot
of
those
ones.
There's
a
couple
of
them
a
little
bit
for
me
and
we
should
probably
have
a
decent
amount
of
time
reserved
for
them
in
Tokyo.
F
N
U
There
it's
Ganassi
Google
some
about
something
else,
so
I
really
agree
with
the
goal
to
have
17
get
a
lot
of
deployment
experience
and
that
we,
a
lot
of
these
ideas
or
parts
for
later,
should
be
pushed
back.
Would
it
still
be
reasonable
to
test
the
extension
mechanism
before
we
ship
the
RFC?
So
one
way
we
can
do
that
is
with
the
Datagram
draft,
but
there
could
be
another
extension.
A
AA
I
Jahmai
and
what
I
just
also
want
to
note
that
the
that
that
is
I
expect
there
to
be
some
chin
in
the
riccati
Draft
and
that's
that's
that's
especially
because
we
just
started
to
get
some
tea
CPM
folks
to
engage
in
this
process.
But
this
is
completely
reasonable
and
fine.
I
think
because
implement
does
haven't
quite
gotten
to
that
point.
Yet
the
biggest
problem
has
been
the
transport
draft,
the
children,
the
transport
draft.
V
Up
on
Ian's
point
about
I'm
trying
to
deploy
17
one
thing
that
I
did
not
go
as
well
as
I
would
have
hoped
with
it
tell
us
when
three
roll
out
was
toward
like
towards
the
end
of
the
process.
We
ended
up
with
like
a
lot
of
different
small
drafts,
all
of
which
basically
were
effectively
the
same,
but,
like
you
know
it
was
a
pain
to
pain,
to
have
like
six
drafts
in
your
server
and
so
it'd,
be
like
we
get
on
slack
and
be
like
okay,
who's
ready
to
roll
out
like
26
come.
V
We
got
like
coordination
on
that,
so
I
think
that
I
kind
of
worked
but
kind
of
didn't
so
I
think
maybe
mu.
We
can
invent
some
structure
inside
it
where
we
a
little
more
aggressive
about
like
what
checkpointing
the
things
that
we're
gonna
know
we're
gonna
roll
out.
So
if
we
can
get
so
that
everybody
can
kind
of
be
on
the
same
version,
this
is
like
a
huge
pain
that
you
have
multiple
version.
Multiple
concurrent
versions
like
on
your
system,
so
an.
A
AE
Mike
Bishop
one
observation
for
that
is
that,
with
the
subsequent
small
drafts,
usually
there's
not
a
non
wire
change.
A
lot
of
those
changes
will
be
editorial
right,
and
so,
if
we
were
to
simply
Minton
instead
of
saying
you
put
your
draft
number
here,
we
put
an
explicit.
This
is
the
version
number
you
use
and
we'll
increment
that
when
we
have
a
breaking
change,
we
can
work
around
that.
V
B
V
B
A
F
J
H
A
There
was
this
document
I
want
to
spend
30
seconds
on
it.
We
had
a
quick
human
rights
review
done
from
some
folks
outside
the
working
group.
I
just
wanted
to
say
thank
you
for
that.
I
originally
put
this
on
the
agenda
to
see
if
people
had
feedback
for
those
folks
but
I
think
that's
taking
place
in
HR
PC
and
since
we're
time
constrained.
We
won't
do
that
here,
but
but
thanks
for
that
input-
and
if
you,
if
you
have
some
send
it
there,
yeah.
B
AC
Right,
hello,
everyone
I'm
just
going
to
give
a
quick
introduction
to
our
datagram
extension
proposal.
This
is
there
have
been
several
versions
of
this
proposed.
I
know
that
ian
had
paper
on
message
mode,
I,
think
these
are
really
the
same
thing.
They
came
out
of
the
same
conversations.
The
goal
is
to
converge
them
all,
so
I
just
want
to
introduce
people
to
this
concept
now
and
some
of
the
discussions
we've
been
having
next
slide
all
right.
So
why
do
we
want
unreliable,
quick
frames
or
partial,
reliable,
quick
frames?
AC
First,
there
are
different
application
use
cases
that
can
take
advantage
of
it.
We
can
go
into
those
details
later.
Quick
also
essentially
can,
through
this
provide
DTLS
equivalent
functionality.
So
anyone
who's
using
detail-
s
could
take
advantage
of
this,
and
the
other
benefit
that
David
mentioned
earlier
is
that
we
have
an
extension
mechanism
and
quick
and
it
seems
like
we
should
be
able
to
use
it.
We
should
try
it
out,
and
this
is
a
fairly
simple
low-risk
one
to
add
in
next
slide,
please.
AC
So
why
would
we
use
Datagram
over
quick
as
opposed
to
DTLS
or
something
else?
Some
of
the
advantages
that
we've
thought
about
so
far
are
that
you
can
share
a
single
crypto
handshake
with
all
of
your
other
streams,
so
you
essentially
get
this
multiplex
Datagram
channel
with
a
connection
you
already
have
you
get
to
inherit
any
of
the
features
of
our
quick
handshake,
which
maybe
have
more
nuances
than
what
DTLS
allows
you
to
do
around
retransmission
around
transport
parameters,
something
we
can't
add
those
to
DTLS.
AC
Of
course
we
could,
but,
as
we
evolved
quick,
you
get
any
of
those
benefits
that
we're
adding
to
quick
and
also
adds
the
ability
to
acknowledge
your
data
grams,
which
gives
some
insight
into
packet
loss
properties.
It's
not
perfect,
but
it's
potentially
interesting
next
slide.
So
some
of
the
example
use
cases-
and
there
can
definitely
a
lot
more
than
this
any
application
that
wants
both
a
reliable
stream
and
an
unreliable
stream
between
two
peers
for
audio
video
streaming
with
control
and
their
actual
data
frames
or
gaming.
AC
They
could
take
advantage
of
this
and
actually
not
have
to
worry
about
having
different
states
for
different
connections
being
blocked.
So
this
simplifies
things
a
lot.
It
also
allows
you
to
get
into
some
VPN
style,
tunneling
of
IP,
packets
or
other
datagrams
over
a
quick
connection.
You
want
unreliable
when
you're
tunneling
so
that
you
don't
incur
extra
layers
of
recovery,
and
this
also
allows
you
to
potentially
hide
the
fact
that
you're
doing
a
VPN,
so
there's
a
whole
bunch
of
things
that
this
opens
up
next
slide
please.
So
the
protocol
details
are
pretty
simple.
AC
These
are
totally
open
to
negotiate
and
change.
Maybe
a
Datagram
frame.
There
are
two
code
points.
One
is
for
one
that
extends
all
the
way
to
the
end
of
the
packet,
and
one
has
a
length
field.
If
you
want
to
have
other
frames
in
there.
The
only
other
change
in
the
actual
protocol
is
that
you
add
and
accepts
Datagram
transport
parameter
to
indicate
that
you
support
this
feature
slide.
AC
So
there
are
a
couple
design
decisions
that
we've
discussed.
One
is
do
we
act
these
Datagram
frames.
This
is
something
new
that
things
like
UDP
and
DTLS.
Don't
do
currently
the
draft
says
yes,
this
is
an
interesting
way
to
gauge
loss
on
the
network,
with
the
caveat
that,
of
course,
this
doesn't
guarantee
that
the
peer
occupation
actually
is
processing
this
Datagram.
The
next
one
is
so.
AC
V
V
H
AC
There's
one
last
slide:
I
can
just
detect
it.
This
is
the
one
other
design
decision
that
we
had
to
make
was.
Do
we
have
multiple
streams
of
datagrams?
Currently
we
have
an
O
there.
If
you
want
to
be
able
to
do
multiplex
different
data
grams.
Add
your
own
identifier
in
the
way
that
HTTP
kind
of
puts
a
prefix
on
things.
The
reason
for
this
is
that,
because
you're
not
doing
flow
control
on
a
per
stream
basis,
that
doesn't
really
make
any
sense,
there's
no
actual
transport
added
value
to
be
able
to
differentiate
these
things.
AC
A
You
Tommy
so
folks
give
you
your
feedback
to
tie
me.
This
isn't
the
working
group
item
I,
don't
think
we're
considering
it
for
adoption
yet,
but,
as
we
discussed
earlier,
that's
something
that
is
on
the
horizon,
perhaps
of
something
we're
gonna
talk
about
as
an
interim
thing,
thanks
for
your
time,
thanks
Rahming.