►
From YouTube: QUIC Working Group
Description
The QUIC Working Group is working on a standards-track specification for a UDP-based, stream-multiplexing, encrypted transport protocol, based on pre-standardization implementation and deployment experience.
B
A
D
C
E
F
G
G
B
I
K
M
M
L
M
L
L
N
O
B
There's
a
wiki
page
in
the
base
drafts
repository
that
has
the
details
of
the
proposed
PR.
It's
not
a
PR
at
a
moment,
so
I
guess
the
ask
is
that
people
review
that
I
think
in
terms
of
the
design
team
that
we
had
to
look
at
GNN
quick.
This
is
sort
of
their
proposal
for
what
what
what
they
believe
was
is
the
best
way
for
it
and
and
now
we're
basically
trying
to
figure
out
whether
this
is
this
proposal.
Has
you
know
enough
consensus
that
we
can
continue
it
in
a
PR,
make
sense
Mia,
okay,.
B
B
A
B
P
B
B
P
L
Q
Thomsonite
I'd
suggest
timing-wise,
it's
been
a
little
bit
more
time
polishing.
This
I
noticed
a
few
grammatical
things
in
here
and
a
few
questions.
It's
a
little
bit
easier
to
iterate
on
the
wiki
than
it
is
to.
You
know,
write
on
a
pull
request
and
for
something
this
large
pull
requests
tend
to
take
a
little
bit
of
time
and
it'll
rot.
Q
B
R
Jenna
I
want
a
second
Martin's
opinion.
I
think
this
is.
This
is
useful
good
to
have,
and
we
should.
We
should
make
sure
the
text
that
we
have
on
the
wiki
is
solid
and
we
will
get
it
in
there's
just
no
urgency
because
I
don't
think
any
of
the
implementers
are
going
to
rush
to
test
this.
Yet
so
we
can
get
to
it
and
we
should
get
to
it
and
we
will
get
to
it.
But
it's
okay
for
us
to
wait
until
at
least
twelve.
B
A
A
S
B
A
And
one
more
bit
of
context:
we've
been
talking
about
this
for
a
while.
Our
intent
as
chairs
is
really
to
try
and
get
a
direction
on
this
and
get
us
something
we
can
confirm
on
the
list
today.
We're
getting
the
point
where
we
can't
install
this
decision
much
longer.
So
please
keep
that
in
mind
in
the
discussion
we're
trying
to
get
to
closing
this
issue
in
some
fashion
and
the.
B
Reason
so
we
specifically
didn't
schedule
this
discussion
at
the
dinner
room,
because
we
wanted
to
have
sort
of
the
broader
participation
that
we
get
in
the
general
ITF.
But
that
is
the
reason
why
we
didn't
do
it
another
one,
for
example.
But
this
is
so
we've
we've
kicked
this
around
long
enough
and
we
really
need
to
decide
what
we
want
to
do
on
this
topic
so
that
we
can
sort
of
move
on
and
free
up
quadricycles
for
a
bunch
of
people.
B
S
T
S
G
S
S
Thank
you
very
much.
The
client
sip
sets
you
know
the
inverse
of
the
last
spin,
it's
all
on
each
packet
that
it
sends.
So
what
this
does
is
a
very
simple
distributed
algorithm.
It
creates
a
square
wave.
That's
on
this
one
bit,
that's
visible
on
the
packets
in
the
flow
with
a
period
equal
to
the
application
experienced
round-trip
time.
S
Why
do
we
do
this?
So
we're
preparing
for
a
post,
TCP
world
we've
seen
in
mapper
G
anywhere
between
five
and
seven
percent
of
quick
I've
heard
on
some
links
that
the
amount
of
quic
is
much
larger
than
7%
of
the
traffic?
That's
crossing
that
link.
There
is
the
ability,
based
on
the
information
radiated
off
of
TCP,
to
do
lightweight,
efficient
RTT
estimation
on
arbitrary
aggregates
of
traffic.
As
quick
traffic
replaces
TCP
traffic.
This
visibility
goes
away.
We
got
a
lot
of
use.
S
Cases
enumerated
in
the
spin
bit
draft
draft
normal,
quick,
spin,
zero
one
basic
internet
or
domain
troubleshooting
home
network
troubleshooting
buffer
bloat
mitigation
for
mobile
networks,
which
I
actually
want
to
note
that
in
the
the
hackathon
this
week
we
actually
built
a
real
buffer
bloat
mitigation
simulation
emulation.
That
shows
that
this
actually
reduces
our
TT
for
all
of
the
flows
over
some
of
these
links
significantly
and
internet
measurement
research.
How
does
it
work
I'll?
Do
the
slides
versus
the
interpretive
dance
I
can
do
the
interpretive
dance
later?
S
If
it's
not
clear,
the
client
starts
sending
once
it
starts
ending
of
short
packets
with
short
headers
it
puts,
pin
0
the
server.
Basically
just
reflects,
pin
0.
As
soon
as
the
client
starts
seeing
spin
0
packets,
it
sets,
pin
1
the
server
reflects
backspin
1.
The
client
sees
that
spin
0.
So
basically,
you
see
all
of
the
packets
in
flight.
In
the
flow
kind
of
pulse
between
spin
1
and
spin
0,
and
the
period
of
that
is
the
RTT
so
how
this
works
if
you're
doing
unidirectional
one
point
measurement.
S
S
With
bi-directional
one
point
measurement,
you
can
actually
compare
the
square
waves
on
the
upstream
and
the
downstream
side
and
you
can
separate
the
components
of
RTT.
So
you
can
know
how
much
of
the
RTT
is
attributable
to
between
the
observation
point
in
the
client.
In
the
observation
point
in
the
server.
Does
it
work?
Yes,
it
does.
Our
student
Pete
Davari
has
implemented
this
and
minke
we've
actually
had
three
other
implementations
of
this
at
the
hackathon.
The
implementation
effort
is
trivial.
S
Basically,
so
pizza
pretty
smart
guy
but
he'd
never
seen
go
and
he'd
never
seen
mink
and
within
the
first
45
minutes
he
had
a
working
spin
bit.
It
took
him
another
couple
of
weeks
to
get
mink
running,
but
that
the
spin
bit
was
actually
spinning
the
spin
signal
you
get
really
high
resolution
information
about
the
RTT
experience
by
the
end
point
applications.
One
of
the
things
that
surprised
us
is
due
to
act,
timing
and
quick.
S
P
A
S
Standard
tip:
oh
yeah,
yeah,
okay,
so
basically
the
the
spiky
orange
stuff
here
is
so
what
we
have
is
a
client
connecting
to
a
server
and
uploading
data
right.
So
it's
it's
the
reverse
of
the
way
that
this
usually
works,
but
you
can
just
switch
the
things.
This
is
the
art.
This
is
the
spin
bit
information
available
at
the
sender
side
and
the
moving
minimum.
So
this
green
line
underneath
here
is
just
a
just
a
minimum
filter
rate.
This
is
it's
like
the
the
linear,
smoothing
filter
that
TCP
uses
for.
U
S
So,
like
the
the
the
unsmooth
TCP
or
TT
is
spiky
like
this
as
well
down
here.
This
is
the
server,
so
the
data
receiver
side,
extreme
information
about
its
RT
T's
and
the
green
here
is
the
moving
minimum.
So
you
see
the
resolution
is
low
Z,
and
so
you
don't
have
a
engine.
You
don't
have
a
picture
that
shows
the
true
number,
the
true
number.
Okay,
the
true
network
number
in
this
case
is
40,
and
then
it
goes
up
to
80.
Okay,.
P
S
M
P
S
So
in
the
world,
with
the
sort
of
the
the
current
10
version,
the
draft
the
packet
numbers
are
still
in
the
clear,
so
it's
very
easy
to
use
packet
number
information
to
reject
reordered
edges
and
to
detect
loss
and
to
reject
edges
where
there's
loss.
So
if
you
have
packet
numbers
that
increment
by
one
per
packet
and
are
in
clear-text,
then
this
signal
is
very
robust.
If
we
encrypt
the
packet
number,
we
can
talk
about
that
in
the
backup,
so
yeah.
S
In
conclusion,
we've
spent
about
a
year
talking
about
this
we've
spent
a
few
months
implementing
it
and
getting
of
experience
with
it
in
real
networks,
as
well
as
an
emulated
Network.
So
Pete
has
a
stack
of
paper
about
this
big
filled
with
plots
with
various
sort
of
loss
and
reordering
models.
It
turns
out
that
this
actually
gives
you
pretty
good
RTT
information.
S
All
the
way
down
to
the
point
where
you
drive
the
transport
protocol
into
the
ground,
we
actually
had
to
disable
flow
control
and
congestion
control
in
order
to
keep
it
to
get
get
it
to
keep
sending
packets.
In
order
to
to
look
at
some
of
the
points
in
this,
this
network
impairment
space,
it's
minimal
overhead.
We
have
one
bit
if
we're
gripping
the
packet
number,
we
can
talk
about
other
options.
S
It's
very
high
fidelity,
it's
an
explicit
signaling
approach
that
replaces
an
implicit
signaling
approach.
It
has
minimal
privacy
impact,
as
we
saw
from
the
the
RT
T
DT
in,
was
that
Prague
or
Singapore
yeah.
So
from
a
while
ago.
It
does
what
it
says
on
the
10.
It
replaces
on
path
visibility
into
the
RTT
in
a
world
where
removing
from
TCP
too
quick
I.
S
S
U
W
S
S
So
if
you're,
so
are
you
talking
about
20%,
random
loss
or
20%
burst
loss?
That's
usually
a
packet
policer
and
okay
yeah.
So
when
you
see
burst
loss,
it
goes
from
sort
of
the
gray
line
here
to
the
blue
line.
Here
you
you
get
essentially
overestimation
of
the
RTT,
because
you're
just
missing
the
edge
right,
so
yeah
the
edges,
the
edge
that
you
see
is
delayed.
S
There
are
so
the
edge
bit
and
status
bit
things
here.
Actually
you
know,
I
should
probably
explain
those.
So
these
are
things
that
we
started
looking
at.
In
order
to
prepare
this
to
be
useful
in
an
encrypted
packet
number
world,
the
status
bits
actually
reject
all
of
the
edges
that
are
lost.
You
can
also
do
this
with
packet
numbers,
and
then
you
get
basically
up
to
the
redline.
S
The
reason
that
the
redline
looks
better
than
the
vanilla
without
loss
line
here
is
it's
actually
rejecting
some
of
the
edges
that
are
further
invariance
right
like
so
that
when
you
start
rejecting
lost
edges,
you
get
fewer
samples,
which
means
your
variance
goes
down.
So
you
get
less.
You
get
less
this
error.
Okay,
so
far,
fine.
W
S
Yeah,
so
if,
if
you
have
a
good,
if
your,
if
your
network
is
running
well,
you
don't
need
to
look
at
the
packet
number.
You
can
basically
just
look
at
the
the
raw
series
of
edges
and
you're
going
to
have.
You
know
few
enough
of
those
are
going
to
be
offset
or
lost
that
it's
not
going
to
affect
the
aggregate
that
much.
S
S
Looks
like
this,
so
basically,
what
happens?
Is
you
entry
with
very
lower
TT?
We
did
pretty
much
everything
with
forty
milliseconds
that
was
sort
of
the
baseline
with
lower
RTT.
You
actually
get
less
absolute
error
because
the
only
like,
if
you
do
like
a
single
edge
reorder,
you
just
get.
You
know
the
you
get
a
you
know
a
spike
up,
one
back
to
zero
and
then
back
to
one
you
get
the
an
RTT
measurement
which
is
pretty
close
to
zero.
It's
the
inner
pocket
time
rate
with
40,
millisecond
or
TT.
S
S
S
The
V
ideas,
the
long
header
packets,
are
one
you
have
like
you
have
the
handshake.
You
can
just
basically
to
your
handshake,
RTT
estimate,
the
normal
way
to
you,
don't
have
any
of
those
of
those
packets.
Three.
What
we
really
you
know
that
the
point
of
this
is
to
create
samples
of
the
RTT
either
that
you
can
use
for
a
running
time.
Series
analysis
of
a
single
flow
if
you're
doing
Diagnostics
or
if
you're,
just
base
lining
or
measuring
you're
gonna.
S
Z
Brian
when,
when
I
look
at
your
numbers
here,
I
have
some
kind
of
fear
and,
and
the
fear
is
that
this
spinning
bit
measurement
would
work
very
well.
If
the
network
is
working
well
and
will
start
to
work
less
well,
if
the
network
is
having
problems
and
I
am
concerned,
that
this
kind
of
behavior
goes
against
the
idea
of
having
a
measurement
tool.
That
tells
you
some
information
when
you
have
a
trouble
so
with
the
so
thank.
S
You
for
leading
into
one
of
my
one
of
my
backup
slides,
so
this
is
an
enhancement
that
we
looked
at
called
the
edge
valid
signal.
So
what
happens
here
is
that
each
so
okay,
first
of
all,
I'll
say
if
the
packet
numbers
are
in
the
clear.
The
entire
path
has
enough
information
to
detect
upstream
loss
and
reordering
of
an
edge.
So
it
has
enough
information
to
determine
completely
whether
an
edge
is
good
or
not.
S
When
you
have
heavy
loss
and
heavy
reordering,
you
tend
to
get
many
fewer
samples,
but
for
any
flow
that
is
able
to
keep
set.
If
the
network
conditions
are
such
that
the
flow
is
able
to
keep
sending,
we've
never
seen
a
situation
that
it
that
we
have
to
drop
all
of
the
samples
right.
We
still
have
visibility
into.
S
There's
a
counter
that
goes,
it
counts
up
zero
one,
two
three,
every
time
an
endpoint
sends
a
good
edge,
so
if
an
edge
gets
reordered
or
lost
the,
what
the
the
measurement
point
will
see
is
what
looks
like
an
edge
because
it
went
from
zero
to
one,
but
the
endpoint
didn't
think
it
was
a
good
edge,
so
the
valid
edge
counter
is
at
zero,
so
it
will
say:
okay,
this
is
not
a
valid
edge.
You
can
easily
reject.
S
The
diagnostic
is,
the
network
is
so
screwed
up
that
the
transport
stops
sending
rate
so
I.
We
shared
your
fear
when
we
look
at
this
originally,
but
we
have
a
fair
amount
of
data
that
at
least
I'm
less
afraid,
Pete's
thesis
on
this
should
be
published
in
about
two
weeks
and
we
can
send
that
to
the
list.
So
my.
Z
Simple
brain
as
a
simple
understanding.
What
you
said
and
I'm
gonna
summarize
summarize,
is
that
if
we
have
a
combination
of
the
spin
bit
and
clear
text
packet
number,
we
are
fine.
If
the
packet
Nagas
are
encrypted,
we
need
a
couple
more
bits
with
the
spin
bit
mm-hmm.
Yes,
what
tune
is
one
not
wrong?
Okay,.
S
S
S
Clarified
right
now:
okay,
there's
another
enhancement
where,
basically,
you
have
a
two
bit
spin
that
counts
up
one
two
three
and
any
time
an
end.
So
the
end
points
of
course
know
that
an
edge
is
valid
or
not
because
they
have
access
to
the
clear
tox
packet
number.
So
they
know
whether
or
not
an
edge
that
they're
seeing
is
is
valid
or
not.
You
can
use
this
that
spins
one
two
three
and
then
an
additional
code
point
zero,
that
it
sends
for
an
entire
half
RTT
to
say
the
last
edge
that
I
sent
was
bad.
S
AB
S
That's
our
scope
for
this
discuss
out
of
scope
for
this
discussion
me
I
may
I
may
I.
May
it
push
an
idea,
though
loudly
V,
the
edge
valid
SiC.
We
have.
We
haven't
done
the
work
yet,
but
we
have
an
intuition
that
the
edge
the
series
of
valid
and
invalid
edges
will
give
you
some
basic
information
about
loss
or
reordering.
S
It
won't
give
you
information
about
which
it
is,
but
it
will,
if
you
see,
sort
of
the
the
valid
invalid
edge
series,
you
can
derive
some
information
about
loss
and
reordering
from
that
we
haven't
done
the
work.
Yet
that's
that's
future
work,
but
it
won't
give
you
information
about
very
low
loss
rates
like
if
your
loss,
if
your
edge
loss
probability,
is
below
a
threshold.
S
S
S
AC
S
S
N
AD
And
does
that
first,
keep
in
the
multi
path
case.
Does
that
bursty
traffic
case
become
more
important
because
it
seems
like
if
you're,
switching
back
and
forth,
between
which
path
you're
sending
things
on
then
you
may
want
to
be
careful
not
to
be
having
people
observe
stuff
on,
because
it'll
each
of
those
paths
may
look
like
it's
bursty
for
some
period
can.
S
S
AE
Y
S
A
All
right
so
now
we're
gonna
go
into
the
discussion,
face
the
non
clarifying
face
so
just
to
give
people
a
little
context.
As
Brian
said,
we've
been
talking
about
this
for
a
long
time.
It's
been
somewhat
contentious
in
the
working
group
for
a
fair
amount
of
time,
good
positioning
Brian,
we
spooled
up
a
design
team
to
evaluate
especially
the
privacy
implications
of
the
spin
bit
a
one
bit
spin
bit
and
the
result
of
that
was
they
came
back
and
they
said
they
couldn't
identify
any
concrete
privacy
issues
with
the
one
bit
spin
bit.
A
We
had
some
concerns
about
whether
the
data
generated
by
the
spin
bit
was
usable,
Brian's
just
gone
through
the
experimentation
and
the
research
they've
done
around
that,
and
so
now
we're
in
a
position
where
the
working
group
needs
to
decide.
Do
we
want
to
add
this
pin
bit
to
the
specification
in
some
form,
and
so
that's
the
scope
of
the
discussion.
Now
we're
not
going
to
talk
about
loss,
for
example,
or
other
aspects
of
things
that
networks
might
need
to
to
understand
about
the
flows.
AF
B
AF
The
amount
that
this
seems
to
me
to
leak
compared
to
say
the
the
information
already
available
on
geolocation
is
just
extraordinarily
small,
in
my
opinion,
for
for
the
threats
that
we
considered-
and
this
does
seem
to
provide
a
very,
very
useful
set
of
signals,
in
particular
I'm-
very
pleased
with
two
design
points
here,
one
that
this
is
in
the
control
of
the
sender.
This
is
designed
so
that
the
sender
does
all
of
the
the
setting
and
all
the
server
does
is
reflect.
AF
The
advantage
of
that
is
that
the
sender
remains
in
control
of
whether
or
not
this
is
on,
and
although
the
the
receiver
can
decide
not
to
reflect,
it
is
set
everything
to
0
as
well.
There's
a
good
bit
of
of
agency
and
the
right
place.
In
my
opinion.
The
other
thing
that
I
think
is
a
very
good
piece
of
the
design
here
is
that
there
are
ways
as
we
move
forward
into
multipath
or
into
other
other
mechanisms,
to
continue
to
use
this
on
a
per
path
basis.
AF
A
Before
you
go
because
I
know,
that's
high
cost
operation,
you
said
this,
a
lot
are
you
referring
to
and
everyone
in
the
in
the
queue
I'd
like
to
focus
a
little
bit
on?
Are
we
talking
about
the
single
bit
if
we
assume
we're
going
to
encrypt
the
packet
number?
How
do
you
feel
about
the
two
or
three
bit
solution.
AF
Ted
Hardy
again
so
I
was
actually
evaluating
in
terms
of
the
way
draft.
Ten
currently
has
it,
which
has
an
unencrypted
packet
number,
having
looked
not
nearly
as
completely
at
the
the
Veck
I
believe
you're,
calling
it
I
believe
it
is
quite
similar.
My
intuition
is
that
by
encrypting,
the
packet
number
and
going
to
the
Veck
we're
actually
making
an
overall
privacy
enhancement,
but,
as
I
said,
that's
an
intuition.
I
actually
haven't
done
enough
of
the
research
to
make
that
as
confidently
as
I
believe
he
has
been
able
to
make
the
assertions
he's
made
today.
B
AG
AG
My
main
so
I
appreciate
that
this
has
been
whittled
down
to
a
relatively
small
number
of
bits.
I
would
prefer
to
keep
it
as
small
as
possible.
Zero
would
be
great
if
we're
forced
into
having
one.
You
know
I
I,
do
appreciate
the
engineering
work
that's
gone
in
here.
I
want
to
point
out
that
it's
not
clear
to
me.
The
discussion
earlier
was
about
bursty
traffic,
as
opposed
to
like
a
steady
flow.
There
may
be
other
traffic
patterns
where
this
doesn't
work
as
opposed
to
flow.
AG
If
we
want
to
use
quick
in
the
future
for
non
reliable
streams,
if
the
network
operators
are
doing
bad
things
to
traffic
that
doesn't
match
what
they
think
is
the
RTT
estimate,
so
I
want
us
to
keep
those
ideas
in
mind.
If
you
think
quic
is
going
to
be
interests
for
non
reliable
streams
as
well
think
about
what
we
might
be
doing
to
ossify
the
network
stack
if
we
include
something
like
this.
R
R
I've
basically
spent
the
last
year
listening
to
arguments
and
I've
heard
them
from
all
over
the
place,
and
it's
yes,
it
has
taken
the
better
part
of
a
year.
I've
spoken
with
many
people,
including
operators,
vendors,
important
implementers
about
the
incentives,
benefits
and
deployment
stories
for
this
bit
and
I've
considered
all
of
these
carefully
from
where
I'm
seeing
it.
Now
we
need
to
make
a
decision
now
and
I.
Think
of
this
as
an
engineering
decision,
not
a
theoretical
one
or
not
a
research
one.
R
My
informed
opinion,
based
on
all
the
conversations
I've
had
and
all
the
thinking
of
done,
is
that
we
should
not
include
this
bit
in
the
core
specifications
for
v1
I'd
be
very
happy
for
it
to
be
an
experiment
that
demonstrates
that
there's
value
and
there's
interest
in
deployment
I
think
it
would
be
very
value
to
have
an
internet
wide
experiment
that
actually
shows
some
of
these
things
and
I.
Think
this
mechanism
is
a
great
starting
point.
R
I
think
there's
some
interesting
data
here,
but
there
are
also
a
lot
of
open
issues,
as
we
can
see
and
as
the
design
of
quick
evolves.
That
will
challenge
the
assumptions
that
are
being
made
in
this
mechanism
here
and
all
of
that
points
towards
an
excellent
starting
point
for
experimentation.
But
I
don't
think
this
needs
to
be
in
the
Co
specifications
now
and
I.
Don't
think
it
should
be.
AH
Kevin
Smith
Vodafone,
so
first
point
he
saw
Hilton
earlier
in
the
week
about
quick
being
measured
at
about
9:10
percent
on
cellular
networks.
Certainly,
we've
measured
it
much
much
higher,
probably
40,
to
50
percent
in
many
of
our
operations,
and
so
a
privacy
aware
or
privacy
compliant
spin
bit,
which
helps
us
track
and
monitor
and
measure.
That
is
very
welcome
to
the
extra
bits
one
driver
Darla's
to
put
forward
his
5g
radio.
So
we
want
to
as
that
evolves,
we
want
to
get
a
feel
for
how
that's
performing
new
new
wave
lengths,
etc.
B
AH
N
AI
We
implemented
on
pre
deployed
the
spin
bit
over
our
network
and
it
provides
us
with
enough
information
to
be
able
to
make
troubleshooting
with
Dakota
me
so
know,
which
side
is
the
wrong
side
on
which
side
it
provides
right
today.
So
now
we
don't
make
any
investigation
with
an
additional
bit.
So
I
don't
have
a
new
opinion
so.
B
Y
Can't
Perkins,
so
I
I
think
it's
fairly
clear
that
there
is
no
meaningful
information
leaked
from
having
this
bit.
So
from
that
point
of
view,
I
think
this
is
worth
including
I
think
if
anything
with
there's
too
little
information
here
and
I
think
we're
gonna
I
worry
that
we're
going
to
find
it
works
in
the
cases
where
the
network
is
behaving
and
we
don't
have
sufficient
information
to
use
it
for
debugging
the
difficult
cases
where
the
network
is
starting
to
misbehave,
so
I
lean
towards
thinking
this
is
worth
doing.
I
am
unconvinced.
Y
It
will
turn
out
to
be
as
useful
as
we
think
it,
but
I
think
it's
worth
doing
as
an
experiment.
I
think
we
should
perhaps
consider
arranging
the
bits
so
that
if
the
experiment
turns
out
to
be
useful,
it
can
become
part
of
the
invariance,
because
if
this
is
something
people
are
building
measurements
infrastructure
around
in
the
future,
then
we
want
to
guarantee
that
where
it's
going
to
be
but
I'm
not
sure
we're
at
that
stage.
Yet
so
it's
not
fair
to
me
that
it
will
become
useful.
AJ
Pravin
Microsoft,
so
we
have
a
general
use
case
today
in
the
cloud
where
we
want
to
measure
what's
happening
with
tenant
traffic
and
that
we're
doing
that
with
TCP
today
and
having
such
a
bit
would
be
extremely
useful
to
be
able
to
continue
to
do
that
with
quick.
If
we
are
looking
at
quick
as
a
replacement
for
TCP
I,
genuinely
think
that
this
will
be
useful
for
us.
AJ
The
other
good
part
about
this
proposal
is
that
it's
not
compute-intensive
so
setting
this
bit
is
not
a
big
problem
for
an
implementation
also
looks
like
the
implementation
effort
is
pretty
small,
but
as
to
the
you
know,
discussion
of
experimentation
versus
not
yeah
I
mean
we
could
make.
We
could
consider
not
making
this
part
of
the
invariants
if
we
want
to,
but
putting
this
in
version.
One
would
at
least
unblock
the
experiment
and
allow
us
to
find
out
if
this
works
well
in
practice.
AK
AL
Patrick
McManus
lines
moving
pretty
well,
that's
good,
so
I
will
take
your
chute
on
the
other
side
that
this
does
not
leak.
Any
interesting
data
I
think
what
it
leaks
is
obviously
RTT
and
when
I
mentioned
that
to
people
they
say
you
can
get
that
out
of
the
client
handshake
and
like
if
you
can
get
that
out
of
the
client
handshake.
AL
AL
It
was
not
trying
to
signal
to
the
network,
those
are
designed
to
be
end
and
signals
and
I
think
making
them
Indian
signals
actually
preserves
our
ability
to
innovate
in
all
ways
around
that,
so
I
I
opposed
to
any
number
of
bits
on
those
basis,
and
you
know
finally,
with
respect
to
you
know
my
product,
it's
fairly
unlikely
that
we
would
participate
in
this.
This
echo
system.
AM
I
think
we
have
compelling
evidence
that
this
works,
at
least
in
some
scenarios.
I
think
for
this
to
be
a
really
useful.
We
need
first
implementation
to
support.
Then
we
have
bat-signal
from
Mozilla
and
secondly,
we
probably
need
to
make
this
part
of
the
invariance.
Otherwise
we
can't
rely
on
this
to
do
the
measurement.
There
was
a
comment
about
the
fidelity
of
the
signal
in
loss,
hearing
order
with
the
environment,
with
high
loss
in
high
order,
but,
for
example,
the
mobile
network.
S
Hi
I'm
Brian
Trammell
well
well,
stating
my
my
general
deep,
deep
skepticism
about
anything
about
the
success
of
traffic
analysis
resistance
in
the
internet.
There
were
three
issues
raised:
I,
actually,
I
didn't
put
names
down
so
I'm
assuming
Jonah
was
one
of
them.
Sorry
I'm
pickin
on
you
cuz
he
right
there.
S
So
there
were
issues
raised
about
the
spin
bit
on
partially
reliable
or
non
reliable
streams
where
there's
no
AK
stream
back
AK,
elimination,
I,
don't
want
to
say
a
compression
or
a
coalescing
right,
because
you
know
so
basically
where
the
acknowledgement
scheduler
is
using
a
different
algorithm
than
the
one
that
TCP
is
working
right
now.
These
are
valid
concerns
but
I,
don't
think
they're
a
problem
because
as
long
as
so
your
sampling
rate
goes
down
right,
that's
the
range,
but
the
sampling
rate
will
never
go
to
zero.
S
As
long
as
you
have
some
sort
of
acknowledgment
driven
congestion
control
and
if
you
don't
have
acknowledgement
driven
congestion
control,
then
you
don't
really
have
much
of
a
network
left
to
measure
so
to
Patrick's
point.
So
it
basically
as
long
as
you
have
as
long
as
you
have
a
situation
where
you
will,
during
the
lifetime
of
a
given
flow
identified
by
5-tuple.
So
these
would
be.
These
are
not
connections.
These
would
be
subclones
in
a
multipath
environment.
We
don't
have
to
link
this
up
close
to
multipath
environment.
S
All
you
need
is
occasionally
a
low
delay
between
one
incoming
packet
and
the
other
packet
where
an
edge
transition
would
occur
in
any
flow.
That
would
contribute
to
measurement
you're
going
to
have
enough
of
these
to
generate
samples
right.
So,
if
you're,
if
you're,
trying
to
use
this
on
a
non
TCP
acknowledging
flow
to
do
per
flow
Diagnostics.
Yes,
in
certain
cases,
you
might
get
the
time
series
will
have
too
many
gaps
in
it.
S
Looking
at
how
that
moves
together
in
order
to
diagnose
the
link,
you're
still
going
to
have
enough
samples
in
order
to
be
to
generate
some
signal
out
of
that,
so
the
in
that
future
world
the
applicability
may
reduce,
but
for
you
know
the
cases
that
we
are
we're
looking
at
for
sort
of
like
network
health,
yeah
I,
don't
see
your
realistic
evolution
of
quick
for
which
that
would
go
away
with
respect
to
leaking
RT
t.
Yes,
of
course,
that's
what
it's
supposed
to
do.
S
S
As
far
as
the
information
that's
leaked,
between
streams,
I
I
want
to
dig
into
that
a
little
bit
more
I.
Don't
see
it
as
a
problem
in
that,
if
you're
doing
multiple
streams
together,
you're,
basically
sort
of
obscuring
the
size
and
timing
relationships
of
those
streams,
but
you're
still
going
to
get
this
pattern
where
you're
going
to
send
a
packet,
that's
going
to
be
an
edge
and
then
you're
going
to
get
some
sort
of
acknowledgment
or
thing
back
that
that
pattern
I,
don't
see
how
that
would
expose
it.
I.
S
A
Before
you
Riku,
because
we
know
that's
what
you're
gonna,
do
it
just
one
clarifying
question
in
your
proposal?
Yes,
this
is
always
opt
in
the
endpoints.
Both
have
to
opt
in
it
is
so
I
just
want
to
make
sure
that
people
realize
that
even
if
we
put
this
in
the
invariance
is
not
a
guarantee
that
is
going
to
actually
happen
as
a
wire
yeah.
S
And
I
would
actually
so
there's
been
some
other
discussion
about
the
relationship
between
this
and
greasing
and
for
for
the
the
common
case,
where
you're,
basically
just
trying
to
do
generate
some
RTT
samples
so
that
you
can
look
at
aggregate
s--,
individual
flows
can
probabilistically
opt
in
or
opt
out
of
this.
You
don't
need
to
negotiate
it.
Basically,
if
you
have
a
probabilistic
opt
in
on
either
side,
then
you
multiply
those
two
together
and
that's
the
probability
that
you're
going
to
get
a
signal.
S
Once
you
have
the
vac,
you
can
also
probabilistically
drop
samples.
You
can
basically
say
here's
an
edge.
I
have
a
valid
violet
edge.
I'm
I
only
want
to
to
expose
my
RTT.
You
have
a
target,
RTT
exposure
rate
and
you
can
drop
the
validate
valid
edge
counter
in
order
to
meet
that
target
rate.
So
there's
a
lot
of
things
that
we
can
do,
there's
very
fine,
grained
endpoint
control
for
how
much
information
gets
exposed.
Okay
and
I
think
that
it
for
a
greasing
standpoint.
S
A
AN
Multi-
Microsoft
yeah
I,
wanted
to
emphasize
the
nature
of
updating
and
Brian
already
did
a
much
better
job
done
on
that.
I
would
like
to
add,
though,
that
we
would
definitely
opt
in
to
that
I
like
the
probabilistic
nature.
Just
just
so,
everyone
knows
when
you
say
we
well
in
Microsoft
we're
okay
with
our
browser
in.
A
AN
Of
your
implementation
yeah,
so
whether
we
would
always
do
it
or
not
that's
different,
but
we
would
definitely
take
part
in
this
and
you
think
it's
important.
We
see
it's
useful.
The
one
very
important
reason
why
I'm
saying
pretty
confidently
yeah
for
this
we
would
have
support
the
interest
is
all
the
very
extensive
privacy
analysis
it
has
been
done.
I
would
like
to
see
similar
analysis
going
on
for
the
back
before
saying
anything
about
that,
but
for
this
one
you
know
feel
pretty
confident.
It's.
AO
So
this
is
useful
and
but
I
also
think
we
should
discuss
a
bit
more
about
these
unreliable
more.
But
having
seen
like
what's
happening
around
the
idea
of
like
quick,
is
kind
of
becoming
the
general-purpose
transport.
You
would
like
to
do
some
media
over
quick,
maybe
unreliable
may
be
partially
verbal
will
work
and
I
have
my
colleagues
who
believes
like
a
similar
kind
of
condition
control
could
work
for
more,
more
reliable
and
partially
over
kind
of
transport.
AO
I,
don't
see
that's
the
big
issue,
but
I
do
concern
that
if
it
is
not
invariant,
if
it
is
not
in
Russian
one,
then
we
might
not
get
the
test
we
want
to
do
and,
as
is
often
I,
don't
see
this
big
issue.
So
if
it
is
a
Russian
one,
we
do
testing,
we
see
how
it's
working
and
we
decide
what
to
do.
If,
if
it
is
there
and
if
it's
opt-in,
if
just
not
feasible,
if
leaking
more
information,
clients
can
always
say
no
tree
so
I
think
it's
fine.
W
So
I
wanted
to
reiterate
the
point
about
how
sending
fewer
acknowledgments
might
actually
increase
the
RTT
signal
and
introduce
about
a
25%
noise.
Currently,
we
are
a
lot
of
our
clients
at
ng,
quick
with
a
only
sending
acknowledgments
four
times
per
our
TT.
If
there's
no
other
data
is
sent
so
just
like
to
be
aware,
there's
this
fair
bit
of
noise
from
a
technical
perspective.
W
If
we,
if
we
do
this
I
personally,
want
this
to
be
good
enough,
that
we
actually
think
it's
it's
a
useful
signal.
So
if
we
do
this
either
we
need
to
not
do
packet,
number,
encryption
or
I.
Think
we
probably
need
like
two
bits,
because
the
last
thing
I
want
to
do.
This
is
add
one
bit
and
have
it
be
like
really
noisy
and
like
in
the
cases
when
the
network
really
degrades
it's
complete
junk.
W
So
I
don't
want
to
add
this
and
have
it
be
a
detriment
actively
detrimental
in
obvious
ways
that
we're
aware
of
so
spoken
with
a
lot
of
implementers
and
a
fair
number
of
operators
and
people
seem
to
have
very
mixed
opinions
in
both
camps.
So
I've
spoken
with,
obviously
Microsoft
said
that
they
would
implement
it.
W
I
can't
give
you
an
official
answer
for
Google
I've
talked
to
a
bunch
of
different
people,
and
people
have
different
answers,
but
I
think
we're
leaning
against
probably
not
initially,
but
maybe
we'll
run
some
experiments,
but
I
think
we're
kind
of
leaning,
no
and
then
on
the
network
operators.
Side
I've
talked
to
a
lot
of
network
operators.
W
I
was
it
in
Alec
last
month
and
I
talked
to
a
bunch
of
people
there
about
this,
and
some
people
said
this
sounds
useful
and
some
people
said
I,
don't
know
why
I
would
ever
use
that
martyr
and
run
my
network,
and
so
even
in
that
community
I
got
very
just
four
responses.
I
think
my
biggest
concerns
is
even
if
this
is
not
part
of
the
invariants.
If
it's
in
v1,
it's
gonna
be
an
ever-loving
pain
in
the
butt
to
change
in
the
future
and
I'm.
W
Actually,
it's
much
concerned
that
this
is
not
enough,
as
it
is
too
much.
So
my
personal
preference
is
that
we
go
along
the
direction
that
John
I
was
kind
of
indicating,
but
I
wanted
even
more
specific
I
want
an
experimental
draft.
I
want
Brian
to
use
more
bits.
I
want
him
to
try
to
incorporate
loss
and
I
want.
You
know,
there's
like
I,
think
five
bits
available
use
them
all
like
try
to
get
as
much
information
as
you
can
and
provide
it
to
the
network
and
try
to
figure
out
and
run
some
experiments.
W
A
W
W
It
awesome
and
I
think
we're
still
at
that
stage
today,
where
we've
almost
like
over
constrained
ourselves
down
to
one
bit
because
like
no
one
wants
to
leak
anything
but
like
it's
possible
that
it's
just
not
useful
so
like
we
shouldn't
do
something
that
we're
not
like
really
sure
is
useful.
So
I
would
rather
the
end
points
that
think
this
is
could
be
useful,
Microsoft
included
and
cloud
environments
and
the
operators
that
that
think.
AP
Markus
Neal
Erikson
I
just
want
to
make
some
comments
on
the
usefulness
and
simplicity
of
this.
So
we
were
a
bunch
of
people
at
the
hackathon
taking
quick
stacks
we
haven't
looked
at
before,
and
we
managed
to
implement
a
bunch
of
running
versions
of
the
spin
bit.
We
got
them
to
interoperate.
We
got
really
nice
measurement
results
and
we
could
even
do
some
interesting
buffer
block
mitigation
techniques
using
this.
So
so
we
did
see
some
some
usefulness
already
here
and
I
also
think.
AP
One
extremely
important
thing
here
is
what
we
call
the
probabilistic
opt-in,
because,
as
I
think
we
should
do
this
and
I
think
we
should
have
probabilistic
opt-in
because
me,
as
a
middle
box,
developer
we'll
be
forced
to
do
the
right
thing
from
the
start.
Right
I
will
have
to
have
to
take
care
of
the
cases
where,
where
where
it
doesn't
flip,
as
expected
from
the
beginning,
because
this
is
how
the
protocol
would
work.
AQ
P
P
S
P
Right
I
mean
I
think
if
I,
if
I,
have
to,
if,
if
I
were
given
only
two
choices,
you
know
the
the
spin
bit
with
clear
text,
packet
numbers
and
the
vac
plus
spit.
You
know
the
vac
plus
spin
bit
with
encrypted
packet
numbers.
I
would
definitely
choose
the
latter,
and
that
seems
like
clearly
like
has
like
superior,
like
you
know,
properties,
so,
I,
I,
guess
I
mustn't
with
you
choices,
but
were
those
many
choices?
Is
this
what
I
think
I
would
pick
so
I?
P
You
know,
I
took
a
little
look
at
where
this
would
actually
go.
If
maybe
I'm
missing
something,
but
we're
gonna
do
some
rejiggering,
so
we
have
effectively
in
the
in
the
short
header.
We
have
five
fixed
bits.
The
first
one
zero,
which
I
think
is
gonna,
have
to
stay
zero.
The
second
was
the
Cape
in
which
we
actually
need.
We
have
this
one,
one:
zero
which
I
understand
some
of
those
things
are
being
used
for
D
mocks,
and
maybe
we
could
screw
around
some.
P
P
So
it
seems
to
me
that
the
vac
is
kind
of
like
unbaked
at
this
moment,
so
I
personally
I
personally
find
it
like
pretty
hard
to
think
about
like
humming,
yes
or
no,
unlike
a
proposal
that
includes
that
because
like
if,
like
it
turns
out
that
kind
of
just
like
sucks
and
like
you
know
as
Johnny
and
ian
kind
of
suggests,
then
it
might
be
bad
in
the
munitions.
Then
we're
gonna
be
sad.
We
like
use
the
space
for
it,
but
if
it's
like
really
good,
then
we
might
be
happy.
P
We
use
the
space
for
us
and
so
I,
so
I
can
I
understand.
This
feels
like
kicking
the
can
down
the
road
a
little
bit,
but
it's
not
required
for
the
invariance
that
we
know
the
answer.
This
question
and
I
wonder:
is
there
somewhere?
We
can
get
more
information
about
whether,
like
this
technique
really
works
like
before.
We
like
make
a
decision
about
what
we're
gonna.
Do
it
or
not,
like
I,
think
we
have
some
like
I.
P
Think
one
thing
we
could
say
is
we
have
like
we
understand
what
the
worst-case
scenario
in
terms
of
like
the
privacy
story.
Perhaps
reasonably
well
at
this
point
and
we
can
decide
like,
were
you
willing
to
accept
that
privacy
loss
and
then
this
base
consume
the
header
assuming
the
technique
base
of
you
worked
really
well,
and
then
we
can
like
charter
Brian
to
go
off
and
find
out
things
very
well
like
we
I
mean
like.
P
Is
it
not
gonna,
take
more
than
like
10
minutes
to
modify
the
specification
to
put
this
in
if
we
decide
it
and
it's
not
in
the
invariance
so
like
it's
not
like,
it's
got
a
hold
up
our
schedule
that
like
wait,
till
November
to
decide
like
if
this
thing
goes
in
right,
so
I'm,
sorry
to
be
like
hey
kick
the
can
in
the
road,
but
I
find
it
very
hard
to
make
a
decision.
At
this
point.
That's.
AR
K
AR
Dawkins
responsible
area
director,
who
has
been
mostly
hands-off
with
the
largest
group
in
transport
to
the
to
up
to
this
point
but
I,
do
want
to
ask
a
couple
of
curious
questions.
It's
different
and
I
was
expecting
to
ask
most
of
them
at
the
end,
but
I
think
this
one
is
probably
appropriate,
I'm
going
to
ask
if
you
please
hum
if
you
think
this
is
research,
please
hum
if
you
think
this
is
engineering.
AR
S
AF
AR
AR
AB
AO
AR
A
AR
A
AK
AC
N
Look
at
the
broader
picture
here:
quick
is
not
the
only
UDP
based
protocol
out
there,
and
the
only
thing
that
we
have
in
this
short
header
to
identify
a
quick
packet
is
a
0
in
the
first
bit.
That's
all
we
have
connection
migration
and
multipath
will
will
be
a
thing
with
quick
or
connection
migration
in
version
1
multipath
later,
so
the
path
will
not
not
necessarily
see
the
handshake.
N
AS
This
is
Sanjay
Mishra
Verizon,
so
first
of
all,
I
want
to
applaud
Bryan
for
the
work
that
he
has
done
in
the
hackathon
implementation.
It's
really
commendable,
I
think
the
amount
of
exhaustive
work
they
have
done
insofar
as
the
deployability
is
concerned.
You
know
we're
already
seeing
increased
traffic
on
the
network,
which
is
a
good
thing.
AS
It
clearly
has
the
value
and
I
think
we
have
to
spend
enough
time.
Brian
is
spend
enough
time
in
trying
to
lay
out
the
value
of
it
as
well
as
I
know.
Privacy
has
been
kind
of
assured,
but
you
know
we
can't
say
a
100%
that
it's
all
covered,
but
I
think
from
more
or
less.
We
can
see
that
the
privacy
issue
is
is
not
as
as
you
know,
if
you
look
at
the
the
benefits
and
the
end,
the
advantages
and
the
disadvantages.
AS
M
Me
accouterment,
so,
yes,
this
is
an
experiment.
We,
as
the
university
we've
already
tried
to
look
into
this
as
much
as
we
could,
but
that's
a
testbed.
So
we
simulated
various
traffic
conditions,
which
are
quite
unrealistic
today
but
might
become
more
realistic
in
future.
Hopefully
not,
but
you
never
know,
and
we
can
say
it
does
work,
it
gives
you
the
information
we're
expecting
together.
So
that's
not
a
research
question
for
me
anymore.
M
The
question
might
be:
is
this
a
useful
signal
where
people
use
it
where
people
deploy
it,
but
we
can
not
answer
that
with
our
University
testbed.
You
need
the
an
operator
you
need
to
deploy
it
to
figure
out
if
it
will
get
deployed
and
also
Microsoft
will
not
be
able
to
answer
this
because
they
don't
have
a
setup
where
they
can
actually
change
both
the
client
and
the
server.
M
So
if
Google
is
willing
to
deploy
large
scale
and
extra
mint
with
it
I'm
happy,
if
not,
then
we
have
to
bake
it
into
version
one,
because
that's
the
only
way
to
get
the
experiment
that
we
want,
because
we
need
deployment
for
it
and
I
don't
really
get
the
point
about
extensibility.
If
we
figure
out
it's
not
useful
and
version
one,
let's
rip
it
out
and
version
two,
that's
what
we
have
versioning
for
and
we
can.
M
We
can't
like
we
can
even
publish
a
worship
tube
with
where
this
is
the
only
change
like
this
should
be
done
really
quickly.
That's
the
extensibility
story.
We
have
so
really
we
should
put
in
a
version
one.
The
other
point
I
wanted
to
make
is
that
there's
not
a
limitation
from
the
spin
bit,
unlike
the
egg
mechanism
or
whatever
the
dependency
we
have.
Is
that
if
quic
is
congestion
controlled,
you
need
egg
feedback,
you
need
at
least
one
singer
per
round
trip
time
or
better
like
four,
and
that's
like
enough
for
the
spin
bit.
M
A
AT
The
whole
cool
fastly
why
I
feel
sympathy
to
having
this
kind
of
observe,
observability
I,
prefer
keeping
stream
but
outside
of
the
core
protocol,
because
not
having
the
spam
bed
will
help
us
ship
quick
oli,
for
example,
consider
the
interaction
with
packet
number
encryption
and
especially
because
spin
bit
can
be
an
extension.
It
is
easy
to
detect
with
a
client
implements
permit
or
not
by
looking
at
the
flowing
packets.
AT
AU
And
Rebecca
Google
for
the
various
reasons,
I've
been
looking
a
lot
at
nonparametric
estimators
of
distributions
of
various
quantities
where
this
falls
in
here
is
that
I
suspect,
there's
a
lot
more
information
you
can
get
out
of
the
Vic
about
what's
happening
in
the
network,
then,
is
immediately
obvious.
Some
of
these
estimators
are
essentially
the
same
computational
cost
as
an
e
WMA
and
will
track
a
given
percentile
of
a
distribution
very
very
nicely.
AU
The
other
thing
is
the
same
estimators
work,
even
if
you
don't
have
the
spin,
but
it's
just
more
expensive,
so
really
what
the
spin
bit
gets.
You
is
a
cheaper
way
of
getting
a
slightly
worse
measurement
of
the
ittv,
otherwise
have
got
by
Auto
correlating
list
the
stream.
So
the
privacy
argument
is
just
not
there.
AU
You
can
spin
to
the
resources
which
is
not
infeasible
and
order
correlate
the
straight
stream
and
figure
out
the
ITT
anyway,
it's
just
too
expensive
to
do
that
in
a
monitoring
system
for
the
network,
the
monitoring
system,
the
network
can
afford
to
do
the
distribution
estimators
and
derive
quite
a
lot
of
information
out
of
even
a
single
bits
been,
but
the
Vic
it
can
get.
A
lot
in
I
suspect,
a
pretty
good
measure
of
loss
and
reordering
induced
badness
and.
A
And
now
I'll
go
ahead
and
put
this
on
screen.
This
captures
what
we
think
the
options
we've
heard
so
far
are
so,
if
you
want
to
speak
to
these
or
you
want
to
add
to
the
possibilities,
please
do
let's
not
get
too
fine-grained.
We
to
keep
this
relatively
coarse
grind
for
the
purposes
of
a
decision.
I
believe.
AU
AI
AV
AF
Go
on
to
my
comments
then,
and
possibly
at
the
end,
we
can
return
to
my
question.
One
thing:
I
just
wanted
to
point
out
related
to
the
comments
that
Patrick
McManus,
everybody
remembers,
Patrick.
His
comments
were
sometime
ago
now
about
the
art
round
trip
time
implications.
I
ran
the
design
team
for
that
and
we
could
not
find
privacy
implications
for
them.
AF
But
I
want
to
to
be
clear
that
what
the
design
team
was
asked
to
do
was
to
look
for
those
implications,
not
simply
to
examine
whether
or
not
this
leaked,
because
it
was
an
uninteresting
question.
The
answer
was
yes.
That
was
the
intent.
If
somebody
has
a
different
question,
for
example,
whether
the
Beckley
--ks
more
or
less
than
a
sequence
number
I'd
be
happy
to
spend
another
design
team.
AF
One
I
also
wanted
to
go
slightly
into
the
question
of
ossification.
I.
Do
think
there
is
a
risk
of
ossification
here,
but
I
don't
think
it's
the
risk.
People
are
seeing
I.
Think
people
are
worried
that
if
they
put
this
into
T
V
1,
it
will
be
hard
to
rip
out
and
will
ossify
both
the
expectations
of
the
network
operators
and
the
expectations
of
the
stack
I.
Think
the
bigger
risk
here
is
that
if
we
continue
to
push
things
into
the
network
without
explicit
signal
as
an
architectural
choice,
people
will
ossify
into
staying
with
TCP.
AF
T
AV
B
B
So
there's
there's
the
people
that
basically
have
started
to
work
on
this
already
we're
gonna
form
one
of
those
things
that
I
can
come
back
with.
Somebody
looks
like
a
PR.
My
guess
is
that
we
would
try
to
land
this
PR
sooner
rather
than
later,
because
it
obviously
infects
the
invariants
and
therefore
my
guess
is
that
we
would
do
this
within
the
next
four
weeks.
Martin
says
it
doesn't
impact
of
the
invariance
okay,
well
that
Martin's
right
right.
So
then.
A
A
B
AG
B
AG
I
mean
if
it's
gonna
happen.
I
would
prefer
it
happen
in
this
group,
because
this
group
has
the
expertise
for
it.
So
right
I
actually
got
in
mind
to
respond
to
your
comment
from
Brian
few
years
ago,
at
this
Mike
Wow,
just
in
particular,
he
said
that
he
was
unconcerned
about
traffic
analysis
countermeasures
because
of
the
inevitability
of
traffic
analysis
on
Internet
traffic
and
I
well
well.
I
share
his
fear.
I
want
to
encourage
people
in
this
room
to
not
share
his
nihilism.
AG
If
we,
if
we
your
comment
was,
was
was
a
form
of
traffic
analysis,
nihilism
and
I,
don't
think
we
can
afford
to
do
that.
Certainly
we
don't
understand
it
very
well,
but
Brian
I
want
many
meaty
research
questions
for
you
to
be
gainfully
employed
on
for
years,
and
if
we
give
up
on
traffic
analysis
now,
then
that
will
not
be
possible.
So
yeah.
A
A
Really
quickly,
is
that
not
sure
what
hat
I'm
wearing
I've
heard
in
a
couple
of
the
recent
comments
of
the
assertion
that
if
we
put
it
in
v1
that
well,
if
we
don't
like
it
or
it
doesn't
turn
out
well,
we
can
just
go
and
mint
to
v2.
That's
very
true,
except
that
we
are
have
agreed
that
v1
is
primarily
about
HTTP,
so
we're
gonna
mint,
a
new
version
of
HTTP
that
uses
quickly
one.
It's
not
clear.
A
AR
S
S
First
I
want
to
apologize
to
dkg
for
encouraging
nihilism
about
traffic
analysis
for
anyone,
I
just
don't
have
the
cycle
stock
on
it.
I
think
other
people
can
please
don't.
Let
me
discourage
you
I,
don't
have
any
money
to
pay
you
to
do
the
research.
Sorry
I'm
pretty
firmly
on
two
here
spin
bits
and
quick
v1
I
heard
a
lot
of
people.
Volunteering
me
to
do
work
if
there
is
a
an
indication
that
comes
out
of
this,
that
there
is
work
that
will
lead
to
experimentation
with
this
signaling
and
scale.
S
I
am
happy
to
do
that
work
if
it
comes
down
to
three
or
four
I,
don't
know
how
many
cycles
I
have
for
that.
Just
in
terms
of
you
know,
people
volunteering
me
to
do
stuff
just
want
to
let
you
know:
I
tend
to
also
agree
with
Acker
I'm,
leaning
toward
spin
plus
vac
plus
encrypted
PN
is
the
right
way
to
go.
I
mean
I
know
we're
not
calling
that
right
now,
I
think
that
seems
superior
to
me
because
there
looks
like
there's
information,
the
signal
we
can
use
for
other
stuff.
S
A
A
Can
run
back
one
more
time.
Brian
I'd,
like
folks
to
Brian
did
something
very
nice
there,
which
was
he
expressed
what
he
preferred,
but
also
what
he
can
live
with.
Oh
look,
it's
the
screen,
so
if,
if,
if
everyone
else
can
do
that,
we
just
got
a
fairly
strong
direction
from
our
area
director
that
he
did
not
want
this
to
be
on
our
critical
path
for
shipping
our
deliverables,
and
he
explained
why.
So,
especially
if
you
can,
you
know,
talk
to
I.
A
AW
Event,
so
my
preference
is
to
have
it
in
version
one
and
again
it
depends
also
on
the
on
the
encryption
of
the
packet
number,
which
we.
What
what
to
do
is
this
case
in
what
Brian
says
was.
Okay,
now
about
the
usage
I
mean
there
was
some
comment
about
the
network
operators
and
I
can
agree
that
not
all
network
I
mean
it's
not
all
network
operators,
because
when
you
go
and
network
operators
and
ask
him
if
they
need
it,
it
depends
what
are
they
managing?
Because
if
you
go
to
someone
who
just
managed
the
error?
AW
Interface
he's
not
interested
in
TCP
at
all,
I
mean
not
about
this,
because
his
interest
is
in
the
lower
layer.
But
if
you
go
to
someone
who
managed
the
operation
of
the
network
and
the
relation
with
other
network
which
he
analyzed
on
the
TCP,
he
has
interesting
able
to
measure
RTT
and
know
what's
happening
on
the
network.
So
it
depends.
We
are
asking
in
the
network
operator.
AW
So
the
other
point
was
about.
There
was
a
comment
about
being
able,
with
this
only
zero
to
figure
out
if
it's,
quick
and
I
think
that's
tied
also
to
the
issue
of
the
de
multiplexing
that
we
had
or
that
I
think
we'll
have
to
consider.
How
to
put
these
bits
runs
if
we
put
them
in
order
still
to
address
I
mean
of
course,
the
moment
we
take
all
those
bits
out
the
other
bits
out.
AW
AX
AY
AX
Ronnie's
point
basically
to
Ian
and
others:
yeah
I
experienced
the
same
thing:
you've
go
to
Nanog
they'll
talk
to
a
lot
of
guys
who
are
peering
experts
and
bgp
experts.
They
won't
really
care
about
troubleshooting
user
flows.
That's
important
when
it
comes
to
the
patterns.
Changing
like
the
unreliable
streams,
the
act
production
all
the
things
that
can
change,
that's
kind
of
like
just
describing
the
day
in
the
life
of
passive
measurement
designers.
If
it
changes,
we
have
to
change
it
tomorrow,
so
I
think
that's
that's!
AX
That's
the
role
that
we're
in
following
what
others
do
we
have
to
make
the
measurements
work
if
they're
gonna
work
for
all
who
want
more
study,
Brian's
slides
did
not
cover
the
entire
draft.
Please
read
the
memo.
One
of
the
things
that
was
studied
in
there
is
one
of
the
things
that
Andrew
brought
up
this
auric
autocorrelation
or
you
can
just
look
at
inner
packet
times
and
tried
to
tell
what
the
round-trip
time
is
from
that
Andrew.
It's
really
hard
to
make
that
work,
and
the
draft
points
to
a
reference
for
that.
AX
It's
probably
even
harder
to
make
it
work
with
quick,
where
we
don't
understand
right
now
what
the
inner
packet
dynamics
are
gonna
be
so,
let's
not
I
mean
this
is
the
alternative
where
we
don't
get
a
spin
bit.
If
we
just
look
at
blind
packets,
can
we
measure
anything?
Probably
not,
but
that's
research,
not
engineering,
oh
yeah,
so
my
choice
would
be
number
two
quicken
v1
I
can
live
with
encrypted
packet
numbers
and
the
back.
Thank
you.
Thank.
A
A
Q
AZ
Kohler
Telecom
Italia
I
will
support
the
additional
spin
meet
in
via
in
v1.
This
can
allows
a
network
operator
to
measure
not
only
the
end-to-end
round-trip,
but
also
by
using
the
RFC
8321,
also
the
performance
measurement
of
its
own
portion
portion
of
the
network
of
the
complete
error
RTT.
So
this
can
be
useful
for
to
expect.
Thank.
AJ
I
wanted
to
clarify
a
question:
the
comment
that
media
made.
We
do
run
some
large
online
services
and
we
will
be
able
to
do
such
experiments
at
scale.
The
other
thing
I
want
to
point
out
is
that
the
primary
use
case
was
the
cloud
where
you
know
we
could
run
quick
in
the
data
center
for
other
use
cases
other
than
HTTP,
because
it's
a
general-purpose
transport.
So
it's
certainly
useful
from
that
point
of
view
as
well,
and
we
can
do
those
measurements
in
terms
of
preference
out
of
these
options.
AE
You
it's
about
diner,
I,
think
the
option
one
into
a
facetious
because
they're
actually
joined
together.
The
version
is
not
in
the
short
header
and
the
experiment
that
Brian
is
running
uses.
The
IP
address
is
the
key.
It
is
very,
very
possible
that
we're
going
to
run
multiple
versions
of
in
before
we
deploy
an
RFC
version
of
quick
or
as
draft
versions.
AE
The
second
point
is
that
I
don't
know
how
it
could
be
option
three
either
because
to
have
a
supported
extension,
the
middle
box
would
need
to
be
able
to
peek
into
the
initial
backed
and
maintain
more
state
per
connection
that
would
also
infringe
upon.
Maybe
so
it
must
maintain
a
map
for
a
connection
ID
and
that
might
affect
the
design
decisions
in
maybe
changing
connection
ID
each
and
every
round
trip
time
if
a
like
a
server
and
a
client
wanted
to
do
that
as
a
as
a
privacy.
Preserving
method.
AE
I
have
other
points
as
well,
but
I'm
going
to
make
it
brief.
I'm
concerned
about
the
differential
behavior
based
on
spin
bit
that
might
be
offered
by
network
operators
I'm,
not
sure
what
the
implications
of
that
are.
Network
operators
have
done.
Things
like
deploy,
TCP
middle
box
proxies
before
which
have
kind
of
sped
up.
Tcp
I'm,
not
I,
don't
understand
that.
Well
enough
and
I,
don't
think
that's
covered
well
enough
in
the
draft
and
I.
Don't
think
this
meets
the
engineering
bar
either
of
including
in
v1.
Right
now
this
was
tested.
AE
For
example,
limited
situations
like
flow
control
is
disabled
version
control
is
disabled.
I
would
like
to
see
it
kind
of
tested
in
real-world
traffic
environments
like
HTTP,
realistic,
h-2b
flows
among
multiple
concurrent
requests
with
HTTP
two
transports
before
it
actually
can
be
included
in
people,
so
I
don't
think
either
these
options
are
actually
like
real
options.
It's.
A
N
AE
This
particular
spin,
but
which
might
push
us
back
like
a
long
and
so
I
think
this
has
privacy
implications,
not
because
of
the
fact
that
hey
we
had.
We
need
it's
exposing
our
TT,
but
it
prevents
us
from
doing
all
these
other
things
in
quick,
based
on
like
the
fact
that
we
middleboxes
want
to
be
simple
and
use
an
IP
address.
A
five
tuple
was
nothing
proposal,
whereas
we're
considering
connections
is
not
five
doubles
and
there's
a
mismatch
between
the
endpoints.
AE
What
the
endpoints
can
serve
as
a
connection
identifier
and
what
a
middle
box
considers
an
and
I
connect
an
identifier.
So
it
is
not
possible
to
remove
this
out
because
short
headers
are
supposed
to
be
and
is
efficient,
and
so
they
will
never
include
the
version.
So
there
could
be
multiple
versions
on
1/5,
double
and
I.
Think
that
and
it
could
be
multiple
connection
IDs
and
find
1/5
double
as
well,
so
5
double
does
not
make
sense.
Ok,
thank
you.
Jonna.
A
AD
Nygren
Akamai
I
think
actually,
following
on
to
something
this
about
said
at
the
end,
I
think
it's
worth
thinking
about
adversarial
and
kind
of
what
some
of
the
consequences
could
be
and
I'm
curious.
What
vendors
are
thinking
about
in
terms
of
when
they
might
start
looking
at
using
this
for
controlling
flows
and
trying
to
optimize
flows
rather
than
just
using
it
for
passive
diagnostics,
cuz
I
think
the
risk
there
has
a
significant
ossification
risk.
They
could
turn
this
putting
this
into
v1
from
being
something
that's
kind
of
a
research
experimental.
AD
What
happens
with
it
into
something?
It
really
becomes
an
engineering
question
and
that
kind
of
pushes
me,
along
with
Ian's
quest
perspective
towards
thinking.
We
should
really
experiment
more
and
figure
out
exactly
what
we
want
and
therefore
I
think
I'm
leaning
really
strongly
towards
option
3,
even
if
we
don't
know
how
to
do
the
extension
part.
Yet.
Thank
you
next.
P
Chris
Carla
first
I'd,
say
Christian,
said
I
emailed
lists
his
opinion,
which
appears
to
be
that
we
should
that
we
should
reserve
the
bits
in
the
spec.
So
first,
let
me
say,
like
the
cost
here
primarily
is
I.
Guess
three
things
the
bits
having
to
rearrange
the
bits
a
little
bit
to
make
room
for
this,
the
cost
of
like
doing
anything,
the
D
editorial
or
working
group
work
to
like
actually
do
the
specification
and,
of
course,
the
potential
privacy
loss.
P
If
it's
a
problem,
so
second
thing
I
would
say,
is
like
this:
entire
project
is
like,
like
it's
some
level
experiment.
What
I
mean
by
that
is
like
you
know,
we're
like
we're,
designing
this
protocol
and
then
we're
gonna
feel
pieces
of
it
or
gonna
see
how
they
work
properly
and
like.
If
things
don't
work
properly,
then
we're
gonna
think
about
so
like
and
then
that
can
still
happen
between
now
and
v1.
P
So
I,
don't
like
actually
like
III
feel
like
a
little
bit
like
the
you
know
like
we
don't
know
if
this
works
like
if
our
objections
ever
know,
if
this
works
the
way
to
what
we
think.
So
it
would
be
good
idea
if
it
did
work,
then
the
way
to
deal
with
that
is
to
like
actually
slightly
put
in
the
protocol
and
like
I'm,
like
what
people
appointed
and
see
if
it
worked
or
not
so
I
mean
like
monoi,
should
never
know
if
it
works.
P
So
so
I
guess
it
seems
like
if
you've
gesture
needs
is
a
bad
idea
in
principle.
That's
one
thing:
if
there's
you
know,
if
it
works,
we
should
like
do.
They
think
we're
doing
everywhere
else.
I
guess
one
thing
I
hope
Brian
will
say
when
he
gets
up
because
I'm
actually
not
particular
clear
on
this
point
is
I.
P
Don't
understand,
I'd
understood
that,
basically,
if
clients
didn't
participate,
that
Brian's
measurement
framework
was
able
to
process
that
that
fact
properly
and
was
able
to
ignore
the
clients,
won't
wear
the
same
but
will
participate,
and
if
that's
true
I,
don't
see
why
we
need
a
negotiating
extension
clients
either.
Do
it
alone
do
it
was
over
here
to
order,
they
don't
do
it
and
like
Brian's
measurement
framework
figures
it
out
it.
P
BA
Mike
Bishop
Akamai
I'm
actually
here
to
make
two
observations
about
the
short
header
and
the
first
byte
first
off.
The
signal
that
is
quick
actually
is
not
just
that
it
starts
with
a
zero.
You
have
zero
something
1
1
zero,
as
currently
defined
in
B
1.
So
the
signal
that
it's
quick,
B
1,
is
4
bits
out
of
the
first
byte
of
those
remaining.
BA
Ok,
so
so
we
will
get
rid
of
some
of
those
or
be
able
to
assign
them
other
uses.
Then
we
have
the
3
bits
of
the
tape
field.
Currently,
the
only
thing
we
communicate
with
type
is
the
length
of
the
packet
number
and,
as
part
of
the
existing
packet
number
encryption
proposal,
we
were
going
to
move
to
bar
rent
for
that
anyway.
So
we're
not
doing
anything
with
those
type
bits.
I
would
I'm
kind
of
leaning
toward
3
a
that.
We
block
those
bits
off
as
reserved
and
let's
do
an
experimental
RFC.
BA
A
BB
BB
Tendrils
of
a
TNT,
it's
been
a
long
exercise,
but
I
think
there
are
a
couple
of
things
that
I
wanted
to
say.
One
is
related
to
architectural
principles.
That
discussion
took
the
right
direction,
basically
with
the
opt-in
and
with
the
explicit
signaling
and
I,
think
it's
it's
the
right
way
to
to
avoid
guessing
in
future
protocols
and
the
second
one
is
more
processed
between
the
between
the
experimentation
and
in
the
in
the
ability
to
to
do
the
privacy
analysis.
I
think
these
were
two
things
that
kind
of
gave
proof
that
that
this
thing
makes
sense.
BB
R
July
anger
I'll
quickly,
state
what
I
was
going
to
come
up
and
say
was
my
opinion,
which
was
going
to
be
number
three
at
best.
Not
for
would
not
sorry
not
not
do
or
1,
because
I
think
2
in
1
both
put
the
spin
bit
on
the
critical
path
and
now,
with
the
editor
hat
on
I,
will
say
that
that's
actually
a
real
issue.
R
We
are
still
trying
to
shoot
for
November
and
it's
becoming
increasingly
clear
to
me
as
we
go
through
this
conversation,
that
there
are
corner
cases
here
and
there
are
edge
situations
that,
as
we
start
writing
this
up,
the
issues
list
is
going
to
explore
again
and
I'm.
Terrified
of
that,
we
just
spent
a
whole
week
trying
to
really
trim
it
down
and
really
get
it
under
control,
and
if
you
have
to
repeat
the
exercise
again
and
again,
that's
not
going
to
be
a
lot
of
fun.
R
A
A
S
S
If
we're
looking
at
going
too
far,
int
packet
numbers
aren't
encrypted
packet
numbers.
We
have
these
bits
in
type
that
v1
will
not
use
for
anything
anyway
and
we
will
have
to
grease
them,
and
if
you
want
to
grease
them,
you
can
spin
them
to
grease
them
rate.
You
can
probabilistic.
This
is.
This
is
useful,
grease
rate.
This
is
one
way
to
look
at
this
with
respect
to
I.
Can
I'll
read
that?
S
Yeah
yeah
right
it
yeah
great,
so
we
can
have
that
discussion
over
of
your
V
I
continue
to
believe
that
the
two
is
the
right
choice
here
again
spin
bit
back
encrypted
packet
number
with
respect
to
all
three
would
be
an
extension.
That's
not
a
negotiated
extension.
What
I
would
want
to
see
with
3a
is
for
the
the
chorus
back
to
essentially
refer
to
the
experimental
document
non
normatively.
To
say
this
is
the
experiment
that
we're
using
this
for
in
v1.
S
If
we
do
an
experimental
look,
the
document
with
reserved
bits,
otherwise
you
know
there's
no
reference
to
it
and
basically
the
people
who
are
going
to
know
what's
going
on
about
that
other
people
in
this
room.
The
other
thing
that
I
would
like
is
through
a
wiki
or
some
other
thing
or
maybe
on
the
list,
is
to
get
a
feeling
of
how
many
people
would
it
would
participate
in
the
experiment
in
three,
because
I
don't
need
an
experimental
extension
to
do
it
myself.
I.
A
S
A
So
you
know
chair
head
on
so
far.
I've
heard
a
number
of
people
say:
I
prefer
quick
v1,
but
I
haven't
heard
structured
are
even
as
to
why
I
have
heard
a
lot
of
people
also
say:
I,
don't
want
it
to
put
it
in
v1
and
the
argument
seemed
to
be
more
structured
for
for
not
putting
it
in
there.
So
if
we
can
explore
that
relationship,
that
would
be
really
helpful
to
help
us
make
a
decision.
Okay,
I.
M
Couldn't
just
let
me
on
add
on
to
that
one
say:
one
thing
is
more
deployment
and
the
end
points,
but
the
other
thing
is
also
what
support
says
like
you
also
need
a
way
to
actually
know
where
the
bits
are
and
read
them.
Otherwise,
the
experiment
is
useless.
Given
we
don't
even
know
how
the
extendibility
would
frame,
it
would
look
like
I.
Don't
think
that
is
actually
an
option.
It's
not
an
option.
N
M
AY
Chrissteele
Hutchison,
my
preference
I'm
an
operator
yep,
the
preference
is
option
2.
The
main
reason
is
I
wanted.
Just
like
Brian
said:
I
want
a
reasonable
sample
size
and
it
because
it's
two
experiments
or
I
think
there
won't
be
enough
and
the
reasonable.
We
actually
do
this
now
with
TCP
X
and
we
use
it
for
early
detection
of
congestion
and
that
in
turn
then
feeds
upgrading
the
network.
So
if
the
I
suppose
the
points
is,
if
you,
if
you
make
us
blind,
then
we
I
ever
have
to
it's
sort
of
just
in
time.
AY
You
know
efficient,
cost-effective,
management's
of
a
network
is
about
just-in-time
upgrades
and
things.
If
you,
if
we
can't,
we
don't
know
that
we
need
to
upgrade
until
it's
too
late.
It's
about
customer
experience.
If
we
upgrade
way
too
early,
then
we've
deployed
capex
when
we
don't
need
to.
Thank
you.
Thank
you.
BC
Yo
god
I
want
to
come
back
to
this
point
that
was
just
made
about
what
we
can
gain
from
TCP
sequence
numbers,
and
some
of
it
could
occurs
to
me
that
if
you
have,
if
you
look
at
a
flow
of
TCP
sequence,
numbers
and
X,
you
are
inferring.
It
signal
directly
from
stuff,
that's
happening
that
is
making
up
the
actual
data
exchange,
whereas
the
spin
bit
is
an
independent
signal,
irrespective
of
your
other
sexual
connection,
progress,
so
you
can
tweak
that
way
more
independently.
BC
That
is,
it
seems
so,
and
so
it
looks
like
we
are
all
assuming
well-behaved
clients
that
don't
try
to
game
whatever
the
operator
does
all
right
now
we
have
been
thinking
about
people
looking
at.
Oh,
we
are
going
to
do
measurements,
but
probably
you're,
not
just
going
to
do
measurements
and
say
who
we
have
this
RTT,
but
you're
also
going
to
have
certain
assumptions
or
maybe
reactions
so
I'm
wondering
whether
we
could
take
us
take
some
time
to
investigate
what
and
in
the
video
flow
can
do
by
lengthening
your
period,
which
is
easy
to
do.
BC
Maybe
short,
shortening
this
to
shorten
your
expected.
Ott
is
more
difficult
to
do,
but
if
you
have
one
or
more
one
client
one
connection
is
the
set
of
colluding
ones,
how
they
can
actually
manipulate
or
drive
network
behavior
I,
don't
think
this
has
been
investigated,
and
so
we
are
just
making
too
many
positive
assumptions
at
this
point.
So
this
is
why
I
would
probably
for
my
site,
even
though
I
don't
have
a
strong
feeling,
it
I,
don't
have
any
any
bets
in
here.
BC
A
Thank
you
you're
one
of
the
mentioned
when
we
set
up
this
conversation
a
few
months
ago.
That
was
one
of
the
items
that
we
called
out
explicitly.
Was
you
know?
How
can
this
signal
be
gamed?
What
are
the
systemic
effects
and
we
didn't
really
see
any
response
to
that.
So
I
share
your
frustration
that
that
wasn't
explored.
A
W
Sweat
Google
I
wanted
to
comment
on
the
negotiated
extension
and
the
exact
approach
that
I
am
posing.
We
we
use,
we
have
a
way
to
change.
Quick
is
called
version
ago.
She
ation.
This
is
an
excellent
opportunity
to
use
it
right
out
of
the
box,
opposed
to
waiting
and
like
trying
to
mint
v2
and
realizing
it
doesn't
actually
work.
W
W
W
U
BD
W
A
AF
A
clarifying
question
you,
you
said
earlier
that
if
HTTP
was
defining
a
version
to
run
over
quick,
would,
in
a
case
like
this
it'd,
be
defined
to
run
over
all
versions
of
quick
of
this
type,
because
that
makes
a
serious
difference
on
the
points
the
operators
have
made
about
the
sample
size.
That's
necessary
for
this
to
be
useful
for
them
to
do
their
work.
BA
A
BA
W
U
Fred
lassi
Google
I
got
up
to
say
effectively
what
Mark
said.
I,
don't
think,
there's
much
of
a
difference
between
putting
in
a
v1
and
and
not
and
making
experimental
in
terms
of
how
much
deployment
will
get
I,
don't
think
being
in
v1
will
influence
our
decision
to
include
it.
So
my
preference
is
for
three
a
or
three
B
or
something
around
three
I
also
just
want
to
make
one.
U
S
Like
to
reiterate
the
observation
during
the
talk
that
these
bits
are,
as
our
all
header
bits,
integrity
protected,
so
a
lot
of
the
fear
that
we
have
about
the
meddling
that
happens
in
TCP.
Just
we've
already
built
a
way
to
make
that
happen.
So
the
the
space
of
things
that
you
can
do
is
way
smaller.
S
A
We
have
20
minutes
left
Spencer's
reserved
a
block
of
time
at
the
end,
I
think
for
me
personally,
the
the
various
comments
combined
with
the
ends
were
quite
illuminating
and
the
way
I'm
thinking
about
this
and
I'm
happy
to
have
this
shouted
down
is
that
it's
either
we
would
put
spin
bits
and
quickly.
One
now
see
how
that
experiment
goes
and
with
the
understanding
that
it
is
an
experiment
they
might
get
pulled
out
before
the
end
of
quickly
1/4
chipped.
M
Mia
kudamon,
so
the
difference
is
that
were
using
the
version
number.
You
actually
also
give
the
leg,
assuming
version
one
would
be
the
server
has
to
support
it.
Then
using
the
version
number
means
the
the
server
can
be
too
and
say:
I
want
to
use
the
non
spin
bit
version,
but
that
also
might
cause
your
round
trip
time
range.
Okay,.
A
M
S
S
Sorry
yeah,
sorry
I
got
to
get
out
of
hackers
head
I,
really
like
Ian's
I,
like
the
more
I
think
about
it.
The
more
I
like
Ian's
proposal,
separate
quick
version,
was
Ben
bits,
because
one
of
the
things
that
scares
me
about
quick
v1
is
that
we
are
going
to
have
a
lot
of
version
negotiation
experience
with
the
implementations
that
we've
done
here,
because
we're
doing
version
negotiation
as
part
of
our
interrupts
testing
and
there's
not
going
to
be
a
lot
of
exercise.
S
The
first
negotiation
mechanism
in
the
wild
so
having
to
like
I've,
been
saying
for
a
while.
We
need
to
have
two
separate
versions:
I
thought
those
were
quickly
one
and
quick
v2,
but
maybe
they're,
quick,
v1
and
quickly
one
spin
right
like
so.
We
get
to
kill
two
birds
with
one
stone
here
and
that's
seems
efficient
to
me.
S
The
network
operator,
who
is
deploying
boxes
that
will
let,
through
quickly
one
spin
and
not
quick
v1,
who
actually
wants
the
visibility
that
you
get
by
looking
at
TCP
and
isn't
just
blocking
quick
to
go
to
TCP,
is
not
doing
the
right
thing
for
their
goals.
Right,
I.
Think
the
the
risk
of
blocking
quick
v1
in
in
favor
of
quick
v1
spin
is
so
much
less
than
the
risk
of
just
saying
it.
We're
gonna
block
and
go
with
UCP
that
it's
not
sure.
A
A
R
A
B
It
must
be,
it
can't
be
before
right,
because
it's
requires
we
want
to
be
done,
but
so,
if
we've
all
needs
to
basically
be
done
and
then
because
this
is
gonna
be
a
DIF,
that's
says
you
know
you
take
me
Vaughn.
This
is
the
new
version,
and
then
you
spin
stuff.
So
so,
therefore
you
know
it's
in
hand
or
after
so.
P
P
P
If
we
don't
need
one,
then
there's
no
point
in
putting
it
in
there's
no
point
in
having
a
sever
version
and
if
we
do
need
one
all
arguing
a
second
at
a
separate
version
is
stupid,
but
but
to
make
that
set
reverse
to
me
even
to
make
this
upper
version
thing
be
plausible.
We
have
to
make
sure
that
we
really
room
in
the
header
to
flip
those
bits
and
we're
not
screwing
around
with
this
bit.
P
We
don't
like
colonize
these
bits
in
you
know
in
v1,
and
so
I
like
just
don't
see
much
material
difference
between,
but
between
the
war.
The
worth
or
working
will
have
to
do
in
the
like
in
the
in
the
case
where
it
goes
in
v1
and
the
case
where
there
was
a
separate
version,
if
no
one
gives
it
shoulda
been
passed,
signaling
at
all,
because
the
VESA
fine,
these
are
the
bits,
is
not
difficult
separately.
P
If
we
do
think
it's
important
to
have
a
new
tab,
I
split
indications
on
the
wire
like
please,
let's
not
do
a
separate
version
like
the
idea
we
have
to
have
like
orthogonal
like
if,
like
a
comment
or
explosion
of
versions,
every
tiny
interesting
feature
like
is,
if
I
can't
reveal
features
just
crazy.
That's
why
wait?
That's
why
we're
doing
a
version,
except
is
it
version,
the
extension?
Sorry,
an
extension
negotiation
mechanism
in
the
first
place?
This
is
a
classic
use
of
why
you
want
to
set
your
negotiation
if
we
want
to
have
like.
P
AW
Rogovin
first
of
all,
3b
is
still
experimental
and
I
was
not
sure
if
I
understand
that,
because
is
it
a
regular
version
understandable,
it
would
be
a
different
transport
version
or
is
it
be
an
experimental
RFC?
That's?
Why
is
it
tree
B
and
not
a
separate
item?
That's
just
to
preserve
the
numbering,
so
people
don't
get
confounded
now.
A
AW
A
AW
Point
of
view
two
and
three
B
are
okay.
The
reason
for
three
did
the
experimental
I
think
that
we
are
talking
here
about
the
transport,
but
this
transport
is
typically
some
other
standard
body
are
defining
what
transport
are
used
Internet
and
they
will
reference
such
documents
and
they
can
reference
the
document
that
we'll
have
without
spin
bit
or
we
spin
bit,
but
they
need
the
document
to
reference
for
that
and
and
I
assumed
that,
when
three
B
we
means
that
it
would,
they
will
progress,
they
empower
and
they're,
not
sequentially.
AW
AE
Anger
so
I
think
that
three
B
is:
there
are
a
lot
of
dragons
lurking
in
there
which,
like
it
seems
quite
simple,
as
is
described,
but
it's
actually
like
probably
way
more
complicated.
It's
not
as
simple
as
the
mechanism
Brian
described
in
his
draft
of
like
just
look
at
the
five
double
and
you're
done.
You
have
to
maintain
a
lot
more
state
for
that
so
like
before
anything,
you
need
to
see
what
the
solution
isn't.
AE
Iron
out,
older,
dragons
and
I
think
that
anything
that
we
do
even
for
a
separate
version,
I
think
if
the
if
a
metal
box
is
going
to
look
at
it,
it
will
practically
have
to
be
an
invariant
and
since
it
has
to
be
an
invariant
I'm
kind
of
opposed
to
the
idea
of
putting
an
experimental
thing
inside
an
invariant,
and
so
this
is
like
a
circular
argument
here.
But
I
think
that,
as
has
proved
like
this
cannot
be.
This
cannot
be
a
separate
version
and
this
cannot
be
an
advantage.
AE
W
Right
Google
I,
wanted
to
address
Marie's
comment
about
the
extra
round
trip.
I
was
gonna,
say
that
and
in
practice
I
expect
most
experiments
at
least
initially
to
use
the
L
surfers
advertisement
mechanism,
and
so
the
peer
would
just
learn
about
it
by
HTTP
and
then
like
do
it
the
first
time.
Basically,
we
just
not
do
it
once
I,
don't
like
there'd,
be
actually
any
any
practical
hit
on
user
experience
and
then
on
the
the
idea
of
negotiating
extensions.
W
The
extension
negotiation
mechanism
that
I'd
have
in
mind
is
encrypted
because
most
the
extensions
I
want
to
do
are
I
want
to
be
entirely
encrypted,
and
so
I
don't
really
want
to
use
that
extension
negotiation
mechanism
to
negotiate
something
that
is
outside
the
encrypted
envelope.
That
seems
weird
to
me
so
I
mean
we
could
do
that.
But
the
point
here
is
that
like
actually
give
the
path
information,
so
why
are
we
trying
to
do
that
negotiation
in
encrypted
way,
when
the
whole
point
is
to
give
the
path
information?
Thank
you.
AI
We
mean
former
lunch,
so
I
support
them
should
do
a
story
searching
too
because
it
will
ease
the
words
we
forgot
to
participate.
You
so
interrupt
day
on
so
on,
because
currently
we
have
a
separated
code
for
the
spin
be,
and
so
it's
very
tricky
to
to
make
interrupts
test.
This
is
a
result
of
the
jacket
on
here.
We
have
separate
table
on
it,
so
we
were
trying
to
put
the
spin
beating
all
the
reversion
under
agitating
times
as
a
developer
or
implementing
a
new
version
on
the
quick
tables
or
trouser.
AS
You
Sanjay
Mishra
Verizon,
some
are
going
back
to
your
question
about
earlier.
You
asked
that
you're
not
heard
as
much
about
this
structure
around
why
you
need
in
v1,
so
I
think
really.
The
the
question
is
that
the
deployability
and
manageability
they
kind
of
go
hand
in
hand.
So
if
we
are
looking
to
standardize,
quick
and
deployed
in
the
network
that
allows
operators
to
maintain
the
same
level
of
service
as
they
do
today,
you
really
need
to
consider
that
the
immense
ability
aspect
as
we
deploy
quick.
AS
So
if
that
goes
with
v1,
then
we
stick
with
v1
and
I'm,
not
really
sure
of
having
a
3
B
option
really
helps
so
I
think
I
would
stick
with
where
we
are
and
as
Brian
earlier
said,
that
you
know
the
implementation
itself
was
not
a
really
big
sort
of
adding
to
the
structure
of
the
of
how
long
it'll
take
to
add
this
thing.
So
we
should
be.
We
should
be
able
to
add
this
into
the
current
release:
I'm,
not
really
sure
about
the
3,
B
and
unfortunately
I'm.
AS
A
So
we're
gonna
take
a
slightly
different
tack.
Can
we
see
a
show
of
hands
in
the
room
of
who
is
implementing
quick?
Now,
ok,
keep
them
up,
but
if,
if
the
spin
bit
were
to
magically
appear
in
our
specification
tomorrow,
would
you
would
your
implementation
be
emitting
and
honoring
that
part
of
the
specification?
If
it
would
please
keep
your
hand
up
if
it
would
not?
Please
take
your
hand
down
okay,
so
there's
some
wavy
hands
that
aren't
sure
good,
there's
a
hand
back
there
and
there's
a
hand
here
which
are
the
same
hand.
A
A
The
we
tried
to
filter
that
out.
We
I
think
we
mostly
filtered
that
out.
So
there
there's
some
interest
from
implementers
in
at
least
experimenting
with
this.
We
had
a
back
and
forth
about.
You
know
how
we
would
do
this
with
it.
As
an
extension,
it
sounds
like
there
are
more
questions
that
that
brings
up
where
we're
not
really
sure
that
that's
a
viable
path
forward,
so
I,
don't
really
think
we
can
make
a
conclusive
choice
about
that.
Now.
If
we
were
to
land
Brian
is,
is
your
pole
request
still
clean?
A
Okay,
all
right,
so
one
thing
we
could
do
is
land
your
PR
and
have
some
experimentation,
see
how
many
people
actually
emit
and
work
with
it
in
the
next
few
months
and
make
that
part
of
the
implementation
draft
goals
and
then
evaluate
that
later
on
and
make
a
decision
about
whether
it
remains
in
the
draft
and
I
want
to
so
I
want
feedback
to
that
approach.
Now,
I
would.
S
That
seems
like
a
good
approach
going
for
hi
Brian
Trammell.
That
seems
like
a
good
approach
going
forward.
One
other
thing
that
I
heard
in
the
room
is
that
there
is
tied
to
the
emerging
consensus
around
encrypting.
The
packet
number
there
seems
to
be
a
lot
of
support
for
Veck
and
I
would
volunteer
to
do
another
PR
to
add
the
vac.
We
write
when
the
when
a
encrypted
packet
number
lands
for.
S
A
So
same
question:
if
you're
an
implementer-
and
we
did
it
some
time
in
the
future,
would
you
admit
these
bits?
I
see
wavy
hands
from
from
the
Google
guys
at
front
and
a
wavy
hand
from
Akamai
still
and
still
a
little
strong
hand
from
Microsoft
and
a
wavy
hand.
So
I
did
same
set
of
hands.
I!
Don't
think
that
change
it
moves
the
needle.
Please
go
quickly
run.
AW
Even
I
think
I
think
that
the
problem
is
that
the
ones
who
are
once
it
are
not
the
one
that
implemented
the
client-side
will
tell
the
one
to
transit
the
network
and
eventually
they
will
ask
for
that
fro
from
the
product
either
by
specifically
asking
or
by
blocking
I
mean
that's
what
will
happen.
So
you
can
say
you
don't
want
to
implement.
It
doesn't
mean
much,
it
depends
what
will
happen
actually
in
the
networks
once
it
started
to
be
more
deployed.
R
Jamming
got
editor
hat
on.
This
will
make
life
very
difficult,
not
just
in
terms
of
managing
the
text,
but
in
terms
of
mechanisms
we
I'm
really
hoping
that
after
the
idea
of
East
are
you
know
getting
into
the
packet
number
encryption
issue
and
try
to
land
a
solution
to
that
this
sort
of
stalls
everything
up
until
we
can
resolve
it.
I
we're
talking
about
resolving.
A
R
A
Q
AR
AF
A
B
Okay,
large
logs
I
get
from
the
floor
and
not
as
chair
but
sort
of
what
you
proposed
or
I,
think
what
I
heard
you
propose
actually
changes,
how
we
work
right.
We
we
don't
land,
PRS
and
then
on
land
up
which
try
hard
to
get
consensus
for
the
PRS,
and
once
we
have
consensus,
we
land
them
in
just
because
what
Martin
and
John
are
set
right.
It
becomes
really
difficult
to
do
the
unlearning
and
so
I
object
that
we
change
the
process
that
we
have
in
the
working
group.
A
Hard
topic,
so
one
thing
we
could
do
is
to
address
that.
One
thing
we
could
do
is
leave
a
couple
of
combination
approach,
I
suppose
we
could
reserve
a
few
bits,
have
a
separate
document
that
describes
how
to
use
those
bits
and
if,
at
the
end
of
our
process,
we
agree
that
this
is
indeed
useful
and
and
is
actually
getting
an
implement
or
take
up.
We
can
incorporate
that
into
the
spec
before
chips
is
v1.
AP
R
Very
quickly,
this
just
changed
the
equation
on
my
mind,
because
I
think
this
means
that
we
are
gonna
actually
discuss
in
bit.
Issues
now
between
now
and
November.
Quite
a
bit.
I
just
want
to
make
everybody
in
the
room
aware
of
that
fact
that
you're
gonna
have
to
not
just
identify
issues
with
this
particular
proposal.
They're
gonna
have
to
try
to
solve
them
right.
A
So
I
think
that
as
I
understand
it,
the
two
possible
paths
forward,
art
and
defer,
put
in
a
spin
bit
in
v1
or
to
reserve
a
few
bits
have
a
separate
document
with
the
idea
that
if
we
prove
it
as
a
viable
thing
that
gets
implementation,
support
and
and
and
we'll
probably
have
to
have
a
rough
consensus
further
down
the
path.
We'll
fold
that
separate
document
into
quick
v1.
Does
that
sound
like
the
two
options
we
have.
B
N
B
AR
AJ
AA
AR
Since
the
RFC
on
what
we
weren't
pervasive
encryption
being
an
attack
was
published.
I
would
like
to
thank
the
working
group
for
that
and
I
would
like
to
thank
the
chairs,
especially
for
that,
because,
even
though
all
the
transport
working
group
chairs
take
a
lot
of
crap,
these
guys
managed
to
still
stand
out.
So
I
would
like
to
thank
you
all
for
that.
AR
B
Out
some
water,
so
I
would
summarize
this
meeting
today
as
sort
of
it's
it's
very
clear.
It
is
enough
interest
from
a
variety
of
people
to
use
the
spin
bit
and
understand
what
it's
good
for
and
and
and
learn
more
about
it
that
I
think
sort
of
the
option
for
right,
no
spin
bit
ever
I
think
rather
than
those
movie
one
I
think
that
is
out.
I
also
think
the
option
wants
limited
invariance
is
sort
of
out
right.
So
that's
that's!
A
S
N
Q
A
A
If
he's
willing,
spin
up
a
separate
document,
we
will
talk
to
implementers
and
then
put
that
the
use
of
that
document
on
the
implementation
drafts
as
a
goal,
not
a
required
goal,
obviously,
but
we'll
try
and
encourage
the
implementers
to
experiment
with
it,
and
we
will
at
some
time
later
this
year,
revisit
this
whole
well
I
say
later
this
year,
assuming
we
do
everything
else
on
time.
We
will
revisit
this
issue
and
we'll
have
this
whole
conversation
again
about
incorporating
that
document.
Based
on
that
experience,
we
had
okay,
that's
off.
Q
A
M
B
N
B
R
R
S
AJ
AL
AR
AR
AK
AM
A
Friend,
thank
you
and
finally,
if
none
of
those
is
satisfying-
and
you
think
that
we
don't
know
yet
or
we
need
to
do
something
else-
option
C,
please
hum
now.
Okay,
that's
really
great!
Thank
you!
So
much
so
we
have
a
path
forward
for
the
spin
bit.
Of
course,
we're
gonna
have
another
lovely
conversation,
probably
in
Bangkok,
so
yeah.
So
thank
you.