►
From YouTube: IETF105-QUIC-20190724-1000
Description
QUIC meeting session at IETF105
2019/07/24 1000
https://datatracker.ietf.org/meeting/105/proceedings/
C
Hello,
everyone
we're
going
to
get
started,
we're
just
dealing
with
a
few
technical
issues
up
here.
Please
have
a
seat
or
take
your
side
discussions
to
the
hallway.
This
is
quick
our
second
session
for
the
week,
if
someone
could
close
the
doors
in
the
back
that'd
be
fantastic.
Oh
thank
you.
We
need
someone
to
take
minutes
today.
Do
we
have
any
volunteers?
I
know
you're,
bright-eyed
and
okay.
Brian
Trammell
is
exempted
because
he
did
such
a
fantastic
job
yesterday
even
minuted
in
a
foreign
language
which
is
fantastic.
C
Chris,
but
thank
you
very
much
here,
you're
a
gentleman,
so
please
do
it
in
the
Java
channel
and
if
folks
could
help
him
out
by
correcting
or
elaborating
more
necessary
or
or
capturing
things
that
he
fails
to
capture.
That
would
be
very
helpful.
Sorry
I'm
not
either
pad
I'm
sorry
on
the
either
pad.
If
you
could
refrain
from
translating
it
to
another
language,
we
would
very
much
appreciate
that.
C
So
this
is
our
second
session.
The
blue
sheets
will
circulate
the
blue
sheets
at
the
moment.
We
have
a
scribe
note.
Well,
we
can
get
from
the
screen
actually,
as
we've
said
so
many
times
before.
These
are
the
terms
under
which
we
participate
here
in
the
ITF
regarding
things
like
intellectual
property,
regarding
things
like
professional
behavior,
would
you
take
these
seriously?
So
please
familiarize
yourself
with
these.
C
If
you're
not
already
aware
sorry
yeah
agenda
bashing,
today
we
are
going
to
continue
to
go
over
the
issues
against
the
base
traps,
especially
the
the
virginal
ossification
and
the
other
issues
we
deferred.
Yesterday,
then,
as
time
permits
we're
going
to
talk
about
the
recovery
draft
and
the
HTTP
draft,
if
we
could
Reserve,
we
had
a
side
meeting
this
morning
with
some
HTTP
folks,
I'd
like
to
reserve
about
10
or
15
minutes
to
have
a
discussion
about
HD
through
our
priorities.
So
we'll
make
sure
to
do
that
before
the
end.
D
Krista,
let's
like
make
a
quick
announcement
with
Antwon
LaVon
for
Microsoft
Research
we're
preparing
a
workshop
for
Bulls
before
and
ESS
this
year,
focusing
on
quick
security
and
privacy.
Hopefully
that
will
be
accepted
and
and
that'll
be
announced
sometime
mid-september
and
the
workshop
usually
takes
place
sometime
in
February.
So
if
you
know,
if
anyone
runs
a
family
who
are
working
on
this
particular
issue,
please
encourage
them
to.
You
know,
continue
that
work
and
then
bring
it
to
the
workshop.
D
C
C
E
Yes,
David
Skinner,
Z
cool,
so
I
applied
the
changes
that
we
discussed
yesterday
to
the
PR
I
saw
at
least
one
comment
saying
that
it
addressed
consider
the
concerns
were
resolved.
What
do
people
think
now,
mainly
it's
yeah,
changing
the
must
to
assured
and
adding
a
sentence
saying
like
you.
This
breaks
these
features,
and
so
you
must
not
do
this
unless
you
know
that
those
are
not
in
use.
F
C
Do
that
today,
so
what
we
might
do,
then,
is
wait
about
another
week
and
you
can
have
something
discussion
on
the
issue
and
then,
if
things
look
settled
there
we'll
go
ahead
and
issue
that
the
consensus
call
after
that
make
sense.
Okay
and
and
again
a
reminder
of
the
acoustics
in
this
rumor
or
horrific.
So
please
speak
distinctly
and
close
to
the
mic
that
you
can
anybody.
A
A
C
C
F
G
E
H
The
the
message
here
is
that
there's
a
cluster
of
issues
that
are
all
all
around
this
and
we
will
be
reopening
some
and
all
the
ones
that
fall
into
this
bucket
revisit
initial,
this
key
discards,
the
unrecoverable
loss
pattern,
one
and
even
potentially
the
timing
side
channel
one
will
be
resolved
at
the
end
of
this
thing.
But
at
the
moment
it's
gotten
worse,
not
better
can
can
any
always.
H
C
H
C
H
H
I
E
You
and
just
one
last
thing
on
the
discard
keys,
I
reaiiy
unarchive,
the
discard
keys
channel
on
slack
I
will
be
coordinating
see
if
we
can
meet
in
person
during
this
week
and
they
clog
us
there
with
the
design
team.
So
whoever
wants
to
be
part
of
that
send
a
message
on
the
discard
keys
channel
aside.
C
C
F
You
can
see
the
first
step
in
bringing
personification
is
use
Comic,
Sans,
Christian,
women
Christian.
We
know
that
kazuo
and
I
sat
down
and
tried
to
work
on
this
problem,
and
this
staff
is
more
like
a
problem.
Sorry,
this
is
this
presentation
like
a
problem
statement
than
it
is
like
a
solution:
I
try
to
present
credit
and
the
problems
and
I
walk
through
all
the
horrific
ideas
we
had
to
try
to
fix
them,
then
up
which
are
really
good.
So
maybe
someone
this
room
will
have
a
better
idea
next
slide.
F
So,
okay,
there's
the
high
level
problem,
but
the
version
is
like
right
there.
It's
like
an
invariant,
it's
in
the
header.
It's
like
fights,
you
know
it's
bite,
bytes,
1,
2,
5
or
0
2,
or
you
know.
However,
you
count
it
to
2
to
6
I,
guess
it's
2
to
5
and
so
like
what
happens
if
middle
boxes
start
rejecting
anything
with
a
long
header.
F
This
is
version
1,
which,
like
is
not
entirely
out
of
the
question,
given
that
we've
already
established
lots
other
stuff
that
looks
like
this
a
pattern
matching
that
would
obviously
make
it
hard
to
deploy.
Quick
version
do,
and
you
end
up
with
some
version
of
world
where,
like
you,
can't
do
that,
so
that
would
be
sad,
I
suppose
we
can
always,
as
usual,
stuff
the
version
somewhere
else
like
we
are
what
to
do
but
like
that
was
annoying
Els.
So
maybe
one
ought
to
do
it
again
next
slide.
F
So
the
first
thing
we
did
was
trying
to
sit
back
and
say
like
what's
the
threat
model
for
this
like-
and
this
is
basic,
an
attack
by
the
middle
box
is,
let's
be
clear.
So
what's
our
threat
model
for
the
middle
boxes
and
we
searched
I'd
like
there
to
kinds
of
my
front
models
like
one
is
implementers
are
like
really
like
really
pretty
Lindsay
right,
like
they
don't
really
read
this
back.
F
They
just
sit
there
with
like
TCP
dump
and
they're
like
oh
well,
like
all
these
packets
out
like
one
here
so
I
guess
it
must
be
one
a
might
like
check
the
quick
bit
and
make
sure
the
version
and
maybe
either
do
dependent
on
a
panel
situation.
Maybe
they
do
state
enforcement,
so
they
say
well,
if
I
have
you
know,
I
have
NAT
state
or
some
other
kind
of
state
for
this
host
port
quartet
then
I
do
then
I
check
the
version,
but
otherwise
I,
don't
that's
like
a
pretty
pretty
common.
F
They
do
is
pull
check
on
the
opening,
but
on
the
rest
of
the
thing.
So
it's
like
version
1
and
like
it's
not
you
know,
motivations
very,
but
those
are
people
aren't
trying
very
hard
on
the
other
end
or
people
were
like
trying
really
hard
right.
Like
read
the
whole
specification,
we're
actually
trying
to
stop
you
from
deploying
the
next
version
hum,
and
we
certainly
have
seen
this
somewhere
TLS
or
people
were
like
well
I.
F
Don't
want
you
to
point
on
this
version
and
and
they're
only
do
essentially
an
arbitrary
amount
of
work,
and
so
that
in
particular
means
like
any
anything.
We
stick
in
this
back,
like
they're
gonna
know
about
so
these
things.
So
one
of
these
we
have
in
the
spec
now
is
we
have
every
version.
F
Has
this
this
encryption
of
the
initial
data,
but
then
curse
is
based
in
a
fixed
key,
which
is
the
spec,
so
they're
gonna
know
about
that
and
they're
gonna
know
that
if
we
change
it
that
it's
different,
so
first
we
just
I
put
a
front
model
is
by
the
way
you
feel
free
to
jump
in
at
any
time.
This
is
we're
almost
tutorial.
I
mean
nature,
anything
else,
because
what
you
need
to
do
in
order
defend
against
these
people
is
like
extraordinarily
different,
next
slide.
F
So
the
good
news
is
the
lazy.
Implementers
thing
is
actually
like
pretty
easy
and
David
Benjamin
can't
see
movies
here,
I'm
floating
a
bunch
of
ideas
for
dealing
with
this
in
CLS.
You
can
see.
Malarkey
is
here
so
the
first
thing
to
do
is
like
get
them
get
the
explicit
version
out
of
the
header,
because,
like
that's
the
source
of
the
problem,
I
mean
you
could
also
leave
it
there
and
have
it
be
one
all
the
time
to
have
to
dumb
you're
just
wasting
bytes.
F
It's
like
effectively
getting
a
header,
and
then
you
have
like
a
bunch
of
versions,
a
bunch
of
versions
of
figure
out
what
the
version
is,
that
more
or
less
depend
yeah,
you're
feeling
bad
now,
aren't
you
David
I
can
see
it
and
the
other
bunch
of
options
that
basically
depend
on
knowing
what
the
spec,
what
the
deals
the
spec.
So
maybe
you
remove
version
nine
use,
travel
encryption
based
on
the
perspect
seed
value.
You
replace
the
version
with
like
a
mass
version,
which
is
like
again,
the
perversion
see.
F
Is
the
person
see
value
another
session
would
have
the
server
pride
like
an
alternate,
be
an
another
connection
like
all
these
are
like
trivial,
easy
to
circumvent,
if
you
actually
for
the
specification
so
like
first
of
all,
you
can
just
ignore
the
version
number
just
travel
too
quick
for
the
potential
version
and
it's
like
the
thing
comes
up
and
it
looks
like
a
quick
packet
and
it's
like
properly
formatted,
then
you're,
pretty
sure
you
do
the
right
thing
and
if
it
didn't,
then
it's
garbage
next
Martin.
D
Duke
f5
I'm
not
convinced
that
the
third
option
there
is
that
easy
to
circumvent
so.
F
There
are
two
versions,
the
third
option,
one
of
which
is
where
you
provide
an
alternate
version
and
the
others
by
the
alternate
version
and
an
alternate
seed
right.
If
you
don't
play
all
for
the
C,
is
a
trivial
right.
If
you
don't
provide
an
alternate
version,
then
then
I
think
the
most
likely
outcome
is
that
most
sir,
that
a
lot
of
servers
are
not
alternate
versions
and
what
the
attackers
do
is
they're
just
like.
F
Well,
we
only
let
version
one
through
and
then
basically,
people
are
gonna
have
to
be
willing
to
fall
back
to
version
one
and
it
of
an
equilibrium
where
we're
basically
repeating
connections,
don't
work
properly
or
they
fall
out
ccp.
So
so
I'm
not
entirely
sure.
It's
true,
but
I
think
it's
a
plausible
if
they're
working
there,
but
he
I
agree
it's
a
somewhat
different
situation
in
situation,
but
he's
other
ones
obviously
trivial
to
get
house.
Okay,.
D
F
Yeah,
maybe
I
think
some
of
the
other
vert
someone,
the
more
aggressive
versions,
don't
have
that
property
necessarily
okay,
but
I
mean
like
let's
I
guess,
but
yes
right,
there's
a
sliding
scale
of
a
region
of
pressure
that
goes
from
like
nobody
does
it
some
people.
Do
it
all
the
time
they're
with
us
all
the
time
right
and
so
the
more
you
get
towards
the
right,
the
more
pressure,
the
harder
it
is,
the
ossification
but
yeah
Roberto.
J
Very
young
there's
one
other
thing
that
is
interesting
here,
which
is
not
necessarily
preventing
ossification
as
a
first-order
effect,
but
preventing
loss
if
ocation
by
letting
everybody
know
something
is
preventing
them
from
upgrading
I,
believe
that
you
know,
we've
talked
about
having
version
inside
of
things
before,
but
it's
interesting
to
have
it
both
inside
and
outside.
So
the
network
can
respond,
because
that's
why
you
have
it
externally,
and
so
you
can
record
and
report
and
accuse
by
having
it
interview.
K
Directly,
so
gory
Fair
has
the
two
things
when,
when
we
want
to
deploy
a
new
version
of
something
in
the
network,
often
we
want
to
know
the
new
version
exists
to
do
good
stuff
to
let
that
traffic
through
to
classify
measurements
from
one
versus
the
other.
If
we
close
that,
then
we
close
an
opportunity
to
deploy
new
versions.
K
F
I
mean
definitely
the
challenge
in
front
models,
totally
legit,
I
think
by
and
large
in
the
front
all
those
group
is
adopted,
but
people
can
correct
me
is
that,
like
we
should
be
treating
the
middle
boxes
the
greatest
and
possible
as
a
dumb
pipe
and
like
trying
to
avoid
them
looking
at
data
and
so
and
not
being
pretty
good
sympathetic
to?
Maybe
if
they
knew
there
is
more
version
information
they
would
do
better.
But
again,
that's
a
question
for
the
group
on
the
certainly
you're
right
that
the
outer
version
goes
ossify.
F
K
F
I
can't
speak
to
that
intelligently,
so,
like
I,
say
with
number
options.
If
we're
willing
to
just
deal
with
lazy
implementers
for
her
working
implementers,
you
either
client/server
to
share
some
kind
of
secret
information.
Somehow
there's
no
way
around.
As
far
as
I
can
tell
that
was
the
consensus
of
like
a
Christian
and
cuz.
You
hold
up
myself
next
slide.
F
So
sorry,
I'd,
like
for
I,
do
these
slides
a
while
ago.
You
showed
me
the
slide
of
this.
Just
so
I'm
like
or
get
you
some
oriented,
okay,
good,
okay,
so
I
mean
the
bottom
line
is
I.
You
have
to
equip
the
initial
somehow,
and
so
the
there's
a
number
of
possible
ways
to
do
this.
One
is
to
use
this
there's
this
detail
about
trial,
decryption
or
separately
encrypting.
F
The
version
number
that's
like
a
really
boring
crypto
detail,
because
I'm
not
gonna,
bother
you
with
right
now,
there's
the
variants
where
you
deliver
the
key
in
yes
and
I.
This
is
very
analogous
records.
De
France
were
to
look
at
the
key
like
in
the
previous
connection,
and
so
that
goes
back
to
the
point.
Martin
Duke
was
making
I
think,
but
the
bottom
line
is
you've
gotta,
like
encrypt
the
damn
thing,
with
a
key
that
life
is
not
known,
not
known
at
none
available
in
the
box
or
they're
just
going
to
equip
themselves.
F
So
this,
obviously,
is
you
for
what
happens
in
cases
with
secrets
and
available.
So
now,
in
the
case
of
DNS,
yes
and
I
style
approaches,
the
secret
isn't
available,
typically
on
a
per
server
basis
that
it
servers,
may
not
publish
it
in
the
case
of
the
case
of
the
subsequent
conversion.
Obviously
it's
key
very
common.
The
secret
will
be
available
numb.
What
do
you
do
and
so
that
that's
one?
Hence
my
concern
about
its
first
connection
for
subsequent
connection,
our
certification
wears
in
the
SLI
style.
It's
more
work,
but
you
get.
F
You
know
you
get
foot
you
get.
You
get
a
randomized
version
from
minute:
zero.
It's
not!
Obviously
the
case
you
could
try
doing
both
of
these.
You
could
try
doing
you
know
you
could
try
doing.
You
can
have
basically
a
standard
way
to
reach
this
end
result,
and
then
you
can
have
something
going
connection,
NES
and
ice
town.
The
same
people
discussed
one
point
Christian
visionary
discussion.
This
is
like
more
than
like
the
sort
of
trend
here
the
trend
here.
F
If
you
follow
this
line
of
reasoning,
it's
just
completely
shut
the
middle
box
out
as
much
as
you
possibly
can,
so
they
can't
even
read
for
missionary
initial
and
so
as
Corey.
What
you're
saying
we're
the
deployment
implications
of
doing
that?
If
you
just
say
like
look,
you're
a
dumb
bit
pipe
stay
out
of
my
way,
I'm
something
we
have
to
consider
in
any
case
next
slide.
F
This
is
a
fine
technical
point,
but
I
know
there's
concerns
when
this
was
initially
raised
at
the
sort
of
cost
of
having
yet
another
publication
for
for
this,
the
so
yes
and
I
obviously
use
the
public
key,
because
you
have
to
worry
about
disclosure
of
the
si
key.
F
It's
possible
you
could
snake
out
here,
which
is
a
symmetric
key
that
was
delivered
either,
which
delivery
or
in
band
on
previous
connections
or
in
DNS
record,
and
the
rationale
for
this
is
that
it's
a
gun
or
miss
I'm,
going
to
work
for
the
for
the
for
the
middle
box
employed
like
that
pull
the
side,
the
DNS
will
make
their
own
connection
and
get
the
information.
That's
try
to
try
to
do
things,
and
that
seems,
like
maybe
it'd,
be
something
almost
nobody
willing
to
do.
F
F
Yeah,
that's
true,
so
right
next
slide,
so
there's
one
other
suggestion
that
kazoo
heard
floated
that
was
sort
of
our
final
of
this,
but
might
be
a
way
to
deal
with
this.
It
didn't
have
all
these
sort
of
crazy
things
with
initial,
and
that
was
what
he
was
calling
mid
connection
greasing.
F
So
the
idea
is
that
you
allow
people
to
send
along
hunter
packets
during
the
connection
and
under
those
the
version
of
Burton
obviously
be
random
appearing
and
of
gender
if
some
protection
secret,
this
probably
is
lazy
implementers,
like
obviously
whether
that
work
depends
on
sites
really
doing
it.
I
think
my
concern
when
he
waged
this
was
it
doesn't
work
properly
if
sites
like
basically
only
do
version
enforcement
for
the
first
packet,
it's
nothing
the
state
table
so
and
I
guess.
Thank
you
for
putting
this
in.
F
You
can
do
force
migrations
to
in
order
to
like
sort
of
pull
the
state.
People
away
is
one
possibility,
but
again,
let's
go
got
two
more
induce
question
of
like
how
well
doesn't
that
hasn't
work
and
how
much
work
do
people
have
to
do
to
it
to
get
like
an
te
ossification
defenses.
So.
H
The
other
observation
here
is
that
this
sort
of
goes
back
to
that
really
old
issue.
Where
someone
said
make
connection
establishment.
Look
like
migration,
you
can.
You
can
imagine
this
being
you
send
long,
header,
packets
in
front
of
those
migrations
and
and
that
further
off
supplies
the
protocol
and
in
in
a
different
way
in
that
yeah.
This
tell
us
the
pattern
that,
if
you're
sending
the
first
packets
or
the
first
datagrams
on
a
path
have
long
header
packet
in
them
and
that's
not
something
that
we've
ever
promised
yeah
so
yeah,
so
Roberto
says
every
other.
F
Next
slide
right
so,
as
I
said
beginning,
this
is
like
not
like
a
great
situation.
If
we're
willing
to
say
look,
we
just
care
about
people
we're
all
we're
trying
to
do
is
stop
people
who
are
like
two
incompetent
to
like
read
the
specifications
and
know
the
invariants
are
then,
like
you
have
a
number
of
options
that
are
like
you
know.
We
can
decide
between
right
and
they're,
largely
pretty
easy
on
some
of
them
may
grow
card.
F
Then,
in
the
variants
a
little
bit
like
to
make
the
pig
version
over
out
or
to
like
mask
personal
things,
but
maybe
not
depending
which
one
you
choose
on
on
the
prettiest
hard-working
bonus
like
he's.
Getting
a
lot
harder
and
is
gonna
almost
certainly
acquire
change
their
instance
pretty
nasty
ways.
F
It
also
involves
some
there's,
which
particular
version
you
choose
involves
and
trade-offs
depend
on
how
well
it
works
and
whether
and
basically
how
much
packet
boat
you
introduce
versus
versus
how
much
work
the
the
server
has
to
do,
determine
which
version
you
have
so
just
to
give
you
a
sense
of
this
trial.
Decryption
has
less
back
upload
button
curtain,
the
curtain
sequence
number
special,
so
version
numbers
faster.
So
so
first
you
decide
like
what,
like
that.
Our
objective
is
here
before
we
like
actually
try
to
engineer
a
solution
hum.
L
Hey
Mia
could
have
been
so
for
me,
this
all
breaks
down
to
whatever
we
do
is
like
just
increasing
the
load
or
the
work
that
somebody
has
to
do
to
try
to
to
break
this,
which
also
means
increasing
the
load
on
the
server
or
on
the
receiver.
Basically
and
like
I
would
actually
think
that
this
is
like
even
worse,
because
in
many
situations
you
might
have
a
minute
middle
box
which
is
somewhere
in
the
excess
network
and
has
like
very
few
quick
connections
to
handle,
while
the
server
can
have
very
many
quicker
connections
to
handle.
L
So
there
is
like
there's
a
big
performance
implementation
here
and
I'm,
not
sure
if
it
worse
is
to
go
down
this
way.
Given
that
I'm
you're
also
uncertain
about
this
red
model
and
we
uncertain
about
what
the
risks
are
for
me,
it
would
be
really
more
important
that
we
have
a
way
out
if
we
find
this
happening
at
some
point,
and
there
is
a
way
out
in
the
next
version,
which
will
be
like
an
overhead.
It
has
a
cost,
but
as
long
as
we
have
a
way
out,
that's
important
right
for
me.
So.
F
What
actually
sure
that
we're
materially
increasing
the
cost
on
either
the
server
deployment
on
memory
designs,
basically
round
up
to
like
one
or
two
more
cooperating
more
symmetrical
operations,
so,
in
particular,
if
you
only
support
one,
if
you
only
support
one
version
and
they
clipped
across
as
identical,
it's
only
becomes
upon
the
matter
which
one
of
these
effectively
issues
so
I'm,
not
sure.
Actually,
I
changed
the
load,
depending
on
which
one
you
choose
then
eventually.
C
M
M
N
David
Benjamin,
so
I
think
there's
a
second
thing
that
we
should
do
a
second
like
access.
We
should
be
considering
in
front
model,
which
is
whether
or
not
I
mean
I.
Guess
it's
kind
of
lazy
and
hard
working,
whether
or
not
these
middle
boxes
can
get
updated
because
for
chillest
1
3,
the
big
problem
is
not
just
that
the
middle
boxes
had
all
supplied
everything
and
done
everything
wrong,
but
that
they
couldn't
ship.
The
update
till.
O
N
F
Thank
you.
It's
good
I
mean
my
basic
assumption,
as
you
say,
is
that
well
have
some
class
and
little
boxes.
You
can't
get
updated
and
then
I
think
this
I
mean
this
meshes.
Not
it
I
say
more
in
Dukes
point
about
like
how
much
commitment
do
we
have
to
like
how
much
sort
of
installed
base
of
people
who
are
exercising
these
functions?
Do
we
have
to
have
before
it
becomes
unprofitable
thing
boxes
to
ossify
in
these,
but
on
these
properties.
J
It's
my
personal
belief
that
protecting
against
the
lazy
implementers
is
good
and
we're
missing
by
the
way
at
the
lazy,
endpoint
implementers
they
exist,
and
but
but
I
do
think
that
it's
important
to
think
about.
The
second
aspect,
which
is
I,
believe
that
hard-working
implementers
are
going
to
do
their
right
thing.
They're,
gonna,
intercept
things,
that's
going
to
be
something
that
will
be
necessary
in
many
networks.
That's
okay,
but
good,
but
you
should
consider
whether
or
not
the
detection
of
that
is
part
of
what
we
need
to
concern
ourselves
with.
P
Print
channel
too
much
work.
What
Roberto
said
I
actually
want
to
address
this
last
point
on
this
slide.
I
haven't
really
heard
a
convincing
model
of
what
a
middle
box
might
actually
want
to
do
to
quick
rate.
I
think
that
we
are
we've
taken
a
lot
of
learning
from
some
of
the
stuff
that
happened
early
on
with
quick,
crypto
I.
Think
we've
taken
a
lot
of
learning
for
what
happened
in
TCP
I.
Don't
think
a
lot
of
those
lessons
apply
here.
P
As
far
as
I
can
see,
there
are
two
operations
that
you
can
do
if
you're,
not,
if
you
basically
don't
have
the
keys
from
both
ends
and
can't
like
break
everything
all
the
way
apart.
There
are
two
operations
you
can
do
with
respect
to
version
ossification
one
you
can
detect
that
it's
quick
and
drop
it,
and
what
we
really
want
to
keep
from
happening
here
is
that
quick
version
one
does
not
become
the
flag
that
says
this
is
quick
versus.
This
is
not
quick.
P
The
other
thing
that
you
can
do
is
in
a
future
where
we
have
determined
that
quick
version,
one
has
a
vulnerability
that
allows
an
intercepting
middle
box
to
actually
be
able
to
do
more
than
we
think
it
can.
It
can
use
the
ability
to
determine
determine
quick
version.
One
complete
version
two
to
force
it
down
great
attack.
Are
there
any
other
things
that
we're
trying
to
prevent
happening
because
I
think
we
are
we're
kind
of
wasting
our
time?
I
see
people
behind
you
in
the
line.
I
would
like
to
be
convinced
that.
H
I'm
wrong,
so
mum,
Thompson
I,
don't
think
you're
wrong.
We
have
evidence,
at
least
from
TLS,
that
people
to
build
products
that
detect
is
this
TLS
and
drop
it
or
vice
versa?
Is
this
TLS
will
let
that
pass?
Is
there
something
else
and
so
having
the
ability
to
obscure
them?
Is
this
quick,
as
is
something
that's
kind
of
important,
too,
to
be
able
to
suppress,
but
that's
specifically
I,
don't
think
we
can
suppress.
Is
this
quick
generically?
Is
this
quick
version?
Q
R
It's
about
anger,
I'm,
not
super
convinced
that
to
kind
of
just
masking
the
version
number
is
not
to
prevent
very,
very
motivated
attackers
them
detecting
quick
version,
one
and
person,
two
differences.
For
example.
Let's
have
we
changed
initial
crypto
scheme
in
quick
version,
one
version
two:
what
version
to
will
look
like
an
attacker
could
do
trial
decryption
of
the
the
packet.
The
packet
encryption
scheme
itself
determine
whether
it's
version,
one
version
do
I.
Think
more
substantial
changes
probably
would
need
to
be
made
for
the
protocol.
We
want
completed
indistinguishability
between
versions
to
exist
as
well.
R
Having
said
that,
I
think
believe
protect
protecting
against
a
lazy
implementers
is
like
using
obfuscation
techniques
to
hide
the
version
numbers
that
like
if
somebody
is
just
implementing
like
a
middle
box
like
the
one
in
the
idea,
quick
was
hard-coded,
diverted,
number,
seven
or
bit
number
seven.
That
should
not
be
allowed
to
block
quick
deployment
subvert
and
do
first
version
month.
F
So
but
I
certainly
agree
masking.
The
version
number
is
not
enough
to
deal
with
someone
who
are
working.
No,
you
have
to
like
okay,
you're
freaking
me
out
yeah,
you
have
to
yep
in
cipher
the
entire
entire
block,
and
it
has
to
end
key.
That
is
not
not
publicly.
No
I
guess
I
just
want
to
float
one
other
thing
we
seen
you
know
boxes
do
that
is
more
aggressive
than
inversion
checking,
and
that
is
a
protocol,
correctness,
enforcement
and
so
first
and
what
you
do.
F
F
That's
more
like
it's
more
like
aggressive
than
checking
the
diversion,
but
it's
like,
but
it's
something
that
it
bit
as
long
as
as
long
as
the
diversion
scheme
is
constant
with
a
version
and
that's
public
information
and
of
course
you
can
pack
the
whole
thing
and
I
felt
like
we.
We
did
it.
Okay,
like
in
the
experience
with
with
I,
mean
there's
some
hope,
I.
Think
that,
like
in
the
Box
people
got
the
message
about
TLS
about
these.
F
This
tension
points
and
littles
it
or
not
and
like
like
not
screwed,
not
screw
of
like.
Is
that
really
Persian,
like
you
know,
on
extension
and
stuff
like
that,
so
I
think
there's
some
possibility
to
deal
with
it.
I
mean
he's
get
away
with
just
hiding
the
version
number,
but
it,
but
definitely
that
kind
of
protocol
enforcement,
something
even.
G
Systematics,
it
occurs
to
me
that
another
you
were
asking
why
a
middle
box
might
be
doing
this
another
possible
use
case.
The
little
box
says
quick
is
great.
I,
love,
quick,
but
I
don't
want
to
allow
random
you
TP
through
so
I'm.
This
is
what
I'm
using
to
detect
that
these
packets
are,
in
fact,
quick
and
not
just
some
other
random
UDP
I'm
obviously
want
that
to
work
going
forward,
but
you
also
want
that
be
possible.
I
think
so
a
little
bit
tricky.
M
Finish
wins
so,
yes,
I
to
you
that
middle
boxes
will
inspect
and
attempt
to
distinguish
quick
version
numbers,
and
the
reason,
as
echo
said,
is
that
the
ability
to
parse
the
client,
hello
out
of
the
initial
is
version
dependent
and
you
need
to
parse
the
client
hello
out
of
the
initial.
If
you
want
to
do
sni
based
censorship,
which
is
which
is
very
common,
so
the
yeah
those
those
systems,
even
if
they're
set
to
not
do
any
filtering
in
at
some
point
in
time,
are
still
going
to
be
doing
version.
M
P
Hi
Brian
Trammell
again,
so
one
of
the
things
I've
heard
is
that
there's
I
think
actually,
the
the
model
that
Jonathan
presented
is
probably
the
most
the
one
that
we
are
going
to
be
least
likely
to
say.
No,
you
can't
do
that
because
there
will
be
an
overwhelming
desire
to
do
it
and
that
is
to
say,
I
want
to
distinguish
quick
from
garbage,
because
I'd
like
to
be
able
to
let
quick
in
and
not
garbage
and
one
of
the
ways
that
that
middle
box
vendors
will
try
to
do.
This
is
the
protocol
correctness
enforcement
I.
P
Don't
actually
know
how
that's
like.
Looking
at
how
like
the
sequence
of
possible
packets
in
a
quick
connection,
there's
not
a
lot,
you
can
do
there
to
say.
Oh
no,
this
was
wrong.
I'm,
not
gonna.
Let
this
packet
through
great
that
doesn't
seem
useful
to
me.
People
probably
try
it.
It
doesn't
seem
useful.
P
The
fact
that
there
will
be
an
overwhelming
desire
to
tell
a
quick
packet
from
a
non-quick
packet
means
that
I
think
it
should
be
an
on
goal
to
just
to
obfuscate
the
distinction
between
quick
packets
and
non
packets,
because,
if
you
make
it
a
goal,
you
will
fail
and
people
will
invent
ways
to
do
the
distinguishing
and
it
will
be
wrong
and
it
will
break
I.
Think
the
right
way
to
go
about.
P
This
is
to
figure
out
what
break
point
we
want
in
the
in
the
the
wire
image
of
the
protocol
design
it
in
make
it
easy
make
it
obvious,
but
the
blink
tag
on
it
and
then
defend
the
rest,
because
the
rest
of
this
is
like
this.
This
rabbit
hole
seems
like
it's
going
to
be
a
lot
of
work
for
a
fair
amount
of
disappointment
in
a
couple
of
years.
A
K
Cory
bear
has
tried
to
make
sure
I
didn't
create
the
wrong
impression.
I
want
a
quick
version,
two
and
three
and
four
to
appear
I.
Think
people
will
try
and
find
which
was
great
one
people
want
to
when
to
is
available.
They
wanted
objects,
not
one
but
two
going
through
their
network
and
they're
going
to
find
ways
to
do
this.
K
If
we
want
to
let
them
learn
it
by
some
heuristics
from
traffic
partners,
which
I
think
is
very
hard
like
Brian
stars,
then,
will
still
try
and
do
this
you'll
produce
products
to
do
that
if
we
give
them
an
easy
way,
they'll
take
the
easy
way
so
I'm
not
sure
that
ossifying.
This
is
such
a
bad
thing.
I
think
it
will
help
us
deploy
version,
2,
3,
4,.
I
July
younger,
can
you
hear
me
mark?
Okay,
just
checking
I
was
going
to
text
to
voice,
but
I'm
not
doing
it.
I
think
as
there's
there's
a
couple
of
points,
and
we
already
have
experience
with
the
fact
that
people-
and
we
know
that
people
are
looking
to
detect
quick
in
the
network
at
the
interim
I-
had
a
slide
showing
a
bunch
of
firewalls
and
middle
box
vendors
that
are
offering
quick
detection
as
as
a
feature
and
that's
only
going
to
increase
as
quick
gets
deployed.
I
More
and
more
I'd
be
surprised
if
that
wasn't
the
case,
I
believe
that
that's
going
to
be
a
feature
for
a
number
of
reasons
and
we
won't
be
seeing
it
in
play
with
G,
quick
I
believe
that
the
quick
version
number
is
going
to
be
in
play
also,
at
least
in
part,
because
of
the
sli
point.
People
want
to
be
able
to
do
as
an
eye
detection
because
they
want
to
be
able
to
block
it's.
It's
done
it's
already
there,
people
this
is
used
for
zero
rating.
I
Don't
think
that
we
should
lose
fixing
this
problem
again
of
protecting
against
lazy
implementers,
because
at
least
my
experience
has
been
that
that
is
a
real
problem.
It
doesn't
seem
exciting
and
interesting,
but
it
is
the
real
problem.
The
one
data
point
that
I
have
is
the
experience
that
we
had
the
cheek
quick
wear.
Public
documentation
was
available,
they
didn't
look
at
it,
we
asked
them
and
they
said
no.
I
It
was
a
doc
heroes,
a
Google
Doc
and
it
was
available,
but
they
simply
didn't
look
at
it
and
they
didn't
even
know
that
it
existed,
but
they
built
a
feature
and
sold
it
anyways.
So
let's
be
clear
about
at
least
I'd
like
this
distinction,
because
I
think
it
really
lays
out
the
options
that
are.
The
considerations
we
ought
to
have.
I
would
say
that
we
should
at
least
build
against
lazy
implementers,
whether
we
go
against
hard
work
implemented
or
not.
I
A
Check
quickly,
so,
at
the
end
of
this,
when
we
have
the
my
clients
trained
I,
think
we
want
to
do
a
three
way
hum
to
get
a
sense
of
the
room
on
what
we
should
be
doing
here.
One
would
be
nothing
so
not
no.
Prevention
of
personalization
one
would
be
protect
against
the
lazy
implementers
and
when
the
last
one
lovely
we
try
to
put
through
something
against
the
eager
implementers,
just
as
a
foreshadow.
A
E
David
can
I
see
cool,
so
we
recently
deployed
Google
quick
version
46,
which
finally
got
us
to
the
IETF
invariance,
which
was
the
old
invariance
before
they
changed,
yay
that
when
we
did
that,
no
one
said
anything
yeah,
it
works,
everything's,
great
and
then
weeks
went
by
and
little
by
little
middle
box
vendors
came
out
of
the
woodwork
Oh
everything's
on
fire.
You
broke
X,
you
books.
Why
turns
out
there?
Al
are
already
a
lot
of
these
features,
so
some
of
them
are
reasonable.
E
E
Whether
that's
a
good
or
bad
idea
is
beside
the
point,
but
that's
what
they're
doing,
and
they
were
complaining
very
aggressively
when
we
broke
them
just
because
we
slightly
move
the
bits
4
bytes
to
the
right,
but
the
problem
is
like
Jonah
was
saying
these
people
who
implement
this
don't
read
the
docs.
They
fall
completely
in
the
category
of
he's.
E
So
is
the
middle
box
going
to
be
to
some
extent
unless
we
throw
huge
resources
at
the
service
on
I?
Don't
think
we
want
to
do
that,
please
from
the
server's
perspective,
so
my
personal
take
would
be
do
a
little
bit.
So
someone
who's
just
being
lazy,
things
fall
over
for
them
and
they
notice
it
very
early,
but
don't
go
don't
get
too
smart
because
greatest
that
could
be
really
dangerous.
A
L
Mia
could
and
I
wanted
to
come
back
to
this
use
case
where,
for
whatever
reason
you
want
to
identify
certain
information,
maybe
there's
an
eye
and
you
will
block
traffic
if
you
don't
identify
it.
What
that
means
is
that
people
think
they
have
a
strong
need
to
only
allow
a
certain
kind
of
traffic
and
they
will
block
everything
else.
So
if
they
can't
get
this
information,
they
will
block
it.
L
They
will
block
all
quick
right,
so
yeah
so
I
mean,
like
some
of
those
cases,
might
actually
the
right
decision,
but
I
don't
want
to
get
in
it
situation
where
we
get
to
the
point
where
people
just
don't
want
to
support
quick
anymore,
because
it's
too
complicated
for
them,
because
that
would
be
like
the
worst
outcome
of
who's
working
with
I.
Don't
think
that
reasoning,
the
Wersching
number
gets
us
to
that
point,
but
like
it
is,
it
has
the
cost
and
I'm
not
sure.
If
there's
a
benefit,
we
know
for
real
that
there's
a
cost.
M
Ben
Schwartz,
so
there's
been
some
discussion
of
a
quick
bit.
Some
some
way
to
identify,
quick
or
not
quick
I
want
at
a
minimum.
The
inverse
I
would
like
to
make
sure
that
there
is
a
space
of
packets,
an
inverse
wire
image
of
quick
that
is
guaranteed,
never
to
collide,
because
I
would
like
to
be
able
to
multiplex
other
protocols
against
quick
on
the
same
points.
A
F
There
patrolling
or
make
two
points
on
first,
two
nearest
point
on
forcing
people
to
block
quick
in
order
to
do
censorship
is
the
point,
in
fact,
the
whole
point
of
like
yes
and
I,
and
things
like
it
is
to
make
a
safer
block
everything
if
you
want
to
block
anything.
That's
like
the
purpose
to
exercise
the
second
on
to
David's
point
on
on.
There
are
two
costs,
I
think
I'm,
trying
to
defend
this
for
working
for
looters.
F
One
is
like
you
know:
whatever
calories
we
burn
thinking
about
it,
and
the
second
is
the
cost
to
servers
on
I
agree
that
it
will
be
expensive
in
terms
of
the
cost
of
our
calories.
I
do
not
think
it
out.
Yesterday,
I
spent
two
servers
designs
that
scene
that
we
discussed
I
think
can
be
done.
Almost
almost
incremental.
F
Zero
incremental
circle
would
so,
if,
if
that's
people's
concern,
that
I
think
that,
like
that
saying,
we
should
explore
and
make
this
anguish
explore.
I
feel
sometimes
like
too
much
work
for
us.
That's
a
political
reason
and
as
it
should
be
clear,
I'm
like
kind
of
undecided
between
these,
like
I'm
I'm,
full
software
lines
towards
doing
a
really
good
job.
But
I
understand
like
that
may
be
worse,
is
better.
O
Because
the
whole
body
have
fun
comment
and
one
clarifying
question
regarding
Maria's
comment.
My
point
is
that
made
conditional
greasing
is
a
good
way
to
prevent
the
mailboxes
trying
to
decrypt
the
client
in
shop
to
see
if
the
client,
how
is
good,
because
in
case
of
meat
connection
grazing
you,
the
middle
box,
would
see
a
long
hitter
pocket
for
gaining
another
version.
That's
unacceptable
and
if
those
middle
boxes
dropped
that,
because
it's
anti
crypto,
then
the
connection
fail.
O
A
F
Good
cuz,
you
already
at
this
point
because
some
of
these
are
potentially
optimal
optional
and
some
of
them
potentially
not
optional.
So,
like
the
version
where
you
like,
remove
the
version
number
and
you
travel
decrypt,
like
obvious
enough,
is
not
optional
and
the
version
where
you
do
make
connection
greasing,
or
this
alternate
version
number
is
optional,
and
so
that's
actually
I,
don't
know
how
to
I.
That's
why
you
get
paid
the
big
bucks
to
sort
this
out,
but,
like
it's
a
more
complicated
question
than
just
optional
versus
not
optional,.
S
S
One
question
is:
are
any
of
the
options
going
to
be
I?
Think
what
Christian
at
some
point
floated
of
basically
like
shipping
new
versions
in
a
relatively
timely
fashion,
so,
like
the
version
update
mechanic
mechanism
of
these
middle
boxes
is
actually
exercise.
One
Watson
is
that
do-nothing
I
mean
that's,
not
really
do
nothing.
That's
specifically
saying
like
we
are
proactively
going
to
try
to
ship
versions
on
a
like
once
a
year
or
more
frequent
basis,
because
as
long
as
we're
exercising
these
these
joints
at
that
frequency,
we
think
it's
okay,
so
we.
A
Can
hum
on
this,
but
it's
it's
kind
of
a
non-binding
right.
I
mean
the
building
a
protocol
here
and
then
we
can.
You
can
have
about
what's
optional,
what's
required
with
it
and
so
on,
but
we
can't
really,
you
know,
agree
on
shipping
very
frequently
for
the
foreseeable
future.
So
it's
an
aspiration
that
we
can
have
in
addition
to
something
in
the
protocol
or
not.
But
it's
you
know
what
about
what
the
hum
do
really
other
than
that,
giving
us
a
good
feeling.
Okay,.
A
So
I
thought
this
was
gonna,
be
easy
to
be
ready
humming.
It
sounds
like
it's
not
so
I'm,
not
gonna
engineer
this
up
here
in
my
current
shape,
but
if
somebody
wanted
to
propose
something
right.
I
I
I
A
What
I,
what
I
wanted
to
do
is
do
a
three-way
hum
on
this
is
we
should
do
nothing
here
where
we
should
try
and
protect
against
lazy
implementers,
or
we
should
try
against
attractive
lady
and
hard-working
implementation
if
I
get
one
with
the
other
and
that's
a
useful
hum
to
have
them
then
I
and
we
can.
We
can
have
another
harm
on
something
else
afterwards,
that's
good!
If
we
need
to
have
a
two
dimensional
harm,
then
no.
M
A
L
A
J
There's
understand
the
spec
thing:
implementations
that
don't
understand
the
spec
and
there's
implementations
that
understand
the
spec
right.
That's
one
way
to
define
lazy
versus
hard-working
I,
don't
know
if
you
want
to
change
anything
I
just
want
to
say
that
this
is
a
definition
that
we
can
wholly
agree
on
because
it
it's
actually
definitional.
A
This
is
I
mean
to
get
a
general
sense
of
the
room.
The
details
of
this
obviously
will
they
need
to
have
proposals
worked
out
right.
So,
as
I
said,
we're
gonna
do
three
hums
on
whether
we
should
do
nothing
to
prevent
personal
version
ossification,
whether
we
should
try
and
protect
against
version
of
vacation
or
get
lazy
implementers
that
would
otherwise
falsify
or
if
we
should
try
to
have
a
describe
type
of
protection
against
the
hard-working
at
the
labs
right.
So
you
believe
we
should
do
nothing
to
prevent
version
ossification
to
be
some
now.
C
H
C
A
A
A
D
D
D
D
A
Like
this,
this
is
again
sort
of
this
is
also
what
what
was
suggested
earlier
right
that
if
we
all
agree
to
should
like
to
rev
the
version
very
quickly,
that
would
help
us.
But
that
is
certainly
true,
but
it's
not
really
something
that
the
working
group
can
agree
to,
because
it
it
affects
people's
deployment,
so
it
can
aspire
to
that.
But
we
can
certainly
agree
to
put
something
in
the
protocol
as
a
mechanism.
L
A
O
Actually,
my
some
travel
different,
meaning
that
well
I
thought
that
we
were
having
or
we
are
confident
about
spending
our
beam
and
discussion
time
on
dealing
with
about
those
options.
I
mean
so
I.
Think
our
consensus
is
that
we
would
spend
time
on
discussing
how
we
prevent
those
lazy,
but
that
we
wouldn't
spend
even
discussion
time
on
discussing
how
we
prevent
those
hard-working.
A
F
That
matched
my
assumption
as
well,
which
is
we
already
spent
some
time
on
this
problem
and
then
maybe
we'd
come
up
with
solution
which
didn't
require
change.
There
were
I,
put
a
call
or
concede
one,
in
which
case
we
would
like
put
it
down
in
this
case,
design,
thinking
about
it
or
there
or
we
hope
the
solution
fire
chief,
nor
a
protocol.
In
case
we
make
those
changes,
that's
basically
I
assume
who
were
hunting
for
so
yeah
I,
guess,
I,
don't
know
how
you
want
to
actually
in
the
car
make
progress
in
this.
F
How
be
part
of
that
yeah
after
organize,
if
you
want.
A
O
A
A
C
H
We
talked
about
this
before
when,
when
we
removed
the
version
negotiation
stuff
from
the
from
the
draft,
that
was
on
the
understanding
that
would
have
a
solution
that
hasn't
been
forthcoming
or
we
haven't
discussed
it
and
any
length.
I.
Think
that's
because
we
made
a
mistake
and
drop
it
from
the
issues
list.
H
Version
downgrade
is
not
something
you
can
really
detect
until
you've
got
a
shared
context,
and
so
whatever
we
do,
I
think
we
need
to
couple
that
to
the
version
negotiation
work.
That's
that's
ongoing
and
I
think
that
guy
has
a
proposal
on
that
one,
that's
relatively
sensible,
so
we
should
look
at
that.
F
Because
I
wanna
make
sure
I
understand
that
they've
downgrade.
So
in
the
present
quick
design,
there
is
no
version
of
eëtion
him
all
right.
It's
a
version
that
was
impossible
in
I
was
not
proposing
to
change
those
semantics
I'd
like
to
change
those
semantics
but
like
in
this
in
this
not
to
change
them.
So,
basically,
I.
Don't
think
this
would
change
anything
in
that
respect,
but
maybe
I
misunderstood
something
about
hyper
reasoning.
Okay,.
E
J
F
C
C
Okay,
that
leaves
a
couple
of
different
discussions.
Oh,
we
have
the
recovery
draft,
which
I
think
it's
good
to
do
in
this
room,
because
it's
a
broader
set
of
folks
then
come
to
our
income.
Sometimes
we
also
have
the
HTP
draft
and
we
also
have
the
discussion
of
HTTP
priorities.
What
I'd
suggest
is
we
take
15
minutes
to
discuss
priorities
now
at
the
most
and
then
discuss
recovery
and
then,
with
the
remaining
time
we
go
back
to
the
other
HTTP
issues.
So
it's
unreasonable.
T
C
Was
that
was
part
of
the
deal,
so
there
was
a
side
meeting
this
morning
about
HTTP
priorities
and
and
I
think
a
useful
discussion
there.
One
of
our
constraints
for
the
HTTP
deliverable
is,
is
that
we
need
to
deliver
something.
That's
compatible
with
this
vinick's
of
HTTP
to
I.
Believe
is
the
phrasing
that's
in
the
Charter,
and
one
can
interpret
that
to
include
priorities,
and
so
our
deliverable
has
currently
has
an
HTTP
two
somewhat
compatible
priority
scheme
in
it.
C
But
there's
been
another
larger
discussion
of
community
about
how
hb2
priorities
is
not
optimal,
and
so
the
question
is,
as
a
group
do
we
want
to
try
and
just
deliver
something
that
I
would
hate
to
be
do
priorities,
or
do
we
want
to
do
something
else
so
in
you
were
leading
you
early
in
that
side
meeting.
Do
you
want
to
kind
of
summarize
what
the
proposed
that
is
from
that
group
of
people
either?
Mike
is
fine.
S
Okay,
yeah
I
can
teach
or
anything
so
what
depth
of
information
would
you
like
me
to
take
the
high-level
takeaways
I.
C
S
So
the
short
of
it
is
there's
fairly
broad
interest,
at
least
in
the
room
this
morning
in
removing
the
existing
h2
style
parties
from
the
HTTP
3
spec.
There
was
quite
a
bit
of
interest
in
trying
to
ship
something
simpler
in
time
for
HTTP
3.
There
was
a
little
bit
of
disagreement,
I
think
about
whether
that
should
be
a
blocking
item
or
not
a
blocking
item.
S
There
was
also
some
discussion
as
to
whether
that
prioritization
information
should
be
conveyed
in
a
frame
or
a
header,
as
in
kazoo
and
Lucas's
header
proposal,
there
was
very
broad
support
for
a
setting.
That
indicated,
are
you
actually
doing
prioritization
and,
if
so
like?
What
schemer
using
this
would
both
allow
YouTube.
S
H
I,
don't
think
that
there
was
support
for
that,
so
yeah
I
think
there
was
support
for
the
notion
that
you
could
signal
in
h2
that
you're
not
using
the
edge
2
priority
scheme,
which
might
be
the
same
thing.
It
might
be
the
same
thing.
I
might
not
be
depending
on
whether
you
want
to
have
multiple
different
priority
schemes.
S
S
C
So
I
think
we
need
to
have
a
coordination
of
the
HTTP
working
group
and
if
we
can
get
consensus
in
those
two
groups
about
what
HTTP
through
will
do
or
will
not
do
at
least
four
priorities,
then
you
know
we
can
take
that
to
the
our
directors
and
talk
about
our
Charter
and
see
if
we
need
to
make
a
charter
change
or
not,
and-
and
so
you
know,
I
think
one
of
the
things
that
came
up
was
if
hdhd
working
group
ships
a
setting
that
says
we're
not
using
priorities.
Then
htv3
can
decide
that.
C
That's
the
semantics
that
it
is.
You
know
considering
to
be
the
the
right
semantics
to
to
carry
forward
and
assuming
that
you
know
someone
at
some
point
and
we
can
talk
about
timing,
but
not
today,
we'll
come
up
with
an
extension
that
works,
that
the
semantics
can
be
mapped
to
HB
2,
NH
2,
to
3
and
and
be
better
than
what
we
have
now
yeah.
C
J
Roberto
Roberto
at
Lyon
as
one
of
the
instigators
of
h2
priorities
and
I,
will
say
that
I've
said
this
in
HTTP
as
well.
I
just
want
to
say
it
is
my
belief
that
this
scheme
has
failed.
H2
priorities,
in
my
opinion,
is
one
of
the
instigators
has
failed
in
its
design
intent.
There
are
many
reasons
for
that,
but
it's
failed
I
think
we
should
move
on.
J
H
Kazuo
suggested
that
there's
value
in
also
having
origin
servers
signal
priorities,
gateways
which
is
a
new
concept
and
a
group
on
I
think
but
I
haven't,
thought
it
or
what
all
the
way
through.
So
there's
a
lot
of
work
to
do
here.
I
would
caution
against
overestimating
our
ability
to
resolve
this
issue
in
the
time
that
we
have
left
in
this
working
group
to
get
something
shipped.
If
we
put
this
on
the
critical
path,
I
have
doubts
that
we'll
see
anything
in
RFC
form
next
year
and.
J
So
I
just
also
want
to
remind
everybody
that
anything
the
client
says
about
priorities
is
a
hint
and
it
doesn't
matter
what
you
spec.
This
is
what
we're
seeing
in
iron
from
the
patient's
today
I
think
that
it's
an
interesting
take
to
cut
priorities
out
right
now,
because
one
of
two
things
is
going
to
happen
either
it
will
be
perfectly
fine
and
we'll
just
move
on
right,
or
we
will
experience
some
extreme
shittiness
in
some
cases
and
we
will
be
incentive
to
fix
it.
Both
of
those
are
in
actually
interesting
outcomes.
I
Generally,
inga
just
note
that
Robin
Marks
has
sent
a
nice
summary
of
the
side
meeting
on
issue.
29
24
for
those
of
you
missing,
there's
also
linked
to
the
notes,
is
not
setting
from
of
the
side
meeting.
I
am
not
sure
exactly
what
this
discussion
is
about.
If,
if
we
are
discussing
whether
to
remove
priorities
or
not,
that
seems
to
have
been
done
at
the
side
meeting
and
I
expect
it
will
happen
in
the
HDP
this
meeting
as
well.
I
C
Yeah
I
think
what
we're
talking
about
is
from
this
working
groups.
Perspective
are
their
shipping
HTTP
3,
with
an
HTTP
2,
compatible
priority
scheme
or
shipping
it
we're
negotiating
and
talking
to
the
community,
though
the
broader
community
passes
working
group
about
shipping
HTTP
3,
with
no
priority
scheme
in
some
fashion,
so
I'm.
I
Actually
very
I'm
very
much
in
support
of
the
latter,
which
is
to
have
this
discussion
with
the
HTTP
community
and
try
to
go
to
its
shipping
without
any
penalties
knowing
fully
well.
That
servers
will
still
actually
do.
Some
implementations
will
still
do
paralyzation,
just
not
based
on
the
pair
Wow.
C
E
Give
its
Ignasi
I
want
to
agree
with
a
lot
of
the
previous
points
that
what
we
currently
have
in
the
spec
is
very
complicated
and,
let's
just
say
an
ideal.
My
personal
preference
would
be
to
not
have
the
hints
in
the
course
back,
because,
as
we've
seen,
this
could
delay
us
for
quite
a
while
and
I
would
love
to
see
and
I
think
there
will
be
experimentation
with
its
new
hint
schemes,
but
all
those
can
be
implemented
as
extensions,
and
we
would
probably
be
experimenting
with
those
and
deploying
them
in
production
as
well.
E
O
As
a
whole
I,
what
I
wanted
to
say
that
I
agree
with
Thompson.
He
says
that
we
shouldn't
be
blocking
HTTP
3
due
to
lack
of
priorities,
and
my
reasoning
is
that
our
whole,
the
server
deployments,
have
the
experiment,
experience
of
handling
browsers
that
do
not
send
priorities
in
the
correct
way.
So
we
know
how
to
prioritize
against
them.
So
it's
not
the
end
of
world.
If
we
ship
HTTP
without
priorities.
J
I
think
in
classic
fashion,
because
it
was
understating
the
situation
here-
it's
not
just
that
clients
may
or
may
not,
arguably
send
something
that
is
correct.
It's
that
the
server's
ignore
it
right.
So
the
purpose
of
putting
any
of
this
stuff
into
a
spec
is
for
Interop,
and,
given
that
these
are
hints,
they
were
always
optional
to
the
inlet
to
be
clear,
they
were
always
optional
right.
We
never
had
a
must
on
on
this,
except
that
you
have
to
receive
it
and
discard
it
right.
J
So
at
worst,
if
we
do
nothing
and
we
keep
H
two
priorities
in
the
spec
we
can
receive
in
discard,
I
think
that
that
is
suboptimal,
because
it's
okay
lights,
I
believe
that
it
is
better
to
to
say
hey,
it
was
hints
we
got
it
wrong,
let's
move
forward,
but
either
outcome,
probably
shouldn't
block
our
are
deciding
to
deliver
h3,
because
these
are
hints
and
we
can
acknowledge.
We
got
them
wrong,
because
Interop
is
terrible
right.
C
And
to
what
Kazuo
have
said,
I
mean
one
of
the
negative
outcomes
here.
That
is
a
concern
of
the
back
of
my
mind
is
that
we
could
have
you
know
a
lot
of
different
party
schemes
emerge
that
you
know
muddy
the
waters
even
more,
but
in
some
ways
that's
already
happened.
We
have
such
drastically
different
uses
of
the
existing
party
scheme.
It's
it's
not
a
great
situation
for
servers
in
any
way,
so.
V
Lucas
modified
fire
I
generally
agree
with
Roberta's
points,
but
I'd
want
to
disagree
on
one
aspect
which
relates
to
placeholders
it's
hard
to
ignore
that
it's
hard
to
create
the
hint
when
we're
talking
about
this
quantity
of
placeholders,
where
you
might
need
a
certain
value
for
that
quantity
to
create
the
prioritization
structure
that
you
want
for
your
user
agent
and
the
server
doesn't
give
that
to
you
and
that
said,
negotiate
or
value
and
quite
a
wide
scale.
V
C
Are
now
out
of
our
time
box,
so
I
think
we're
just
sorry.
Alan
I
think
what
we
probably
want
to
do
at
this
point
is:
do
a
hum
and
I
think
the
options
for
that
hum
are
to
keep
H
2
priorities
in
H,
3
or
H
2
compatible
programs
or
to
negotiate
the
removal
with
the
greater
community
or
we
don't
know
yes,.
C
C
C
The
parties
are
keep
H
two
compatible
priorities,
remove
them
from
h3
or
we
don't
know
yet.
So
if
you
would
use
its
we've
done,
the
first
one,
if
you
believe
we
should
negotiate
with
a
greater
community
to
remove
h2
compatible
priorities
from
htv3
and
effectively
ship
it
with
no
hints
from
the
client
to
the
server
as
to
priority.
Please
hum
now.
U
So
you
initially
described
the
second
option
as
not
making
h2
priority
as
part
of
h3
and
negotiating
with
the
community,
the
implication
of
how
that
would
happen,
and
then,
when
you
said
it,
the
second
time,
you
said
how
that
would
happen
would
be
not
shipping
the
priority
mechanism
in
h3.
Those
are
different
things
yeah.
H
C
U
We
don't
know
if
that's
gonna
happen,
arguing
that
the
definition
of
what
negotiation
has
to
be
multiple
parties,
including
your
other
working
group
as
well
like
HTTP.
It's
going
to
be
very
interested
in
what
this
may
look
like,
even
if
we
feel
as
a
quick
working
group
that
no
one's
going
to
implement
the
h2
thing.
I
think
that
negotiation
could
have
come
up
a
bunch
of
different
outcomes
if.
C
U
C
C
H
C
H
Q
C
Are
the
blue
sheets
right
now?
Who
has
the
blue
sheets
Kingdom?
Could
you
please
send
them
towards
the
middle?
Please
the
middle
section?
Thank
you.
A
So
what
Martin
Thompson
whispers?
If
you
want
to
summarize
for
us,
what
do
you
have
to
state
with
it?
It's
actually
a
gory
issue,
originally
yeah.
H
H
K
K
S
S
A
I
So,
for
what
it's
worth
we
already,
if
we
talk
about
using
the
pod
challenge
and
path
response
frames,
that
the
seed
would
be
basically
equivalent
to
an
initial
are
TTC
and
we
use
two
times
the
initial
RTD
for
the
initial
time
out
anyways.
So
it's
actually
even
more
than
the
1.5
that
let
me
suggesting.
K
A
It's
only
a
design
issue
because
it
changes
some
specification
text,
but
it's
basically
editorial
because
yeah
we
are
just
allowing
it
needs
to
be
gutted,
Thank,
You
Janice
a
up
there.
Next
one
is
yours:
26:30
define
under
utilization
of
Seawind
I
thought.
There
was
text
that
had
the
proof
that
are
discussed
in
London
we'd,
like.
K
S
Disappear
for
this
I
think
right.
Yeah
there's
been
a
PR
for
it
for
awhile
we
just
kind
of
going
keep
going
back
and
forth
on
it.
It's
it's
rather
difficult
to
get
right.
I
need
someone
to
I
guess
we
need
more
people
to
review
it,
but
yeah
pretty
yeah.
C
I
A
H
I
I
The
the
whole
the
whole
reason
we
want
to
specify
what
under
utilizing
this
even
means
is
to
avoid
bursting
when
you
have
your
bytes
in
flight
is
substantially
below
the
condition
window,
and
so
we've
had
discussions
around
that.
Gory,
Ian
and
I
have
had
a
discussion
around
that
and
we
I
think
we
have
some
way
to
go
around
that
I.
S
Actually
didn't
particular
that's
the
other
issue.
The
underutilization
one
is
actually
about
not
growing
the
congestion
window
when
you
are
not
using
the
dish
was
a
separate
issue
about
not
bursting
too
much
into
the
network.
They're
both
I
attempted
to
address
both
of
them
in
one
PR,
because
they
saw
what
really
I
think
as
much
as
anything
on
this
stuff.
S
We
just
need
like
people
who
have
strong
opinions
to
either
write
text
or
take
a
closer
look
at
the
existing
PR
and
try
to
make
proactive
suggestions
about
trying
to
fix
it
because
I
think
we're
going
in
the
right
general
direction.
I
think
there's
a
big
design
issue
here,
but
we
need
to
like
eventually.
A
I
O
I
A
K
A
25:56
I'm
mark
here
we
have
coasters
at
some
point.
Maybe
I
should
just
k,
persistent
connection
congestion
threshold
be
two
or
three
from
open
by
Praveen
in
March,
so
a
bunch
of
discussion
in
March
and
then
April
and
then
mark
made-
and
this
is
best
to
bring
this
up
at
the
full
ITF
meaning.
What
you're
doing
now.
H
H
S
What's
the
principle
the
current
value
was
chosen
because
previously
in
spec
you
could
fire
the
Telus
probe
twice
before
firing
an
RTO
and
declaring
all
bytes
in
quite
lost
and
basically
declaring
persistent
congestion,
and
so
we
picked
the
constant
that
was
most
similar
to
that
model,
which
is
like
you
get
two
timeouts
and
then
the
third
one
you
know
do
that
and
that's
how
the
current
number
was
chosen.
I
mean
these.
Are
it's
a
constant?
S
It's
it's
a
little
bit
magic,
but
it
basically
allows
you
to
lose
packets
twice
alpacas
twice
before
you
declare
persistent
congestion.
Just
for
me,
yeah
I
mean
we
can
make
it
one
or
the
other,
and
let
implementations
choose
that's
what
we
did
actually
up
above
in
the
PTO
text.
We
said
you
can
send
one
or
two
full
sized
MSS
opposed
to
just
prescribing
only
one.
W
S
I
A
H
Month
on
something
I
think
there
are
two
valid
paths
here.
One
is
to
say
two
is
fine,
we'll
get
more
data
book
it
later.
The
other
one
is
to
say
two
or
three
is:
is
acceptable
and
implement.
Implementations
can
decide
on
their
own
and
we'll
get
more
data
and
refine
that
as
we
as
we
go
on
I,
don't
have
a
preference
on
either
one
of
those
I'm
a
little
cautious
about
being
confident
that
we
can
get
the
information
we
need
to
make
a
solid,
firm
decision
on
this.
H
One
I
think
that's
ever
the
case
that
we'll
have
another
information
to
be
really
confident
about
these
sorts
of
constants,
so
I
would
I
would
actually
lean
towards
saying
two
or
three
and
recognize
that,
and
maybe
even
explicitly
knowledge
that
we
don't.
We
don't
know
what
the
right
answer
is
here,
which.
Q
I
G
I
Know
it
honestly,
it
doesn't
matter
to
me
what
I
think
may
be
more
useful.
Here
is
the
illustration
of
why
or
what
the
what
the,
what
the
value
means?
What
happens
if
you
change
the
value
to
three,
what
happens
if
they
change
the
value
to
2
and
people
are
going
to
set
the
constants
the
way
they
want
anyways,
so
we
might
as
well
recognize
that
and
simply
describe
the
effects
of
doing
this
I
don't
mind
allowing
two
or
three
we.
K
K
The
sort
of
Tory
take
us
home
and
I
will
encounter
next
can
I
try
on
this
and,
first
of
all,
very
first
again,
the
this
is
actually
new
ground
in
the
HF
surprising.
They
have
lots
of
things
about
congestion,
controller
all
over
the
place
in
RFC's,
but
we
don't
really
have
some
sort
of
this
is
how
the
principles
work
I'm,
trying
to
cook
for
something
in
TCP
M
on
that,
and
you
might
want
to
look
it
up
and
we
might
want
to
see
we
can
take
it
forward
in
the
absence
of
that.
K
A
A
A
S
I
I
People
should
take
a
look
and
comment
and
see
if
that's
adequate
and
say
something
if
it's
not
second,
on
the
particular
or
the
general
issue
of
idle
period
between
on
defining
idle
period,
water
reviewing
an
idle
period,
we
specifically
chose
not
to
walk
into
that
territory,
because
Gauri
knows
how
painful
that
is,
and
we
would
like
to
we
deferred
the
discussion
to
his
RFC,
which
is
the
CWA,
the
new
cwv
RFC,
which
I
think
is
adequate.
We
don't
need
to
spend
time
in
this
document,
I
believe
on
making
sure
that
we
can
write
a
people.
I
A
B
S
I
C
I
I
K
We
we
this
is.
This
is
just
a
question.
We
have
a
mineral
tea
tea
and
we
also
have
the
expectation
that
Creek
floors
last
for
a
long
time
in
some
cases,
because
we
might
use
them
over
hours
and
min
RTT
records
the
smallest
RTT.
We
saw
on
the
path
you're
going
to
change
connection
to
part
in
the
document,
but
that
is
men
forever
and
if
your
path
changes,
then
the
men
are
TT
changes
to
lift
like
so
it
may
not
eat
e
is
useful.
Then
maybe
we
should
periodically
reset
the
not
eating
question.
A
A
good
to
the
point,
so
let
that
has
a
similar
concept
of
minerality
and
I
think
we
do
something
there.
Where
we
don't
let
it
you
know,
be
unbounded
or
or
we
refresh
it
over
a
lifetime
of
connection
and
something
similar
makes
sense.
A
to
I
agree
is
the
let
everybody
know
what
that
that's
doing.
Can
we
just
copy
that
or.
H
A
K
Proposal
was
the
very
simplest
which
I
think
would
be
helpful
to
do
the
same
as
path
MTU
discovery.
Every
ten
minutes
just
read
the
RTG
and
work
from
there.
I
think
all
these
other
proposals
are
better
and
more
helpful
and
slightly
more
caught,
so
somebody
has
to
make
a
call.
It
partly
depends
on
what
you're
going
to
use
min
RT
t
for
it's
used
as
a
rejection
think
rejection
samples
at
the
moment.
So
it's
not
that
critical.
When
you
get
it
right,
it's
important
that
you
don't
get
it
wildly
wrong
for
long
periods
of
time.
L
J
X
Andrew
Grega
I
recall
somewhere
in
the
Linux
kernel.
This
is
a
very
simple
algorithm
for
a
sliding
window
to
maximum
I
think
maybe
we
might
want
to
a
draw
adopt
the
inverse
of
that,
and
so
yes,
it
becomes
a
windowed
in
an
RTT,
it's
just
the
window
being
samples
or
anything
else.
But
you
know
that
seems
like
a
reasonable
thing.
H
So
Martin
Thompson-
if
it
occurs
to
me
that
there
are
many
possible
ways
you
could
paint
this
particular
bike
shed,
and
it
really
is
a
bike
shed.
I
think
that
we
want
to
make
some
suggestions
and
not
do
anything
more
concrete
than
that.
The
suggestion,
for
instance,
the
idea
that
you
have
you
reset
this
on
idle,
won't
work
for
a
number
of
very
common
usage
patterns,
because
their
definition
of
idle
is
such
that
we
actually
get
that
very
frequently.
A
S
I
I'm
Jenna
Inga,
so
I
agree
with
with
the
idea
that
we
should
build
something
fairly
simple,
but
we
should
build
something
fairly
simple.
It's
important
to
bear
in
mind
that
this
is
the
consequences
of
getting
the
minority
wrong
here.
So
this
is
not
a
congestion
control
issue.
It's
a
loss,
recovery
issue.
The
minority
in
quick,
is
used
primarily
to
reject
samples
that
might
be
too
small,
then
the
measured
minority.
I
S
A
I
Look,
that's
that's
completely
fair
I!
Don't
think
that
the
velocity
of
change
here
is
that
dramatic,
the
which
also
leads
to
the
other
question
right:
we've,
not
gotten
a
ton
of
feedback
regarding
feedback
from
a
couple
of
people
right
from
the
from
the
time
of
the
document,
but
not
everybody,
so
I,
don't
know
where
people
are
on
implementing
loss
recovery,
an
agreement
in
condition
control.
This
is
part
of
the
reason
that
Martin
and
I
worked
on
building
the
simulator
same
framework,
so
that
we
could
actually
test
what
people's
about
implementations
are
doing.
I
C
A
Fine,
my
impression
from
from
talking
to
the
implementers
that
some
implementers
are
actually
just
trying
to
quick
stack
into
whatever
condition,
control
framework
they
have
for
other
transports.
Others
implement,
you
know
cubic
in
some
way.
Some
are
actually
trying
to
implement
the
recovery
draft
and
then
I,
don't
I,
don't
know
if
there's
still
any
out
there
that
just
have
a
a
quick
hack
that
suppose
it
mostly
flow
control
based
I
think
those
are
like
upgrading
to
proper
congestion
control
now
or
have
done
that.
I
Maybe
they
just
read
and
just
don't
care,
but
but
I
was
gonna
say
that
condition
control
yes,
you're
right
people
will
use
other
controllers
because
it's
much
harder
to
implement
those
ones
but
loss
recovery
should
be
this.
Prom
is
going
to
have
to
be
granion,
so
we
would
definitely
for
the
people
who
read
and
for
the
people
who
have
implemented
we'd,
definitely
like
to
hear
some
feedback
on
whether
you
think
clarifications
required
or
even
if
it
did,
if
it
all
went
well,
that
would
be
very
useful
feedback
to
have.
U
Very
briefly,
Oh
Erica
near
Apple
to
what
large
said:
we've
actually
done.
Both
we've
got
cubic
and
all
that,
but
we
also
just
did
a
vanilla
exactly
what's
in
recovery,
draft
and
I
think
the
last
time
we
asked
this
question,
I
stood
up
and
said:
hey
I
think
we
need
more
time
before
we
do
the
late
stage
process
cause
nobody's
really
poked
at
it
yet
and
I
think
now
we're
seeing
that
most
people
have
poked
it.
We've
done
a
nice
rebbe
of
kind
of.
How
do
we
word
it?
U
What's
confusing
what
makes
sense,
what
just
flat-out
doesn't
work
and
we're
kind
of
into
the
place
where
we
still
have
a
bunch
of
testing?
We
need
to
do
but
changes
that
would
that
I
think
at
least
on
my
end,
I'd
be
saying:
hey.
We
really
need
to
change.
This
would
have
a
bunch
of
like
test
results
and
data
behind
them,
which
kind
of
fits
okay
in
the
wastage
process.
C
It
sounds
like
we're
getting
there,
but
not
quite
there.
Yet,
okay,
so
we
have
nine
minutes
left.
We
have
the
HTTP
issues
up.
I,
don't
think
we'd
have
time
to
go
through
them,
so
Mike
Bishop
worry
there.
You
are
anything
in
particular
you'd,
like
some
information
or
help
from
the
working
group
on
in
this
time.
Y
So
I
was
looking
through
the
issues
trying
to
find
a
couple,
but
hopefully
we
could
make
good
progress
on
a
couple
minutes.
At
the
interim,
we
said
that
we
were
going
to
reread
7540
and
ask
questions
of
HP
mailing
list
with
regard
to
this
issue.
That
has
happened,
and
so
we
were
to
see
if
anyone's
opinion
has
changed,
should
to
recap
this
issue.
It's
basically
the
observation
that
go
away
in
h2
refers
to
screens
and
tells
which
makes
things
stop
in
both
directions.
Y
It
makes
push,
stop
as
well,
where
it's
intended
to
refer
to
requests
and,
in
fact
does
refer
to
requests
streams
of
h3,
but
that's
a
difference
from
h2.
It
doesn't
do
anything
about
push
other
than
let
the
transaction
finish
a
sparkly
response.
So
there
are
two
schools
of
thought
here.
We
just
need
to
pick
one
in
the
book.
H
I'm
going
to
argue
the
converse,
this
all
depends
on
your
on
your
conception
of
push
and
we
have
different.
Alan
and
I
have
different
views
on
this
one,
because
we
have
different
understandings
of
what
push
really
means
and
I
think
this
is.
This
is
the
fundamental
disagreement,
then
I
say
push
it
being
related
to
the
requests,
and
so
you
shut
down
the
requests.
You
ultimately
need
to
allow
the
pushes
to
continue.
H
S
F
P
C
C
Y
J
Minutes
it
shouldn't
take
that
long
unless
you
want
me
to
take
the
full
three
minutes,
but
anyway,
I
think
that
what
we
might
be
seeing
here
is
a
bit
of
the
tussle
between
whether
or
not
go
away
makes
the
most
sense
of
the
h3
layer
or
the
layer.
I
wouldn't
say
transport,
but
earlier
than
you
I,
don't
believe
we're
gonna
resolve
that
in
v1
I,
don't
know
if
that
changes
anyone's
opinions.
H
C
Sounds
like
we
need
to
take
a
discussion
of
the
list
and
have
some
hawai
discussions
with
that.
I
think
we're
just
about
done.
As
we
mentioned,
we're
going
to
try
to
announce
an
interim
as
soon
as
possible.
Again
we're
thinking,
probably
October
early
October
to
mid
October
I
think
is
their
current
thinking,
but
we'll
we'll
get
that
information
to
you
as
soon
as
we
possibly
can
from
North,
America
and
and
we're
looking
at
North
America.
Now
it
would
be
at
this
point
where
we're
trying
really
hard
for
North
America.