►
From YouTube: IETF106-TCPM-20191122-1000
Description
TCPM meeting session at IETF106
2019/11/22 1000
https://datatracker.ietf.org/meeting/106/proceedings/
B
B
A
Not
so
everyone
good
morning
hey
this
is
this
is
PCP
working
with
meeting,
please
make
sure
you're
in
the
right
room.
My
name
is
Yasiin
Ishida
and
unfortunately,
Michael
chef
and
the
Mike
toxin
couldn't
come
to
this
meeting,
but
I
believe
they
will
join
the
meeting
from
remote.
Although
Germany
time
is
3:00
a.m.
right
now,
okay
and.
A
This
is
user
note.
Well,
this
is
just
a
reminder:
ytf
policy
with
regard
to
your
behavior,
your
privacy,
your
intellectual
property,
your
copyright
and
so
on.
So
if
you
have
any
concerns
about
this
one,
please
read
this
carefree
and
you
can
find
some
contents
on
the
ITF
web
page
and
not
logistics
and
I
really
appreciate
mudding
from
peer
note-taker
and
the
Mahesh.
A
Okay,
so
to
present
surprise
know
we
have
lots
of
agenda
today
and
so
first
working
with
Jarrett's
update
the
status
of
the
working
group,
and
after
that
we
have
discussion
about
working
group
items.
First,
one
is
RTO,
consider
and
career
as
a
reviewer
present
some
feedback
of
this
RTO
consider
draft
so
that
we
can
think
about
it's
a
draft.
A
It's
ready
for
working
the
plastic
or
not,
and
next
one
is
accurate,
Asian,
press,
Asian,
prosperous
discussion
and
in
this
one
yeah
we
also
chaired
think
you
know
this
is
close
to
the
working
group
Roscoe,
but
beforehand.
We
would
like
to
check
you
know:
there
are
no
I
need
technical
respect
remaining
issue
or
if
there
is
any
procedural
issues
so
be
because
of
that
we
have
no
several
presentation.
First,
mal
Sarah
will
talk
about
update
for
Asian,
prosperous
and
then
after
that
Bob
my
I.
A
C
A
C
A
A
A
And
after
that,
media
will
talk
about
registration
policy
for
TCP
header,
so
this
is
related,
accurate,
easy
and
discussion
and
then
after
that's,
no,
we
will
discuss
about
procedure,
discussions
for
his
activities
and
easy
entrust
us
the
meaning
of
procedure.
Discussion
is
not
focusing
on
technical
style,
just
focus
on
how
to
proceed
this
draft.
So
that's
not
some
meaning
of
this
discussion,
and
after
that
we
have
a
for
presentation
for
non
working
group
items.
A
First,
one
is
high
stud.
Probably
we
will
talk
about
it
and
after
that,
my
fish
talk
about
young
model
for
TCP
configuration
and
after
that
caress
talk
about
TCP,
octo
and
then,
after
that,
a
lot
will
talk
about
some
congestion
experience.
So
that's
the
today's
agenda.
Any
comment,
questions
suggestion
about
this
agenda.
A
A
Tcp
M
combat
a
draft
we
have
completed
working
group
last
ago
and
then
we
have
submitted
to
our
yesterday
and
77
93
based
draft.
This
draft
has
been
continuously
updated
and
then
current
plan.
According
to
the
authors,
no
current
plan
to
update
these
reflect
some
meds
review
and
the
micros
review,
and
then
also
we
have
two
reviewers
Korea
and
probing
and
after
we
got
already
is
no,
we
think
and
if
it
looks
okay,
we
are
thinking
about
issuing
initiating
working
group
rustical.
A
So
our
current
front,
its
initiating
working
group,
rustical
re
2020
if
possible
and
that's
a
plan,
so
we
expect
maybe
was
to
submit
their
abuse
aureus
is
possible,
so
be
great.
I
appreciate
your
support
and
21:40
based
draft.
This
draft
recently
updated
three
days
ago
and
it's
add
new
a
pending
appendix
for
automating
the
initial
window
increase
then
after
this.
Basically
in
this
version,
they
also
think
this
draft
is
modern,
was
ready
for
working,
replace
to
call
and
they
don't
have
any
specific
front
of
lady
anymore.
A
A
E
F
A
H
Proving
I
had
one
brief
comment
on
working
group:
Lashkar
I
do
think
the
draft
is
complete,
but
I
gave
the
feedback
to
the
authors
that
it's
currently
not
that
readable.
It
needs
an
editorial
path
to
make
it
easy
to
consume
right
now.
It's
too
verbose
and
too
complicated.
So
that's
the
only
thing
that's
remaining
I
think,
but
we
should
go
to
dr..
Blasco
is
just
an
editorial
comment.
A
I
A
A
Ok,
next
one
is
RT
or
consider
okay
and
then
I
and
then
RKO,
functional
I
think
we're
as
I
say.
I
think
this
draft
is
very
close
to
backing
refresco.
So
we
have
our
located
some
slot
and
then
gory.
You
know
we'll
provide
a
feedback
as
assigned
reviewers
and
then
next
one
is
accurate,
Sen
and
in
general,
generalized
vcn,
and
recently
we
have
many
discussion
on
these
two
draft
and
the
chair
think
this
drug.
A
These
two
draft
is
also
close
to
the
working
group
rustico,
but
at
the
same
time,
that
she'll
think
we
need
to
check
several
points
before
we
move
on
to
the
backing
replace
the
work.
That's
why
we
allocate
some
time
to
discuss
this
one.
So
basically
it's
the
purpose
of
the
discussion
today.
It's
if
there
is
any
remaining
technical
points
issue
before
we
going
to
go
back
in
row,
Brasco
and
then
next
point
is
what's
the
best
way
to
proceed
this
draft,
so
we
will
have
a
discuss
later.
F
Hi
Corey
first
I'm
gonna
try
and
talk
a
little
bit
about
the
RT
or
considered
draft.
This
is
just
my
own
review.
The
purpose
of
the
sides
isn't
to
make
a
pronouncement
on
this.
It's
just
to
try
and
illustrate
what
we
might
want
to
comment
on
as
we
go
to
a
wicking
group
last
call,
and
hopefully
it
helps
other
people
think
and
conclude
on
this
piece
of
work,
see
if
I
can
over
what
my
slides
say.
A
F
So
yep,
that's
just
me
so
I
had
a
bit
context
on
reading
this,
which
might
be
useful,
Marc's
been
doing
doing
this
document
for
a
long
time.
He
started
off
just
doing
it
and
then
it
got
more
and
more
concrete
right.
F
At
the
time
we
did
our
RCA
2
8
5,
which
he's
know
a
little
while
ago
and
Mark
commented
on
825,
and
we
included
some
of
the
advice
from
this
into
RFC
808
5,
just
the
UDP
advice
and
I've
written
a
document
as
a
individual
and
I
read
a
whole
lot
of
of
documents
and
I
came
to
my
own
conclusion.
Then
I
went
back
to
look
at
the
RSC
series
to
see
what
it
said.
F
I've
now
gone
back
and
looked
at
this
document
to
see
whether
it
says
the
same
thing,
and
the
final
point
is
this
is
my
context.
The
other
thing
is
this:
it
represents
BCP
status.
It
was
originally
a
TCP
oriented
document.
Now
is
a
little
bit
wider
in
scope,
but
it
comes
from
TCP,
and
so
it
gives
the
TCP
background.
So
good
news,
I
read
it
again.
It
is
readable.
Yeah
I
mean
my
opinion
is
readable,
so
anyone
else
can
read
it.
F
F
F
Yeah
and
it
might
have
a
big
impact
on
how
the
working
group
sees
that
if
we,
otherwise,
you
have
two
updates
against
other
RFC's,
so
we
should
check
that
first
and
then
get
feedback.
So
this
is
a
general
question
on
the
whole
thing,
it's
the
most
difficult
questions.
So
it's
comment
one
and
here's
once
I
don't
think
we
can
easily
get
out
of
but
mark
uses
the
word
in
steady
state.
The
RTR
should
be
based
on
recent
observations.
I
don't
give
any
idea
about
how
to
quantify
recent.
F
So
that's
probably
okay,
but
we
could
say
it
was.
We
could
explain
what
recent
was
if
we
knew.
If
you
have
opinions
on
this,
we
can
make
the
text
better.
Otherwise,
it's
kind
of
not
that
useful,
as
should
to
evaluate,
and
similarly,
in
the
same
thing
time,
stop
measurement
should
be
taken
regularly
and
then
it
says
the
notion
of
regularly
should
be
defined
as
at
least
once
per
RTT.
I
think,
in
this
case
marks
done
exactly
what
I
hope
to
do
in
comment
too.
F
J
G
J
J
K
J
F
A
good
idea,
okay,
you
just
say,
may
do
whatever
it
likes
and
can
take,
or
whatever
I
mean
should
without
a
boundary
is
not
really
something
that's
measurable
should
without
a
boundary
should
should
being.
Recent
is
not
really
about,
because
you
there's
no
way
I
can
look
at
that
and
compare
it
with
anything
else.
Okay,
so,
okay!
This
is
this.
Is
me
kind
of
doing
a
review
to
try
and
create
some
discussion
here.
So
we
can
go
to
working
group.
Last
call
not
me
pronouncing.
L
F
Like
I,
like
I,
like
my
own
rewritten
blue
text
here,
which
says,
shouldn't
sex,
it's
kind
of
some
sculpture
or
some
example
of
what
this
should
means.
Okay,
that's
what
Janice
said:
okay,
that's
fine,
I!
Think
probably
these
two
can
be
read
a
bit
more
and
we
can
probably
get
consensus.
I
would
imagine,
there's
some
knit
some
choice
of
words
which
really
are
nits
and
what
about
CC
guidelines?
You
asked
me
about
this.
This
is
current,
an
individual.
F
M
:
I
think
you
did
a
very
great
and
working
group
last
call
with
you
here.
Let's
just
do
the
working
group
has
corn
game
like
one
or
more
than
one
or
two
more
of
these
reviews
and
get
that
given
out
the
door
I,
don't
think
we
need
those.
We
I
mean
like
great
that
you
did
it
right,
but
I
don't
think
we
need
those
reviews
before
working
class,
called
order
to
get
ready
to
work
in
class
cause.
This
is
like
something
you
do
in.
F
A
The
reason
why
we
asked
to
review
rights
in
the
be
hoe
hand,
we
didn't
get
much
feedback
on
this
rap.
That's
why
we
assign
the
reviewers
here
right
now.
It's
done
corey
one
question,
so
these
are
determine
our
comments
from
my
point.
If
it's
not
major
issues,
so,
let's
know
after
so
you,
basically
okay
with
yeah.
A
F
My
comments
for
working
great
last
call
will
be
these
comments
if
the
text
remains
like
this,
and
these
apart
from
the
first
one,
there
are
none
of
these
comments
which
are
which
will
block
a
working
group
must
call
the
first
one
should
be
clarified,
I
think
by
the
chairs.
So
the
intent
of
the
document
is
clear:
does
it
update
other
RFC's
or
does
it
not
because
that
is
an
important
thing
to
get
right?
F
L
I'll
first
apologize
for
not
having
done
the
review
sooner
and
I
am
writing
up
some
things
right
now,
but
it's
I
read
through
the
draft
carefully
and
I.
Think
it's
it's
it's
well-written,
except
there
is
one
major
question:
that's
a
clarification
point
or
question
of
scope
really
of
the
document,
so
the
document
isn't
eCPM.
L
It
says
that
the
let
me
pull
the
text
search
is
horrible.
The
text
the
draft
says
in
section
3
the
principles
we
are
try
on
this
document
or
protocol
agnostic
and
widely
applicable.
So
that's
point
one.
However,
the
draft
continues
to
say
that
the
requirements
of
this
document
only
apply
to
cases
where
loss
detected
by
a
timer
is
repaired
by
a
retransmission
of
the
original
data,
and
there
are
other
ways
of
doing
recovery,
but
this
document
doesn't
consider
those
transports
effectively.
The
document
precludes
quick
because
quick
does
not
actually
require
you
to
retransmit.
L
L
Think
it's
perfectly
fine,
without
that
I'll
apologize
to
mark
for
bringing
this
up
this
late,
I'm
great
I'm,
grateful
that
he's
not
on
the
call,
because
when
he,
when
he
else
at
his
computer
later
on,
I
won't
be
there
to
hear
it,
but
I'm
happy
to
write
this
up
now
and
and
send
it.
But
this
is
this
is
a
question.
L
I
suppose
do
we
want
to
say
this
is
for
TCP
or
do
we
want
to
say
this
is
broader
or
for
other
protocols
and
include
quick
in
it
explicitly
or
it's
somewhere
in
the
middle
right
now,
which
is
maybe
alright
I
don't
want
to
have
to
go
to
change
the
whole
thing.
It's
still
useful
as
it
is
I,
don't
wanna
make
this
go
through
a
whole
of
the
process.
Again,
that's
okay!.
H
H
Praveen
I
had
a
clarification
question
actually
for
Jonah,
so
when
I
say
quick
doesn't
do
retransmission
we're
done
we're
still
with
reliable
delivery.
You
will
end
up
retransmitting
the
payload
at
some
point.
If
it's
not
the
packet
right,
so
I
mean
any
reliable
transport
in
this
probably
applies
to,
maybe
maybe
in
certain
ways,
but
not
others.
I.
L
Think
that's
true,
but
really
what
I
care
about
is
loss
detection.
Ultimately,
the
RTO
is
about
detection,
not
about
actually
the
retransmission
of
the
data
after
that,
so
I
think
I'm
trying
to
say
that
if
the
scope
of
the
document
is
limited
to
detection,
it
applies
much
more
broadly
than
it
does
right
now,.
F
Curry
fellows
at
the
beginning,
I
said:
IRC
I-285
applies
to
udp-based
transports.
That
applies
to
quick.
This
aligns
I
think
with
that,
because
Marc
provided
input
to
that.
So
I
think
this
is
probably
just
a
circular
dependency
as
far
as
I
can
see,
as
in
you
asked
does
it
apply
to
quick,
because
this
says
no
only
retransmission
protocols,
RFC
808
5,
does
apply
to
quick
and
has
the
same
guidance
in
so
we
just
know.
L
M
So
if
it
actually
was
not
intended
to
say
that
like
if
they
actually
wanted
to
talk
about
loss
detection
you're
not
about
because
mission
is
unnecessary
right
but
like
I
also
don't
have
any
problem
with
it,
because
we
have
the
experience
with
TCP,
it's
a
PCP
for
TCP,
which
is
very
applicable
to
TCP,
and
you
can
of
course
use
it
for
other
protocols.
It
would
make
sense
to
you,
but
it's
like
not
binding
in
that
sense,
for
other
protocols,
which
is
also
fine.
So
it's
so
Gaiden
3
yeah.
O
Morocco
yaah
grunting
grunting-
that
is
very
important.
Is
that
always
even
though
its
loss
deduction
was
detection
means
that
we
quite
likely
retransmitted
and
retransmissions
are
always
they
have
to
do
with
the
congestion
control.
So
whenever
you
play
with
the
timer's,
that's
related
to
consistent
Rockets
also
very
clearly
said,
also
India
conscious
the
motor
principles.
Please
read
that.
O
A
P
P
This
table
will
show
the
difference
between
the
original
3168
ec
n
specification
and
our
proposed
draft.
Basically,
the
original
specification
didn't
enable
the
marking
of
any
control
packet
in
the
draft.
We
allow
this
in
two
different
scenarios
in
case
where
a
key
CN
has
been
negotiated
or
is
being
negotiated
in
the
case.
That
occasion
is
not
being
negotiated,
so
for
most
of
packet
is
the
same
thing
you
can
mark
them,
except
for
a
couple
of
cases
where
you
can
only
mark
them.
P
As
long
as
I
mean
you
have
are
trying
to
negotiate
occasion,
we
have
so
we
have
had
a
very
thorough
review
from
Michael
in
the
last
money.
Over
the
last
couple
of
months,
we
changed
quite
a
few
things.
I
would
say
that
most
of
them
were
like
clarifications,
rewarding
justifications,
rearrangements
Neen,
but
essentially
we
were
like
most
editorial
and
and
not
only
editorial,
but
clarifications
in
this
type
of
things
right
to
improve
readability
and
this
type
of
things-
and
there
is
one
main
change
that
we
have
done
based
on
Michaels
comment.
P
That
is
the
following
right
in
the
previous
version
of
the
draft,
the
only
the
only
situation
that
you
can
actually
mark
the
seen
packet
as
ICT
was
if
we
were
also
trying
to
negotiate
occasion
right.
The
reason
for
that
is
because
a
key
CN
allows
enables
you
enables
the
server
the
one
receiving
the
seen
mark
with
AK
CCM
to
feedback
the
congestion
signal.
In
case
the
scene
was
C
marked
right
standard
I
mean
the
current
3168
EC
ends.
I
mean
server.
Supporting
this
spec
does
have
the
means
to
provide
that's
it
right.
P
So
we
have
the
long
discussions
before
about
this,
and
the
decision
was
that,
unless
you're
able
to
feedback
the
congestion
signal
back
to
the
client,
you
should
not
be
able
to
mark
the
scene
right.
That's
why
we
only
enabled
the
marking
of
the
scene.
If
you
were
negotiating
a
kiss
en
Michel
suggestion,
was
he
still
wanted
to
allow.
P
The
marking
of
the
scene
in
cases
where
you
were
not
negotiating
occasion-
and
he
proposed
that
you
do
that
as
long
as
you
keep
the
initial
window
to
one
right,
you
react
as
if
you
have
receive
a
mark,
a
congestion
signal,
even
though
you
will
not
receive
anything,
because
there
is
no
way
for
you
to
get
the
signal
back
right.
So
we
we
thought
that
this
was
okay,
I
mean
it
doesn't
break
anything
I
mean
it's
I
mean
you're
putting
yourself
in
the
worst
case.
P
P
Good
question:
a
good
good
question,
so,
as
current
what
we
are
stating
in
the
draft
is,
you
can
mark
this
if
you
have
some
way
to
get
the
feedback
back
either
a
Kishin
or
any
other
mechanism
that
will
be
refined
in
the
future
because
as
far
as
I
know,
currently
there
is
no
other
standard
that
actually
allows
them.
Yeah.
M
It
could
even
I
just
realized.
It
could
can
even
generalize
this
a
little
bit
more
because
what
we
usually
the
advice
we
give
to
UDP
traffic.
That
is
not
congestion
control.
Is
you
kind
of
sent
more
than
one
packet
per
under
time?
So
if
you
keep
your
window
forever
at
one
I,
don't
know
why
you
would
do
that
with
TCP,
but
maybe
there's
a
case.
You
can
actually
mark
all
your
packets.
Also
your
X
with
it
is
he
capable
ECT
cable
I
mean
that
good
make.
N
F
F
K
G
K
Just
thinking
about
taking
advantage
of
the
fact
that
ECE
is
sticky
in
standard
IO,
61
6
8,
so
the
stick
could
record
the
the
state
of
C
II
in
during
the
handshake,
even
though
it
won't
be
visible
until
after
the
handshake.
So
for
the
first
RTT
it
might
be
necessary
to
limit
the
initial
window
to
1,
but
subsequently
it
could
be
increased
once
the.
It
is
confirmed
that
no
c
e
mark
occurred
during
the
handshake.
D
D
K
K
D
P
P
So
I
am,
as
far
as
I
understand,
Jonathan
suggestion
seems
seems
acceptable,
seems
reasonable
right.
The
problem
is
that
there
are
implementations
that
will
behave
in
a
on
on
desire
way
if
that
action
did.
If
we
take.
If
you
took
that
approach.
So
the
question
is
whether
we
should
want
to
acknowledge
the
existence,
implementations
and
try
to
avoid
having
a
problem
with
them,
or
do
this
that
seems
to
work
unless
I'm,
except
for
the
fact
that
80%
of
the
server
seems
to
take
it
in
the
wrong
way.
P
M
M
So
actually
it's
not
a
problem
because
like
if
that
occurs,
you
won't
negotiate
easy
and
with
the
server
right
and
then
you're
in
the
state
where
just
not
like
you
should
easy
and
capable,
and
you
shouldn't
set
any
easy
nfx.
So
if
you
negotiate
easy
and
with
the
server
then
you're
right,
if
you
don't
get
feedback
right.
G
M
You
should
be
able
to
be,
then
you
should
know
that
there
was
no
marking
and
you
can
probably
increase
your
window
again,
but
I
think
we
should
double-check
how
this
is
implemented.
If
it's
actually
implemented
as
sticky
or
not
I
mean
it
should
be,
but
I'm
not
sure
how
it's
implemented.
That's
the
one
part
so
like.
If
it's
actually
implemented
a
sticky,
we
can
do
that.
M
R
P
S
C
M
P
A
M
So
what
we
have
right
now
is
that
we
have
our
C
27:18
2780
that
specifies
the
registration
policy
for
the
TCP
header
flex
standard
section
and
we
have
31
80
68,
which
actually
forms
a
registry
for
these
slicks.
So,
firstly,
there
was
there
was
a
registration
action,
but
no
registry.
Then
we
had
a
registry
and
then,
after
that
we
had
an
experimental
RFC
that
assigned
bit
number
seven,
which
is
not
really
what
the
registration
policy
said.
M
M
83
11
doesn't
make
any
recommendations.
What
to
do
about
like
you
know
how
we
can
use
seven
bit
number
seven
again.
It
says
like
it's
open
for
experimentation,
but
like
what
do
we
do
about
the
registration
in
the
regice
regice
tree,
and
so
we
now
want
to
use
it
again
for
equity
CN,
and
we
are
not
sure
what
to
do
here.
M
Usually,
so
how
can
we
ever
use
a
bit
if
we
want
an
experiment,
but
then
we
have
send
as
action
registry.
So
the
the
the
end
of
this
thought
process
would
be
that
we
use
a
bit
for
an
experiment.
We
don't
put
it
in
the
registry,
which
also
doesn't
make
sense,
because
we
have
a
registry
so
actually
announce
that
it's
used.
So
that's
why
I
would
like
to
change
the
registration
policy
here.
Of
course,
we
have
to
be
very
careful.
M
This
is
like
one
proposal
there
other
proposals.
We
could
only
apply
this
to
the
equity
CN
bit
because
it
was
already
messed
up
or
like
the
the
nonce
bit.
Actually
the
reserve
bit,
because
that
was
already
messed
up
and
there's
also
chance
for
temporary
assignment.
But
it
doesn't
really
say
exactly
what
a
temporary
assignment
isn't,
what
it
means,
or
we
can
just
like
not
assign
it
and
and
go
on
with
the
experiment
or
whatever
or
like.
M
A
T
T
So
I
would
submit
that.
Basically,
any
use
of
these
flags
is
going
to
be
in
its
initial
deployment
phase,
which
is
from
twenty
twenty
to
twenty
twenty-nine
experimental
de
facto.
So
I
think
that
the
document
or
the
you
know
the
documentation
about
this
registry
should
actually
reflect
the
reality
and
that's
what
this
does
so.
T
Do
it
I'll
notice
that
we
did
a
we,
you
know,
so
you
and
I
actually
did
a
very
small
experiment
last
year
that
that,
compared
in
a
small
slice
of
the
network,
the
deployability
of
these
actual
flags
without
a
registration
to
experimental,
TCP
options-
and
this
came
up-
favorably
like
it
was
there
was
no
like
the
difficulty
of
deployment
was
the
same.
So
given
that
I
think
we
even
have
data
that
says
that,
yes,
this
is
experimental
and
you
know
make
their
make.
The
document
reflect
reality
so
adopt
publish
last
call
home.
We're
done.
M
F
Gory
first
I
think
you've
applied
the
slow
start
method
to
writing.
Internet
drafts,
yes,
I,
like
the
idea
of
doing
this,
no
I,
don't
like
your
draft
and
no
I,
don't
like
the
choice
of
keywords
in
your
draft
and
no
I,
don't
like
the
spelling
mistakes
and
other
stuff.
So
thank
you
for
making
a
draft
quickly.
F
M
F
G
F
M
U
David
black
author
of
83
11,
yes,
do
this
at
the
time
the
HP
eleven
was
done,
I
already
had
more
than
enough
stuff.
I
was
cooked
with
net
draft
and
did
not
I,
don't
think
the
tray
sponsor
was
ever
mentioned.
Had
it
mentioned
at
the
time,
I
would
have
gently
declined
to
have
taken
on
consumer
had
already
had
more
than
enough
scope
creep
adventures
on
83
eleven.
Q
Yeah
I
mean
the
only
there
was
only
one
real
negative
in
the
draft,
and
that
was
the
word
that
was
recent
used
and
I.
Don't
I,
don't
like
time-variant
sayings
in
drafts,
so
that
that
we
shouldn't
talk
because
recent
only
applies
for
a
short
period
of
time
so
that
but
the
the
other
one
is.
How
do
we
handle
the
the
must
situation?
That's
in
the
draft
of
we
must
negotiate
before
use
of
the
bits
which
effectively
means
the
bits
or
permanently
have
a
default
state
where
they're
unused.
Q
M
When
I
was
what
I
was
trying
to
say
in
the
draft,
if
you
use
a
bit,
you
need
to
add
some
kind
of
negotiation
mechanism
to
make
sure
that,
like
whatever
you
define
in
your
experiment,
can
be
changed.
But
like
there's,
no
negotiation
to
use
a
bit
like
because,
like
I,
don't
know
how
that
would
work.
Okay,.
T
Yeah
sounds
like
there's
a
little
bit
of
words.
Nothing
to
do
here,
because
one
of
the
one
of
the
things
you
might
want
to
do
is
use
these
bits
to
negotiate
the
use
of
the
bits.
All
right
like
cuz
I
mean
like
so
any
any
encoding
is,
is
probably
gonna
have
a
trick
like
that.
Like
you
know,
so
we
did
with
our
you
know.
T
M
I
mean
I
think
this
is
a
really
important
point,
because
the
point
is,
if
you
have
proposed
on
it,
you
don't
have
to
think
about
like
negotiation
anymore,
because
you're
sure
this
mechanism
is
like
what
we
want
and
we
never
want
to
change
it
ever
again
right
for
an
experiment.
It's
really
important
to
be
able
to
like
change
some
things
so
so.
V
M
K
K
D
M
To
say
is
that
if
you
want
to
use
this
bit,
you
need
some
way
of
negotiation
it
in
order
to
change
the
mechanism
that
is
using
the
bit.
Somehow
it
doesn't
say
you
have
to
use
a
bit
for
negotiation,
it
doesn't
say,
like
you
have
to
use
an
option
or
whatever
it
doesn't
say
how
you
do
you
negotiate
and
win,
but
you
have
you
have
to
have
a
way
because
it's
experimental
to
change
your
experiment.
M
And
and
I
think
actually
Nantes
did
not
a
good
job
about
defining
the
experiment
and
trying
to
figure
out.
You
know
what
could
fail
and
how
to
change
it,
but
I
also
don't
know
how
non
that
assigned
to
this
bit,
because
that
doesn't
seem
to
be
what
the
procedures
are
saying
and
I'm,
not
old
enough
for
that.
I'm.
Sorry,
like
somebody
maybe
somebody
remembers
I,
would
really
like
to
know
some.
Q
Broad
crimes
I'm
in
agreement
with
Johnathan
here
that
I
think
we've
discussed
this
enough
I
think
we're
in
and
we've
got
some
paths
forward.
We
need
to
do
a
little
bit
of
research
and
figure
out.
Maybe
what
some
of
these
other
things
that
might
be
possibilities
are,
but
this
is
a
really
good
start
to
move
things
forward.
Q
D
You
know
it's
the
the
question
of
whether
something
is
an
experiment
doesn't
depend
on
what
you
put
at
the
top
of
the
draft.
It
depends
on
whether
it's
reversible
and
so
I
I
think
maybe
the
least
we
should
do
is
write
into
this
thing.
Some
some
statement,
like
that
say
it
must
they're
working.
It
must
be
clear
that
the
the
experimental
status
is
not
used
just
to
get
a
code
point
in
India
in
the
TCP
header
you
have
it
prove
that
it's
reversible
it.
M
Actually,
the
draft
says
it's
not
result
reversible.
If
you
use
these
bits,
then
you
use
them.
If
you
deploy
it,
then
they
are
in
use.
Then
it's
not
reversible
anymore.
That's
the
problem
about
that's
why
we
had
the
Senate's
action
before,
but
what
the
draft
does
say
is
that,
because
it's
not
reversible,
you
have
to
make
sure
you
can
still
change
your
mechanisms.
You
propose,
so
you
need
some
negotiation
for
that.
Q
M
M
N
L
L
Respond
to
the
previous
speakers
point:
you
can
have
a
plan
for
deployment.
A
plan
for
deployment
doesn't
mean
deployment.
I
have
plan
for
deploying
many
things.
It
doesn't
mean
that
they
are
deployed,
and
so
really
the
question
at
the
point
when
you
want
to
reverse
something,
is
to
look
and
see,
as
we
always
do
if
it's
already
been
deployed,
if
it's
not
deployed,
go
ahead
and
reverse
it,
if
it's
reasonable
pain,
go
ahead
and
reverse
it,
if
it's
not
reasonable
pain,
you
can't
reverse
it.
This
is
Trey
Polster.
L
D
D
The
idea
is
well
there's
the
ACN
field
in
the
IP
header
and
then
three
three
bits
use
three
flags
in
the
TCP
header
in
order
both
to
negotiate
and
then
use
over
load
and
use.
Those.
So
much
like
we've
just
been
talking
about
to
really
solve
a
problem
with
the
3168
feedback.
That
I
was
Jonathan
calls.
It
was
sticky,
you
could
only
you
could
only
feedback,
1
congestion,
experienced
mark
/,
round-trip
time
and
the
structure.
D
It
can
only
last
up
to
eight
increments
of
the
C
II
can't
er,
and
then
you
use
that
with
the
other
fields
at
number
and
signals
number
to
work
out
how
many
bytes?
If
you
want
to-
and
there
was
a
supplementary
accuracy-
an
option
with
variable
length
for
a
number
of
fields
and
that's
what
I'm
going
to
talk
about
today
and
that-
and
that
was
it
was
added
in
so
that
you
can
have
information
about
more
fields
such
as
the
EC
T,
1
and
e
ste
0.
D
If
you
want
to
get
feedback
on
them,
and
so
we've
had
one
suggestion
that
to
cut
the
current
sorry,
these
slides
were
drawn
very
quickly,
so
I
may
have
to
explain
them
or
I'm
done
a
good
job
of
explaining
them
visually
properly.
The
current
design
is
the
top
one,
and
the
proposed
design
is
to
have
both
of
them
and
for
the
initial
value
in
the
first
field
to
determine
which
order
the
fields
are
in
for
the
rest
of
the
connection.
D
D
Yeah,
okay
and
that's
also
been
pointed
out
that,
if
someone's
monitoring
the
path
that
means
that
you're
affected
your
counters
are
fixed,
we've
got
halfway
through
the
path
when
used
to
halfway
through
the
number
space
when
you
start,
and
so
even
if
you
miss
beginning
of
the
connection,
you
can
tell
for
quite
a
long
time
which
all
of
the
fields
are
and
things
like
that,
all
right.
Okay,.
D
F
F
F
D
I
suppose
this
has
the
advantage
that
it
is
for
the
case
where
someone's
measuring-
and
this
is
the
beginning
of
the
connection.
This
is
clearer.
What's
going
on,
if
you
miss
the
beginning
of
the
connection
or
you
know,
packet
gets
lost
and
you
don't
see
the
first
packet
first
or
they
get
reordered.
You
know
this
one
still
works,
but
the
kind
one
will
work
all
the
time.
Yeah.
Q
Q
M
D
M
D
D
K
D
Each
one
there's
more
because
that
the
idea
of
this
sorry
I
didn't
give
the
introductory
idea,
which
is
that
even
already
you
don't
have
to
have
all
the
fields
you
can
have
two
of
them.
If
this
one's
never
changed
or
you
can
have
one
of
them
with
both
of
the
last
two
have
never
changed,
and
so
and
and
what
I'm
wanting
to
be
able
to
do
is
with
the
initial
values
of
that
first
field.
L
L
Me
what
media
was
saying,
I'm
just
gonna,
be
a
little
bit
more
specific
and
we
shouldn't
design
this
here
at
the
mic.
That's
a
bad
idea,
but
if
you're
gonna,
it's
it's
a
lot
easier.
If
you,
if
you
identify
each
field
on
its
own,
you
don't
have
to
care
about
the
the
ordering
of
the
fields
in
here
at
all.
M
M
D
D
M
Yeah,
actually,
we
used
to
have
a
different
design
at
the
very
beginning.
Then
we
make
more
simple.
We
changed
now
we're
changing
it
back
and
we
ruble,
but
like
I,
think
the
important
question
here
for
the
group
is:
do
people
want
to
support
only
one
kind
of
option
for
like
this
version
or
two
people
want
to
support?
Also
the
different
ordering
for
yeah.
G
F
Eat
ect,
ect,
yeah
and,
as
I
see
no
elf
rest
but
yeah,
so
the
question
I
see
is:
do
we
want
to
allow
reporting
different
combinations?
In
other
words,
is
the
so?
Can
you
make
a
simple
pricey
of
the
question?
We
just
ask
the
group
whether
this
is
a
use
of
place
to
dig
without
without
how
we
encode
it.
But
just
is
it
useful
to
actually
look
at
that?
Yes,
Camille
I.
D
F
A
So
what
do
we
think
okay
question
needs,
so
do
we
want
to
think
about
in
this
kind
of
you
know,
define
two
formats
basically.
A
V
D
In
the
only
two
schemes
that
exist,
you
would
right,
but
you'd
only
either
use
H,
t0,
always
or
or
use
s
t1,
always
and
at
the
moment
no
one's
proposing
to
use
both
or
what
no
that's,
not
sure
se
e
se
e
wants
to
use
both.
So
in
some
cases
you'd
have
to
changing
and
and
the
way
the
draft
works
is
that
it
says
you
can
truncate
it
if
the
counter
hasn't
changed
that
you
must
beacon,
think
three
times
of
per
round-trip
time,
all
of
them
just
so.
V
Thanks
I
think
it's
you
know
the
the
the
option.
Space
is
for
some
abuse
cases
pretty
well
constrained,
so
I
think
that
would
be
well
valuable
and
there's
probably
an
encoding
I
mean
again.
We
won't
do
it
at
the
mic,
but
I'll
probably
do
something
to
list
on
how
maybe
we
could
generalize
this
in
an
efficient
way,
but
yeah
I
think
this
is
I,
think
if
we
can
get
away
with
this,
usually
being
a
eight
byte
option
instead
of
a
eleven
byte
option,
that
would
be
good
salary
thanks.
A
A
D
So
I
just
wanted
to
heads
up
on,
go
and
have
a
look
at
the
draft
because
there's
some
reasonably
extensive
changes
because
due
to
comment
from
Michael
which
actually
made
us
realize
there
was
a
lot
bigger
problem
when,
when
we
made
the
option,
we've
just
been
talking
about
optional.
In
other
words,
so
that
you,
you
could
just
work
with
the
three
bit
counter
without
the
option
we've
got
all
this
stuff
about.
If
a
counter
has
changed,
you
must
send
the
option.
D
But
of
course,
if
you
weren't
sending
the
option,
you
couldn't
must
send
it,
and
so
we
we
had
to
put
in
some
additional
stuff
there.
But
then
we
realized
we
hadn't
actually
got
that
any
text
for
when
you
must
send
an
ACK
at
all,
even
if
you
weren't
sending
the
option
so
we
had
to.
It
was
there's
quite
a
bit
of
text
in
there
now
about
when
you
send
an
ACK
depending
on,
what's
changed,
even
if
you're
not
sending
options
as
well
as
when
you
are
alright.
A
Okay,
now
I
would
like
to
talk
about
the
procedural
discussion
for
partition
and
Asian
prosperous
and
then
what
I
would
like
to
discuss
its
how
to
proceed
these
drafts?
So
it's
not
a
technical
discussion,
how
it's
like
to
focus
on
how
to
proceed
these
two
draft
and
then
basically
you
know
this.
Why
I
don't
want
to
need
any
detailed
discussion
to
think
about
how
to
proceed
is
rough.
So
please
not
avoid
any
technical
discussion
in
this
discussion
and
then
first
checkpoint.
A
We
have
a
several
technical
discussion
beforehand,
and
so
my
initial
check
is:
do
this
rough
time
remaining.
The
technical
discussion
point
before
working
with
Roscoe
once
he'll
talk
about
some
in
the
negotiation
of
feedback
things
and
then
also
both
talks
about
some
TCP
option,
format
things.
But
my
I
would
like
to
check
if
this
is
very
big,
shows
top
of
these
this
draft
or
to
have
any
opinion
on
that.
M
Actually
would
like
to
deep
bundle
the
discussion
of
occurred,
easy
on
and
easy
on,
plus
plus
here,
because
we
cannot
publish
you,
see
n
plus
pass
without
equity
CN,
but
we
can
publish
or
can
move
on,
equity
C
and
before
we
have
for
agreement
on
e
CN,
plus
plus
so
I
believe
echo,
DC
n
is
mostly
ready.
I
mean
this.
This
negotiation
is
not
like
an
issue
in
the
sense
that
it's
like
something
was
wrong.
It's
something
we
actually
had
discussed
before
and
now
we
changed
our
mind,
so
we
should
like
address
it.
D
A
H
D
We
we
were
considering
writing
a
slight,
a
slight
addition
in
a
separate
draft,
but
that
gave
another
negotiation
you
could
do
without
curry,
CN
which
it
says
you
can
do
in
the
draft.
It
says
you
know
this
is
this
is
a
way
to
extend
it
in
future
and
both
or
a
number
of
companies
have
said
we're
using
DC
TCP
to
style
feedback
internally.
D
If
we
move
to
using
accurate
ecn,
we're
gonna
have
a
transition
problem,
and
so
can
we
use
the
accurate,
easy
n
negotiation
at
the
start,
but
still
be
using
our
old
feedback
scheme,
because
we've
got
hardware
that
depends
on
in
all
the
rest
of
it,
but
at
least
then
we
can
start
using
something
different
and
and
move
to
it
as
we
get
in
new
hardware
and
things.
So
that
was
the
problem
and
we've
said
yes:
we've
got
the
facility
to
do
that.
You
can.
D
You
can
use
different
initial
values
of
the
ACE
counter
in
the
three
bit
header
to
say
to
tell
the
other
end
and
negotiate
with
the
other
end
that
I'm
declaring
I'm
using
a
different
sort
of
feedback
on
the
on
these
bits
and
s.
You
could
do
this
instead
of
using
the
TCP
option
as
well.
So
it's
got
that
benefit,
but
you
know
that
would
require
you
the
the
one
this
benefit
of
this.
A
H
M
A
Toby
Pato
procedural
discussion,
okay,
so
I
think,
let's
say
you
know
we
move
forward
to
accurate,
easy
and
draft,
and
then
both
you
impress
Prosser
and
then
from
Chad's
point
Oh
bill.
We
still
have
several
remaining
points
and
then
first
one
is
bit
severe
occasion
and
then
second
one
is
I
would
like
to
check
in
dependency
of
the
other
related
proposal.
Basically,
right
now
we
have
a
see
my
future
might
be.
We
might
have
another
proposal
so
but
I
what
I
would
like
to
avoid
it.
A
If
we
proceed
accurately
see
an
ancient
process,
we
cannot
do
any
other
issue.
Experiment,
that's
I,
try
to
avoid
such
kind
of
things.
So
before
we
proceed
our
creation
among
Asian
prospers
I
would
like
to
confirm.
There
is
no
conflict
or
a
dependency
for
other
proposals
so
that
we
can
safely
proceed
accretion
and
the
Gaussian
process.
That's
what
I
directed
the
third
point.
I
would
like
to
come
from
before
we
move
up
to
the
Viking
Rusco
coming
right.
A
Yeah
I
think
so
that's
to
me
or
just
obvious
okay
and
then
also,
if
you
have
any
other
thoughts.
No,
this
is
a
to
major
point.
You
know
we
need
to
think
about.
If
you
have
other
point,
we
need
to
think
about.
Please
stick
up
if
no,
we
just
focus
on
to
these
two
point
to
think
about
procedure:
accurate,
easy
and
easy
and
prosperous
okay.
So
first
I
would
like
to
discuss
about
PC
bar
location.
So
now
you
know
that
we
have
a
several
choice.
A
One
choice
is
promote
a
creation
to
propose
standard
and
allocate
b7
for
tradition.
This
is
one
option
and
then
second
option
is
the
media
proposed
abouts
registry
frog
thing
and
then
utilize
this
method
and
then
apply
B
7,
fortunately
CN.
But
there
are
several.
You
know,
possibility
and
so
Michael
Schaff
mentioned
that's
no.
We
only
apply
this
policy
on
bp7
or
the
other
way
is
now.
We
can
apply
this
policy,
all
remaining
reside
bit
and
then
the
other
way
is,
you
know,
I,
don't
know
this
one
exactly.
A
A
We
might
be
able
to
you
check
that
one,
but
I
don't
know
if
we
have
been
seeing
any
precedence
in
my
as
far
as
I
know,
I,
don't
know
how
it
works,
and
so,
but
this
is
documented,
so
there
could
be
a
way
for
this
and
then
also
if
there
is
other
way
to
AutoCAD,
BC
I
would
direct
mode
here.
So
any
comments,
I.
K
Q
R
I'd
like
to
add,
based
on
what
I
heard
here
in
the
room,
if
there
might
be
another
option,
because
we
have
repeated
in
the
term
negotiation-
and
one
thing
you
could
think
about-
is
to
move
accurate,
easy
end
proposed
standard
for
the
negotiation,
part
of
because
that
seems
to
be
useful
even
to
other
schemes
and
then
discuss
separately.
What
happens
after
negotiation,
which
could
either
be
proposed,
send
out
or
experimental
and
as
I
heard,
that
other
word
guys
are
not
thinking
about
using
the
negotiation
for
OPEC
or
compatibility,
and
things
like
this
I
mean.
R
It
seems
to
me
that
this
negotiation
is
can
be
crucial
and
it's
a
relatively
trivial
thing
to
do
it
so
I
think
the
powerful
proposed
standard
for
the
negotiation
would
be
relatively
low,
so
that,
to
me
at
least
putting
the
negotiation
to
proposed
standard
would
be
an
option
that
could
possibly
also
be
beautiful.
But
it's
just
a
thought.
I've
been
thinking
about
this
before
so
far.
I
wasn't
really
convinced
it's
a
good
option,
but
base,
but
not
but
I
get
and
now
in
the
room
is
I.
R
M
R
Well,
yeah
I
mean
the
other
registry
that
you
mention
is
a
couple
of
the
other
things,
so
that
is
all
part
of
the
negotiation,
and
then,
when
you
do
afterwards
is
I
mean
there
can
be
different
specs
for
what
happens
after
what
SSU
discussed?
I
mean
it's
all
deck
mode
for,
if
you
think
you
think
could
be
another
experimental,
whatever
spec
for
just
so
I,
don't
know
how
exactly
the
document
would
look
like.
I
just
want
to
note
its
option,
and
it
would
have
to
benefit
that
the
bid
is
allocated
by
a
proposed
standard.
M
The
problem
is
you
negotiate
something,
and
then
you
have
an
extension
that
negotiate
something
else.
So
if
the
extension
is
not
understood,
you
have
to
fall
back
to
the
thing
that
you
negotiate.
It
first
right
and
if
the
first
thing
unique,
a
shade
doesn't
actually
imply
any
mechanism,
then
you
have
to
have
a
default
mechanism
with
the
negotiation.
Otherwise.
R
R
But
I
think
even
even
in
the
negotiation,
you
can
mandate
other
guidelines
on
what
to
do
afterwards,
because
it
would
be
proposed
to
end
up
possibly
so
you
can
mandate
what
has
to
happen
after
that.
So
you
can
act
requirements
when
the
schemes
after
I
I
mean
I,
don't
know
how
it
exactly
works
and
I
don't
want
to
engineer
it
right
now.
I
just
mention
that
to
me
after
there's
another
option-
and
it
means
putting
these
parts
of
occurred-
is
the
proposed
standard.
I
would
other.
Finally
other
to
conclude.
D
This
is
Bob
Brisco
they,
the
idea
of
splitting
the
negotiation
from
the
scheme.
It
negotiates
assume
you
use
the
word
after
a
lot
in
that,
but
you've
got
the
possibility
of
reordering
you've
got
TFO
to
deal
with,
potentially
which
start
sending
data
a
bit
well
during
the
handshake.
So
these
things
are
intimately
tied
together,
you're,
you
know
and
you've
got
the
possibility
of
losing
the
third
ACK
in
the
handshake
and
you've
got
to
deal
with
all
those
things
and
if
you
try
and
split
that
into
two
completely
separate
mechanisms,
it's
nearly
impossible.
D
You
know
you
really
need
to
do
all
that
in
one
mechanism
and
have
like
me
a
set
of
default,
and
then
anyone
who
wants
to
start
with
something
different
can
build
on
that
rather
than
try
and
have
a
clean
that
in
an
ideal
world,
yes,
you'd
have
a
clean
separation,
but
we're
way
beyond
that
because
we
got
so
few
bits.
You
know
it's.
R
M
R
R
I
mean
to
be
clear:
I
disagree
that
need
to
change
the
registration
registry.
If
you
find
another
way
for
a
Keynesian,
if
you
don't
find
a
way
per
acre,
BC
a
not
proposed
standard,
then
of
course
we
have
to
do
something,
but
I
would
strongly
suggest
the
working
group
to
think
about
the
the
first
way,
because
this
would
actually
not
require
any
changes
in
the
registry
right
now,.
A
M
So
what
I
heard
from
an
earlier
discussion
was
that
I
think
people
would
like
to
change
the
restoration
policy
no
matter.
What
so
I
will
work
on
the
draft
and
propose
it
again?
Okay,
but
maybe
we
can
independent
of
that
we
can
maybe
take
a
ham
if
people
think
they
would
like
to
go
for
proposed
under
or
experimental
for
equities
in,
like
I
personally
I,
actually,
really
don't
care
I
just
wanted
to
move
it
ahead.
Okay,.
A
A
Something
actually
and
then,
but
you
know,
if
we
accept,
we
try
to
publish
okay
edition
as
proposed
standard.
Do
you
have
to
restructure
the
drug,
because,
right
now
the
draft
is
very
well
written
as
a
experimental
draft.
In
my
understanding,
because
it's
discover
how
to
do
X
remain.
What's
the
goal
of
the
explain
something
like
that
right,
you
need
you
have
to
modify
that
draft.
A
drastic
re,
I
think
I.
M
F
Cory
and
I
think
the
decision
on
this
is
actually
the
chairs
with
their
ad
and
so
I
don't
mind
how
you
get
the
consensus
opinion,
but
you
could
ask
who
raised
the
hand
twice,
because
they
really
just
think
we
should
publish
something.
So
you
even
discover
the
momentum
if
you
wish
to
I'll,
leave
it
to
you.
Okay,
but.
A
P
Mean
just
to
just
more
to
a
point
than
to
of
what
Cory
just
said:
I
mean
this.
This
doesn't
seem
to
be
the
case
as
clerk
like
hard
people
thinking.
That
should
be
one
thing
or
should
be
the
ER
thing,
since
that
a
lot
of
people
think
it
should
be
published
that
it
doesn't
matter
how
okay
right
so
I
think
that's
the
situation.
I
mean
that
I
think
the
decision
is
pretty
much
irrelevant
here.
I
mean
you
need
to
I
mean
the
the
feedback
of
the
room.
For
me
is
this
should
go
ahead.
L
M
So
if
we
want
to
go
for
experimental,
we
want
to
allocate
the
bit,
we
have
to
publish
the
registration
change
at
the
same
time.
So
if
people
think
we
should
publish
its
experimental,
then
like
this
is
also
an
agreement
of
this
group
to
move
quickly
ahead
with
the
registration
policy
change,
which
I
think
it's
a
good
thing.
Yeah
right.
A
A
A
V
Sorry,
okay
I
would
like,
if
I
couldn't
just
go
back
to
the
previous
discussion
briefly,
so,
okay
in
terms
of
the
shortest
path,
the
publishing
accurate,
ecn,
I
heard
two
different
road
blocks.
If
we
make
it
a
proposed
standard,
then
we
have
to
do
some
editorial
rewrite
of
the
draft.
If
we
choose
to
make
it
experimental,
we
must
get
Mira's
Draft
all
the
way
through
to
go
to
last
call
simultaneously.
That's.
G
V
Its
quibbling
about
the
details
of
Mirrors
draft,
so
I
think
we
should
probably
I
have
no
idea
what
how
big
the
rewrite
is
and
how
big
the
Delta
is
on
what
people
want
to
see
out
of
Mira's
draft,
but
I
think
we
should
spend
maybe
a
little
time
seeing
what
the
shortest
path
is.
Since
nobody
seems
to
care
on
the
substance
of
whether
which
classification
is
but.
L
F
F
And
the
echo
Sen
Draft
is
only
changing
one
thing:
people
are
trying
to
implement.
This
is
probably
good
for
PS
a
if
you
feel
it's
mature
enough
is
good
for
PS.
The
registry
thing
yeah
sure,
but
if
we
do
this,
this
probably
becomes
sticky
or
immediately
becomes
equivalent
to
P
us,
because
we,
the
sticky
allocation,
happens
so
I
think
the
registry
thing
is
something
we
should
definitely
progress
as
quickly
as
we
can,
but
I
wouldn't
get
the
other
one
on
that,
because
it's
a
wider
consensus
car.
That's
my
input.
I.
F
Am
so
I
was
saying
that
there
could
be
a
good
argument,
the
proposed
standard,
because
people
are
starting
to
implement
against
this.
Therefore
it
will
be
seen
in
the
Internet
and
therefore
it
will
be
effectively
a
sticky
bit
in
the
update
draft,
the
other
draft
and
therefore
it
doesn't
really
matter
what
what
path
we
take
through
this.
If,
if
your
your
draft,
your
draft
matures
quickly
that
can
go
quickly
and
if
there
is
not
consensus
on
that
discussion,
then
this
shouldn't
block
it
right.
So
so,
let's
place
PS.
L
R
I
just
like
to
note
I
mean
the
key
advantage
of
going.
Why
RPS
is
that
we
have
no
dependency
on
IETF
consensus
and
changed
into
registry.
So,
of
course,
even
if
this
working
group
decides
to
publish
the
registers
change
fast,
it's
don't
need
to
get
IETF
consensus
and
that's
a
question
of
its
own.
The
benefit
of
doing
PSS.
You
can
trust.
You
have
used
utilized
IGF
procedures
and
you're
done,
at
least
in
the
working
group,
so
that
to
me
it
would
be.
L
Jen
Iyengar
I
actually
was
going
to
say
exactly
that.
I
was
going
to
say
that
that
is
actually
what
that
is.
One
part
that
is
faster
and
that's
PS,
so
experimental
because
it
brings
in
this
dependency,
can
be
the
same
speed
or
can
be
slower.
It's
not
gonna
be
faster,
so
this
is
definitely
going
to
be
faster
and
with
that
it
might
be
worth
sort
of
getting
a
sense
of
the
room
again
of
whether
we
want
to
do
my.
A
A
L
Jana,
younger
I,
don't
think
that's
I,
don't
think
that
is
relevant
to
whether
this
is
pious
or
experimental.
That's
a
deployment
question
right
so,
but
this
is
our
experimental
doesn't
change
the
fact
that
the
bit
on
the
wire
is
gonna
conflict.
If
you
use
it
in
two
different
ways,
so
I
think
going
to
be
s,
make
sense
independent
of
that
question.
I
wouldn't
I,
wouldn't
bring
those
two
questions
together.
M
A
F
A
Let's
see
if
you
want
to
okay
addition
as
a
proposed
standard,
please
raise
your
hand
if
you
don't
care
and
I
know
check
rate.
If
you
don't
key
I,
don't
raise
your
hand
if
you
don't
I
would
come
to
number
don't
care
as
well,
so
that
if
you
really
think
this
is
fine,
please
raise
your
hand
yeah.
It
should
be
PS.
A
A
L
Honestly,
I,
don't
think
it's
it's
controversial,
I
think
that
people
here,
who
don't
care,
still
want
to
see
it
published,
which
to
me
counts
as
a
vote
towards
going
with
the
shortest
path.
So
if,
if
the
people
there
are
more
people
going
for
PS-
and
there
are
a
lot
of
people
who
say
yes
or
experimental,
don't
care
I
would
count
them
towards
towards
either
neither
or
or
or
or
to
us.
Yes,
okay,
let's.
A
M
Didn't
people
just
make
kind
of
choose
the
parts
I
mean
like
you
have
to
confirm
on
the
mailing.
This,
yes,
but
I
think
it
was
pretty
clear
what
was
set
in
the
room
yeah.
So
like
the
of
cloth,
the
chest
should
sit
together
and
and
make
sure
that
they
all
agree
that
there's
contenders
in
the
room,
but,
like
my
sense
of
the
room,
is
there
is
consensus,
room.
A
M
A
W
A
A
R
Yeah,
no
I
think
that
the
first
of
all
consensus
in
TCP
must
always
figured
out
on
the
mailing
list,
because
we
have,
for
example,
people
that
don't
attend
the
meetings
so
anyway,
we
need
to
confirm
this
on
the
on
the
mailing
list.
At
least
this
much
share
head
on
I
also
see
here
quite
some
momentum
on
the
proposed
standard
way
to
do
it.
So
that's
probably
what
I
would
take
out
of
this
discussion,
and
then
this
means
that
we
can
separate
out
the
discussion
for
what
registry
trapped
as
we
have
to
discuss
the
separately.
R
M
Would
like
to
disagree
a
little
bit
here,
because
it's
not
just
decided
yet
if
your
proposed
standard
or
experimental
right
so
those
an
option.
If
you
go
for
experiment,
we
should
move
very
quickly
ahead
with
the
registration
change
and
given
that
there's,
like
logic,
women
in
the
room
already,
and
we
want
to
move
quickly
anyway.
It
would
be
nice
to
at
least
kind
of
make
a
ham
about
it
up
in
the
room
now,
which
anyway
has.
R
Under
made
because
we
are
Jared,
this
share
had
on
the
disk
draft
was
submitted
after
the
deadline
and
the
presentation
slides
were
submitted
very
late,
so
I
usual
tea.
Cpm
means
we
don't
do
an
adoption
called
in
that
situation
and
Mia.
This
would
not
be
a
good
idea
and,
as
I
said,
for
what
I
think
I
hear
right
now
is
we
don't
even
need
it?
We
can
have
the
adoption
discussion,
in
my
opinion,
on
the
mailing
list
later
right
when
people
had
time
to
think
about
the
different
variants.
This
is
Jared
on
yeah.
M
I'm
accepting
the
chat
decision,
but
this
is
also
not
a
usual
situation
because
usually
when
you
propose
something,
that's
not
this
dependency
right,
there's
a
dependency
here
in
this
period
of
moving
quickly
and
I,
submitted
it
very
late,
but
only
because
I
was
discussing.
This
was
a
chance
in
the
background
and
like
confirming
that
this
is
what
you
want
to
do,
but,
like
it's
a
chess
decision,
definitely
yeah.
D
D
A
Q
Rod
crime
sure
are
is
ongoing.
Discussion
too
in
that
area
and
I,
don't
believe
we
are
at
a
conclusion:
okay,
one
exactly
what
the
compatibility
situation
is
between
a
QC
and
SCE
again
between
l4
s
and
s,
EE
independence,
and
we
would
like
more
time
to
continue
that
discussion
before
we
talk
very
much
about
it
here.
Okay,
got
it.
F
Corie
fur
has
very
quickly
I
think
the
the
first
thing
on
the
marking
of
ECC
t1
and
reporting
of
it.
We
had
a
we
had
a
discussion
here.
We
thought
that
was
something
that
accurate
ACN
should
consider
I.
Think
looking
in
the
room
here,
we
should
consider
whether
reporting
ECT
one
behavior
is
also
possible.
Inaccurate
ACN
on
the
second
one
ts
vwg
did
not
make
a
call
on
that
situation.
It
doesn't
plan
intend
to
look
at
potential
conflicts.
Currently,
there
is
nothing
to
report.
We
cannot
report
anything
on
the
second
bullet
from
TS
vwg,
okay,.
Q
Rod
Grimes,
if
the,
if
we
change
equities
hand
to
a
proposed
standard.
If
that
negotiation
fails,
that
the
handshake
fails
as
long
as
the
bit
that's
allocated
to
accurate
ECM
then
becomes
available
for
another
use,
then
we
don't
have
a
conflict.
There's
a
qualifying
thing,
though,
that
bit
has
to
become
available
after
the
the
handshake
has
failed.
So
it
gives
a
deep.
It
gives
a
default
state
to
the
use
of
the
bit
and
that's
that
needs
to
be
addressed
so.
M
W
A
H
H
H
H
We
don't
see
too
much
difference
for
short
flows,
small
RTD
flows,
anything
less
than
100
milliseconds,
and
but
we
see
something
that
is
very
consistent
across
all
this
tests
is
that
even
if
goodput
doesn't
improve
the
number
of
retransmissions
decrease
a
lot,
which
means
we're
putting
less
load
on
the
network,
we're
not
cpu
limited
here,
so
the
number
of
bytes
on
the
network
is
reduced
and
our
tears
are
reduce
as
well,
and
there
is
some
improvement
to
loss
recovery
because
fewer
packets
are
lost.
We
are
awaiting
results
from
a
B
test.
H
H
A
E
H
L
A
A
H
A
A
D
I
I
will
commit
to
reviewing
this.
Thank
you
and
also
I,
just
wanted
to
point
out.
I
did
a
little
survey
of
the
main
implementations
and
how
they
were
being
used
and
with
high
start
before
high
start
plus
plus,
and
everyone
was
turning
it
off.
So,
if
you're
willing
to
turn
it
on,
then
it
says
something
so.
D
X
X
This
idea
deeds
in
the
last
revision
of
the
document
physically,
taking
into
account
feedback
from
the
room
in
Montreal
and
well
in
in
the
annex
of
the
document,
we
have
tried
to
summarize
some
alternative
approaches
that
might
be
useful
to
do
what
we
want
to
do
to
some
extent
and
well
here
are
some
of
them
acts
EC
would
weather.
The
sender,
tells
the
receiver
di
Grigio
to
be
used,
and
this
entails.
However,
some
overhead,
due
to
the
options
that
are
supported
there,
also
Talos
probe,
was
suggested.
X
However,
this
entails
sending
additional
probe
segments,
so
perhaps
it
that
some
overhead,
we
might
prefer
to
avoid
there,
also
workarounds
such
as
sending
an
old
bite.
However,
this
is
perhaps
not
so
clean
and
also
it
may
enter
sending
a
whole
new
packet
if
there's
no
new
data
available
for
transmission
or
something
like
the
split
hack
supported
in
the
contiki
OS,
which
is
based
on
splitting
a
message
into
two
segments.
There
was
a
lot
of
great
feedback
by
risk
on
the
mailing
list.
So
thank
you
very
much
for
that.
X
There
are
additional
motivating
scenarios
for
why
one
may
want
to
suppress
delayed
acts.
So
one
reason
is
getting
up
to
speed
fast
without
in
DC
image
queue
during
slow
start
that
had
been
actually
supported
for
a
while
in
an
old
version
of
the
actually
TC
n
draft,
and
also
there
had
been
discussions
in
the
context
of
quick
for
a
more
general
support
of
communicating
the
ik
ratio,
and
there
are
other
well
other
use
cases
for
getting
treat
triggering
quick
acts
so
well.
X
There
have
been
other
comments,
such
as
considerations
on
middle
box,
traversal
of
bits,
four
to
six,
perhaps
not
so
good,
and
what
also
suggested
using
the
urgent
pointer
in
an
innovative
way
such
as
reserving
three
bits
of
that
to
define
an
accuracy
exponent.
That
might
be
used
for
several
communication,
communicating
several
akrasia,
such
as
the
one
which
would
suppress
delayed
acts,
but
also
perhaps
other
a
gracious,
and
this
would
be
interesting
because
it
adds
no
overhead,
perhaps
there's
the
problem
of
what
happens
when
the
urgent
flag
is
actually
set.
X
X
Well,
there
was
some
discussion
previous
to
Montreal
and
it
seemed
like
setting
the
push
flag
doesn't
mean
you
get
an
immediate
ACK.
There
was
some
discussion
on
the
mailing
list.
Several
these
cases
described
and
it
seemed
that
someone
brought
this
point,
but
the
response
from
the
working
group
was
more
than
actually.
You
cannot
assume
that
push
the
push
flag
means
suppressing
delay,
tax.