►
From YouTube: IETF104-QUIC-20190326-0900
Description
QUIC meeting session at IETF104
2019/03/26 0900
https://datatracker.ietf.org/meeting/104/proceedings/
A
B
B
First
of
all,
this
is
the
note
well
statement.
You
should
be
familiar
with
this,
but
if
you're
not
you
can
find
it
by
searching
for
IETF
note
well
on
your
favorite
internet
search
engine,
including
waste
and
gopher,
and
anything
else,
I
guess
these
are
the
terms
which
we
participate
in
this
work
under
regarding
intellectual
property
regarding
your
behavior
regarding
things
like
harassment,
code
of
conduct.
So
if
you're
not
familiar
with
these,
please
do
take
a
look
at
them.
B
B
Spacebar
is
broken.
There
we
go.
Administrivia
blue
sheets
are
going
around.
Thank
you,
Joe!
No,
we're
trying
to
go!
That's
weird!
Okay!
We
have
scribes.
Thank
you
very
much.
Patrick
McManus,
with
a
backup
of
Brian
jabber
relay
Craig
volunteered
to
relay
whatever
happens
on
jabber.
Thank
you
so
much
and
we
are
using
the
ether
pad.
That's
linked
from
the
minutes.
Correct
sorry
from
the
agenda
correct.
Just
if
folks,
we
start
having
performance
problems
on
that
people
who
aren't
actively
editing
disconnecting
might
be
a
good
idea
because
the
ether
pad
does
tend
to
have
some
issues.
B
B
So
we
had
the
hack
of
thought
on
the
weekend
today.
We'll
have
a
quick
report
of
what
happened
at
the
hackathon
from
Lars,
and
then
we
have
one
discussion
from
the
editors
about
discarding
old
keys
and
then
we'll
go
into.
The
focus
for
today
is
mostly
on
the
recovery
draft,
so
ian
is
going
to
go
over,
what's
happening,
the
recovery
draft
and
the
relevant
issues
and
we'll
try
and
focus
on
that
take
advantage
of
the
time
we
have
here
in
Prague
with
the
larger
IT
have
to
talk
about
that.
B
Since
when
we
have
our
interim
meetings,
it's
often
the
case
that
we
don't
have
all
the
right
people
in
the
room.
If
we
have
time
permitting
after
that,
we're
gonna
have
a
quick
discussion
of
quick
connection
migration
and
then
on
Wednesday.
We
go
into
issue
discussion
on
transport,
TLS
and
HTTP.
Talk
about
our
next
steps
and
I.
Don't
think
we
have
any
other
as
time
permits.
There's.
B
B
B
Don't
go
to
the
mic
for
bad
jokes,
please!
So
yeah,
that's
Magnus!
If
you
have
any
problems
with
the
way
the
working
groups
running
or
or-
and
you
can't
resolve
them
with
us,
Magnus
is
the
person
to
talk
to
make
sure
you
forget
what
he
looks
like
No,
okay,
that
doesn't
work.
I,
guess
and
one
other
thing
we
wanted
to
mention.
We
have
scheduled
an
interim
meeting
for
May
the
20
the
week
of
May,
the
20th
I
believe
in
London.
B
B
We'll
see
how
this
goes,
we
consulted
with
a
lot
of
people
before
we
chose
that
date
and
time
and
we
waited
as
long
as
we
could
to
see
what
the
future
would
look
like
and
then
the
future
changed
very
quickly,
of
course,
so
we're
still
going
ahead
at
this
time.
I
don't
see
us
canceling
the
meeting
unless
things
get
quite
dire,
which
some
people
predict,
but
people
sometimes
get
in
the
habit
of
predicting
dire
things.
B
D
A
It
depends
so
whether
or
not
we're
going
to
keep
having
interims
will
depend
on
how
quickly
people
will
want
to
make
progress
and
some
of
the
stuff
that
is
next
on
the
agenda,
like
media
/,
quick
and
multipath
right.
So
let's
talk
about
there
on
Wednesday
and
we
I
see
as
also
still
organizing
interrupts,
but
since
they're
not
ITF
events
that
is
sort
of
a
bit
orthogonal
to
whether
we're
gonna
have
an
interim.
B
A
Well,
can
you
click
on
the
thing,
the
the
thing
that
says
sheet
somewhere?
If
you
go
up?
Yes,
that
the
Google
Docs
thing
right,
so
so
we've
been
doing
this
for
a
long
time
now.
Basically
this
interrupts
at
a
hackathon,
and
we
have
every
time
there's
at
least
like
one
implementation
that
either
hasn't
participated
in
a
long
time
or
is
new.
So
this
was
no
exception.
It's
starting
to
look
pretty
solid
in
terms
of
the
base
functionality.
A
It's
there's
a
lot
of
green
happening,
and
you
you
see
that
that
you
know
there's
pretty
broad
inner
up
across
the
board.
It's
a
little
misleading,
so
some
columns
are
dark
or
some
fields
are
darker
than
others.
That's
because
we
we
added
a
bunch
of
new
tests
for
this
inner
up
round
that
not
a
lot
of
clients
have
implemented
the
tests
for
yet,
like
you
know,
Natura,
binding
or
but
the
other
guys,
peak,
CCN
and
so
on.
A
So
it's
a
little
bit
misleading
because
I'm
guessing
that,
if
more
clients
we're
testing
these
things,
you
would
see
darker
shades
of
green,
because
some
servers
already
support
them,
except
that,
if
they're
not
tested
for
that
yet
so
it
looks
pretty
good.
I
will
point
out
that,
so
my
personal
opinion
is
that
for
specifically
connection
migration,
there's
a
whole
bunch
of
edge
care
case
testing
of
who
needs
to
happen
at
the
moment.
Everybody
seems
to
so.
A
If
somebody
tests
this,
maybe
to
be
the
exception
of
Christian
I,
don't
know,
everybody's
just
sitting
passively
seem
to
close
support
in
spider
ports.
The
IPS
doesn't
change
to
support,
number
changes
and
there's
not
really
any
artificial,
reordering
or
any
fancy
stuff
like
that
being
introduced.
Yet
so
I
expect
we
were
gonna
hit
some
more
corner
cases
there,
but
it
looks
pretty
good
and
given
that
night.
So
this
is
a
18
that
we're
testing
here.
A
19
is
already
out
with
reasonably
minor
changes
at
the
recovery
and
and
trans
what
level
I
think
many
of
more
to
changing.
On
the
HTML
side,
it
also
looks
pretty
good,
so
this
is
the
compared
to
the
last
time.
I
think
we
did
this
there's
a
lot
more
h3,
that's
being
tested,
which
is
very,
very
very
nice.
A
When
you
have
a
nice
clean
path
between
decline
and
the
server
things
seem
to
work
really
well
up,
I'm
guessing
that
there's
gonna
be
a
whole
bunch
more
issues
when
we're
running
over
some.
You
know
stranger
edge
case
for
us,
so
it's
arrium,
so
the
ietf
network
is
a
pretty
good
test
because
it's
usually
not
great
in
terms
of
packet
loss
and
again
they
had
so
in
Bangkok,
and
here
there's
a
box
in
the
network
that
likes
to
order
UDP
packets
by
size,
which
means
that
so
the
knock
knows
about
this
we've.
A
We
figured
this
out
in
Bangkok,
it's
it.
The
box
is
present.
Somebody
found
it
during
you
interrupt
because
they
were
wondering
why
they
persistently
get
this
one
ticket
after
the
other.
That
is
why
so,
the
ITF
networks
an
excellent
test
network,
but
we
we
don't
have
sort
of
a
lot
of
repeatability
here
yet
and
then
this
comes
back
to
tooling
and
and
Ottomans
has
supported
Christian.
E
Kushina
Itamar,
yes,
one
thing
I
did
observe
in
his
intro
up
is
that
lots
of
stuff
are
working
well.
But
if
you
start
digging
like,
for
example,
if
you
start
trying
to
download
hundred
megabyte
or
something
that
you
do
find
issues,
and
there
are
lots
of
issues
about
confusion
between
the
transporters
one
way
on
the
other
way
or
these,
and
that
so
dust
is
and
and
then
the
retransmission
and
the
management
of
flow
control
I
mean
we
need
more
tests.
They're
in
a.
A
I
I
agree,
so
I.
Think
of
the
the
first
stacks
are
now
sort
of
getting
to
the
point.
We're
doing
well.
I
think
nick
has
been
doing
performance
testing
for
a
while,
but
but
some
of
the
other
sects
are
also
now
getting
to
the
point
where
the
X
we
wonder
what
kind
of
through
Patek
they're
getting
and
and
where
they
actually
try
to
push
a
lot
of
data
over
connection
or
multiple
connections,
and
that
exposes
a
bunch
of
stuff.
A
I
mean
one
thing:
is
we
have
a
bunch
of
students
and
academics
show
up
that
I
mean
if
you
profess
over
and
you
have
students
that
are
looking
for
master's
thesis
topics.
This
is
not
I
mean
there's
PA
cheese
here
too,
but
a
lot
of
tooling
is
more
like
a
master
level
kind
of
exercise,
but
it
would
actually
help.
You
know
a
large
part
of
this
community
significantly.
If
there
was
some
more
open
source
being
written
along
those
lines.
F
F
A
H
A
D
G
E
G
A
I
F
A
Was
a
discussion
where
they're
gonna
do
a
virtual
interrupt
day
between
now
and
London
and
and
what
version
we
would
do
it.
So,
if
you
will
care
about
that,
I
think
it's
on
the
general
channel
on
slack
and
if
you're
not
on
the
slack,
and
you
want
to
be
honest,
like
send
email
to
them.
Mark
of
me,
yeah.
B
J
So
this
wide
dick
was
updated,
I
think
yesterday
and
it's
out
of
date,
so
I'm
gonna
go
through
it
anyway.
Part
of
the
problem
here
is
that
we're
dealing
with
I
think
three
or
four
different
things.
That
would
the
various
reasons
decided
to
lump
into
the
same
bucket.
So
let's
go
ahead
and
we'll
see
if
we
can
make
any
progress
here,
but
I
don't
hold
high
hopes.
Next
sorry,
I
should
not
be
so
negative
early
in
the
morning.
J
J
J
We
can
proceed
anyway,
and
so
there's
really
three
distinct
cases
that
we
were
concerning
ourselves
with
here
and
and
each
one
has
some
different
nuances
to
them,
and
so
I
think
we'll
probably
go
through
that
a
little
bit
more
detail
as
we
go
and
I'm
waiting
for
a
clicker.
Let's
see
how
this
works
out,
I.
J
J
So
we've
had
four
proposals:
I
think
there
may
be
a
fifth
one
now
I'll
see
if
I
can
do
that.
One
justices
we
work
through
this
one.
The
first
three
of
these
use
frames
to
sort
of
signal
that
things
are
ready
to
go.
The
fourth
one
steals
one
of
those
unused
bits
that
we
have
in
the
first
octet
to
create
the
signal,
there's
a
fairly
substantial
differences
between
the
first
set
and
the
last
one,
and
in
some
regards,
but
essentially
they're
all
some
sort
of
explicit
signal
that
we're
ready
to
throw
away
the
other
keys.
J
J
This
is
the
first
set
of
changes
that
you
can
see
here
on
the
slider
over
the
past
day.
The
idea
was
that
you
would
send
this
this
frame
when
you
believe
that
when
you
have
read
case
for
something-
but
we
realized
in
discussing
this-
that
what
you
really
want
to
do
is
say
send
this
frame.
When
you
expect
the
peer
to
be
sending
with
the
corresponding
keys,
it
implicitly
identifies
the
keys.
This
is
a
point
of
difference
with
some
of
the
other
ones.
J
If
it,
if
the
frame
is
included
in
a
packet,
that's
protected
with
key
X,
then
it
means
that
I'm
willing
to
receive
the
corresponding
packets
that
are
protected
with
the
corresponding
key.
It
doesn't
have
a
an
explicit
counter
or
something
in
there
that
identifies
these
things,
and
so,
if
you
start
sending
these
back
these
packets
after
key
updates,
that
means
something
different,
which
is,
which
is
something
that
we
sort
of
do
with
acknowledgments.
J
But
maybe
acknowledgments
are
so
special
that
they're,
the
only
ones
we
can
get
away
with
out
with
I,
don't
know
when
you
receive
one
of
these
things
at
least
used
to
say
when
you
send
it.
But
when
you
receive
one
of
these
things,
you
know
that
the
older
keys
that
are
associated
with
keys
from
the
previous
epoch
are
safe
to
be
discarded.
You
may
want
to
retain
those
all
the
keys,
the
the
ones
you
use
for
reading
packets
for
some
amount
of
time
and
there's
some
discussion
in
the
document
about
how
that
that
works.
J
K
J
Some
pictures-
hopefully,
these
decipherable
at
that
range,
it's
very
difficult
to
get
these
things
on
the
one
slide.
But
essentially,
what
happens
here
is
that
when
you
send
the
first
handshake
packet,
you
say
well
I'm
expecting
to
receive
packets
that
are
protected
with
an
Shakey's
at
this
point,
so
I'm
going
to
send
this
frame
in
that
first
handshake
packet,
and
when
you
receive
that
packet
containing
this
frame,
it
means
that
you're
okay
to
proceed
to
the
next
one,
and
it
also
means
that
you're,
okay
to
throw
away
the
the
previous
keys.
J
When
that
arrives
at
the
server
the
server
may
have
thrown
out
the
initial
keys,
depending
on
the
ordering
of
things
same
happens
at
one
RTT
you'll
notice
that
it's
not
sent
in
the
first
one
RT
t
packet,
because
the
server
doesn't
have
the
ability
or
it
doesn't
have
an
expectation
that
the
that
the
client
is
is
sending
in
one,
not
one
RCT
keys.
Until
it's
it's
gotten
the
one
ITT
that
packets
from
the
client.
J
L
J
L
Just
trying
to
make
sure
I
understand
at
this
point,
so
let's
take
that
first
transition,
if
the
let's
assume
the
like
as
being
natural,
that
the
initial
and
the
first
handshake
from
the
server
bundle
in
the
same
Datagram
and
that
the
server
and
the
client
supplementing
lay
back.
So
what
will
happen
here
is
if
the
point
where
the
client
is
ready
to
send
initial
it'll
already
have
received
them
processed
the
keys
ready
flag
in
the
first
hand,
and
an
intuition
of
the
circuit
right.
That
might
be
the
case
unless
shoulder.
J
L
L
L
L
The
expectation
is,
you
would
drop
it,
so
you
would
drop
which
so
so,
if
the
app
does
not
appear
in
the
server's
initial
yep
now
you
have
a
case
where
you've
deleted
the
key
or
you
could
delete
the
key
for
the
rules
right,
but
you
haven't
standing
on
act
data
one.
Well,
that's
the
question.
I'm
asking
right:
I
tend
to
establish
the
rule.
What
the
proposed
rules
are
arguing
the.
L
But
more
generally
the
rule
is,
and
it
is
me
me,
I,
don't
think
this.
The
only
case
that
can
happen.
Maybe
it
is
more
done
where
the
rule
is
that
on
that,
if
you
have
outstanding
data
on
an
empath
that
could
not
be
sent,
they
cannot
or
should
not
send
other
epoch.
When
you
receive
he's
ready
on
epoch,
M,
+,
1
or
M
+,
M
+
anything,
then
you
can
be
said
that
you
see
effectively
so
that
an
AK
or
you
you
start
test.
J
J
They
wait
until
they're,
seeing
packets
from
the
new
epoch
before
they
they
send
the
frame,
and
the
consequence
here
is
that
you're
allowed
to
update
once
you've
received
the
the
frame
and
there's
there's
no
way
that
you
can
use
this
state
machine
to
do
anything
faster
than
one
key
update
per
round
trip
and
that
achieves
the
goal.
It
fixes
the
problem.
We
can
go
from
n
to
Oh
without
actually
having
packets
from
n
in
flight,
and
that
causes
the
M's
and
the
O's
to
be
indistinguishable
from
each
other
and
the
connection
to
fail.
J
This
shares
the
property
with
the
previous
one
that
it
implicitly
identifies
the
the
keys.
It
does
have
a
little
wrinkle
for
the
initial
handshake
transition.
It's
it's
a
special
case
like
with
the
other
one
you
send
it
in
the
very
first
packet
and
that
triggers
the
the
drop
of
the
initial
keys
in
the
same
way.
That's
a
little
janky
in
some
ways,
because
it's
not
it's
not
a
consistent
rule
that
you
follow,
but
it
has
fairly
similar
properties.
J
K
J
The
one
that
did
you
drew
David,
because
I
think
once
I
think
you
you
had
the
retire
keys
in
the
first
RTT
packet
of
the
first
one
RTG
packet
from
the
client
is
that
right
is
this
right?
Okay,
it
looks
fairly
similar
to
the
other
one.
The
difference
is.
If
you
look
at
the
one
RCT
case,
you
send
the
retire
keys
frame
later
at
the
client.
I'm,
not
sure
that
I
understand
out,
though,
do
you
want
to
speak
to
this
David.
L
L
H
The
this
is
the
question.
Please,
yes,
jarett's
cannot
see
google,
so
we've
been
kind
of
going
back
and
forth
and
I
think
what
Martin
has
been
doing
a
good
job
demonstrating
is
we
can't
find
a
like
a
really
clean
solution,
but
in
indeed
in
that
particular
design?
That
was
the
one
I
had
a
few
weeks
ago.
The
idea
was
that
you
send
retire
keys
when
everything
that
you
want
to
sent.
There
has
been
acknowledged
from
some
implementers
opinions.
H
M
H
H
Right,
yes,
it
is,
and
just
as
an
alternative.
Another
way
to
key
off,
which
we
were
talking
about
last
night,
is
to
key
off
the
TLS
state
machine
transition.
We're
on
the
client,
you
don't
react
necessary
to
a
single
packet,
but
when
you're
separate
to
us
implementation
off
the
top
tells
you
I
am
now
connected.
The
handshake
is
done.
Then
you
can
send
it.
Then
that
also
works.
You
see
if
I
didn't
restate
what
you.
L
L
I
know
but
they're
the
same
packet.
Well,
no,
he
just
said
like
my
point,
is
that
in
this
case
those
two
are
at
this
droids
have
two
identical
timings
right
and
so
John
you
were
saying
he's
proposing
a
different
rule,
which
is
this
on
the
state
machine
right
yeah.
So
that
was
suggesting
two
different.
J
N
L
E
L
Right
right
right,
you
need
to
you
need
to
wait
for
some
acknowledgement
of
some
sort.
Yes,
yeah
great,
just
just
as
like
give
you
this
I'm,
not
trying
to
argue
at
the
bat
merit.
So
these
things
are
to
try
and
understand.
Oh
yeah,
well
in
a
minute,
I
should
make
sure
I
really
understand
exactly
bill,
proposing
right.
J
J
Then
we
can
talk
about
the
principles
that
drive
them,
because
that's
important
too
next
next
slide
will
actually
highlight
some
of
the
interesting
ways
in
which
there's
changes.
So
what's
interesting
with
this
proposal
is
that
you
send
this
packet
in
the
very
first
packet
you
send
in
after
a
key
update,
because
when
you
initiate
a
key
update,
you
have
to
be
sure
that
you
are
done
with
the
previous
previous
epoch.
J
So
what
this
doesn't
show
is
the
next
key
update,
but
it
does
show
that
you
can
initiate
a
key
update
once
the
once
the
retire
keys
frame
has
been
and
retires
keys
frame
becomes
the
things
that
you
would
send
in
this
epoch
that
need
to
get
completed
and
transmitted
and
acknowledged
before
you
move
on
to
the
next
phase.
So
it's
no
longer
crypto
frames
that
were
concerned
with
here.
It's
the
retire
keys
frames
that
you
would
use
to
drive
that
that
decision-making
process,
so
that
I
know
how
to
restate
that.
J
F
E
J
L
So
it
seems
to
me
that
this
actually
is
importantly
different
from
the
rule
we
applied
in
the
previous
slide,
which
is
the
rule
applied
in
a
previous
slide.
Was
the
data
has
been
delivered
and
knowledged
through
a
living
on
this
slide,
however,
is
not
the
day
has
been
delivered
in
knowledge,
because
I
can
just
send
it.
I
can
just
send
it
again,
the
new
epoch
and
so,
and
it's
like
I
guess,
I'm
struggling
to
actually
wrap
my
head
around
exactly
what
the
rule
long
and
apply
my
code
is
so.
J
L
I
understand
but
but
the
point
is
that,
like
on
it
so
I'm
sending
an
M
right,
you
know
and
I
play
like
all
sorts
of
data
like
stream
data
are
standing
in,
am
right,
yeah
and
that,
but
that
the
stream
data
does
not
matter
for
the
purposes
of
this
calculation
I
I
understand,
but
on
the
question
is:
when
can
you
send
retiree
keys,
right
and
you're
gonna
say
on
but
I
mean
you're
gonna
say
you
can
summer
hierarchies
well?
The
previous
hierarchies
has
been
acknowledged
right,
yeah.
E
L
L
H
H
There
is
a
very
key
difference,
which
is
no
pun,
intended
the
fact
that
what
you
retractable
Smit
frames
at
layer
m
at
layer
n,
so
the
you
know
you're
done
sending
at
a
buck
m
the
moment
you
have
keys
for
a
buck
end,
because
you
know
you
will
never
send
anything
at
a
buck.
Em
anymore,
you
don't
need
a
mac
at
a
park.
M
he's
just
like
I
have
the
keys.
I
will
never
send
anything
o'clock
anymore.
Yes,.
L
I
understood
this
point,
but
my
point,
but
the
point
I'm
making
is
that
that's
like
three
different
tests
in
the
Co
to
have
to
make
for
each
different
kinds
of
transition,
because
the
first
rule
use
they
did
is
not
like
a
mechanic's
enforceable
and
the
other
ones
and
the
other
ones.
All
the
things
mechanically
enforceable.
H
L
H
N
J
Retire
keys
in
one
directly
and
then
the
other
direction,
because
if
you,
if
you
drive
this
just
off
the
retire
keys,
you
can
get
the
simultaneous
update.
And
then
you
end
up
with
no
round
trip
between
that
and
the
next
one
you
can
have.
You
can
actually
end
up
at
a
situation
where
you
go
from
em
to
end.
J
O
Martin
zoom
on
protocol
apps,
so
looking
at
this
diagram
for
key
updates,
it
seems
like
all
we
are
doing,
is
looking
for
the
AK
for
the
retire
keys
frame,
so
this
would
be
equivalent
to
just
not
sending
the
retire
keys
frame
and
just
looking
for
the
up
for
the
ACK
of
a
packet
in
packet
phase
n.
In
fact,
the
retire
keys
frame
is
strictly
worse
than
this,
because
it's
a
single
signal,
as
opposed
to
a
continuous
signal,
correct.
J
J
We
say
you
can
initiate
three
key
updates,
including
the
ones
you've
already
done
up
to
that
point,
and
so
the
you
have
a
frame
that
has
an
explicit
counter
in
it.
So
we
deal
with
some
of
the
retransmission
logic
problems
that
some
of
the
other
proposals
had
you
don't
drive
things
over
hacks,
you
don't
dry
it.
You
don't
have
some
weird
retransmission
logic
for
the
frame
in
case
of
a
key
update.
You
simply
have
the
frame
that
you
send.
J
It
means
that
you
can
hold
off
the
key
update
in
two
till
you're,
probably
ready
for
it.
What
Kazu
has
kazuo
proposes
in
this
one
is
not
doing
anything
for
the
initial
two
handshake
transition
and
using
the
text.
That's
currently
in
the
draft
that
some
people
are
unhappy
about
for
driving,
that
transition,
and
otherwise,
just
using
this
frame
to
say
when,
when
when
a
kid
updates
are
possible,
I
think
the
the
very
first
one
of
them
would
be
used
as
the
basis
for
signaling.
Maybe
we'll
need
to
do
things
like.
J
And
all
sorts
of
other
things
we
should
talk
about
migration
as
well,
because
that's
something
that's
come
up
next
slide.
Please
I
think
we
have
something
here,
and
so
the
idea
here
is
that
you
have
the
the
implicit
drop,
the
initial
keys
somewhere
I'm,
not
sure
whether
this
is
entirely
correct,
but
you
have
the
initial
drop
of
the
drop
of
the
initial
keys,
driven
off
implicit
signals
of
some
sort
and
then
once
you're
ready
to
start
doing
key
updates.
J
Whenever
that
happens
to
be
you,
you
send
this
frame,
saying
I'm,
distantly
updates,
I,
think
1
or
0
is
the
first
one
I'm,
not
sure
whether
that's
I,
don't
think
we
fixed
that
one
I
put
0
in
but
I
think
we
might.
We
might
want
to
say
that
you
know
one
is
the
right
answer
there,
but
that's
another
problem.
Yeah.
J
Is
that
number
supposed
to
mean
so
the
number
means
the
number
of
key
updates
that
you're
willing
to
accept,
including
the
ones
that
have
already
happened.
So,
if
I,
this
guy's,
no
key
updates
have
happened,
you
send
the
frame
I'm
not
willing
to
accept
any
more
key
updates
on
this
connection.
It's
what
0
means.
If
you
were
to
send
one,
it
means
that
you
can
update
once
so.
If
there.
P
P
J
J
J
If
you're
willing
to
do
trial
decryption,
you
can
send
this
way
earlier,
but
as
a
practical
matter,
you're
going
to
do
this
when
the
handshake
is
done
and
you're
you're
ready
to
start
reading
with
the
new
keys
and
you're
sure
that
you
want
you're
fairly
sure
at
least
that
you
won't
be
receiving
anything
with.
It
can
be
confused
for
the
key
update
that
you're.
Looking
for.
F
E
Christian
Reda
mom
when
I
look
at
these
diagrams.
There
is
one
practical
issue
that
I
have
is
that
I
know
when
I
can
stop
sending
any
given
ebook
right,
because
I
mean
if
my
back
is
severe
acknowledged,
I
know:
I,
don't
need
that
anymore.
I
could
get
rid
of
my
right.
Key
I
could
get
rid
of
my
cache
copies.
I
could
get
better
many
things.
What
I
don't
know
is
when
I
should
stop
acting
whatever
is
sent
by
the
peer.
E
Because
what
I
don't
know
take
the
case
of
this
diagram
there,
the
client
and
check
contains
there.
So
the
client
finish
the
the
first
kind
and
check
okay
and
the
the
problem
for
the
client
for
the
sellers
to
know
it
is
to
stop
acting
that
saying
if
the
clients
repeats
it
because
it
believes
it
hasn't,
been
act,
etc.
So
that's
the
rule
I
mean
they
will
at
what
point.
Do
I
not
need
to
worry
about
sending
repeated
acts
and
things
like
that.
I
J
J
J
Next
next
place,
this
one
was
in
an
earlier
version
of
one
of
the
four
requests
that
I
put
together.
I
think
because
whoever
suggested
that
we
create
a
continuous
signal
by
using
a
neck
one
of
those
spare
bits
that
we
have
in
that
first
octet,
essentially
the
bit
would
be
you
can
you
can
initiate
a
key
update
from
this
and
you
it's
carried
in
every
packet,
so
it
has
the
the
advantage
of
not
having
the
problems
that
I
think
someone
pointed
out
about
Martin
pointed
out
about
the
frames
that
we
have.
J
K
J
Signal
doesn't
have
any
special
retransmission
rules,
it's
just
a
different
way
of
signaling
things,
I
think
we're.
Probably
what
we
need
to
do
now
is
discuss
the
the
principles
that
are
driving
this
one
rather
than
then
talk
about
the
specifics
of
the
of
the
signaling
and
talk
about
what
the
what
the
triggers
are
for,
generating
that
that
signaling,
so
I
think
I
have
a
little
bit
more
but
I
turn
over.
What's
here,
can
we
skip
ahead?
See?
What's
there
all
right?
J
Let's
talk
about
this:
they
don't
all
use
a
frame
again
slides
problems,
but
there
is
an
explicit
signaling
in
all
of
the
proposals.
What's
interesting
about
all
the
proposals
that
hasn't
been
discussed
so
far
is
that
endpoints
can
block
CLE
updates
by
not
sending
the
frame-
and
this
has
some
nice
properties
for
some
from
some
angles,
and
otherwise
what
Kazuo
pointed
out
is
that,
with
the
ability
to
block
a
key
update,
you
can
also
control
the
number
of
keys
that
you
have
active
at
any
one
point
in
time.
J
So
it's
always
the
case
that
you
can
limit
the
number
of
right
keys
that
you
have
to
one,
because
you
only
ever
need
to
write
with
one
particular
set
of
keys.
Typically
during
the
handshake
is
a
little
bit
funny,
but
generally
you
can
limit
that
to
one,
but
the
number
of
Reed
keys
that
you
have
active
if
you
allow
unbounded
key
updates,
there's
the
possibility
that
you
need
to
maintain
multiple
of
them.
If
you're
concerned
about
not
losing
packets
simply
because
they're
on
indecipherable
the
time
limit.
J
There
is
something
that
we're
suggested,
but
primarily
the
time
loadings
exists
deal
with
reordering
on
the
network
and
delay
packets,
but
you
can
do
things
like
delay
the
time
that
delay
the
time
that
you
send
the
signal
so
that
you
have
a
period
of
time
to
accept
all
the
packets
from
the
old
keys
before
you
allow
even
newer
keys
to
be
installed,
then
you
can
work
at
things
down
next
place.
What's
different
is
where
the
where
the
signals
have
happened
so
because
I
was
arguing
for
an
explicit
counter.
J
Any
of
these
proposals
can
be
modified
to
use
an
explicit
counter,
and
then
you
don't
need
to
worry
about
it,
David's,
one
less
so
because
the
way
that
it's
that
the
logic
works
drawback
is
it's
more
stuff,
it
allows
for
more
than
one
update.
It
can
be
wrong
if
it's
wrong,
just
ignore
it,
but
there's
a
bit
more
logic
involved
in
dealing
with
it.
J
The
problem
with
the
encryption
level
and
the
ambient
signal
is
that
you
need
to
worry
about
retransmission
rules,
whether
it
be
to
drive
for
the
logic
forward
or
whether
it
be
to
suppress
free
transmissions
of
the
of
the
frame
and
it's
smaller.
But
you
know
whatever
these
things
are
infrequent
so
I,
don't
think
we
need
to
worry
about
that
one.
It
all
that
much
next.
J
Because
there
are
suggest
that
the
implicit
signal
on
the
initial
handshake
handshake
transition
is
is
okay,
others
use
an
explicit
signal.
The
thinking
here
has
evolved
a
little
bit
those
people
who
would
prefer
to
drop
initial
keys
as
soon
as
possible.
We
should
discuss
this
now,
I
think.
If
you
want
to
talk
about
that,
basically
decided
that
you
can
throw
away
the
initial
read
keys
as
soon
as
you
have
hand
checked
keys.
J
If
you
want
to
use
any
of
these
mechanisms,
and
the
reason
we
might
want
to
do,
that
is
that
we
want
to
make
sure
that
endpoints,
don't
accept
connection
closes,
for
instance,
in
initial
packets
and
allow
for
denial
of
service
for
a
connection
that
has
gotten
to
the
point
where
you
have
shared
shared
state
of
some
sort,
which
would
appear.
So,
let's
talk
about
that
for
a
little
bit
before
we
move
on.
It's.
H
Ganassi
Google,
so
absolutely
the
initial
keys
are
the
ones
that
we
really
have
a
security
problem
if
we
don't
drop
as
soon
as
possible
for
exactly
the
other
reason,
they're
not
authenticated
and
integrity
protected.
Anyone
can
send
anything
there
so
they're.
The
ones
were
even
though
I'm
putting
a
very
strong
proponent
of
an
explicit
signal.
All
the
time
over
something
implicit,
you
can't
physically
send
a
message
at
the
handshake
level
that
the
client
like
it'll,
receive
it
necessary
one
RTT
too
late.
So
or
those
are
that's
on
the
server
you
know.
H
So
what
that
means
is
you
have
to
key
off
of
having
the
client
and
server
hello's,
which
means
that
now
you
have
the
handshake
keys.
So
as
soon
as
you
have
the
handshake
keys,
you
need
to
toss
away
the
initial
and
one,
do
you
want
to
talk
about
the
being
able
to
discard
the
read
in
the
light
and
set
the
times?
I?
Think
that's
the
key
property
here,
yeah.
J
H
H
And
then,
once
you
finish,
the
entire
handshake,
you
just
toss
the
whole
initial
infrastructure
away.
So
that's
when
you
throw
the
read
keys
and
the
right
keys,
all
the
outstanding
packets
die.
So
that's
not
as
clean.
Yes,
it
doesn't
get.
Actually
you
just
shoot
that
whole
piece
of
memory
in
the
head,
yeah.
L
And
quite
possibly,
you're
like
five
or
six
times,
even
though
actually
you
would
even
actually
run
an
analogy
before
it,
because
the
client
certificate
is
potentially
large
and
the
end
hazard
has
no
events,
so
no
the
server
the
what
causes,
what
what
is
it
that
causes
the
server
to
stop
retransmitting
its
first
flight,
and
the
answer
is
that
it
perceives
some
acknowledgment
from
it
from
the
client.
What
is
that
message
and
you
handshake
packet
yeah?
This
is
like
holding
your
piece
of
machinery
to
solve
this
like
really
incredibly
trivial,
screwed
apart.
H
B
So
I'm
not
gonna,
cut
the
queues
now,
but
I'm,
very
conscious
that
you
know
we
asked
the
wider
ITF
community
to
come
and
talk
about
recovery
in
this
session.
I
don't
and
it
seems
like
the
number
of
people
who
are
really
engaged
in
this
discussion
is
relatively
small
and
they
see
each
other
a
fair
amount.
So,
let's
continue,
but
let's
keep
in
mind
that
maybe
we
have
ten
or
so
more
minutes
to
do
this
and
see
if
we
can
make
progress
in
that
amount
of
time.
Okay,.
O
Hello,
yep
it
Mike
so
in
in
Tokyo
I,
like
the
idea
of
using
a
unified,
explicit
signal
for
dropping
this,
the
keys
or
all
keys.
But
looking
at
the
different
proposals
that
that
were
presented
here,
it
seems
like
the
initial
and
handshake
keys
are
special
and
we
will
need
special
rules
for
them
anyway,
no
matter
which
of
the
three
three
or
four
proposals
we
adopt.
O
So
I
now
prefer
having
an
implicit
signal
to
drop
to
drop
initial
keys,
because
I
realized
that
there's
a
pretty
cool
thing
we
can
do.
Can
you
go
back
a
slide
to
the
diagram?
Oh
yeah
just
pick
any
diagram,
the
other
one.
So
the
server
knows
when
it
sent
its
server
hello.
So
the
server
can
drop
the
initial
keys
right
after
receiving
the
initial
packet
from
the
client,
so
the
server
will
only
accept
a
single
packet
with
initial
keys.
So
there's
no
injection
attack
possible
in
the
direction
of
the
server.
O
E
Like
to
say
that
I'm
very
much
agree
with
what
Martine
said,
ok
is
that
the
initial
is
special
and
you
have
to
consider
that
any
implementation
will
be
tempted
to
do
something
special
for
the
initial
packets.
So
we
could
just
as
well
acknowledge
that
and
say
yeah
I
mean
basically,
if
I
have
my
handshake
keys,
I
don't
need
the
initial
anymore,
at
least
on
the
client
side
and
on
the
server
side.
It's
pretty
wise
to
keep
it
until.
You
know
that
this
good
client
has
handshake
key
too,
but
it's.
N
Yes,
what
Google,
yeah
I
tend
to
increase
agree
that
at
this
point,
we
probably
should
need
to
separate
these
signals.
That's
mostly
what
I
was
gonna
say.
The
other
comment
was
that
David
and
Martin's
comments
are
interesting.
Ideas,
I
think
it's
best
to
think
of
those
as
optimizations
a
server
could
perform
rather
than
a
necessary
feature
of
this
mechanism,
because
I
think,
if
that's
what
I
think
that's
a
better
way
of
thinking
about
personal.
L
People
operating
under
risk
in
order
Montes
environment,
any
injection
attack
you
have
to
have
assets
that
clients
initial.
Do
your
clients
initials
require
generate
your
notepad
can
be
valid
for
the
server
and
his
connection
period.
So
your
330
peers
to
be
that
the
attacker,
for
some
reason,
has
access
to
the
clients.
Initial
can't
like
can't
like
give
the
packet
in
before
it
for
the
other
quarter.
That
happens
and
also
can't
transmit
its
own
bogus
initial.
L
The
other
direction,
which
which
recalls
the
client
about
the
connection
down
like
neither
of
those
things,
is
true
in
particular
the
second
one.
Is
it
true
on
and
in
particular
to
look
so
let
us
say
that
you
have
an
attacker
who's
on
path
and
but
KITT,
but
can't
control,
and
this
guy's
back
by
the
way.
My
request
was
when
actually,
when
a
threat
model
for
this
situation,
as
opposed
to
think
we're
using
trying
to
find
a
tax,
they
can
count
on
that.
L
There
are
basically
they're
there,
their
attackers,
which
are
on
which
are
on
path.
You
can
see
the
traffic
and
will
always
win
there
and
can
always
put
their
packet
in
front.
There
are
attackers
which
can
they
put
their
packet
in
front
and
their
attackers,
which
turns
on
those
are
three
categories
of
attackers
on
the
first
kind
of
attacker
will
always
you'll
turn
the
connection.
Regardless
of
anything
we
do
here.
L
Second
kind
of
your
attacker,
you
might
say,
would
not
be
able
tear
that
connection,
because
it
will
always
this
race
to
the
server,
but
then
with
them
in
the
waste,
a
client,
and
so
they
only
have
to
be
a
posture
which
is
slated
for
Sur,
which
has
to
be
president
between
the
client
server.
They
said
that
the
client
initial,
which
caused
that
has
me,
turned
out
so
someone
please
describe
to
me
an
attack,
it's
actually
defended
against
by
by
this
mechanism.
On
that
the
best
answer.
O
Yeah
I
can
do
that.
So
the
thing
is:
if
a
client
receives
an
initial
packet
that
closes
the
connection,
a
client
might
be
willing
to
wait
for
a
certain
time
if
it
receives
another
and
another
initial
packet.
That
looks
valid,
because
the
client
has
the
interest
in
establishing
the
connection.
So
if
you
receive
the
the
attackers
initial,
you
just
say
like
okay,
it
looks
like
a
connection
close,
but
a
wait
for
another
100
milliseconds
or
so.
L
L
J
L
F
Iyengar's
I
think
it's
already
starting
to
happen,
and
it
might
be
worth
actually
not
just
continue.
This
conversation
elsewhere,
but
I
was
gonna,
say,
is
separated
in
the
conversation.
What
Martin
said,
Martin's
him
and
said
earlier
is
important
in
another
way,
which
is
that
the
conversation
for
went
drop.
The
initial
keys
can
be
separate
from
what
to
do
with
the
handshake
keys
and
one
oddity
he's
I
think
it
might
be
useful
to
actually
separate
those
two
conversations,
because
then
you
can
talk
about
a
threat
model
for
the
initial
separately
and
deal
with
that
separately.
F
J
J
F
A
F
R
Just
wanted
to
respond
to
it,
cuz
and
well,
there's
a
merit
of
service
coming
in
child
case
as
far
as
possible,
because
that
approach
allows
only
the
client
use
the
plank
has
the
capability
of
handling
multiple
pairs
of
case.
Then
it
would
defense
without
requiring
service
to
do
a
costly
work.
So
I
think
it's
a
bit
there's
a
benefit
in
letting
the
server
to
drop.
10
buckets
I
shall
read
case.
Also,
that's
possible.
L
Yeah
I
think
there
may
be
some
setting
offenses
but
like
I'm,
like
what
I'm
asking
people
actually
worked
out
like
I've
seen
a
lot
of
the
law
of
discussion,
this
working
group
for
the
past
year
and
a
half
of
like
very
specific
attacks,
then
we've
had
various
picks
defense
forward.
Any
concrete
theory
about
we're
actually
trying
to
publish
and
what
I'm
asking
for
is
a
concrete
or
we're
trying
to
accomplish
about
what
exactly
the
hacker
is
allowed
to
do.
L
J
The
reason
that
I
suggested,
that
is,
that
these
are
very
different
things
that
we're
discussing
one
is
a
bug
and
the
other
one
is.
It
is
we're
dealing
with
this
threat
model
question
that
you
raised
right
and
I
think
we
can
fix
the
bug,
because
we
all
agree
that
one
party
T
explicit
signal
is
the
way
we
solve
the
bug,
and
so
I
would
rather
fix
the
bug,
move
on
of
that
with
that
and
try
to
close
that
discussion,
and
then
we
can
argue
to
our.
L
L
B
Seems
like
we're
getting
to
diminishing
returns
in
the
discussion
here,
or
indeed,
we've
we've
been
there
who,
in
the
room,
is
in
sorry
Ted,
we'll
get
you
in
just
a
second
I
just
wanted
to
ask
who,
in
the
room,
is
interested
in
and
feels
invested
in
the
outcome
of
this
discussion.
Quick
show,
hence:
okay,
it's
mostly
the
usual
suspects,
Thank
You
Ted.
Please
go
ahead.
Teri.
D
We
can
actually
say,
okay,
that
that's
a
that's
a
bug
that
causes
a
reset
and
it's
it's
gonna,
be
rare
enough.
That
reassociation
in
in
quick
is
relatively
cheap.
Let's
just
do
that.
If
what
we're
optimizing
for
is
we
never
want
to
throw
the
packets
on
the
floor
and
therefore
we
don't
want
this
case
to
to
exist.
D
J
I'm
I'm
really
happy
that
this
group
is
so
good
at
going
back
to
the
drawing
board.
Every
time
we
discussed
this
issue,
we
discussed
this
in
Tokyo
and
had
largely
the
same
discussion
and
I
thought
that
out
of
the
discussions
of
Tokyo,
we
at
least
made
progress
on
the
key
updates
thing,
but
it
doesn't
I'd
like
to
see
if
we
get
somewhere
towards
in
conclusion
on
that,
and
even
if
we
have
to
wind
that
back
I'd
be
happier
my
making
forward
progress
on
that
then
and
and.
B
S
B
F
I
know
this
is
but
not
not
on
the
topic
of
normal
technical
details
here
at
all,
but
we
have
had
actually
fairly
good
success
with
using
small
design
teams
in
this
working
group.
I
think
in
the
past,
even
on
thorny,
complicated
issues,
we've
actually
managed
to
make
some
thing.
I
know
it's
not
the
best
necessarily
way
to
go
forward.
B
People
together
in
a
room
we
said
this.
That
was
my
next
suggestion.
Was
you
know
the
number
of
people
who
raised
their
hands
looked
a
little
bit
too
big
for
a
successful
design
team.
So
if
we
can
pare
that
down
to
thing
on
the
order
of
I'm
thinking,
eight
ish
people
who
are
willing
to
spend
some
time
this
week,
we
might
be
able
to
make
some
progress
I
just.
I
A
Bernhard
at
the
minute
least,
a
bug
right,
we've
actually
hit
in
inter
up
so
that
that
is
something
that
we
certainly
want
to
fix
urgently
and
the
other
issue
we've
actually
also
hit
with
at
least
one
stack,
did
something
that
was
legal
according
to
what
we
wrote
down,
but
it
cost
interrupts.
Is
that
have
not
worked
very
great,
so
those
are
not
sort
of
your
mate
made
up
problems
actually
sort
of
they
need.
We
need
to
fix
them
soon.
If
we
want
to
ship
b1,
Brian,
hi,.
L
Jana
one
thing
that
I
sort
of
noticed
while
I
was
trying
to
keep
up
with
that
discussion
is
this.
It
does
seem
to
be
emerging
consensus
around
splitting
these
right,
like
so
that
that
seems
like
rough
consensus
and
I
would
say
that
that
might
be
the
starting
point
for
the
design
team
is.
Do
the
dog
I
mean
it
seems
like
that's
where
you
were
in
Tokyo
I
wasn't
in
Tokyo,
but.
A
This
team
forms
I
would
personally
prefer
if,
if
somebody
was
coordinates,
who
wasn't
an
editor
or
otherwise
already
doing
ten
different
PRS
right.
So
so
you
don't
have
to
step
back
if
you,
but,
but
so
somebody
who
is
whose
understands
this
particular
problem,
spies
and
and
has
maybe
a
some
spare
cycles
to
corral
the
usuals
together
David.
Thank
you,
okay,
cool.
So,
if
you're
interested
in
this
talk
to
David
and.
H
B
B
A
T
B
A
N
All
right
so
first
thing
when
I
start
off
weather
update
of
recovery,
sings
Bangkok,
so
we've
changed
quite
a
number
of
things
next
slide.
So
a
review
of
key
points
just
about
quick
in
general.
Just
so,
if
you're,
forgetting
from
Bangkok
pocket
numbers,
monotonically
increase
in
send
order,
a
cranes
acknowledge
one
or
more
ranges
of
packets,
there's
an
explicit
actally
on
each
act
frame
and
the
pier
communicates
the
max
act
too
late
that
it's
going
to
use
typically
the
time
or
value
during
the
handshake.
So
each
pier
knows
what
the
other
appears
max
act.
N
Delay
is
there's
an
overview
at
ITF
103
from
TCP
M
pitch
other.
Did
it's
very
nice
as
well
as
104
just
yesterday,
so
the
slides
are
linked
for
my
slides,
so
there
were
almost
as
many
changes
since
draft
16
as
there
have
been
in
all
previous
revisions.
I
realize
that
when
looking
at
the
release
notes
so
yeah
there's
been
a
fair
number
of
changes,
I'm
gonna
try
to
go
over.
N
So
one
one
change
that
sort
of
simplified.
A
lot
of
things
is
the
old
texts
and
the
old
pseudo-code
assumed
that
you
are
either
running
in
Thailand
threshold,
boss
detection.
So
that's
you
know
in
in
some
time-space
fraction
of
an
RTT
or
in
packet
threshold.
So
you
know
kind
of
a
typical
FAQ
or
dewbacks
iowa
packet
threshold
loss
detection.
We
are
currently
assuming
now
that
you
do
both
at
the
same
time.
N
N
So
a
larger
change
is
to
merge,
TLP
and
RTO
into
something
we're
now
calling
probe
time
out.
Quicks,
TLP
and
RTO
were
always
subtly
different
from
TC
P's,
and
it
was
not
really
particularly
well
thought
out
that
one
of
them
had
a
very
different
formula
than
the
other.
So,
as
you
can
see,
TLP
was
1.5
times
s,
RG
t
plus
max
AK,
to
lay
with
also
a
min
time
out.
Rto
was
you
know
s
RT,
t
plus
RT
T
bar
these
two
equations
have
something
to
do
with
each
other,
but
are
not
particularly
well
related.
N
Tlp
sent
one
packet,
RTS
n
two
packets
RTO
has
exponential
back-off
Tila
P
did
not
it.
There
was
really
no
I,
think
really
good
reasoning
for
the
difference
between
the
mechanisms,
besides
kind
of
historical
accident,
so
we
combine
them
so
the
time
out
is
now
very
similar
to
the
old
RTO
formula,
smooth
our
TT
plus
max
of
four
times
RT
t
far
and
kate
granularity.
This
is
actually
taken
from
that
see
is
tcp
our
RTO
RFC.
N
A
N
A
N
Touche,
thank
you.
Returns.
Middle
has
also
been
renamed
to
active,
listening
I,
believe
that
happened
right
before
Bangkok.
But
yes,
that
is
mm-hmm.
They
are
intended
to
be
the
same
thing.
There's
literally
a
wheel
place
one
word
with
another
because
we
transmittable
head
and
they
get
ambiguous.
Meaning
is
an
editorial
change.
N
J
U
G
Eric
near
so,
do
we
actually
need
those
to
be
the
same
thing.
I
know
that,
right
now
it
seems
like
everything
is
but
say
we
wanted
to
in
an
extension,
Nasri
transmit
a
frame,
but
still
have
it
illicit
acts,
but
those
are
two
very
different
concepts
that
are,
admittedly,
related,
but
very
much
not
the
same
thing
for.
N
N
N
N
S
N
N
However,
there
are
certain
cases
in
this
process
during
do
where
the
timer's,
our
chef,
that
you
can
actually
extend
the
RTO
essentially-
and
you
might
not
actually
have
you-
know,
an
RTO
or
to
RTOS
or
three
darts
year
as
fire,
and
instead
you
might
just
you
know,
trickle
out
some
tiny
amount
of
data
for
that
period
of
time,
and
so
the
key
concept
here
is
c1
is
reduced
to
minsu
and
when
all
packets
prayed
prior
to
an
acknowledged
RTO
packet,
are
lost
over
a
long
enough
period
of
time.
Oh
next
slide.
N
Sorry,
that's
what
I
meant
to
be
reading
knew
that
didn't
make
any
sense,
and
the
period
is
currently
three
tons
the
PTO
time.
Oh
so
this
is
in
terms
of
time
very,
very
comparable
to
the
old
text.
So
we
tried
to
keep
the
functionally
as
equivalent
as
possible,
but
this
takes
into
account
the
fact
that
the
application
might
be
driveling
data
for
a
long
period
of
time
and
the
PTO
timer
might
not
actually
fire
just.
N
N
So
there
we
are
now
going
to
limit
active
a
to
max.
Actually
so
currently
the
the
concept
of
active
a
is.
You
have
an
R,
DT
estimate
that
is
actually
observed,
and
then
the
P
R
communicates.
Ok,
you
know
there
was
this
much
delay
back
time
before
I
actually
sent
that
that
action,
so
you
can
compensate
in
your
SR
GG
measurements.
N
However,
one
could
potentially
say
well,
I
know:
I
have
100
millisecond
or
it's
T.
I'm
gonna
give
you
like.
You
know
a
95
millisecond
actally,
and
you
know
that
will
cause
you
to
shorten
your
timer
and
especially
with
the
you
know,
I
mean
RTO
that
could
potentially
like
cause
appear.
Just
previously.
We
can
spend
a
lot
of
data
either
intentionally
or
otherwise
so
next
slide.
N
So
nobody
now
limited
to
a
minimum
of
actally
and
max
act.
Delay
and
that
ensures
that
the
peer
is
incentivized
to
actually
advertise
a
max
act
away,
value
that
is
kind
of
consistent
with
what
it
actually
believes
it
can
it
can.
It
can
achieve,
and
so,
if
it
ever
does,
is
an
overlay
Lomax,
actively
value
it'll
just
come
out,
as
you
know,
into
PSR
TT
measurement,
just
like
it
wouldn't
tcp
excellent.
N
Yes,
we
we
had
some
nice
text
on
discover
discarding
recovery
state,
so
this
came
up
earlier
with
the
various
keys
ready
proposals
and
basically
there
are
a
variety
of
situations
in
which
you
need
to
actually
just
discard
your
recovery
state,
because
there
is
no
way
that
it
could
possibly
be
acknowledged.
So
zero
RTG
rejection
is
one
dropping
keys
is
another
and
the
solution
is
fairly
straightforward.
N
You
discard
all
the
recovery
state
for
those
packets
in
terms
of
like
tracking,
what's
outstanding
and
you
remove
them
from
bytes
in
flight
because
they
can't
be
acknowledged
or
lost,
and
you
will
never
know
whether
they
are
acknowledged
or
lost.
So
this
is
a
fairly
mechanical
process,
but
particularly
critical
of
given
the
conversations
about
key
dropping
we're
having.
N
However,
it
didn't
really
say
like
what
to
do
if
you
weren't
fast,
the
packet
pacing,
and
so
now
we're
actually
specifically
saying
that
you
should
be
doing
slow
start
after
idle.
If
you
are
not
pacing
and
if
you
are
pacing,
then
you
can
send
up
to
an
initial
window
and
then
you
must
pace
out
the
rest
of
the
rest
of
the
window.
So
we
think
this
is
in
keeping
both
with
kind
of
common
desk
processes
and
operating
systems
like
Linux,
and
also
providing
a
suitable
incentive
to
add
pacing
to
stacks.
F
Myself,
so
one
comment
yourself
in
the
when
I
was
reading
the
draft,
where
this
is
defined.
It's
currently
defined,
as
the
idle
state
of
the
sender
is
defined
as
when
there
is
nothing
to
send
right
and
there
is
nothing
outstanding
in
the
network,
but
in
if
you
look
at
the
tcp
RFC
that
define
how
to
respond
to
idle.
F
It
basically
says
that
there
has
to
be
a
peep
there's,
a
period
defined
for
which
it
has
to
be
idle
before
you
reset
the
clinician
would
know
so
that
period
is
defined
to
be
a
birthday
time-out,
essentially
how
that
ends
up
being
like
me,
not
even
TCP,
but
I
think
we
need
to
need
a
more
crystal
definition
of
what
idle
is,
after,
which
you
drop
the
congestion
window.
So
that
is
missing,
and
the
other
thing
I
would
like
to
point
out
is
is
not
not
many
stacks
are
doing.
Tcp
stacks
are
doing
this
by
default.
N
F
General,
you
can
just
add
a
comment
to
that.
I
mean
I.
Think
there's
there's
a
difference,
though
right
semantically,
when
TCP
defines
this
to
be
clear.
They
do
there's
no
talk
about
pacing
at
all,
so
the
expectation
is
that
bursts
are
okay
right
after
you've
gone
into
idle,
I.
Think
the
the
premise
that
we've
operated
on-
and
maybe
that's
that's
the
issue
that
we
need
to
discuss.
F
The
premise
we
operated
on
here
is
that
if
you
are
pacing,
then
you
should
start
pacing
immediately
as
well
and,
and
the
idea
is
that
you
shouldn't
send
a
whole
initial
Windows
worth
or
you
shouldn't,
send
the
whole
condition
Windows
worth
of
bursts
up
front
now.
This
is
different
from
what
TCP
does
and
I
would.
I
would
argue
that
TCP
should
also
have
this
recommendation
not
to
burst
at
any
point
in
time,
but
that's
a
premise
that
we've
applied
here
absolutely
agree.
I
think
this
is
a
good
change.
F
All
I'm
saying
is
that
for
implementations
that
are
not
facing
the
the
idle
period
needs
to
be
defined.
More
crispy,
you
mean
more
liberally
because
it
is,
it
is
different
right
now
it's
just
defined
as
immediately
I
think
that
needs
a
little
bit
more
debate,
but
yeah
yeah
I'll
open
an
issue,
and
then
we
can
discuss
Thanks.
V
N
They're,
very
possibly
I
think
they
can
I
go
back
to
what
John
and
Praveen
were
just
talking
about.
I
think
it
probably
makes
sense
to
figure
out
what
our
our
core
goals
are
here.
It
seems
like
a
good
core
goal
is
to
to
ensure
we
don't
drop
large
earths
into
the
network
because
the
network's
likely
to
drop
them,
and
so
we
need
to
balance
that
with
trying
to
be
a
little
more
liberal,
with
implementations
that
don't
support
pacing
so
yeah.
If
you
could
add
a
reference
to
that
draft
to
the
issue
that
Praveen
opened.
B
K
K
F
Gouri
so
July
anger,
we've
done
this
right
in
pcbm
for
quite
a
while.
It's
called
new
cwv
and
that's
the
that's
the
draft.
That's
actually
that
reference
in
the
in
the
quick
draft
we've
gone
through
yeah,
sorry,
yeah,
the
RFC
now
and
that's
that's
already
referenced
in
the
quick
draft
and
we
basically
said
what
what
Ian
said
is
that
you
know
we
have
stuff
they're
saying
you
can
follow
the
recommendations
there,
but
we're
just
doing
the
bare
minimum
required
here.
I
think
the
same
considerations
in
that
RFC
apply
here
completely
I.
F
Sorry
to
close
that
off,
I
think
can
be
ended
up
having
the
discussion
on
the
issue
here
in
the
room,
Maria
you're
right.
It
is
that's
exactly
what
the
draft
says
right
now.
Is
you
collapse
the
condition
into
as
soon
as
you
go
idle
and
that's
the
conservative
behavior?
If
you
want
something
more
liberal
than
go,
look
at
me.
So
you
see
the
V
is
what.
N
Please
take
a
closer,
read
and
yeah
feel
free
to
file
an
editorial
issue.
If
you
think
it's
just
sufficiently
clear,
so
we
moved
the
pseudocode
to
the
appendix
the
text
was
always
intended
to
be
normative
and
complete.
I
think
there's
still
a
few
more
PRS
to
to
make
that
actually
true.
But
there's
also,
ideally
a
goal
that
you
know
the
pseudo-code
might
compiled
by
that
some
definition
of
compiled
in
the
board
Python.
But
it's
it
doesn't
it
currently
not
but
yeah.
N
N
At
the
current
draft
traffic
19,
you
know,
has
the
the
various
studio
code
updated,
so
it
kind
of
indicates
what
you
should
be
tracking
in
multiple
packet
number
spaces
and
is
generally
clearer
about
how
this
should
have
done.
That's
up
next
I
think
we're
at
the
end.
Okay,
so
these
are
just
a
bunch
of,
and
these
are
basically
the
release
notes
in
16,
17
and
18.
So
you
can
thumb
through
those,
but
this.
B
F
F
N
F
D
A
Question
right,
so
we
we
have
the
new
process
for
that,
we're
already
applying
to
transport
and
to
TLS.
Sorry,
that's
also
I
think
this
might
lead
to
questions
that
that
I
don't
want
to
answer,
but
recovery
and
HTTP
at
the
moment
do
not
follow
a
new
process.
Yet
do
people
feel
like
specifically
recovery
is
ready
to
be
declared
as
capturing
the
consensus
of
the
working
group
in
19
and
I'm
going
forward.
A
B
It
in
and
and
just
to
remind
folks,
you
know,
the
editor
still
have
the
ability
make
purely
editorial
changes
in
terms
of
rearranging
things
and
rewriting
things
that
don't
affect
the
normative
heft
of
the
document
relatively
freely
under
the
new
process.
I
think
the
question
is
whether
that's
going
to
be
possible
whether
the
rewrites
might
impinge
upon
that
and
need
some
working
group
consensus
at
this
point.
B
F
A
I'm
not
saying
that
we
want
to
close
the
document
and
freeze
it
right,
so
we
want
to
move
to
so
in
for
HTTP
and
for
recovery,
we're
still
giving
the
editors
basically
full
control,
letting
them
run
ahead
and
change
the
text,
and
if
people
disagree
right,
we're
rolling
back
this.
This
would
flip
it
around.
Where
any
changed
at
that
mark
and
I
decide
is
not
purely
editorial
would
need
to
see
work
group
consensus
first.
So
this
is
what
we're
doing
in
this
late
stage.
A
N
I
think
we're
getting
close
I
think
it
might
make
sense
you.
We
have
a
variety
of
changes,
I
hope
to
discuss
today
on
the
issues
I'd
like
to
close
those
out
and
then
maybe
start
the
new
process.
It
started
with
draft
20.
Okay,
that's
that's.
My
I
feel
I
think
I
think
we're
pretty
close
to
closing
all
the
substantive
non
editorial
issues
that
are
open
and
so
yeah
that.
N
G
On
over
here,
go
ahead,
I
think
we're
just
now,
starting
to
see
a
lot
of
people
actually
doing
Interop
with
recovery
and
finding
bugs
and
I'm
encouraged
that
most
of
the
bugs
that
we've
found
so
far
I've
been
in
the
implementations
and
not
as
much
in
the
spec.
But
at
the
same
time,
given
the
amount
of
stuff
that
we're
trying
to
focus
on
I,
don't
think
we've
been
steered
wrong
yet
in
recovery
land
by
having
the
editors
have
a
little
bit
more
freedom
to
to
fix
things
up
as
necessary.
G
A
With
you
right,
transport
is
the
one
that
seen
a
lot
of
issues
open
against
it
continuously
and
that
we
want
to
control.
Recovery
has
been
much
more
stable
and
it's
much
the
more
steady
development
right
and-
and
it's
mostly
sort
of
that
eventually
we
want
to
basically
have.
We
were
kind
of
unusual
when
we
started
out
because
we
wanted
to
move
fast
where
we
gave
yeah
there's
lots
of
leash,
and
now
we
want
to
maybe
become
more
like
a
regular
ITF
working
group.
Where
is
actually
consensus
based,
it
won't
change
much
here.
B
I
just
want
to
interject
one
there.
The
other
part
of
this
is
that,
as
we
move
along
having
the
editor
have
that
a
much
capability
also
puts
a
lot
of
responsibility
on
their
shoulders
and
and
part
of
the
discussion
around
TLS
and
and
invariants
and
and
the
transport
was
that
that
was
in
some
ways,
unfair
to
the
editors
and
so
we're
conscious
that
we
don't
want
to
put
too
much
on
Ian's
shoulders
here.
The
other
factor
for
me
is
is
that
in
an
ideal
world,
I
don't
want
all
the
documents.
B
F
July
as
one
of
the
editors
of
the
TAT
I
can
also
say
that
we
we
really
what
Kinnear
is
saying
what
I'm
seeing
now
is
that
there
are
people
who
are
starting
to
interrupt
and
finding
things
you
just
suffered
of
income
and
talk
about
something.
That's
been
there
for
a
little
while,
but
that's
because
they
are
starting
to
actually
pay
attention
to
the
traffic
now
and
I.
F
Personally,
think
that
the
load
on
recovery
has
not
been
very
high
in
the
past,
it's
not
been
very
high
and
we
don't
I,
don't
think
we
and
EMI
can
I
think
we
might
agree
on
this,
but
I
don't
think
that
there's
a
lot
of
there's,
not
a
tremendous
amount
of
churn
on
this
and
in
the
draft
itself,
I
feel
like
there's.
Some
amount
of
agility
at
this
moment
would
be
useful,
so
I'm,
gonna,
I'm
gonna
push
back
against
the
late
stage
process.
Yet.
A
Means
proposal
was
that
we're
doing
it
we
would
maybe
think
about
it
for
20
and
then
I
will
also
want
to
say
that
the
late
stage
process
really
only
makes
the
difference
for
design
issues
and
I.
Don't
see
very
many
design
issues
for
recovery,
they're,
mostly
editorial
where
either
things
were
unclear
or
there's
a
buck
in
the
pseudocode
or
the
text.
But
we're
not
like
this
we're
not
designing
a
new
pedestrian
control
protocol.
Here
right,
we
don't
have
very
many
of
those
like
I,
don't
think
that's
true
I
mean
literally.
F
B
L
I
was
just
that
we
target
London
ish
for
the
same
process,
breach
in
Tokyo,
which
is
surfacing
the
final
issues
last
call
for
movie
ad
and
then,
if
editors
feel
like
they
need
more
time
after
that,
and
we
can
discuss
in
London
if
they
feel
like
they
don't.
Then
we
get
I,
think
that
sounds
reasonable.
Yeah
hi.
L
L
T
Duke
yeah
just
to
amplify
that
I
know
about
four
to
six
weeks
ago,
Christian
compose
on
slack
that
we
add
a
Interop
letter
or
some
sort
of
at
volume
testing,
possibly
in
parallel,
TCP
and
I.
Think
doing
them
in
Interop
is
probably
the
next
best
thing.
Actually,
someone
deploying
something
like
the
latest
draft
in
production,
which
it
doesn't
sound
like
it's
close.
U
Gouri
fares
back
and
yeah
and
I
think
the
auditors
are
doing
a
great
job
here
that
they're
really
kind
of
trying
to
buy
to
the
problem,
but
the
underneath
they're
trying
to
it
with
a
new
set
of
mechanisms
to
make
these
things
work
and
I'm
worried.
We
haven't
done
the
congestion
collapse,
testing
and
really
whether
we
got
the
words
right
so
I'll
be
really
lost
to
freeze
it.
I
think
they
should
be
given
time
to
do
it
until
the
numbered.
If
it's
not
about
freezing
the
docq
yeah.
Okay
I,
know
the
process,
but
everyone.
U
A
B
A
Y
B
N
N
N
N
So
the
the
core
of
this
issue
is
what
should
be
the
initial
handshake
timeout
when
you
have
absolutely
no
other
information
about
the
network.
For
some
reason,
what
are
the
defaults
so
praveen
at
the
very
bottom
helpfully
pointed
me
to
a
paper
by
a
Googler
from
2009
that
kind
of
did
a
cumulative
distribution
of
parties
over
the
Internet
and
said,
if
you
in
the,
if
you
have
a
one
second
timeout',
you
will
have
a
like
two
percent
spurious
retransmit
right.
N
According
to
those
slides
that
yeah
I
point
to
and
RFC
62
98
recommends
a
one
second
timeout'.
My
understanding
is
that
is
no
longer
the
Linux
default.
I
think
the
one
is
default
is
300
milliseconds.
Can
someone
correct
me
if
I'm
wrong
and
so
there's
there's
sort
of
a
divergence
between
common
common
practice
and
what
is
recommended
in
the
RFC?
The
the
number
we
currently
recommend
is
a
default
RT
RT
g
of
100
milliseconds,
which
results
in
a
initial
retransmission
of
200
milliseconds.
N
So
you
know
obvious
here
that
we
might
be
able
to
pick
our
200
milliseconds
300
milliseconds
cos
Linux.
Does
it
and
one
second,
because
it's
in
the
most
recent
RFC
that
references
this
text
to
delight
with
some
pros
and
cons
here,
picking
a
larger
value
by
default
is
actually
not
all
that
bad
because
it
might
incentivize
implementations
to
actually
try
to
do
something
more
intelligent,
like
remember,
recent
RTT
estimates
or
do
other
intelligent
things
that
might
be
overall
beneficial
to
the
network,
so
I
don't
have
a
super
strong
resistance
to
it.
N
F
F
The
oddity
I
think
it's
only
a
problem
when
you're
completely
going
blind
into
a
network,
because
you
could
be
like
on
a
satellite
link
and
then
cause
foodies,
retransmissions,
no
reason
I
think
that's
the
reason
we
have
a
conservative
value
by
default,
but
yeah
if
implement
I,
think
we
should
actually
make
a
recommendation
that
implements
patience,
try
to
use
the
previous
carriage
path
or
TT
as
much
as
possible
in
that.
If
we
do
that,
then
I
think
the
conservative
value
is
not
be
that
much
of
a
problem
in.
F
U
Go
first,
a
slightly
different
touch
if
we
choose
one
second
and
those
people
who
get
routed
over
satellite
hops
are
very
long,
devious
routes
because
the
operators
decide
to
do
that
for
their
traffic
still
function.
And
if
you
have
some
caching
method,
then
we
can
also
deal
with
it.
But
please
don't
optimize.
Just
for
99%
of
people
than
1%
get
a
big
problem.
N
N
N
Practice
you
would
never
expect
it
to
imply
to
0rc
connections,
because
your
RTD
connections
should
have
the
type
of
cached
information
associated
with
the
zero
TTT
information
and
I.
Think
we
call
that
out
in
the
draft
and
if
we
don't,
we
should
I'm
pretty
sure
we
do
so.
We
basically
say
if
you
think
you
know,
do
reserve
our
two
tier
assumption.
You
should
really
store
their
RTT
of
the
resume
connection.
What
we
don't
say
is
what
useful
anarchie.
Oh
we
don't.
We
don't
say
what
which,
if.
B
M
This
is
the
hardest
one
we're
a
little
tongue
constrained.
So,
let's,
let's
focus
please
go
ahead.
Microcosm.
We
have
a
working
document
about
RTO
considerations
in
general
and
T
CPM
and
the
statement
there
is.
You
must
not
use
a
value
less
than
one
second
capital
at
a
must
all
right
now,
the
other
thing
you
said
you
cash,
the
Archie.
You
use
a
cash
value
for
the
Archie
Oh
formula
for
the
RT
for
the.
A
F
Suggest
something
here,
pretty
specific:
you
actually
have
Michael
Dixon
point
of
RT
o
consider
as
a
draft
and
eCPM
and
you're
gonna
have
to.
You
know
basically
be
seven
between
these
two
drafts
for
the
iesg
to
stamp
this
anyways.
So
the
draft
actually
and
I've
discussed
with
McCallum
and
the
wording
here
and
it's
very
carefully
written.
It
says,
in
the
absence
of
any
knowledge,
about
the
latency
of
the
path
the
RTO
must
be
conservatively
set
to
one
second
to
just
counter
what
Michael
said.
F
This
actually
gives
us
room
to
do
three
hundred
milliseconds
or
whatever
small
value
we
want
in
zero,
RTT
and
I
honestly
think
that
we
need
to
we
it's
okay,
to
be
conservative
in
the
non
zero
oddity
case,
simply
because
it's
not
the
common
case
anyways,
and
so
it
seems
to
me
that
we
should
be
focusing
on
the
zero
oddity.
So.
D
N
N
X
Paulie
so
I,
like
the
direction
of
this
I,
think
the
one
second
with
caching
is
a
good
approach
with
regards
to
zero
or
TT
I
think
we
still
do
need
to
make
some
recommendations
about
what
you
do
in
the
absence
of
any
RTT
information,
because
you
can
definitely
do
zero
RTT
on
a
different
network
right.
So
if
I
was
on
life,
I
have
never
been
on
the
cellular
network
before
I.
Don't
know
the
RTT
there.
I
do
need
to
differentiate
that.
X
N
A
good
clarification,
although
I,
would
add
that
most
of
the
time
when
you're
doing
zero
to
T,
you
also
need
to
have
source
address
validation
and
that
would
be
different
across
SL.
What
a
Wi-Fi
network!
So
you
you
could
do
the
resumption,
the
the
TLS
presumption
but
right,
but
you
could
do
source
address
validation
to
be
living
descending
like
three
packets
or
something.
X
B
P
Taylor
relaying
Ingemar
Johansson
note
that
LT
in
some
cases
can
have
a
ping
RT
t
greater
than
100
milliseconds
because
of
various
battery
saving
technology.
On
the
other
hand,
a
flood
ping
may
give
40
millisecond
RT
t
as
the
radio
is
kept
alive.
So
that's
just
a
practical
example
of
yeah
sub1
at
one
second.
A
F
One
point
that,
in
terms
of
cash
values,
I
think
it's
cash
per
path.
So
it's
a
source
test,
IP
combination.
So
when
you
change
the
networks,
you
will
be
using
a
different
source
address
and,
as
is
equivalent
to
starting
the
browser
search.
Basically,
your
only
new
network
with
no
previous
target
information,
so
you
should
not
use
cash
values
soon.
K
N
For
a
little
while
longer
I,
actually
this
is
a
question
for
the
for
the
group.
There's
a
park
tissue
sender,
control
delayed
at
ratio.
This
is
helpfully
opened
by
bug.
Brisco,
there's
extensive
discussion,
but
at
this
point,
I
think
we've
all
decided
that
this
is
probably
appropriate
for
an
extension
or
a
quick
v2.
Is
there
anyone
who
objects
to
us
closing
this
and
declaring
that
I
or
someone
else
should
write
an
extension
for
this
Oh
Bob.
W
All
right,
Briscoe
I,
just
want
to
explain
the
implications
of
not
doing
it.
The
number
of
networks
of
link
technologies
do
act,
thinning
and
the
reason
for
primary
reason
for
putting
this.
You
know
and
they're
all
written.
There
are
three
main
reasons
in
there,
but
the
primary
reason
was
that
I
wanted
to
make
sure
that
quick
did
that
act
finning
for
them
to
discourage
them
from
trying
to
work
out
which
were
the
acts
and
thinning
them.
Yeah.
N
F
Yeah
I,
Jenna
and
God
I
think
in
the
meanwhile.
You
all
definitely
recommend,
as
I've
had
to
a
couple
of
people,
that
the
smallest
packets
you
see
on
the
wire
are
not
necessarily
axon
quick,
I.
Just
sort
of
make
that
point,
because
people
have
asked
me
that
question
for
exactly
that
reason,
because
they
want
to
thin
those
packets
I'm
like
no
actually,
the
smallest
packets
are
not
necessarily
AG.
They
could
be
just
packets
carrying
ping
frames.
So
don't
do
that.
N
N
A
E
N
N
So
this
is,
this
is
fairly
simple.
The
the
text
has
been
updated
substantially.
I
guess
my
my
question
to
both
Praveen
and
the
rest
of
the
group
is
I.
Believe
the
text
currently
says
I
cannot
remember
if
it
says
you
should
send
one
and
you
may
send
two
or
if
you
should
send
to
you
or
may
send
one,
but
I
think
does
that
we're
pretty
much
kind
of
on
one
of
those
two
recommendations.
N
F
N
O
F
F
N
N
Is
there
aa,
23
93
I
have
known
this
for
Nick
banks,
ugly
I,
don't
think
next
year,
but
there's
a
question
of
when
K
granularity,
which
is
the
alarm
granularity
and
the
max
act.
Delay,
which
is
the
peer
specified
max,
actually
should
be
added,
whether
it's
before
after
exponential
back-off,
this
issue
suggested
should
be
after
is
currently
before
it
seemed
safer
to
do
at
it
before
and
that's
why
I
did
it
that
way,
I'm
not
sure.
If
that's
a
well
reasoned
argument.
D
F
In
TCP,
the
minority
is
included
before
so.
In
that
spirit,
I
think
keeping
to
a
glamour
ID
before
is
consistent
with
what
TCP
is
doing
like.
If
you
look
at
keygen
right
is
a
replacement
formula
at
you,
then
then
what
we
have
right
now
is
actually
correct,
but
it
right
at
the
end,
I
actually
posted
a
comment.
Yesterday,
where
there
was
one
possible
change,
we
could
do
to
the
equation.
We
could
probably
take
that
offline,
but
I,
think
keeping
K
again
and
write
it
before
is
probably
more
consistent
with
PCP
Jana.
F
Anger,
I'm
gonna
agree
with
that
and
give
just
one
more
add.
One
more
comment,
which
is
the
whole
point
of
exponential
back-off,
is
that
we
waited
this
long
and
didn't
hear
anything
back,
so
we
should
meet
about
twice
as
long.
It's
a
rule
of
thumb.
It's
not
you
know
some
sort
of
magical
expression.
That's
only
going
to
give
us
the
right
answer
here.
The
point
is
to
try
backing
off
and
backing
on
back
now.