►
From YouTube: IETF103-TCPM-20181106-1120
Description
TCPM meeting session at IETF103
2018/11/06 1120
https://datatracker.ietf.org/meeting/103/proceedings/
A
B
D
C
C
Ok
restart
welcome.
This
is
seconds
40
GPM
meeting
and
please
make
sure
you're
in
the
right
room,
and
this
is
user
not
well,
and
please
keep
this
in
mind.
If
you
have
some
concerns,
you
can
find
the
same
contents
on
the
ITF
webpage
and
thanks
for
volunteering
note-taking
baby.
Thank
you
so
much
and
media.
Thank
you
so
much
for
taking
care
of
jabber
and
before
we
start
a
meeting
breezily
may
remind
when
you
speak
up.
C
Please
see
your
name
at
the
microphone
so
that
note-taker
can
track
your
name,
and
this
is
our
agenda
for
today
and
as
we
have
already
announced,
we
have
a
single
agenda
for
today,
which
is
roster
diction
and
the
congestion
control
in
quick
and
TCP,
and
this
is
not
the
user.
You
know
discussion
topic
for
TCP
and
working
group,
but
I
believe
this
will
be
a
useful
discussion
for
both
quick
working
group
and
this
VM
working
group,
so
I
appreciate,
know
Ian
and
Jenna
for
reading
busy
efforts
thanks.
E
Awesome
so
we
don't
talk
about
I'll,
make
a
small
correction
to
what
yo
she
said.
We
are
not
going
to
talk
about
PCP
condition,
control
or
loss
detection
very
much,
but
we
will
talk
about
quick
loss,
addiction
and
condition.
Control
specifically
we'll
be
talking
about
draft
ITF,
quick
recovery.
If
you
haven't
seen
it,
that's
fine,
you
can
take
a
look
at
it
after
this
meeting.
Hopefully
we
will
bring
enough
interest
for
you
to
do
so.
So
this
is
I'm
Jenna,
Inger
and
Ian.
E
E
E
on
the
loss
recovery
mechanism,
specifically
in
quick,
the
quick
working
group
deals
with
a
lot
of
things:
loss
recovery,
just
one
of
them,
and
so
it
hasn't
gotten
a
lot
of
airtime
and
it
hasn't
gotten
a
lot
of
air
time
with
people
who
understand
PCP
loss
recovery
really
well.
So
the
the
goal
is
that
once
we
get
those
people
up
to
speed
what
we
currently
have
going
on
and
quick
that
hopefully
going
into
the
future,
we'll
have
more
engagement
with
those
folks.
That's
you
folks.
E
Next
slide
nan
goals.
Just
for
the
next
hour,
we
will
not
redesign
mechanisms
here.
We
will
not
really
to
get
constants
here.
It
is
not
to
say
that
we
can't
discuss
them
or
we
should
not
rathole
on
them
be
louder
at
holes
and
we
would
love
to
have
them.
But
let's
have
them
in
a
different
forum.
We
can
either
do
it
on
github
or
on
the
mailing
list
or
in
a
later
session,
but
not
this
time
not
now,
and
we
will
not
really
get
quicks
use
of
TCP
standards.
E
We've
agreed
to
use
RFC
62
98
in
56,
81
and
various
other
RFC's
that
are
part
of
the
PCB
set
as
non
normative
references
for
quick.
So
our
goal
is
to
do
this
design
and
build
congestion,
control
and
loss
recovery
for
quick
entirely
inside
of
this
document,
but
we
use
these
as
infinitive
references.
So
bear
that
in
mind,
and
all
of
these
things
like
I
said,
can
be
done.
E
Just
don't
do
them
right
now,
but
let
me
not
stop
you
from
coming
up
to
the
mic
and
asking
clarifying
questions
or
whatever
it
is
that
you
might
want
to
ask
or
say,
but
just
bear
this
in
mind,
as
as
you
come
to
the
mic
and
a
note,
I
will
ask
questions
and
I
hope
to
get
answers.
I
have
long
runs
here
and
if
you
give
me
a
good
answer
or
if
you
like
your
answer
or
whatever
you
say,
I'll
throw
a
long
in
at
you,
so
you
can
have
it
all
right.
E
E
E
This
is
good.
Hopefully,
this
will
be.
Some
of
this
will
be
a
breeze.
How
many
people
understand
quick
itself,
the
quick
transport
protocol?
How
many
people
here
understand
the
quick
transport
protocol
I
know
I'm
using
understand
very
fluidly,
but
if
you
think
you
do
that's
fine,
that's
really
good
or
bad
I.
Don't
know
what
to
think
of
this.
Is
this
the
quick
I
think
this
is
the
quick
working
group
did
I
raise
my
hand
yeah
well.
I
should
probably
have
this
man
anyways.
E
Let's
start
with
just
the
overview
of
what
parts
of
quick
are
relevant
next
slide.
First,
off
quick
packet
numbers,
quick
packets
have
packet
numbers,
not
sequence
numbers.
Why
are
they
called
packet
numbers
and
not
sequence
numbers,
because
we
didn't
want
to
conflate
the
semantics
of
TCP
sequence:
numbers
with
quicks
packet
numbers.
Specifically,
a
quick
packet
is
a
container
of
things.
Those
things
we
call
frames
the
container
the
quick
packet
has
a
packet
number.
E
E
That
packets
are
containers,
they're
carried
things,
we
call
frames
one
of
those
things.
One
of
those
frames
is
a
quick
action.
What's
a
quick
act
frame,
it's
basically
a
frame
that
contains
acknowledgment
information
about
what
the
receiver
has
seen
so
far
and
also
what
it
hasn't
seen
so
far
implicitly.
So
a
quick
Akram's
contains
these
fields.
E
The
second
set
of
fields
is
the
ACK
ranges.
Think
of
this,
as
your
sag
blocks,
it's
roughly
that
the
third
field
is
act
delay.
This
is
an
explicit
encoding
of
the
amount
of
time
that
the
receiver
was
sitting
on
the
largest
act
before
this
AG
was
sent.
Let
me
clarify
that
not
sitting
on,
but
the
time
since
the
largest
act
packet
was
received
when
this
act
was
sent.
So
it's
basically
not
only,
but
it
also
encodes
any
pause
times
that
might
be
at
the
receiver
in
particular,
it
encodes
delayed
ACK
delays
at
the
receiver.
E
That's
very
useful.
We
don't
have
to
infer
that
at
the
sender
anymore
and
the
ACK
frame
also
optionally
contains
not
optional
means.
It
does
contain
three
ecn
accounts.
Ect
zero
is
81
and
ce4
easy
and
stuff
again.
We
will
not
go
into
ecn
stuff
here,
because
again
the
the
Sen
encoding
Magnus
talked
about
in
th
pwg,
and
we
are
going
to
leave
it
there.
Next
slide
at
generation
is
close,
but
slightly
different
than
TCP
s.
A
receiver
is
expected
to
act
every
other
packet.
E
This
is
similar
to
TCP,
in
that
every
other
packet
is
act
again,
but
we
have
a
25
millisecond
delay
that
timer
we
say
the
receiver
should
act
immediately.
If
the
received
packet
number
is
not
the
next
expected,
meaning
that
the
largest
received
you're
expecting
to
receive
packets
are
not
increasing
order
of
packet
number.
If
that's
not
the
case,
then
you
act
immediately.
Otherwise
you
delay
the
acknowledgement.
E
Similarly,
if
you
receive
a
congestion
experienced
coat
point
from
the
network,
then
you
go
ahead
and
a
comedian,
because
you
want
to
communicate
that
back
to
the
sender
as
soon
as
possible.
We
have
a
caveat
for
for
processing
more
packets
before
sending
an
ACK.
This
is
particularly
useful
when
you're
in
user
space,
because
the
receiver
might
not
be
scheduled
right
now
and
by
the
time
it
gets
scheduled.
Multiple
packets
have
arrived
and
are
queued
up
in
the
kernel
buffers
and
then
the
application
goes
and
reads
all
of
those
packets.
E
You
don't
want
to
have
the
receiver
send
out
acts
for
every
two
packets
there.
It
makes
no
sense
the
receiver
might
as
well
drain
the
entire
kernel
queues
and
then
send
out
one
ACK
that
acts
everything
that
it
has
received
so
far.
So
we
want
to
allow
for
the
receiver
to
act
less
frequently.
That's
not
the
only
case
where
we
want
to
act
less
frequently,
but
we
will
talk
about
acting
less
frequently
later,
but
that
is
allowed
in
quick
next
slide
and
we'll
jump
soon
into
the
recovery
mechanisms
and
those
are
all
timelines.
E
Just
you
know,
timing
diagrams
so
and
to
understand
those
timing.
Diagrams
I
will
introduce
some
notation
here.
That
will
be
useful
and
I'll
repeat
this,
as
I
show
the
timing
diagrams
just
to
make
sure
that
you're
all
clear
on
what
you
are
looking
at,
a
packet
that
is
sent
is
shown
with
PN
X.
That
means
this
is
a
packet
with
packet
number
X,
and
an
act
that
is
sent
is
shown
with
this
notation,
a
which
implies
ACK,
followed
by
X,
which
is
the
largest
act
followed
by
a
crane
jiz.
E
If
you
note
this
particular
notation
for
act,
this
is
very
similar
to
sac
notations
with
one
difference.
X
here
is
greater
than
the
ik
ranges
when
you
show
TCP
sacs,
you
usually
so.
The
cumulative
ACK
point
followed
by
sac
blocks
and
usually
the
sac
and
always
the
sag
blocks,
are
greater
than
the
cumulative
ACK
point
in
quick.
E
What
you
will
see
is
the
largest
act
followed
by
a
crane
just
so
the
largest
actives
always
made
larger
than
everything
else
in
that
block
in
that
in
that
frame,
next
slide
is
everything
everything
clear
so
far,
any
questions
any
clarification:
okay,
good,
because
if
you've
not
been
paying
attention,
so
far
pay
attention.
Now,
that's
all
I'll
say
hopefully,
you'll
follow
along
so.
E
Quick
and
easy
PR
trick
is
quite
similar.
It's
actually
the
same,
but
you
know
you
trip
up
on
small
things:
oh
wait
a
second
that
looks
different
and
it
is
so
that's
sort
of
the
thing
that
you'll
see
in
these
mechanisms
and
I'll
try
to
note
them
as
we
go
so
quick
uses
mechanisms,
it
doesn't
necessarily
implement
them
in
in
this
sort
of
distinct
ways,
but
it
implements
the
functions
of
fast
retransmit
earlier
I
transmit
a
loss,
probe
rtos
and
also
implements
spurious
audio
detection
for
congestion
control.
E
As
I
said
earlier,
quick
implements
new
Reno,
there's
a
very
small
caveat
that
it
is
the
largest
act
that
ends
the
recovery
period.
I
won't
dig
into
that
right
now,
but
it's
an
important
caveat.
Remember
that
TCP
the
recovery
period
is
ended
by
the
cumulative
act,
point
moving
past
the
recover
point
and
that
can
often
cause
me
a
TCP
to
be
in
recovery
mode
for
more
than
one
round-trip
time.
E
When
you
have
multiple
losses
in
a
window
in
particular,
but
with
quick,
you
will
always
leave
recovery
within
a
round-trip
time,
which
is
really
the
ideal
property
that
we
want.
Even
for
DC
D,
but
we
can't
have
because
sometimes
you
can't
have
nice
things,
but
in
quickly
can
so
we
do
next
slide,
and
now
we
jump
into
recovery
mechanisms.
E
We
will
start
with
the
favorite
of
the
bunch
fast
retransmit,
also
known
as
the
3do
pack
mechanism.
So
here's
the
first
time
you're
gonna,
see
the
standing
diagram
so
I'll.
Let
you
take
this
in
slightly
slowly,
but
take
it
in
because
I'm
not
going
to
go
slowly
on
the
next
one.
What
do
you
have
here
on
the
left
side
left
side?
Is
the
sender
marked
as
s
in
the
receiver
on
the
right
side
mark
with
R
and
time
goes
downwards?
Okay,
so
time
is
increasing
down,
and
you
can
see
that
the
sender
is
sending
model.
E
This
is
not
to
scale
by
the
way
for
any
definition
of
scale.
So
the
the
left
side
is
is
showing
you
packet
numbers
of
packets
that
are
transmitted.
The
right
side
is
showing
you
acts
that
are
sent
back
towards
the
sender.
Okay,
I
hope,
that's
clear
and
obvious,
and
that
little
explosion
that
you
see
there
is
not
just
for
fun.
It's
actually
showing
you
that
a
packet
got
dropped
and
yes,
it
is
an
explosion.
E
So
the
packets
here
are
packet.
Numbers
1
through
5,
are
sent
from
the
sender
and
they
all
go
towards
the
receiver
except
packet.
Number
2
is
dropped.
Packets,
one
packet,
one
is
receiver.
The
receiver
is
not
act
immediately
because
the
receiver
delays,
the
sack
receives
packet,
number
3
and
goes
I'm.
Gonna.
Add
this
immediately
and
since
an
act
back,
if
you
notice
the
ACK
has
the
largest
act
of
3
and
has
an
ACK
range
of
1
of
1.
It
acts
3
and
1.
Basically,
packet
4
is
received
again.
E
The
receiver
acts
4
3
&,
1
5
was
received
at
the
receiver
acts
5,
4,
3,
n,
1,
okay,
so
2
is
not
act.
The
the
sender
sees
that
3
missing
reports.
Three
times
the
receiver
has
or
3
packets
have
been
received,
marking
2
as
potentially
lost
and
after
3
do
backs.
This
is
the
packet
threshold
of
3,
the
sender,
retransmits
packet,
number
2.
So
question
Aquos.
E
I'm,
so
sorry
about
that
I
just
realized,
I'm
gonna
be
creating
a
mess
for
the
cleaning
people
here,
I'm
I'm,
sorry
they
are
not
durians.
Yes,
indeed,
that's
a
good
point.
Thank
You
Stuart
picked
it
up.
Thank
you
so
much!
Yes,
that
is
exactly
right.
That
is
one
thing.
There's
another
thing
in
here
another
longer
than
its
take.
E
E
E
So,
yes,
packet,
number
six
packet
two
is
actually
sent
as
packet
six.
This
is
a
pretty
big
difference.
It's
a
subtle
point
here,
but
it's
a
huge
difference,
because
this
shows
up
later
so,
as
you
can
see,
packet
numbers
are
monotonically
increasing,
despite
the
fact
that
six
actually
carries
data
that
is
retransmitted
it
from
a
packet
number
space.
It
doesn't
matter,
it
simply
looks
at
six.
G
G
E
Whatever
good
clarification,
okay,
thank
you
yep.
So
this
is
partly
why
we
calling
the
draft
detection,
because
you
don't
necessarily
retransmit
data.
This
is
because
some
frames
in
quick
that
we
want
to
detect
as
lost.
We
may
not
retransmit
and
that's
completely
reasonable
and
fine.
This
is
also
true
for
data
application
data
which
an
application
can
cancel
in
quake
and
we
want
to
detect
them
as
lost,
but
we
won't
retransmit
them.
Yeah.
H
E
You
want
to
know
that
it's
lost
so
yeah
excellent
points
all
so
that's
fast
retransmit
for
you,
that's
mostly
the
same
next
slide.
This
is
something
that
you
may
be
familiar
with.
This
is
often
called
the
fact
mechanism
in
Linux.
It's
a
forward
acknowledgement.
It
comes
from
yeah,
it's
called
forward
acknowledgement.
The
idea
here
is
that
you
don't
need
to
wait
for
3
ack
packets
to
be
received
explicitly
as
long
as
a
packet
is
received.
E
E
What
this
means
is
that,
because
packet
number
5
is
acknowledged
immediately,
the
sender
can
mark
packet
number
2
as
lost
and
retransmitted
if
it
should
be
retransmitted.
So
this
is
called
frak,
it's
a
minor
modification
to
fastly
transmit
and
it
helps
in
cases
where,
for
instance,
app
packets
may
be
dropped
on
the
floor.
The
other
place
it
helps
tremendously
is
when
you
want
to
reduce
the
number
of
acts
that
are
being
sent
from
the
receiver.
I
Hi,
a
cherry
from
Apple
I
have
a
quick
question,
and
if
this
is
a
rathole,
we
shouldn't
take
time
on
it.
We
just
had
a
bunch
of
discussion
about
how
six
might
not
be
a
retransmission
of
to
my
tree
transmit
some
of
it
and
not
others.
Is
there
something
in
there
that
tells
the
receiver
consider
this
to
be,
maybe
not
a
repeat
of
two
but
recovery
from
that,
so
that
it
knows
to
go
out
of
the
duplicate
ahmed,
where
it's
acting
every
packet?
E
E
That's
the
more
important
thing
here
so,
quick
by
definition,
a
receiver
has
to
basically
think
about
gaps
as
the
normal
case
and
that's
how
it
operates,
which
is
why
you
want
to
allow
for
fewer
acknowledgments,
even
when
there
are
gaps
and
the
receiver
will
stop
reporting
some
gaps
after
it
knows
that
the
sender
has
heard
that
at
least
once
that's
really
the
goal
here.
So
thank
you
for
the
question.
Yeah,
that's
an
important
in
a
good
question
in.
H
Story
I
mean
if
I'm
gonna
file
an
issue
on
that
just
attract,
because
I
think
the
text
is
not
quite
as
clear
about
what
might
be
optimally
done.
I
think
you
basically
might
send
an
immediate
ad
for
every
single
incoming
packet
at
the
matheus
for
an
entire
RTT,
or
at
least
it's
a
little
bit
too
vague
about
what
might
happen
so
I
think
it
deserves
clarification.
It's.
E
A
good
one
next
slide,
so
we've
added
one
thing,
as
we
do:
we've
added
an
optional
time
threshold
based
retransmission
mechanism
in
quick.
This
allows
for
a
sender
to
ignore
packet
thresholds
and
wait
for
a
certain
amount
of
time
before
it
declares
a
packet
lost.
Of
course.
Thus,
the
the
sender
is
expected
to
receive
at
least
one
ACK.
That
indicates
that
a
packet
has
not
been
received
before
it
marks
it
as
lost,
but
that's
the
general
idea
here.
E
This
helps
with
with
avoiding
this.
This
helps
with
reordering
reordering
is
one
of
the
things
that
trips
up
fast
retransmit,
quite
a
bit
and
if
your
reordering
is
is,
is
under
a
threshold
of
3
that
works
out
alright,
but
if
the
reordering
is
greater
than
a
threshold
of
3
the
packet
threshold
of
3,
then
that
causes
problems.
E
E
Yep
next
slide
so
yeah
times
we
showed
allows
reordering
tolerance
and
packet
space,
and
you
can
see
that
there's
a
computation
that
we
do
based
on
our
DD
and
the
latest
artery
that
you
see
there
in
that
computation
is
the
latest
oddity
sample
that
is
used
next
slide
early
transmit
again,
something
we
are
all
familiar
with,
but
with
a
small
twist.
So
how
many
of
you
know
early
transmit
in
TCP,
three
people?
Okay,
five
people
good
early
retransmit,
the
the
problem
that
early
transmit
sets
to
solve
is
basically
what
do
you
do.
E
So
remember,
fast,
retransmit,
right,
you,
a
sender,
retransmits
a
packet
when
it
receives
three
acknowledgments
that
mark
that
packet
has
lost
or
the
center
with
faq.
It's
that
the
third
packet
beyond
it
has
been
acknowledged.
But
what,
if
they
aren't?
There
are
in
three
packets
after
this
packet
that
is
lost.
What,
if
there's
exactly
one
packet
that
you
sent
after
this
packet?
You're,
never
going
to
get
the
three
packet
gap
or
the
three
packet
distance
from
the
packet
you're
trying
to
retransmit
or
you
want
to
detect
as
lost
as
in
this
case
package.
E
One
two
and
three
are
sent
to
is
lost
and
you
receive
one
ack
that
says
three
is
acknowledged
and
one
is
acknowledged,
but
you're
never
going
to
get
an
AK
4
5,
which
is
what
you
want
to
trigger
a
fastly
advancement.
So
early
you
transmit.
Basically
what
it
says
is
we
will
in
this
case
the
sender
knows
that
there's
no
foreign
five,
so
the
sender
will
retransmit
to
based
on
the
single
report
that
it
received
from
the
receiver,
because
that's
all
it's
gonna
get
from
the
receiver.
E
There's
a
problem
with
just
doing
that
and
I'm
saying
right
now
ignore
the
the
the
time
that
I'm
showing
there
in
that
slide.
If
the
sender
was
to
retransmit
for
immediately
on
receiving
that
first
report,
it
makes
itself
vulnerable
to
simple
packet,
reorderings
back
at
twiddles
in
particular,
and
so
that's
something
that
in
practice
happens
a
lot
and
so
the
Linux
implementation
does
this
implementation
of
this
timer
for
TCP,
and
so
we
borrowed
that
out
of
the
Linux
implementation
and
we
have
a
timer
that
says
if
you
received
one
just
give
me
one
second
Bob.
F
J
E
So
that's
really
the
transferred
for
you
next
time
and
now
we
are
going
to
go
into
the
timer
based
mechanisms,
specifically
TLP
RTO
crypto
and
the
handshake
timeouts
and
things.
But
to
do
that,
we
need
to
understand
the
rtt
measurement
mechanisms
in
quick.
So
very
briefly,
RTD
is
basically
sixty
to
ninety
eight
there's,
nothing,
that's
different
about
this
than
the
standard
TCP
mechanisms,
except
for
one
difference,
the
RTD
sample.
We
do
something
to
make
the
RTD
sample
cleaner,
so
to
speak.
E
So,
specifically,
remember
that
I
talked
about
AG
delay,
whether
you
are
explicitly
encodes
the
amount
of
time
that
it's
sitting
on
and
a
packet
before
aking
it
the
delay,
rack
time
or
yeah.
We
know
that
so
we
can
remove
it
from
the
RTD
measurement.
Explicitly
now
understand
that
we
will
bring
this
back
later
because
we
do
want
to
know
how
long
we
should
wait,
how
long
a
sender
should
wait,
but
the
RTD
measurement
is
expected
to
be
a
network,
RTD
measurement
and
that's
the
semantics
here.
E
It's
slightly
different
from
the
DC
dr/dt
measurement,
which
is
not
a
network
RTD
measurement.
It
is
a
expected
response.
Time
measurement,
basically
because
it
includes
the
delay,
rack
timer.
So,
as
you
can
see
here,
the
oddity
measurement
is
the
time
when
the
AK
has
received
to
the
time
when
the
packet
was
sent.
The
delay
that
the
receiver
reports
in
that
AK
the
receiver
also
or
not
the
receiver
both
endpoints,
also
declare
at
the
beginning
of
a
connection
the
maximum
that
they
will
delay.
E
Acts
by
this
is
called
Max
AK
delay
and
you
may
be
familiar
with
a
similar
max
a
grade.
A
proposal
for
TCP
that's
been
floating
around
and
T
CPM
and
that's
basically
used
in
this
case
in
later
thing.
But
this
is
the
max
AK
delay.
Is
the
repeater
is
an
endpoint,
sorry
unilaterally
declaring
how
long
it
will
what's
the
maximum
amount
of
time
that
it
will
wait
before
sending
an
ACK
back,
and
this
informs
how
we
do
timeouts.
E
So
if
you
look
at
the
timeout
computation,
the
time
of
RTO
computation
is
the
same
as
for
TCP
as
far
as
in
sixty
to
ninety
eight,
but
there's
an
additional
max
AK
delay.
Remember
that
the
RTD
sample
itself
does
not
include
the
active
a
here,
whereas
in
TCP
it
does
so
the
SRTP
computation.
The
smooth
the
RTD
computation,
therefore
in
in
quick,
does
not
include
the
AG
delay
and
so
when
you're
waiting
for
an
AK
from
the
receiver,
you
want
to
compensate
for
that.
E
You
want
to
wait
for
the
AG
delay,
because
the
receiver
might
be
waiting
for
that
period
of
time.
So
we
explicitly
add
the
max
delay
in
the
RTO
computation,
so
we
bring
it
back
TLP
again
similar.
We
use
1.5
x,
sr
DT.
This
is
based
off
of
the
now-defunct
and
expired
TLT
draft,
but
we
are
can
explicitly
add
the
Mac
side
delay
back
in
and
you
have
mins
for
both
of
these.
Our
min
audio
is
200
milliseconds,
informed
by
what
we've
seen
in
practice
in
Linux
and
the
min
timer
for
TLP
is
10
milliseconds.
E
E
You,
oh
boy,
this
is
not
fun.
I'm,
gonna,
go
and
race
through
this.
If
you
have
questions
come
to
the
mic
when
I'm
trying
to
but
I
won't,
have,
discussion
and
and
and
I
want
to
leave
some
room
for
discussion
later.
Okay,
so
RTO
is
basically
the
same
as
DCP
but,
like
I
said
eating.
Oh
sorry,
this
is
TLP,
my
bad
for
people
who
don't
know
TLP
I'm,
not
gonna,
go
into
the
details.
It's
it's!
The
last
packet
offered
of
a
train,
the
last
packet,
that's
outstanding.
E
If
it's
lost
it's
useful
to
have
a
quick
timer
that
that
that
fires
and
and
send
something
out,
that's
what
TLP
does.
If
you
know
TLP.
This
is
exactly
the
same
as
TCP
TLP,
there's
no
difference
at
all,
and
it
includes,
as
I
pointed
out
max
actively
there's
one
small
difference
in
the
overall
mechanism.
Next
slide,
the
TCP
PLP
draft,
which
is
again
now
defunct,
an
expired,
specifies
using
one
TLP
before
going
to
an
RTO.
We
do
two
TL
piece
because
we
found
that
this
is
actually
helpful.
E
E
We
fall
back
on
a
an
RTO
timer
and
the
RTO
timer
is
seated
as
as,
as
shown
on
the
slide
there-
and
this
is
again
includes
explicitly-
includes
max
ACK
delay
and
has
a
minimum
value
of
200
milliseconds
according
to
the
draft
right
now
next
slide-
and
this
brings
us
previous
audio
detection.
This
is
actually
all
the
cute
things
about
about
the
way
the
mechanisms
work
out
and
quick.
Remember
I
told
you
that
in
quick,
we
don't
have.
We
don't
repeat
packet
numbers
right.
We
never
repeat
packet
numbers
now.
E
This
is
a
bit
of
a
pain
in
TCP,
because
if
you
want
to
detect
that
this
is
where
this
is,
what
leads
to
retransmission
ambiguity
and
when
you
receive
an
act
for
a
packet,
you
don't
know
if
the
a
cause
for
the
original
packet
or
a
retransmission
and
so
on
in
quick.
There
is
no
such
ambiguity,
because
every
packet
is
that
back
in
number
exactly
once
so.
In
this
case,
this
is
the
case
where
there
was
in
fact
an
ordeal.
This
is
the
same
as
the
previous
slide.
E
The
RTO
fires
six
is
sent
as
the
retransmission,
let's
say,
and
then,
as
acknowledged
when
the
acknowledgement
comes
back,
the
sender
looks
elegant
goes,
does
his
ack-ack
anything
that
was
sent
before
six?
Does
this
agonizing
newly?
Does
it
act
five,
for
example,
or
four?
If
it
does,
then
my
rtos
was
prettiest
if
it
doesn't
mayority
or
was
legit,
so
quick
calls
the
RTO
verified
at
the
time
that
it
receives
the
first
stack
after
the
RTO.
E
If
this
happened,
where
four
was
sent,
got
delayed,
didn't
get
dropped
in
the
network,
booked
got
delayed
and
eventually
was
received,
and
then
the
sender
retransmits,
five
and
six
and
then
receives
an
act
that
says
for
exact,
quick
calls
that
RTO
spurious.
So
that
is
the
same
moment
in
time.
The
first
act
after
the
RTO
and
that
moment
in
time
quick,
makes
a
decision
about
the
RTO
event
itself.
E
What
this
means
is
that
quick
does
any
changes
to
the
congestion
controller
and
so
on
at
the
moment,
where
it's
able
to
either
verify
or
call
the
RTO
spurious.
It
does
not
collapse
the
condition
window
when
the
RTO
happens.
This
is
again
a
difference
from
the
way
TCP.
Does
things
TCP
collapses,
the
condition
window
on
an
RTO
and
then
tries
to
reinstate
it
later
we
don't
do
anything
until
we
know
for
sure
what
happened.
That's
a
difference
next
slide.
E
That's
what
this
slide
says,
basically,
that
if
we
detect
the
packet
as
spurious
later,
we
do
nothing,
nothing,
no
changes
to
the
congestion
controller.
Basically,
it's
a
no
op,
but
at
the
moment
of
verification,
if
we
detect
the
act
as
the
RTO
as
valid,
then
we
apply
condition,
control
actions
and
there's
some
discussion
on
this
going
on
right
now,
but
yeah,
that's
the
shape
of
things.
Next
slide
crippled
I'm
out.
E
This
is
the
equivalent
of
the
handshake
timer
in
the
syn
synack
timers
in
DCP,
except
it's
a
lot
more
complicated
and
quick,
because
it
includes
a
crypto
handshake
so
and
we
have
different
levels
of
encryption
and
various
other
things
are
possible
there.
So
the
the
general
gist
is
that
this
is
set
aggressively.
This
is
set
aggressively
because
we
want
to
recover
from
from
from
losses
in
this
early
stage
as
quickly
as
we
possibly
can.
E
This
is
a
critical
part
of
the
communication.
This
is
a
setup.
We
have
no
idea
what's
going
on
on
the
network,
but
we
want
someone
to
be
a
bit
aggressive
so
before
any
RTD
samples
right
now,
200
milliseconds
is
what
is
used
and
after
our
daily
samples,
we
use
two
times
the
s
RTD
for
a
crypto
timeout.
E
This
is
the
timer
that's
used
for
all
handshake
packets,
not
just
for
the
first
one,
but
for
all
of
them-
and
there
are
this,
of
course,
exponential
back-off
on
consequent
timeouts,
and
when
the
timer
fires
we
transmit
all
all
symmetric
to
packets.
This
is
still.
This
is
again
one
of
those
things
which
we
need
a
little
more.
E
We
are
discussing
continue
to
discuss
this
too,
and
there's
going
to
be
some
more
clarity
on
the
text
here,
but
that's
what
it
is
right
now
next
and
that's
about
the
end
of
what
we've
got
so
far
go
over
this
very
quickly.
There
are
some
potential
improvements
we
are
discussing
and
things
that
are
open
questions
which
we
love
your
input
or
for
you
to
be
engaged
in
the
first
one
is
generating
here.
E
Ax
TCP
says
the
spec
says
generate
an
ACK
once
every
two
packets
in
practice
there
are
wireless
drivers
and
metal
boxes
that
compress
acts
that
drawbacks
when
they
know
that
subsequent
acts
are
going
to
simply
replace
the
information
and,
in
effect
the
network
has
fewer
than
one
act
for
every
two
packets.
So
the
question
for
us
is
given
that
quick
will
not
see
the
sin
of
compression
and
will
never
see
it
because
the
acts
are
encrypted
instead
of
packets.
What
should
we
do
as
default?
E
Should
we
do
too,
because
that's
what
the
book
says
for
for
TCP
or
can
we
live
with
for,
should
be?
What's
the
default?
What's
a
good
default
for
us
years,
it'd
be
nice
to
have
a
higher
number
there.
We
can
live
with
it.
This,
of
course,
has
implications
to
the
condition
controller
as
well.
So
this
is
a
bit
of
an
open
question.
We
right
now
have
two
on
the
draft,
but
this
is
definitely
something
that
we
can
discuss
a
fake.
C
E
H
I
think
he
was
asking
kind
of
are
we
are
we
open
to
making
changes
or
improvements
that
are
in
the
next
three
or
four
slides?
Yes
in
in
this
time,
for
improvement,
I
think
I
think
the
short
answer
is
is
yes,
but
you
know
sooner
is
is
better
and
obviously
at
some
point
yeah,
it's
just
gonna
we're
not
gonna
hold
up.
Let's
put
it
this
way.
We're
not
gonna
hold
up
the
quick
drafts
for
for
an
improvement
here.
E
I
think
that
is
so,
you
interrupted
you.
I
was
just
gonna
say
that
the
people
are
showing
up
at
the
mic,
and
maybe
we
should
start
should
we
start
the
discussions
with
these
slides,
or
should
we
go
through
the
last
couple
of
slides
and
then
load
just
a
couple.
More
slides
on
questions
should
I
finish
the
slides,
okay.
F
F
E
E
That's
a
huge
change,
so
it's
something
that
we'd
love
to
be
able
to
do,
and
it
is
a
question
that
we'll
discuss
in
the
past
we've
sort
of
held
off
on
really
rattling
on
this,
because
we've
had
to
work
on
many
other
things.
But
this
is
something
we'd
love
to
discuss
and
maybe
even
make
happen
next
slide,
there's
a
potential
time
of
simplification
to
combine
TLP
and
RTO.
If
you
have
noticed
this,
we
thought
about
this
in
the
past.
E
E
Because
the
cost
of
a
spurious
specifically
a
spurious
retransmissions
is
lower,
because
when
you
receive
an
acknowledgement,
that's
when
we
make
a
conditioned
control
decision
and
if
it
was
prettiest,
when
you
receive
an
ACK,
you
know
it
was
prettiest
and
you
do
nothing
to
the
transition
controller.
Basically,
quick
pool
detectives
previously
transmitted
and
not
have
any
condition,
control
effect.
E
B
B
Is
that
there
isn't
the
cost,
because
we
detect
that
it's
spurious
okay?
So
we
don't
actually
make
the
change
to
congestion
control.
We're
not
paying
like
the
cost
of
the
retransmit
itself
is
the
same,
but
the
constant
of
your
modification
of
how
you
view
your
congestion
control
state
is
mitigated
by
the
detection.
In
fact,
we
should.
G
E
I
F
I
I
E
J
G
K
Several
things,
so
the
TLP
draft
is
expired,
but
the
back
draft
in
TCP
now
subsumes
t.o.p
and
that's
active
so
about
ax
generation
of
ax
right.
So
TCP
already
does
projects
today
because
of
things
like
LRO.
So
I
actually
don't
see
a
big
problem
in
moving
away
from
because
looks
like
the
conditional
controller,
as
documented
in
the
quick
draft
already
does
like
appropriate
by
coating
with
ordinal
limit.
So
in
terms
of
congestion
control,
there's
not
a
big
problem
if
you're
racking
less
frequently,
because
they're
already
counting
bytes
and
that.
F
K
E
G
G
K
E
True,
yes,
it's
the
same
timer
for
sure
yep,
that's
good
feedback.
This
is
the
last
slide
again
questions
on
fast
retransmit.
How
do
you?
How
do
we
deal
with
the
packet
based
in
the
time,
based
on
the
time?
Jason
was
really
not
present
in
TCP
standards.
It's
there
in
code
to
some
degree
for
the
early
transmit,
for
instance,
but
it's
something
that
we
are
thinking
about.
E
L
E
We
you
couldn't
element
the
RTO
verified
because
you
want
to
detect
so
so
here's
the
way
to
think
about
it,
call
it
all
retransmissions
we
just
not.
Do
it
aggressively.
That's
all,
and
we
can
do
it
aggressively
because
we
are
gonna
do
the
verification
later.
So
maybe
one
way
other
way
to
think
about
it
as
eliminate
PLP
and
just
do
or
do
not
aggressively.
L
So
the
effect
of
an
act
of
the
TLP
is
different
from
the
effect
of
the
currently
in
the
quick
drafts.
The
effect
of
Akron
TLP
is
different
from
the
effect
of
arc
of
an
RTO
which
is
an
effective
market.
Our
TLP
just
triggers
packet
threshold
based
loss,
affliction
or
packet,
time-based
loss,
section,
missus,
RTO
triggers
min
RTO
verified
and
actually
goes
to
min
Seawind
at
the
moment.
So
I'm
wondering
what
you
are
thinking
about
in
terms
of
unifying
those
two
behaviors.
F
E
H
Think
what
the
reasons
we
want
discussed
this
in
this
working
group
is
because
we
think
it's
an
area
of
potential
improvement
for
both
TCP
and
quick
and
I.
Don't
think
either
of
us
have
if
I
had
a
clear
answer.
I
would
just
put
it
up
on
the
slide
and
say:
oh
I
should
do
this,
but
I
don't
I've
been
thinking
about
this
for,
like
a
year
and
a
half
and
I'm
really
came
up
with
a
very
clear
answer:
yeah.
I
I
In
today's
world.
Is
that
it's
very
better
algorithm
because
intuitively
what
we
want
to
do,
if
we
assume
there's
some
normal
distribution,
we
want
the
retransmission
timer
to
be
set
three
or
four
standard
deviations
out,
so
that
there's
always
a
probability
that
we'll
guess
wrong.
But
we
want
that
probability
of
a
spurious
retransmissions
to
be
sufficiently
small.
G
It's
too
bad
that
when
Jacob
son
is
not
in
the
room,
because
I
mean
he
was
using
violence,
but
it's
not
meant
violence
in
statistical
term.
What
was
computed
was
a
tweety
average
Delta
between
the
measured
average
so
far
and
the
values
which
statistically
is
proportional
to
the
standard.
Deviation
it's
something
like
square
root
of
two
times.
The
standard
deviation
on
the
bell
curve
that
it's
yeah.
E
I
E
On
variance
of
the
distribution
but
but
the
second
point
about
other,
better
algorithms,
absolutely
there
are
and
I
think
that's
something
for
folks
to
try
out.
We
aren't
going
to
standardize
it
because
this
analyzing
nariƱo
here
for
a
reason
right.
It's
easy
to
do
it's
hard
to
figure
out
what
what
better
answers-
and
we
don't
want
to
spend
time
on
that
right
now
and
here
but
I
think
it's
a
good
time
to
after
we've
gotten
the
first
round
of
quick
done.
It's
a
great
time
for
folks
are
thinking
about
better
algorithms.
For
these
things.
E
K
Hello,
Hebron,
hey
so
question
on
time
base
last
detection,
so
I
actually
sent
this
question
over
to
the
ministers
where
it
seems
to
me
that
it
kind
of
subsumes
packet
based
launch
detection
in
the
sense
that
the
way
it's
documented.
Currently,
if
you
do
time,
based
detection
and
FAQ
and
TLP,
then
you
don't
really
need
to
do
er.
So
my
question
was
having
that
boolean
variable
in
there
just
seems
to
be
confusing
things
a
little
bit
more.
What
it's
worth!
We
have
never
implemented
here
in
Windows
TCP
and
we
seem
to
be
doing
fine.
E
K
H
K
E
So
you're,
absolutely
right,
I
think
neither
you
nor
I
has
been.
You
never
argue
that
the
pool
eNOS
is
clarifying.
It's
actually
that's
why
we
have
this
question
you
would
like
to
combine.
In
fact
the
question
was
and
I
changed
it,
but
I
shouldn't
have.
How
do
you
combine
packet
and
time
threshold?
So
we
don't
have
that
boolean
first,
because
even
with
the
boolean
off,
you
still
have
ER
with
the
timer,
which
is
current
kufi,
and
so
what
we
call
time
threshold
based
this
is
kind
of
broken
there,
but
I
think.
E
M
M
Not
having
followed
quick,
very
close,
they
are
not
sure
if
that
has
maybe
already
been
discussed,
but
I
presume
that
acts
carry
these
continuously
growing
packet
numbers
as
well
all
right.
So
that
would
make
it
very
easy.
It
should
make
it
very
easy
to
do
a
congestion
control
which
not
so
long
ago,
Ingemar
has
presented
as
well.
He
said
that
you
know
we
may
actually
need
something
like
that.
M
I
think
the
big
issue
with
FCC
and
TCP
is
that
it's
pretty
hard
to
figure
out
how
many
acts
really
really
were
lost
or
were
transmitted
in
quickly
should
be
quite
clear.
So
that
would
be
a
simple
message
to
tell
the
other
side
to
say.
Well,
you
want
to
reduce
the
accurate
to
be
adaptive
in
that
that's
a
good
point.
We.
E
Yeah,
that's
a
great
point,
actually
it's
something
that
can
certainly
be
done,
but
care
has
to
be
taken
to
not
affect
the
condition
controller
on
the
send
side.
Of
course,
we
know
that
implications,
but
yeah
it's
it'll
certainly
be
an
easier
thing
to
do
and
quick.
The
question
is:
can
it
still
be
done?
Well,
but
yes,
it's
certainly
something
worth
giving
a
shot
in.
H
Particular
one
on
that
I
want
to
comment
that
I
think
put
the
congestion
controller
and
the
application
have
various
reasons
why
they
might
want
to
change
or
have
an
input
on
the
acknowledgment
strategy.
So
for
things
like
for
unreliable
transports,
you
you
want
enough
information
to
do
congestion,
control
but
you're
less
much
less
sensitive
to
loss,
recovery
delays.
So
as
an
example.
L
Suppose
anger
I
remember
the
last
time,
don't
exactly
when
the
presentation
was
on
rack
about
adaptive
thresholds
or
AK
thresholds
as
well,
I'm
wondering
if
we're
planning
to
keep
up
with
that
and
do
gate.
I,
don't
know
whether
we
have
the
mechanisms
and
quick
at
the
moment
to
be
able
to
do
what
Rack
is
doing
at
the
moment
with
believe
they're
using
D
socks
or
something
I've
I.
It
was
a
while
ago,
but
are
we
planning
to
do
that
work
as
well
and
set
the
quick
so.
E
We
aren't
right
now
in
part
of
this,
goes
to
the
spurious
detection
as
well.
I.
Think
because
we
actually,
while
we
do
spurious
RTO
detection,
we
don't
do
spurious
fast,
retransmit
detection
and
that's
something
that
we
could
do.
It's
something
that
maybe
it's
worth
opening
an
issue
about
yeah
we
haven't
discussed
this,
but
yes,
well,.
E
C
This
is
yours'
initiative
from
for
so
yep
I
have
very
general
comment
and
then
so
at
first
I
think
you
know
quick
starting
from
based
on
TCP
and
then
becoming
compatible
with
PC.
But
especially
you
know
thing
you
talk
about.
Second
half
of
the
one.
You
know
it's
syncing,
nothing
that
the
last
one.
This
is
we.
There
are
some
proposal
in
TCP
Empire.
It's
not
even
not
a
backing
group
items.
Well,
so
we
are
not
running
a
standard
feature,
but
still
quick
want
to
utilize
such
kind
of
widget.
E
C
E
It's
the
first
answer
to
that
is:
we've
tried
to
follow
best
practice
in
terms
of
TCP
implementations.
We've
taken
a
lot
of
cues
from
the
Linux
TCP
implementation,
for
example.
So
the
thing
that's
sharing
the
bottleneck
is
a
real
TCP
implementation,
not
the
standard
right.
So
that's
what
we
try
to
bring
into
the
quick
standard
is
what
is
common
practice
right
now
in
TCP?
E
The
the
second
point
is
that
I
think
some
of
these
things
make
a
ton
of
sense
even
in
TCP,
and
they
should
totally
be
used
in
TCP
too,
and
pretty
much
everything
that
we've
discussed
here
has
been
present
in
has
been
proposed
for
TCP
in
some
form
or
the
other.
Tmp
is
a
great
example.
There's
no
standard
at
all,
but
implementations
do
it
every
freebsd
does
of
the
next
asset.
These
things
should
be
sanitized.
These
things
should
be
done,
nd
CPM
and
they
should
yeah.
At
that
point,
we
won't
have
much
differences.
N
F
N
So
the
but
the
good
news
is
also
we
are.
We
are
about
to
freeze
the
17
drafts,
which
are
the
ones
that
are
currently
open
for
editing
in
in,
and
we
tried
to
then
only
update
and
based
on
implementation
experience
now
that
in
some
sense
the
good
news
is
that
the
recovery
draft,
specifically,
which
all
of
this
is
about,
hasn't
actually
seen
a
whole
lot
of
implementation
experience.
Yet
so
I
expect
it
will
be
relatively
easy
to
motivate
changes
to
that
yeah.
N
Also
because
you
know,
creation,
controls
and
recovery
is
difficult,
but
it's
not
actually
a
huge
amount
of
code
that
needs
to
change,
and
so
I
would
think
that
we
can
probably
get
the
implementers
to
agree
that
that
we
want
to
keep
making
the
recovery
draft
better.
While
we
are
in
this
freeze
phase,
simply
because
so
far
nobody's
really
done
much
there.
E
Yeah,
thank
you
for
saying
that
and
that's
a
thing.
That's
important
for
people
who
haven't
been
following
the
process
and
might
want
to
engage
now,
there's
room
for
engagement,
but
do
it
soon
and
because
we're
gonna
try
and
close,
even
this,
not
too
long
from
now,
but
it's
gonna
be
less
aggressive
than
the
gentle
drafts.
Tommy
Polly,
Apple
yeah.
So.
O
I
would
agree
with
Forrest
that
we
should
be
willing
to
kind
of
iterate
and
update
this
regarding
kind
of
like
how
it
relates
to
TCP
and
making
sure
it's
compatible
and
in
scope
in
that
regard.
I
think
it's
useful
to
distinguish
kind
of
like
the
differences
of
what
quick
has
available
as
information
and
what
is
Hannah
doing
on
the
wire
format,
from
how
it's
using
that
information
so
like
it
certainly
has
more
accurate
signaling
to
get
this
information,
and
so,
in
that
regard,
it
deviates
from
what
TCP
could
ever
do.
O
E
This
is
one
example
of
that
MIDI
I
was
pointing
out
that
TCP
has
prettiest
audio
detection,
for
example
right
if
you
were
to
assume
a
perfect
world
where
TCP
was
doing
that,
all
the
time,
then
absolutely
being
good
I
think
we
could
have
the
general
more
broader
discussion
of,
shall
we
remove
minority
Oh.
Unfortunately,
some
implementations
don't
all
implement
frt
or
some
sort
of
spurious
retransmissions.
Please
audio
direction.
If
you
can
assume
that,
then
maybe
we
could
have
the
conversation
for
just
those
implementations
that
actually
do
spurious,
but
yeah.
O
E
With
that
I
think
that's
I
mean
you
know
just
to
extend
that
point.
I
think
that
these
are
both
evolving
pieces,
work
and
I
think
they
can
learn
from
each
other
to
the
extent
that
quick
can
learn
so
I
Pacific
and
learn
from
what
we
want
to
do
and
quick
I
think
that's
helpful
and
we
want
to
engage
there
as
well
so
meeting.
C
The
tango
so
I
have
one
last
question
so
since
you
know
this
discussion
seems
to
be
very
active
and
then
we
have
lots
of
productive
discussion.
So
so
we
should
continue
the
discussion
on
the
mailing
list
why
you
want
to
have
another
kind
of
decision?
Maybe
this
is
a
question
for
quick
quality
or
some
other
ad.
You
are
suggest.
E
That
we
could
do
something
like
this
again
in
the
next
IDF,
but
I
mean
I.
Don't
think
we
should
wait
until
then
to
have
discussion.
But
if
you
have
discussion
we
definitely
expect
to
see
changes
between
now
in
in
Prague
and
at
that
point,
I
could
come
and
do
another
update
and
do
another
session
where
we
have
more
discussion
right.
Yeah.
N
So
Laura
tiger
I
think
is
actually
sort
of
asks
here
at
one
ask,
and
this
is
what
I
think
this
session
was
about
is
please
help
us
fix
the
recovery
drafter
we're
going
to
ship
initially
with
the
initial
set
of
quick
documents,
so
that
is
good
and
and
as
close
to
TCP,
as
as
we
can
make
it,
but
ideally
no
worse
and
ideally
also
not
way
more
aggressive
right.
So
basically
help
us
write,
something
that
the
is
we
will
not
discuss
in.
N
Still
TCP
or
not,
you
know,
the
second
ask
I
think
is
longer-term
and
I
think
this
is
also
what
maybe
Tommy
was
getting
at
that
there's
a
whole
bunch
of
new
information
in
quick
that
can
lead
to
better
congestion
control
in
the
future
right
and-
and
that
is
a
worthwhile
thing
for
people
to
play
with
and
think
about,
and
and
this
I
would
expect
initially
maybe
goes
to
ICC
RG
and
maybe
even
stays
in
ICC
RG.
But
is
this
so
quick
opens
up
this?
N
Somehow
for
us
to
then
use
them
and
I
think
I
see.
Sergey
might
be
that
place
for
some
of
it
yeah.
So
it's
it's
mainly
two
things,
but
one
is
hell.
Let's
get
the
quick
version,
one
recovery
stuff
ready
so
that
the
is
she
doesn't
object
to
it
and
and
to
help
us
figure
out
how
we
can
build
better
congestion
control
for
quick
in
the
future.
Yeah.