►
From YouTube: IETF99-TCPM-20170717-0930
Description
TCPM meeting session at IETF99
2017/07/17 0930
https://datatracker.ietf.org/meeting/99/proceedings/
A
B
Okay,
so
let's
get
shot
at
welcome
to
the
first
session
here
at
the
IHF,
and
so
this
is
the
TCAP
meeting.
So
if
you're
not
interested
in
TCP
M
point
TCP,
this
might
not
be
the
right
working
group
for
you
and
before
we
get
started,
let
me
introduce,
let
me
introduce
Michael
so,
as
you
might
have
seen,
we
have
the
new
co-chair
and
I
think
this
is
the
first
time
where
Michael
is
sharing
on
site.
So,
let's
all
that
come
home.
B
B
So
this
is
the
note
well
so
for
those
of
you
who
are
the
first
time
it
in
IETF
meeting.
Please
read
carefully
the
note
well
for
those
of
you
who
know
it.
You
probably
know
it.
So
this
is
not
yet
meeting
and
everything
that
you
say
here
is
governed
by
the
note.
Well,
some
logistics
for
this
meeting.
We
have
a
note-taker
at
the
quarry
and
more
or
less
as
usual.
So
thanks
a
lot
to
Corey
for
his
volunteer
for
volunteering.
For
that
we
I
will
look
myself
at
Shepherd.
B
If
somebody
else
could
look
at
Shepherd,
that
would
also
help,
but
ladies
I
will
take
care
of
it.
If
nobody
else
does
it
whenever
you
go
to
the
mic
as
a
please
say
your,
let
me
say
your
name
and
it
also,
it
might
be
useful
if
you
check
afterwards
in
the
easier,
is
a
pet.
If
we
correctly
spelled
your
name,
if
not
please
correct
it.
So
that's
the
easiest
way
to
fix
the
minutes,
and
in
general,
whenever
you
submit
an
internet
traffic
that
is
somehow
related
to
what
is
working.
B
Who
does
that
is
more
or
less
TCP?
Then?
Please
use
the
TCP
mm
in
your
traffic
name,
so
next
slide.
So
this
time
our
agenda
is
not
fully
packed.
So
we
have
time
for
heated
discussions.
This
week
we
will
start
as
usual,
with
the
working
groups,
teachers
and
then
we
have
three
working
group
items
on
the
agenda.
We
go
and
discuss
the
alternative.
Take
off.
We
will
discuss
the
acquisition
and,
last
but
not
least,
we've
all
discussed
the
generalized
ecn
draft
and
then
we
received
requests
for
two
individual
presentations.
B
The
first
one
is
located
latency
option,
so
this
is
presented
for
the
first
time
in
TCP
M,
and
then
we
decided
to
have
another
presentation
on
the
24
140
days
and
so
and
as
the
agenda
is
not
really
full,
we
really
have
some
time
for
discussion.
This
meeting
stall
I
mean
we
will
probably
have
to
extend
some
of
the
slots
a
little
bit
bigger
see.
B
The
request
is
a
little
bit
short
on,
but
still
I
asked
the
the
some
of
the
presenters
to
be
quick,
even
if
this
is
not
quick
on
the
status
of
the
documents,
so
we
don't
have
any
RFC,
but
we
are
working
on
getting
here.
So
the
data
center
TCP
draft
is
at
the
moment
in
in
the
final
phase
of
addressing
the
iesg
comments.
So
I
think
there
was
an
update
this
morning
and
we
are
getting
close,
I
think
to
adding
all
comments.
So
this
one
should
be.
B
You
should
get
into
the
IRC
edited
queue
relatively
soon.
We
had
a
working
group
last
call
on
topic
and
ye.
There
was
an
update,
I
think
last
week.
So
at
the
moment,
Yoshi
for
me
is
working
on
that.
So
the
document
shepherd
run
on
topic
is
usually
for
me
and
we
will
come
back
with
the
next
steps.
Once
we've
analyzed
the
the
new
update,
then,
as
usual,
our
quick
overview
of
the
active
working
group
documents,
so
the
three
ones
that
are
shown
on
this
slide
here
are
all
discussed
in
in
this
session.
B
So
I
will
not
comment
too
much
on
the
alternative.
Peg
of
the
accuracy
and
a
generalized
ecn,
one,
the
cubic
one
as
I
have
mentioned-
has
passed
the
working
group
last
call
and
we
currently
look
into
the
new
version
other
than
that
we
have
a
couple
of
working
group
items
which
are
not
presented
here
on
the
right.
One
I
think
there's
ongoing
experimentation
as
we've
not
received
any
update
on
that
one,
but
it
was
discussed
quite
a
bit
in
the
last
meetings
on
the
793.
B
This
vest
is
currently
working
on
an
update,
so
he
actually
told
us
that
will
probably
be
an
update
this
week.
Unfortunately,
bass
is
not
here,
so
so
he
can't
resend
it
and
but
there,
but
there
should
be
an
update
this
week
on
our
geo
to
consider.
There
is
no
news
after
the
last
meeting
and
the
same
also
applies
on
an
idio,
so
I
think
Joe
is
not
in
office
this
week.
So
that's
why
he
can't
comment
himself
on
on
video
and
that's
actually
the
state
rish.
So
are
there
any
comments?
B
C
E
D
D
Gonna
be
fine,
so
the
alternative
back
of
it
is,
you
know,
as
we
call
it
eight,
so
we
have
submitted
the
version
zero
one.
So
basically
the
changes
that
in
zero
one
compared
to
the
version
zero,
is
that
that
we
improve
the
text.
We
have
lots
of
comments
from
Stuart
Cheshire
and
we
incorporated
all
of
those
comments
into
the
document
and
also
we
basically
did
some
minor
changes,
including
changes
changed
to
the
reference
that
we
made
to
the
technical
report.
That
shows
our
results
now
it's
published.
D
D
We
also
make
provided
clarification
on
the
intent
intended
purpose
of
the
experiments
or
what
we
mean
by
the
experiment
in
this
draft.
Since
this
graph
is
a
right
now
and
in
the
experimental
status,
basically
all
the
changes.
There
were
basically
the
wards
meeting
an
inch
and
clarifications.
There
were
no
major
changes,
so
almost
no
changes
to
the
technical
contents
of
their
slides
that
the
draft,
then,
when
it
comes
to
implementation,
we
had
some
early
freebsd
implementation
of
it,
which
is
a
patch
available
online.
D
This
patch
was
brought
up
by
Tom
Jones
from
the
University
of
Aberdeen
and
last
week,
and
we
have
submitted
this
for
the
free
beastie
upstream
and
waiting
for
the
results.
Also,
we've
got
patches
available
for
Linux
when
we
are
planning
in
the
future
to
submit
it
to
the
to
the
Linux.
So
next
what
we
are
trying
to
do,
because
this
draft
initially
was
focusing
on
TCP
and
then
we
decided
that
we
basically
generalize
it
to
the
congestion
control
mechanisms
that
are
window
based.
D
There
was
a
discussion
right
now,
as
the
Dreyfuss
stands
is
that
it
promises
that
it
would
do
an
sctp,
basically
condition
control
based
on
Abe
using
the
ACN.
But
what
we
are
suggesting
here
is
that
we
do.
We
won't
add
the
CTP
ape
support
to
the
draft
that
we
have.
Rather,
we
provide
the
general
guidance
to
say
that,
basically,
we
recommend
that
the
tape
will
be
the
part
of
the
design
of
any
transfer
protocol
that
implements
the
window
based
reduction
to
ACN,
mark
congestion.
D
So,
basically,
that's
the
general
statement
that
would
be
written
in
this
draft
instead
of
going
to
specifically
SCTP
related
stuff
and
how
something
happened.
So
then,
since
the
city,
a
city
piece,
a
congestion
control,
spec
is
not
defined.
Yet
we
leave
the
detailing
of
the
how
to
react
to
easy,
enter
to
any
future
draft
that
basically
defines
that
congestion
response
in
a
CTP
and
just
stay
kind
of
generic
in
this
draft
about
it.
D
F
F
The
other
comment
is
that,
in
the
description
of
what
you
are
doing
is
you're
assigning
flight
size
to
flat
ties
n
plus
on
equal
is
flight
size
times.
The
factor
and
I
think
you
can't
Wi-Fi
flight
size,
since
this
is
just
the
number
of
bytes
which
are
outstanding
and
not
Q
max,
so
you
can't
change
this
variable.
You
can
observe
it
and
use
it,
but
not
change
it.
I.
F
D
D
F
D
F
B
Okay,
so,
as
it's
I
think
it's
clear
that
an
update
of
the
document
is
needed,
but
still
for
our
educational
purpose,
could
we
have
a
show
of
hands?
How
many
have
read
this
document
recently,
because
we
definitely
look
forward
to
on
web
use
of
this
document.
So
and
can
you
give
me
a
show
of
hands
how
many
have
read
this
document
so
I
see
off.
B
F
H
I
The
black
editor
of
the
TSV
WG
e
to
experimentation
draft
that
dress
basic
basically
through
its
completed
working
group
last
call
we've,
as
will
be
discussed
tomorrow.
We've
figured
out
what
to
do
in
that
draft
about
the
one
remaining
open
issue
of
and
talk
about
here,
so
that
draft
is
basically
through
th.
Vwg
should
be
going
to
IETF
last
column
in
the
near
future.
B
J
J
Right
so
conditioned
notification.
Just
for
those
of
you
don't
know,
there's
a
table
on
it
there.
The
problem
was
that
when
ACM
was
added
to
IP
and
TCP,
both
in
the
same
document,
it
it
only
allowed
one
TCP
feedback
per
round-trip
time
of
an
ACN
mark.
So
if
there
were
many,
it
only
allowed
one
and
some
experience
since
then
has
shown
that,
with
that
more
information,
you
can
do
a
lot
better,
particularly
on
latency,
but
at
the
time
we
only
had
a
TCP
that
reacted
once
so.
J
J
To
change
the
ecn
feedback
and
instead
of
using
them
as
Flags,
use
the
three
bits
which
you're
only
used
when,
when
you're
doing
capability
negotiation
of
the
handshake,
but
once
the
handshakes
finished
use
it
as
a
three
bit
counter
field
and
just
repeat
a
counter
in
there
and
every
time
the
count.
The
counter
of
the
number
of
marks
you've
seen
increments,
then,
eventually,
the
the
sender
will
realize
that
it's
updated,
even
if
there's
been
some
drops
of
X,
because
the
problem
is
that
you've
got
no
reliable
delivery
of
peer
acts
in
TCP.
J
Obviously,
a
3-bit
field
is,
is
a
bit
limited,
but
that's
all
you
can
get
through
middle
boxes,
we've
discovered
from
measurements,
so
there
is
a
option
as
well.
That
gives
you
the
information
in
by
it's,
not
packets,
and
you
know
that
that
will
supplement
the
this
revolving
counter
in
in
the
ice
field.
K
J
First
thing
is:
the
accuracy
n
has
to
be
agreed
by
both
ends
because
it's
changed
the
wire
protocol,
all
right.
So
what
I've
done?
I've
split
that
in
the
diagram,
I'll
split,
the
layers
between
the
wire
protocol
in
in
the
transport
layer
and
the
congestion,
control
and
accuracy
n
is
essentially
the
extension
to
the
feedback
wire
protocol.
So
it
does
all
the
things
the
previous
ones
did
as
well.
J
He
mentioned
that
he's
interested
in
in
when
he
adds
ec
n
to
be
BR,
to
jump
straight,
to
accurate,
easy
and
and
not
not
go
through
the
old
feedback
mechanism
so
and
and
yes
for
DC
TCP
Acura
ecn
also
gives
you
benefits
that
we
talked
about
years
ago,
and
we
don't
need
to
go
through
again
right.
So
that's
where
it
all
fits
I
did
this
because
one
or
two
people
putting
Stuart
we're
saying.
J
Can
you
give
me
a
road
map
of
where
all
these
bits
of
ecn
fit
and
as
I
say,
it's
not
clear
that
this
helps,
but
it
might
do
I,
guess
what
it
does.
Do
the
next
talk
I'm
giving
is
about
a
draft.
That's
got
the
file
name
generalized
ecn,
but
we've
now
decided
to
call
it
a
TN
plus
plus,
and
that
also
fits
in
this.
J
It's
a
change
to
the
sender
depending
on
what
things
it's
set
in
the
IP
ecn
field.
But
it's
only
applies
in
the
TTP
context
it.
These
are
all
basically
updates
to
the
TCP
way
of
doing
ACN,
which
was
a
sort
of
missed
out
on
the
experience
that
all
the
other
protocols
got
from
it
and
they
did
it
right,
whereas
TCP
has
sort
of
got
behind
because
it
it
had
all
these
problems
with
it.
So
there's
all
these
bits
need
to
be
added
to
it
to
make
it
work
or
make
it
work.
Well,
alright!
J
And
so
there
can
be
some
really
dangerous
situations.
For
instance,
your
home
router
has
a
3g
or
4g
dongle
in
it,
or
you
know,
and
so
your
you've
got
say,
fq
cuddle
in
that
that's
easy,
n
marking
packets
and
then
that
those
ECM
marks
get
wiped
and
so
both
ends
think
they're,
talking
easy
n.
But
this
this
thing
essentially
just
pushes
the
cue
right
right
through
to
tail
drop
until
it
does
anything.
J
So
you
get
this
sort
of
oscillation
between
ignoring
ECC
N
and
then
tail
drop
going
on
so
inaccurate
ec
n
the
feedback
on
the
sin
and
sin
AK.
We
are
proposing
to
replace
what
was
just
feedback
of
whether
it
was
CEO
or
not
with
feedback
of
exactly
which
ECT
there
was
there
as
well.
So
he
David
to
your
honor
hang.
I
J
I
J
So
we're
proposing
that
we
have
four
possible
states
on
the
feedback
of
the
scene
and
the
syn/ack,
so
we
can
both
ends,
know
what
he's
getting
through
and
what
isn't
getting
through,
based
on
the
two-bit
field
in
the
IP
header,
all
right
and
with
we've
got
just
that
many
spare
states
in
those
three
flags
given
to
all
the
previous
uses,
they've
had
for
negotiation
and
all
the
broken
implementations
there
are
and
all
the
rest
of
it.
So
we've
just
got
enough
space
to
do
this
right
and
we've
had
a
bit
of
discussion
on
that.
J
J
He
was
you
know
what
so
no
can
he
just
do
the
icefield
part
of
it,
the
essential
part
of
it
and
not
the
optional
part,
and
the
spec
actually
allows
him
to
do
that,
but
it's
sort
of
please
don't
you
know
that
wasn't
the
intention,
in
other
words
the
spec
says
you
must
not
put
the
option
on
this
sin
because
it's
not
necessary
because
the
the
flags
implicitly
say
you're
going
to
support
the
option.
Okay,
thanks
David
David,
just
said
I'm
right
by
the
way
for
the
record.
J
Then
the
on
the
on
the
three-way
handshake,
there's
assured
and
assured
for
the
option
and
on
the
first
day,
two
packet,
those
assured,
because
the
act
before
it
isn't
delivered
reliably.
So
this
is
just
a
test
where
the
options
getting
through
all
right
and
then
after
that,
once
established
it's
all.
You
only
need
to
put
it
on
it's
change
triggered
and
even
then
it's
optional
Cossack
takes
precedence
because
drops
more
important
than
ecn
right.
So
the
upshot
of
all
that
is,
there's
no
musts
there.
J
There's
only
should
optionals
and
must
not,
which
means
essentially
for
being,
would
not
have
to
put
this
option
on.
However,
it
does
say
that
you
must
implement
it
and
you
must
try
to
use
it,
because
the
idea
is
that
it's
useful
and
this
isn't
meant
to
be
a
get
out
for
an
implementer
just
to
do
less
work.
J
M
Maybe
just
one
more
point
say
original:
we
saw
it
also.
You
can
use
this,
for
example,
for
data
centers,
where
you
might
know
what
your
setup
is,
and
you
might
know
that
you
don't
need
the
option,
but,
for
example,
if
you
specify
some
kind
of
mechanism
that
wants
to
use
the
accurate
information
and
really
really
needs
the
option,
you
can
specify
in
that
document
that
it
should
activate
the
option.
Yeah.
J
Yeah
and
that
example,
you
gave
in
a
data
center,
if
you
think
I,
don't
need
this
option.
You
may
well
find
that
if
you
get
long
strings
of
loss
due
to
in
caste,
then
your
counters
do
get
out
of
sync,
and
you
do
need
this
option
and
supplementary
information
to
deal
with
rack
of
that
three
bit
field
yeah,
because
the
three
bit
field
isn't
isn't
much
to
get
wrap
on,
especially
in
with
large
windows.
J
We
need
to
use
the
flag
to
the
left,
their
mark
ie,
that's
currently
the
nantes
flag
for
this
negotiation
that
you
just
saw,
and
also
for
this
three
bit
counting
field
and
the
nonce
as
we've
just
been
explaining,
David's,
easy
and
experimentation
draft,
as
well
as
enabling
Abe
and
enabling
the
next
talk
also
makes
the
easier
Nantes
historic
and
what
we've
agreed
to
do.
This
too
I
on
a
process
is
needed.
J
J
The
registry
policy
requires
and
proposed
standard
RFC
to
change
it
and
then
the
accurate
Sen
draft,
where
in
thinking
it's
likely
to
be
experimental,
but
we
are
going
to
assign
that
flag
from
a
registry,
but
the
policy
saying
it
has
to
be
a
proposed
standard
RFC,
but
we're
going
to
or
mayor
is
going
to
raise
an
exception
or
Spencer
is
going
to
raise
an
exception
and
say
there's
a
good
reason
for
this.
It
used
to
have
an
experimental
IC
on
it,
we're
not
going
to
try
another
experiment
on
it.
J
E
J
Yeah
I
think
that's
about
it,
so
the
status
is
it's
implemented
in
Linux
Mayer's
implementation,
the
URL
is
there,
we've
been
waiting
for
this
flag
to
become
available
officially
before
it
can
go
any
further.
We
were
also
waiting
for
ECM
plus
plus
to
be
adopted,
which
is
my
next
tour.
Actually
Marcello's.
J
Next
talk
we're
co-authors,
because
there's
some
things
that
accurate,
easy
and
allows
ECM
plus
plus
to
do
better,
but
you
couldn't
really
refer
to
it
when
it
wasn't
even
adopted
and
then
finally,
we've
got
a
few
pizzas
I
want
to
open
up
for
discussion
in
appendices
at
the
moment
in
the
draft.
The
first
one
is
what
I've
just
been
talking
about:
feeding
back
for
code
points
on
the
cinemas
in
AK.
Oh
sorry,
on
the
sin
focus
the
fall
code
points
were
that
were
on
the
scene.
J
Feed
them
back
in
the
syn
ACK
and
opens
is
an
alternative.
B
is
about
feeding
back
or
for
EC
anchor
points
that
were
on
the
syn
ACK
in
the
first
act
yeah.
So
you
know
the
sin
goes
that
way
you
have
to
feed
back.
What
was
in
the
IP
header
back
in
the
TCP
header
and
the
sim
on
this,
the
IP
header
in
the
syn
ACK?
You
have
to
feed
back
in
the
TCP
header
what
it
was
decently,
so
you
go
up
one
layer
at
each
of
each
way
of
the
handshake.
J
J
J
If
there's
any
discussion
needed
on
that
or
if
anyone's
read
the
draft
and
doesn't
like
that,
we'd
certainly
like
people
to
look
at
that
some
TCP
expertise
to
look
at
that
to
check
that
we
haven't
forgot
any
cases
you
know,
I
don't
know,
simultaneous
opens
and
things
like
that.
We
have
thought
about
all
that,
but
maybe
not
in
all
all
the
possible
cases
right
now.
This
the
sorry,
the
open
issues
I
wanted
to
ask
people
about
particularly
the
day
and
the
people
here.
At
the
moment
we
have.
J
We
have
had
a
little
discussion
on
this
before
at
the
moment.
We
we
only
send
the
Acura
ACN
option
on
when
a
different
ECM
code
point
changes.
So
if
the
counter
is
continually
updating
you're
getting
lots
of
ECT
nor
you
don't
have
to
send
an
accurate
ACN
option
unless
all
right
you
got
to
seee.
So
it's
like
when
something
happens,
you
have
to
send
a
macro
ACN
option,
that's
what
we
call
change
triggered
now.
N
N
Sure,
but
it
knows
well,
its
own
time
resolution
is
yeah
see.
The
thing
is
producing
that
many
acts
is
going
to
cause
problems
further
for
both
stacks
in
a
very
short
RTD,
come
in
with
an
environment
just
because
you're,
constructing
more
packets
and
you've
got
to
go
around
that
loop,
so
many
more
times,
yeah,
okay
and
also
the
switches
themselves,
the
average
size
of
a
packet
in
the
network
matters
and
access
small.
So
you
pushing
it
downward
and.
N
J
Like
okay,
so
maybe
we
could
put
some
put
together
some
sort
of
I'm
more
concerned
that
we
put
together
something
so
that
the
thing
that's
receiving
this
feedback
can
know
for
sure
when
it
can
rely
on
the
timing
information
of
the
acts.
Yes,
so
it
needs
to
be
something
deterministic
it
not
just
sort
of.
If
the
round
returns
a
bit
bigger,
you
know
yeah.
J
Argued
for
an
extra
bit
to
say
whether
you're
doing
this
or
not
that
we
haven't
really.
You
know
that's
just
awkward
and
really
got
a
bit.
Yeah
I
understand
yeah.
We
have.
We
have
done
option
actually
what
one
one
possibility
is
we
did
consider
the
possibility
of
than
the
initial
number
you
put
in
the
option
to
start
the
counter
we
can.
We
can
put
different
numbers
in
depending
on
what
your
mode
is.
If
you
like,
we
could
do
that.
Maybe
a
mere.
M
Michael
Ivins
I'm,
not
convinced
that
would
really
need
it,
because
if
you
put
a
shirt
and
in
most
of
them
but
I
should
do
it,
then
you
can
just
make
a
stronger
assumption
that
it's
done
that
way
and
also
you
can
probably
detect
that
it's
not
done
that
way.
If
you
just
you,
know,
see
every
second
peg
attacked
and
nothing
changes
ever
and
charming
information
anyway,
that
has
Issei
it's
it's
anyway,.
M
J
N
J
B
I
mean
before
we
go
there:
okay
from
the
to
the
fun
part,
was
the
one
comment,
I'm
speaking
and
I,
called
speaking
from
the
individual
Mike
I
read
some
statements
in
the
document
on
the
TCP
M
consensus,
and
my
recommendation
to
the
authors
is
to
review
that,
because
there
are
some
statements
on
the
success
criteria
of
that
experiment,
which
I
find
a
bit
surprising.
So
to
me,
an
extra
Herman
can.
B
What
I
was
like
I
remember,
the
diverting
is
the
success
criteria,
for
the
experiment
is
that
the
TCP
M
working
group
team
is
the
protocol
stable
or
something
like
that,
and,
let's
be
clear.
The
success
criteria
for
everything
that
we
do
here
is
getting
things
deployed
in
the
intranet
getting
it
running.
It's
not
the
working
group
thinking
about
I,
don't
know.
Okay,.
J
B
F
Can
say
there?
So
if
there's
no
other
comments,
then
we
move
do
that.
So
that's
a
procedural
thing
and
in
an
earlier
version
of
Bob
slides
there
were
some
alternatives
listed.
So
we
had
a
discussion
with
the
working
group
chairs
of
TSW
G
and
the
80s
about
how
to
deal
with
this
reassignment.
So
it
was
agreed
that
in
TS
bwg
arm
the
unassign
'men
of
the
NS
bit
is
triggered.
So
that's
that's
agreed,
and
so
the
open
crash
I
mean
not
the
open
question.
F
What
had
to
be
discussed
was
the
reassignment
and
there
were
a
couple
of
options.
The
first
option
is
that
it
is
signed
within
the
tea
CPM
working
group
by
the
accurate
ecn
document.
There
are
three
variants
of
that.
The
first
one
is
the
document
itself.
It's
heading
for
experimental
status
and
the
registry
for
these
bids
requires
a
standard
strike
document.
So
that's
why
an
ad
has
to
it
has
to
be
involved
to
to
say
this
is
okay
and
it
was
indicated
that
that's
a
possibility.
F
The
other
one
is
that
the
document
is
not
going
for
experimental,
but
for
proposed
an
it.
So
then
we
don't
have
that
problem.
The
third
one
is
that
the
registry
for
that
registration,
the
procedure
for
that
registry,
the
registration
procedure
is
changed.
So
currently
it
requires
a
standard
strike
document.
So
you
can
change
that
to
something
that
requires
only
in
RFC
or
something
like
that.
However,
the
registry
covers
six
bits,
so
you
would
change
it
for
not
only
for
the
three
which
are
now
currently
assigned,
but
also
for
the
three
being
unassigned.
F
So
this
is
also
a
drawback,
and
another
very
end
of
the
third
option
is
to
have
to
change
the
policy
only
for
the
NS
bit,
but
that
would
mean
you
have
to
add
a
registry
for
one
bit,
so
it's
also
getting
very
lacking.
Another
possibility
is
that
it
is
assigned
in
a
TS
w
TS
vwg
document
with
or
without
it.
So
in
two
variants.
F
However,
they,
the
chairs
of
that
working
group,
indicated
strong
that
they
don't
want
to
do
it
in
that
working
group,
and
I
mean
we're
just
checking
if
there
are
any
other
possibilities,
so
one
generic
possibility
would
be
to
to
have
a
standard
document
assigning
assigning
this
document,
assigning
the
spit
and
then
are
saying
whenever
and
experiment
wants
to
use
it.
It
has
to
negotiate
by
itself
that
it's
being
used,
and
then
it
can
use
this
bit
for
whatever
experiment
it
wants
to
use.
F
P
J
F
K
M
A
cool
even
say:
there's
actually
one
more
option:
one
is
we
don't
assign
it
right
now
you
could
open
until
the
extra
mind
is
closed
and
then
it
sign
it
as
soon
as
we
have
a
proposed
standard,
but
I
think.
The
reason
why
we
have
the
registry
is
because
we
want
to
use
this
as
a
mechanism
to
make
people
aware
that
this
experiment
is
happening.
So
I
think
the
outcome
should
be
that
the
RFC
number
for
the
experiment
should
be
mentioned
in
the
registry.
K
F
H
Hi
gory
fur
has
had
trouble,
gig
item
right
place
for
our
sitting
in
Barton.
I
got
here
somewhere
already
said
it
all,
but
one
a
was
what
we.
What
we
suggested
I
could
ask
another
question
while
we're
on
silly
questions.
Oh-
and
it
was
from
a
conversation
with
the
man
behind
me
but
and
the
NS
field
appears
in
textbooks
and
on
some
people's
web
pages
like
mine,
it
might
be
nice
to
keep
it
called
an
S
and
rename
it
because
that
diagram
is
exceedingly
well
distributed.
B
So
I
just
want
a
backward
or
reset
so
I
mean
the
TCP.
Header
is
well
documented
in
many
documents
outside
the
IHF,
and
while
it's
clear
that
we
want
to
have
this
experiment
here,
it's
still
an
experiment
and
I'm
a
little
bit
concerned
about
out
dating
every
single
text
book
that
is
written
on
TCP
by
an
experiment
and,
as
I
said,
there
might
be
ways
to
deal
with
this
and
one
way
might
be
to
use
another
name
for
that
date
or
somewhere
else,
but
I'm
a
bit
a
little
bit
concerned
not
about
the
experiment.
B
F
Michael
jackson,
from
the
floor,
sir
personally
I
think
it's
it's
better
to
make
clear
that
the
document
that
the
diagram
is
outdated
because
you
see
it
so
you
name
the
flag
differently,
but
compared
to
stick
with
the
acronym
that
the
semantics
has
changed
completely.
So
people
think
it
hasn't
changed,
but
it
did
change
so
break
it
as
soon
as
possible.
J
M
K
I
P
Like
it
so
I
to
me,
the
most
important
thing
is
the
first
bullet
or
at
the
assignment
I,
don't
actually
care
about
any
of
the
rest
right,
because,
in
the
good
old
tradition
of
squatting
on
code
points
your
fire
by
the
time
you
get
so
successful
that
we
will
need
to
deal
with
this,
we
will
deal
with
it.
So
it
seems
like
we're
doing
a
lot
of
thinking
here.
We
leave
it.
Unassigned
use
it
for
the
experiment,
and
you
know
if
it's
successful,
we
will
we'll
know
what
we
need
to
do
right.
F
M
So
I
don't
think
that's
the
worst
option.
We
discussed
that
and
we
sought.
If
we
have
a
registry,
it
should
also
reflect
what
the
current
state
is.
That's
why
we
were
rather
in
favor
for
signing
it,
but
that
leads
to
another
option.
We
could
also
remove
the
hope
registry,
so
I
think
say
between
the
small
group
we
had
yesterday.
We
we
kind
of
agreed
to
go
for
option
A
or
C.
Where
a
is
the
default.
We
can
do
right
now
and
see
something
the
working
group
could
decide
on.
P
B
So
this
is
Michael.
That's
individual
contributor,
I've
seen
a
lot
of
vendors
squatting
on
court
points,
no
matter
what
the
honest
at
Saudi,
whether
we
reach
a
registry
of
this
Yana
or
not,
that
doesn't
matter
to
those
implementers,
that's
quote-unquote
points.
Of
course.
We
can
agree
that
it's
this
the
right
thing
to
do,
but
it
will
the
thinking
of
bad
implementers
is
a
non
concern.
At
that
conversation,
my
opinion
yeah
I.
J
Just
can
I
say
what
I
what
the
problem
is
with
I
just
in
the
it
essentially
is
a
circular
dependency
with
the.
If
the
I
see
don't
agree
it
because
we're
assuming
they
will
agree
this
process
exception.
If
they
don't,
then,
with.
There
are
two
experiments
in
the
ECA,
an
experimental
patient
draft
that
depend
on
echo
ACN
and
that
will
have
gone
through
and
and
then
the
ice.
You
throw
this
back
and
say:
well,
you
can't
have
accurately
CN
yet
or
whatever
David.
J
J
M
J
J
J
B
P
B
As
a
we
are-
or
we
are
only
talking
about
the
second
step
here
as
a
better
B,
we
are
W
we
assign
on
this
bit
for
the
acquisition
experiment
and,
as
I
said,
my
proposal
is
to
hum
on
that
this
two
options,
as
the
first
option,
is
that
we
figure
out
the
process
to
assign
it
again
to
the
aggregation.
The
second
option
is
probably
what
lost
a
proposed
that
we
keep
it
on
our
side.
For
the
moment,
logic.
P
B
L
B
J
B
Q
Q
What
we're
doing
in
this
draft
in
this
document
is
to
enable
the
marking
of
oil
control
packet
and
also
retransmission,
whenever
the
marking
ECT
marking
of
all
control,
packets
and
retransmission.
So
what
we
do
in
the
draft
is
with
the
two
things
we
specify
how
this
gets
done
and
we
go
through
all
the
arguments
that
represent
an
Ori
originally
in
3168,
and
we
try
to
deal
with
them.
Okay,
so
we
have
several
revisions
of
this
draft.
Q
We
have
a
several
very
total
reviews
from
media,
from
david
black
from
gory
and
from
Padma,
and
thank
you
very
much
for
these
reviews.
Actually,
they
were
very
helpful
and
very
in
detail.
Actually
they
they
provided
a
very
good
excuse
for
Mike
offer
to
completely
rewrite
the
draft.
So
now
we
have,
this
is
new
version,
and
it
was
recently
adopted
us
as
a
working
group
item.
So
I
will
this
next
I
will
I
will
describe
what
more?
What
is
in
the
current
situation
is
so
why
are
we
doing
this?
Q
Well,
actually,
not
enabling
marking
off
of
this
of
all
the
TCP
control
packets
results
in
performance
penalties,
but
this
has
been
reported
in
different
scenario,
especially
when
you
have
a
high
amount
of
marking.
Then
these
control
packets
tend
to
tend
to
get
lost,
I
mean
deploy
getting
low,
inter
of
dropping
them.
Is
it's
much
higher
because
the
other
packets
are
getting
much
and
that
actually
results
in
performance
tendency.
Q
So
actually
you
see
that
that
actually
getting
the
scene
loss
actually
perform
a
harms
performance,
II
severely
right
so
way
to
go,
would
try
to
is
okay,
so
we
mark
these
packets,
so
they
they
are
likely
to
get
marked
before
getting
loss.
Hence
the
performance
will
will
will
improve.
Next
slide,
please.
Q
Q
We
really
don't
don't
know
which
is
the,
which
is
the
sender
when
we
start
with
the
connection
right
and
what
we
are
defining,
that
what
we're
currently
defining
the
draft
is
that
you
can
set
the
ECT
marking
in
all
packets
in
all
control
packets
and
we
transmissions
for
when
you
know
that
the
I
mean
when
you
try
it
the
accurate
vision
protocol.
Basically,
when
you
try
the
accuracy
and
sim
and
after
the
the
accurate
decision
has
been
negotiated
and
when
you're
not
sending
accurate
DC
and
when
you're
sending
3168
sim
in
order
to
to
negotiation.
Q
At
that
point,
you
should
not
mark
the
ECT,
but
you
can
actually
use
a
mark
all
the
rest
of
the
packets.
The
reason
for
wrap
is
because
accurate
ecn
already
incorporates
the
means
to
feed
back
the
the
echo
if
congestion
has
occurred
in
the
sim,
but
it's
very
hard
to
accommodate
that
if
you
have
3168
receiver
on
the
other
end,
all
right.
So,
for
this
reason,
we're
only
proposing
to
support
DCT
marking
of
the
scenes
when
you're
trying
to
negotiate
equation.
Q
Okay,
so
that's
that's
the
current
state
thanks
next,
so
now
I'm
going
to
go
through
each
of
the
different
types
of
packets
and
explain
you
what
situation
is
what
is
approach
the
GUI,
what
we
were
proposing
so
in
in
when
we're
sending
in
the
scene?
The
problem
is
that
we
don't
know
if
the
other
end
actually
supports
acquisition,
in
particular,
if
it
supports
ecn
plus
plus
the
soup,
the
marking
of
the
of
the
packet,
the
ECT
marking
of
the
scene
packet.
Q
So
if
it
support
is
actually
the
same
is
great
because
you
you
get
the
the
the
see
echo
back
right
in
case
it
was
marked.
The
problem
is:
what
happens
if,
when
you
send
the
scene,
you
get
a
reply
that
it
doesn't
support
acquisition.
So
it
may
happen
that
the
scene
got
CE
marked
or
it
didn't
right.
So
what
do
you
do
at
that
point?
So
what
we?
What
we're
proposing
to
do
is,
in
that
case,
we
conservatively
reduce
the
initial
window
to
one
where
we
assume
that
it
was
marked
okay,.
Q
Q
This
actually
puts
you
in
the
position
that,
if
you
try
to
use
this,
if
there
is
a
large
number
of
servers
that
does
support
this,
you
get
you
you
get
worse
performance
because
you
get
the
penalty
of
reducing
the
initial
window,
even
though
it
did
it
was
in
a
mark
which
is
the
most
likely
scenario
right,
and
so
there
are
two
arguments
why
we
still
think
that's
the
right
thing
to
do.
The
first
is
because
a
you
cache,
so
you
only
you
only
suffer
this
once
and
the
second
is
actually
a
feedback
varietal
by
YouTube.
Q
That
is
that
usually
the
client
actually
doesn't
really
need
a
big
window
in
the
initial.
What
who'd
really
need
to
will
be
window
is
the
server
right
so
to
send
a
get
with
one
packet
you're
good
enough.
Alright,
so
it's
not
that
you
will.
You
will
hurt
your
performance
in
large
number
of
cases
severely.
So
that's
why
we
are
proposing
this
okay,
next,
okay.
So,
as
I
said
before,
the
ECT
marking
in
seeing
acts
was
already
defined
in
ec
n
plus
in
the
fifty
five
sixty
two.
Q
However,
what
it's
in
there
it's
really
weird,
actually
so,
actually
the
behavior
described
in
there,
it's
actually
some
attempt
to
completely
mimic
what
will
happen
if
the
packet
get
lost
right.
So
basically,
if,
if
you
get
this,
if
you
get
a
see
mark
in
the
Cenac,
what
5560
to
set
that
you
should
do
is
you
should
reduce
the
initial
window,
but
also
you
should
resend
once
a
second
scenic
without
the
ICT
market
right.
So
not.
Actually,
we
find
that
that
this
is
very
weird
and
sorry,
it's
a
five
way
handshake,
yes
right!
Q
So
actually
we
we
don't
think
that's
the
way
to
go.
Actually
we
think
it's
probably
by
simply
reviewing
the
initial
window.
You
should
be
fine
right,
I
mean
you
got
the
scene.
Are
the
Rosa?
The
awesome
there
was
a
mark
on
the
scenic,
just
react
to
congestion
and
go
on
with
it.
Actually
we
did
some
measurements.
We
drive
the
500k
top
Alexa
servers.
There
are
a
few
of
them
that
actually
supports
in
AK,
AC
marking
I
mean
ECT
marking
in
the
scenic.
None
of
them
actually
does
what
55
60
to
the
specifies?
Q
Okay,
so
that
doesn't
listen
I
mean
as
far
as
we
can
tell
nobody's
doing
that
right.
So
what
we're
suggesting
is
to
actually
update
55
62
if
needed,
I,
don't
that's
procedural
I
think
that
needs
to
be
discussed
whether
this
document
should
update
55
62,
but
actually
what
we're
suggesting
is
that
the
support
for
the
ECT
marking
on
the
scene
at
should
be
this
right,
simply
reduce
the
congestion
window,
and
that's
it
next.
Q
So
this
is
a
comment
from
media,
so
the
question
is
whether
we
should
enable
ECT
marking
of
pure
acts,
given
that
there
may
be
some
unresponsive,
a
receiver,
so
that,
basically,
that
you
may
be
the
receiver
may
receive
the
burek
mark
with
C
and
doesn't
and
do
not
send
the
echo
back.
I
understood
that
was
that
was
your
argument.
M
Q
O
M
Q
Do
you
mean
if
it
was
the
last
ACK
yeah,
that's
gosh
sure
unless
performance?
Yes,
so
again,
if,
if
I
mean
the
thing
is
again
what
I
think
we
probably
need?
Actually,
that
I
think
I
have
this
data,
but
I
actually
didn't
process.
It
is
to
find
out
whether
whether
current
deployed
servers
do
actually
send
a
echo
back
from
from
Purex
marks
with
with
with
ECT
right,
so
that
that's
an
easy
test
to
do
right,
I
mean
you
know,
only
need
to
send
Pyrrhic
smart
would
see
and
see
what
what
you
get
back
right.
Q
Okay,
so
this
is
something
that
we
need
to.
We
need
to
figure
out
I'm
happy
to
try
to
provide
some
some
data
about
what
what
I'm,
what
I'm
able
to
find
about
this
and
and
based
on
that
we
can
figure
out
what
to
do.
Okay,
the
current
recommendation
is,
if
you
receive
I
mean
you
should
I
mean
that
you
should
mark
is
ECT
mark
the
pure
acts,
and
if,
if
you
receive
an
echo
of
a
CE
Marking
of
Iraq,
you
should
react
to
it.
Q
R
Does
the
reason
the
draft
was
informational,
the
Darcys
informational,
it's
actually,
as
it
turns
out
it's
it's
it's
fairly
complicated
to
get
this
right.
That's
what
we
discovered
in
looking
into
this,
and
it
was
just
a
lot
of
there's
like
I
I,
think
the
RFC
has
like
over
ten
corner
cases
about
things
that
you
need
to
be
careful
about
and
a
yeah.
It
turns
out
that
it's,
if
you
try
to
do
acknowledgement,
condition,
control,
you're,
you're,
very
close
to
shooting
yourself
in
the
foot
and
you're
likely
to
do
it
so.
R
Q
So
so
there
are
two
things
here
right:
one
is
whether
you
should
if,
if
Purex
is
a
useful
efficient,
mean
to
convey
congestion
signal,
I
think
they
are
at
their
packets.
If
you,
if
you're
getting
the
signal,
that's
fine,
the
question
is
the
other
question
is
how
do
you
react
to
this
congestion
even
either
only
with
data
packets,
reducing
the
congestion
window?
In
case
you
have
data
packets
to
send
in
that
direction
right
and
if
you
don't
whether
you
should
actually
try
to
do
something
along
the
lines
of
the
congestion
control
regarding
acts.
Q
R
R
Problem
is
that
when
you're
getting
so
yes,
the
way
I
see
it
right,
the
easy
and
marking
that's
happening
on
the
flow.
That's
only
sending
acts
is
getting
a
signal
on
bites
that
it's
not
counting
really.
So
it's
a
weird
signal
and
so
I'm
sending
you
acknowledgments
and
then
I
get
easy
and
marks
and
then
I
receive
that
signal
back.
What
exactly
is
that
signal
telling
me
that
my
rate
is
too
high?
Yes,
yes,.
Q
Q
C
M
J
C
J
J
R
The
problem
the
problem
here
is
that
we
mark
the
marks
you're
getting
is
actually
related
to
this.
The
other
side's
condition
window,
not
yours,
because
you're
simply
sending
acknowledgments
back
in
response
to
all
the
packets
you're
receiving
and
those
are
getting
marked.
You
look
at
those
marks
and
reduce
your
own
condition
window.
That's
em
silly,
because
those
acts
are
not
constrained
or.
R
Q
Q
S
J
Juice
pack
you're
congested
window.
If
you're
effectively
got
an
idle
connection,
or
at
least
an
idle
half
connection,
but
you're
getting
seeing
some
congestion,
then
you
reduce
back
faster.
So
if
you
do
start
sending
data
you're,
you're
correct,
you
know
you're
using
all
information
you're
getting
okay.
Q
Actually
funny
enough
I
think
that
you
could
actually
make
I
think
you
could
actually
use
this
information
to
keep
a
regional
track
of
your
of
instead
of
completely
starting
from
from
slots.
That
again,
you
see
what
I'm
trying
to
say
is
you
get
some
information?
You
can
actually
try
to
make
this
to
be
an
accurate
estimate
for
a
bit
longer
than
then.
R
R
More
state
based,
not
not
just
state,
but
you
would
have
to
track
at
the
receiver
roughly.
What
the
other
side's
condition
window
is
not
the
other
side's
conditional
you're
trying
how
many
acts
you
have
outstanding
in
a
in
a
round-trip.
That's
currently
something
that
you
don't
try.
But
yes,
yes,
yeah.
D
K
R
J
Q
C
C
R
Q
R
R
Q
Optimization
right,
if
you
only
send
in
pure
rock
for
the
last
ten
round
three
times
or
something,
then
you
don't
react
to
congestion.
But
at
that
point,
I
would
like
to
understand
a
bit
more
what
what
usually
do
with
the
congestion
window,
because
as
far
as
I
understand,
if
you
don't
send
data
at
some
point,
you
you
just
reduce
the
congestion.
No.
R
R
R
R
But
but
again
the
the
simple
thing
here
is
that
I'm
trying
to
tease
this
about
in
my
head-
and
perhaps
it's
just
my
confusion,
but
it
seems,
like
a
sender,
is
sending
packets
at
a
certain
rate
and
that
packet
rate,
it's
ax,
is
basically
directly
proportional
to
the
rate
at
which
I'm
receiving
packets.
Yes,.
Q
Q
R
R
R
Q
Q
That's
why
am
I
working
was,
if
you
have
a
send
data
for
I,
even
peeled,
that
needs
to
be
determined
right,
I
mean
so
maybe
we
can
include
that
particular
situation,
I'm.
Just
saying
that
that's
that's
a
proposal
I
mean
then
with
you.
How
much
for
how
long
you
haven't
sent
data
and
that's
a
but
first,
let's
agree
on
the
approach,
and
then
we
figure
out
how
to
tune
the
parameters.
Q
S
M
Vehicle
even
first
of
all,
on
Tanner
on
changing
the
congestion
window
say
the
problem
is
congestion.
Information
will
be
outdated
after
a
while,
like
in
both
directions.
If
you
increase
your
congestion
window
or
if
you
reduce
your
window
and
say
if
you
don't
send
any
data,
you
have
like
outdated
data
information
about
congestion,
you
don't
want
to
react
it,
but
I
think
that's
true
also
for
having
like
a
large
congestion
window
left
after
a
certain
idle
time.
M
It
just
doesn't
make
any
sense
anymore
because
because
it
doesn't
reflect
the
current
situation
on
the
link
say
maybe
this
can
you
can
be
used
to
reset
the
to
the
initial
window
quicker?
Then
we
do
it
right
now.
Reducing
it
below
the
initial
window
probably
doesn't
make
too
much
sense
and
then
my
second
point
was
because
he
said
we
should
not
not
react
to
it.
So,
first
of
all,
there
are
two
things
one.
Is
you
not
send
a
marking?
If
you
cannot
ever
get
feedback
because
then
you
cannot
react
to
it.
M
If
you
never
have
fun
back,
then
you
can
for
sure
not
react
to,
and
then,
if
you
get
the
feedback,
you
should
react
somehow
to
it,
but
it
also
doesn't
have
to
be
immediately.
You
can
also
say
I'm
reacting
overtime
at
some
point
if
I
have
a
certain
number
of
markings
or
whatever.
So
what
the
reaction
is.
This
very
can
be
very
different.
Okay,.
J
Right,
just
in
response
to
Jana
I,
just
wanna
put
a
scenario
say:
you're
using
HTTP
too,
and
you're
you're
doing
byte-range
gets
and
so
you're
getting
a
large
number
of
packets
each
time
you
do
one
and
then
you're
sending
a
little.
You
know
now
that
byte-range
get
and
you
know
you're
controlling
what
the
server's
doing
over
multiple
streams.
All
in
one
connection
and
then
by
your
logic.
If
one
of
those
byte-range
gets
gets
marked,
you
would
sort
of
residual
Seawind
less
than
if
a
large
packet
got
marked
at
you
know.
S
B
H
H
K
H
Q
H
The
second
thing
is,
we
did
all
this
quit
when
we
did
the
cwv
stuff
in.
Was
it
seven
six
six
one
and
we
got
some
conclusion
there.
It
seems
like
we're
reinventing
the
same
thing
here.
So
let's
just
think
what
happens
when
I'm
not
sending
data
the
cwv
work,
we
did
in
TCP
m76
61,
okay,
which
is
what
applies
when
you
don't
send
data
and
whether
that's
a
good
choice
or
a
bad
choice.
All
you
need
pacing,
etc.
So
I
was
just
saying:
well,
let's
take
that
one
into
consideration
when
we
think
about
what's
doing.
Q
Q
We
also
propose
to
mark
a
finn's
and
besides,
there
is
a
kind
of
trade
off
here
on
one
hand,
and
you,
if
you
mark
them,
you
protect
I
mean
you
cannot
react
to
this
right.
I
mean
there's
no
reaction.
If
you
get
a
mark
on
on
a
Fenian
our
reset
right,
there
is
no
more
data
to
send.
So
that's
it.
So
why
do
we
do
this
well
in
order
to
prevent
them
from
getting
more
drops
when
there
is
a
high
level?
Q
No
I
mean
there's
a
high
number
of
marks,
and
so
the
counter-argument
for
not
doing
is
is
is
that
if
you
mark
them,
if
you
enable
for
them
to
be
marked,
then
they
will
not,
there
is
likely
to.
There
is
less
likely
they
get
drop
if
you're,
they're
heavy
load
and
when
you
are
in
a
deal
in
a
Dios
attack
or
something
like
that,
the
the
the
the
attacker
can
actually
use
this
in
order
to
send
this.
Q
This
handful
packets,
with
with
less
chances
to
getting
dropped
but,
however,
so
the
first
thing
in
the
first
observation
is
attackers
will
send
them
marked
whatever
in
no
matter
what
right?
No
matter
what
our
RFC
says
or
what
our
specification
says,
so
we
cannot
do
much
about
them
and
on
their
hand,
if
we
allow
them
to
to
get
to
be
ECT
mark,
then
it
is
more
likely
that
in
normal
situations
they
will
actually
get
that.
N
Q
So
we
did,
we
did
a
few
experiments
to
get
some
data
about
this.
This
is
basically
an
experiment.
We're
trying
to
figure
out
if
using
ECT
marked
packets
for
launching
an
attack
is
more
efficient
than
sending
regular
packet
right,
given
that
switches
are
supposed
to
turn
off
ecn
treatment
when
there
is
a
high
loss.
Q
Alright,
so
next
slide
so
easy
what
I'm
not
going
to
go
through
this,
but
basically
what
you
see
here
is
different
situations
where
there
is
an
attack
that
it's
there
is
a
TCP
flow,
either
ecn
or
non-linearity,
incapable
that
it's
being
used
and
suddenly
attack
start
right.
So
the
ASEAN,
the
ASEAN
flow,
the
legitimate
flow
is
the
one
that
it's
in
black
or
in
red
right.
Q
So,
basically,
what
you
see
is
you
are
launching
the
attack
with
ECT
and
without
the
city,
and
basically,
what
we're
seeing
is
that
the
reaction
is
the
same.
There
is
a
slight
difference
because
at
some
point,
the
the
ACN
mechanism
in
the
the
ACN
mechanism
in
the
router
is
still
working,
but
suddenly
it
gets
deactivated.
Q
Actually,
it
gets
deactivated
in
these
red
lines
here
and
then
after
this
is
exactly
the
same,
so
we
actually,
we
don't
see
too
much
difference
if
you
are
using
ECT
mark
pockets
when
you're
launching
and
attacks
and
we're
using
just
regular
packets
right.
So
basically,
that's
that's
the
conclusion
next
life
and
then
we're
doing
a
bunch
of
experiments
on
figuring
out.
If
these,
actually,
if
ECT
might
control
packets
and
we
transmission,
is
all
this
type
of
packets
actually
get
how
they
get
processed
by
the
network
and
by
the
servers
right
there
are
out
there.
Q
Our
conclusions
is
basically
this
that
they
basically
the
same
treatment
than
ECT
mark
packets,
right
and
and
then
normal
packets
right.
When
you
send
no
regular
ecn
on
data
packets,
whenever
ECT
packet
initiative
data
packet
goes
through
control,
packet
gets
through
as
well,
and
so
there
is
not
too
much
difference.
There
is
no
special
treatment
of
control
packets
as
what
we
can
see
now
so
we're
going
to
report.
Q
This
I
mean
the
data
set
and
and
the
results
of
our
experiments
in
probably
for
the
next
for
the
next
meeting
and
okay,
and
we
have
an
open
issue.
I
was
thinking
that
it
was
the
last
one.
So
this
is
one
open
issue
that
both
Pat
McCrory
brought
up.
That
is
what
happens
if,
because
you
send
the
ICT
marks
from
the
seamless
was
and
and
and
and
you
managed
to
see
that
EC
end
plus
plus,
is
being
supportive
along
the
path.
What
happens
is
in
the
middle
of
the
connection?
Q
You
start
losing
ECT
marked
pockets
or
DCT
control
mark
pockets
right
understood
that
that,
because
there
was
some
changing
the
routing
and
now
suddenly
you
get
a
different
middle
box.
So
is
there
any
way
you
can
actually
react
to
that?
We
haven't
actually
come
up
with
a
very
neat
solution
for
this.
At
this
point,
it's
still
an
open
issue,
I'm
not
seeing
that
it's
very
pervasive,
the
fact
that
control
packets
are
treated
differently
than
data
packets.
So
this
is
not.
We
don't
see
that
this
is.
Q
There
is
boxes
that
do
this
specifically
for
for
control
packets.
This
may
happen
to
you.
Sorry,
we
do
haven't
found
any
right.
Sorry,
sorry,
sorry!
Yes,
we
haven't
found
any
cases
that
that's
that,
that's
that
that's
the
situation
right
so
probably,
maybe
that's
not
a
big
deal.
I,
don't
know!
Media
me.
M
A
cool
event:
this
is
an
open
question
for
you,
CN
in
general,
so
you
need
go.
She
ate
you
CN,
you
mark
your
packets
and
then
you
take
that
something
goes
wrong
and
then
you
should
stop
marking
your
packets,
yes
say
and
like
yeah,
we
don't
really
have
a
good
solution
for
Italy
for
easy
and
in
general,
if
we
would
have
a
solution
would
be
the
same
solution
here.
So
I
don't
think
it
needs
to
be
addressed
in
this
document.
That.
K
Q
Well,
next
steps
so
we're
going
to
post
zero
one
version
that
actually
incorporates
actually
I've
been
so
meters
already
that
incorporates
all
the
feedback
and
I
mean
and
all
our
changes
reacting
to
those
to
those
comments.
Hopefully
we
were
able
to
address
most
of
them.
I
would
really
appreciate
the
people
who
actually
review
the
document
can
check
that
it
reflects
what
you
wanted
out
of
the
document
and
we
need
a
more
measurement,
so
we
have
done
a
few.
We,
hopefully
we
hope,
to
to
report,
probably
in
the
next
meeting.
Q
B
Yeah,
okay,
so
this
is
Michael
speaking
and
this
this
time
more
or
less
is
chair.
So
I'm
wondering
a
little
bit
about
the
cross
dependency
between
EC
+,
+,
+,
+,
equity,
Zn
I'm.
Not
really
asking
that
to
you,
it's
more
to
the
working
group
so
because
I
understand
there
are
some
cases
where
the
the
two
could
be
deployed
together
or,
if
even
get
its
value,
if
you
use
them
in
combination.
B
B
Q
Just
just
to
to
help
with
this
question,
this
is
the
summary
right.
I
mean
basically
what
the
dependencies
as
of
today,
if
we
don't
change
the
products
and
stuff
right,
but
what
the
draft
dust
reflects
today
is
this
right.
The
dependency
is
on
the
scene
right
all
the
rest,
it's
okay.
Just
to
summarize,
and.
M
B
J
Yeah
so
Bob
Briscoe
and
maybe
I-
can
put
this
in
terms
of
companies
because
that
it,
the
RFC
3168
columnar,
is
more
for
people
over
already
deployed
ACN
3168
like
Apple
all
right,
and
what
this
is
saying
is
you
can
get
the
advantages
without
also
implementing
at
crazy,
and
if
you
want
alright,
but
you
don't
get
the
advantage
on
the
sin,
which
is
one
of
the
big
advantages.
So
it's
it's
sort
of
to
allow
companies
like
Apple
to
think
do
we
want
to
do
that
so
yeah.
B
C
Q
T
T
If
you
negotiate
ecn,
you
end
up
passing
in
an
anycast
network
to
a
potentially
at
different
box,
and
you
get
a
reset
if
you
do
it
straight
away
with
ECT,
and
you
just
get
a
reset
later
on,
it's
completely,
not
obvious
that
that
might
have
been
because
it
congestion
marking
changed,
and
so
you
ended
up
in
a
different
box
and
I
didn't
see
really
any
in
the
measurements
in
particular.
The
assumption
is
ECT
makes
it
through
so
success
I'd
be
curious.
Q
N
Andrew
McGregor,
of
course,
if
you're
hashing
on
the
entire
byte
in
the
presence
of
easy
and
your
network
is
broken
so
and
also
most
of
the
boxes
that
do
that
with
the
configuration
that
was
suggested
in
their
documentation
for
hashing,
there
I
have
a
different
configuration
that
does
it
the
right
way.
So
I'd
say
that
many.
N
Many
CD
ends
and
they're
like
who
are
who
might
investigate
deploying
ACN
that
don't
do
it
at
the
moment.
We
do
it
because
of
the
benefit
on
the
syn
here
and
therefore
would
want
to
do
accurate
ecn,
I
think
the
case
of
not
wanting
to
do
accurate.
Is
he
and
kind
of
means
you
don't
want
to
bother
with
this
either
right?
N
Q
Q
There
should
be
a
strong,
strong
case
as
what
Michael
was
saying,
because
you
will
eat
quite
a
few
whole
points.
In
addition,
if
you
wanted
to
support
all
the
possible
combinations,
thirdly
right
so
so
it
will
be
expensive
if
you,
if
you
want
to
do
some
other
things
than
this
right,
so
there
should
be
a
strong
case,
but
that
that's
what
he's
asking.
N
T
Just
to
agree
that
the
whole
hashing
thing
is
completely
broken,
but
it
does
give
a
barrier
of
entry
in
terms
of
implementation
cost
because,
like
you
end
up
paying
the
cost
and
customer
support
for
a
broken
box
somewhere
else
in
the
internet,
and
so
this
is
a
hurdle
for
deployment
that
you
have
to
consider
right.
Yeah,
and
this
is
the
whole
problem
with
the
original
deployment
of
ecn,
which
had
the
same
kind
of
implementation.
Hurdles
which
were
kind
of
waved
off
because
of
the
huge
benefits
of
ecn.
So
we've
been
through
here
before
I.
M
B
O
Everyone
today
I'm
here
to
present
the
new
TCP
option:
tcp
low
latency
option
and
the
motivation
behind
this
option
is
that
the
next
recently
L
the
next
thing-
the
data
center
machines
recently
are
usually
up
to
speed,
10
gigabits
per
second.
That
makes
the
RTT
time
less
than
100
millisecond
100
microsecond,
and
this
pretty
low
ITT
time
makes
the
some
of
the
fixed
parameters
in
RFC
outdated,
and
one
of
them
is
RFC
one
one,
two
two.
O
It
defines
the
lay
back
mechanism
and
in
most
modern
operating
system,
it
usually
delays,
act
for
40,
milliseconds
up
to
200
milliseconds
and,
as
you
can
see,
the
delay
is
mostly
about
400
times
the
RTT
time
and
or
so
for
a
minimum
RTO
time.
The
retransmit
timeout
RFC
62-38,
I'm
of
1
second,
and
that
is
10000
times
of
the
RTT
time
and
also
above
the
2
above
parameters
that
both
of
them
introduce
unnecessary
delays
to
the
data
center
machines
and
more
so
yes.
O
So
next
is
the
FC
73
22
23.
It
defines
the
tcp
timestamp
option
and
the
granularity
of
the
timestamps
is
usually
1
millisecond
to
1.
Second,
and
even
though
it's
granularity
of
1
millisecond,
it's
still
10
times,
then
the
RTP
is
so.
It
makes
the
RTT
measurement
from
the
TCP
timestamp
option,
not
that
accurate.
O
So
we
propose
this
one
solution
to
the
above
problem
as
that
during
the
collection
establishments
face,
the
local
side
will
advertise
some
hints
of
the
above
parameters
so
that
the
remote
side
will
pick
the
hang
up
and
then
do
some
adjustment
on
the
related
parameters.
So
if
you
go
to
the
next
slide,
here
is
an
example.
That
explains
a
little
bit
more.
How
we
do
this
so
during
this
three-way
handshake,
when
the
active
site
sends
a
sing,
it
will
include
this
TCP
low
latency
option
and
take
the
maximum
ACT
delay
as
an
example.
O
Milliseconds,
so
that
the
active
site
can
also
do
some
adjustment
accordingly
and
after
the
the
connection
is
established
when
the
same
side
wants
to
send
the
packet
and
the
receives
I
received
it,
and
if
the
active,
if
the
delay
occurs
active,
then
the
receive
site
can
only
delay
ACK
as
up
to
5
milliseconds
as
advertisers
before
and
also
for
the
same
side.
When
you,
when
you
do
retransmit
the
maximum
retransmit
time
out
on
your
site,
will
be
set
accordingly,
that
will
be,
it
will
be
greater
or
equal
to
5
milliseconds.
O
O
Maximov
delay,
unit
and
templates
will
specify
the
maximum
absolute
value
and
there
are
four
bits
reserved
that
will
be
for
a
future
use.
So
as
there
is
no
Ayana
option
number
yet
so
we
are
going
to
first
use
it
with
experimental
ID.
So
then
the
kind
of
will
do
will
be
to
54
and
the
length
will
be
6
and
the
experimental
ID
that
we
get
is
of
F
990
and
the
rest
are
the
same.
O
O
So
we
are
proposing
that
in
Linux
we
will
use
2
if
he
is
one
as
through
the
IPL
command.
So
you
will
be
able
to
use
it
to
specify
a
maximum
activate
per
out
so
that
all
the
connections
going
through
this
route
will
use
that
and
the
other
is
through
a
socket
option
where
you
can
specify
this
for
a
specific
socket
and
the
implementation
should
use
a
value
as
close
as
possible
to
the
user
specified
maximum
at
delay.
O
Oh
the
reason
we
use
as
close
as
possible,
it's
mostly
because
the
because
of
the
timer
granularity
limitations
on
the
operating
system.
If
the
user
specifies
a
timer,
that's
but
too
low
will
be
rounded
up
to
whatever
the
operating
system
supports.
Oh
and
when
the
user
specifies
a
maximum
ACT
delay.
O
O
It
will
now
you
can
do
smooth
RT
t
plus
k
times,
RT
t
variation
and
then
just
plus
a
maximum
active,
a
received
on
the
other
side
and
nor
so
when
we
are
trying
to
compute
the
probe
time
out
in
the
rack
draft.
Initially
it
was
using
this
there
is
this
WC
tell
act
ii.
Initially
it
was
set
to
200
milliseconds.
Now,
if
you
receive
this
maximum
active
a
value,
you
can
replace
that
with
with
switch
what
you
are
receiving
and
the
status
of
this
is.
O
We
have
already
submitted
the
initial
draft
and
the
draft
the
second
draft,
as
is
currently
so.
The
first
draft
only
includes
the
maximum
actally,
and
the
second
draft
will
also
be
including
the
micro
time
microsecond
time
stamp
and
the
maximum
x
value
by
maximum
active
a
has
been
used
in
who
those
things
2005
and
the
microsecond
time
stamp
option
has
been
used
in
Google
since
2000,
and
we
are
also
currently
working
on
the
upstream
Linux
implementation
for
both
of
them
and
we're
also
hoping
that
other
platforms
or
operating
systems
can
support
it.
And
that's
it.
J
But
Bruce
Kyle
I've
read
this
draft
very
carefully.
You'll
get
a
long,
written
review
of
it
because,
but
I
you
know
in
the
last
week,
I
had
a
lot
of
other
things
to
do
so.
I
haven't
actually
written
it
out,
but
it's
if
I
can
summarize
my
comments.
I
support
where
you're
trying
to
get
to,
but
not
the
way,
you're
starting
and
maybe
I
need
to
pre.
Pre
start
this
with
a
question.
Why
are
you
bringing
it
here?
J
Presumably
because
you
believe
this
has
benefit
for
the
whole
internet,
not
just
inside
Google,
yeah
and
and
then
all
these
arbitrary
values
are
all
wrong,
except
for
certain
cases.
You
know
that
they're
right
for
one
case
and
then
they're
wrong
for
all
the
other
cases
when
you've
got
a
host,
that's
using
different
round-trip
times
for
different
flows.
J
Picking
an
arbitrary
number
and
configure
it
and
saying
this
is
the
number
we're
going
to
use
so
I
think
the
way
around
this
that
way
to
think
about
this
is
once
a
flow
has
started,
and
you
know
it's
round-trip
time.
Let's
try
and
make
all
these
numbers
go
away
and
base
them
on
the
round-trip
time
and
only
have
arbitrary
numbers
before
you
start
like
for
the
sin
for
the
time
out
on
the
sin
and
everything
else,
why
does
it
need
to
depend
on
something
that
someone's
configured
rather
than
what
you
just
measured
right,
I?
Think.
O
U
O
C
J
The
initial
party,
oh
I,
once
your
flow
started,
it's
better
to
have
get
you've,
got
your
art,
round-trip
time
measurement
from
the
handshake,
and
then
you
base
all
your
numbers
on
that
and
the
reason
why
I
say
it.
The
way
you've
started
is
wrong
by
just
doing
one
of
them
first,
which
is
the
initial
RTO
and
not
doing
the
delay
back.
J
O
C
J
Can
use
this
yes,
but
but
the
point
I'm
making
is
that
you
by
that
time
you
both
know
your
own
round-trip
time
and
you
both
got
an
estimate,
that's
reasonably
the
same
as
each
other.
So
if
you
just
then
say
right,
we're
gonna
use
our
my
own,
our
own
round-trip
time
I
submit.
We
don't
even
have
to
tell
each
other
what
it
is,
because
we
should
have
both
measured
a
similar
round-trip
time.
Yeah.
V
W
Yeah
the
the
issue
is
that
the
the
thing
that
we're
advertising
is
something
that
the
receipt-
the
sender
can't
necessarily
know
what
the
receivers
policy
is.
So
that
quick,
because
you
typically
what
happens,
is
the
sender
sends
a
bunch
of
data
and
you're
not
seeing
any
delay
tax
because
you're,
seeing
because
you're
sending
enough
data
packets
that
the
other
person
is
acting
immediately
and
the
thing
is
you
don't
know
what
the
other
person's
delayed
Act
policy
is
and
tell
you?
How
does
various
retransmit
so
that
there's
you
can't
really.
W
J
Internet
is
is
potentially
talking
to
a
media
server
in
in
your
home.
You
know
with
it
with
a
500
micro
second
round
trip
time
and
it's
talking
to
a
another
host.
That's
got.
You
know
to
200
millisecond
round-trip
time
over
the
other
side
of
the
world,
so
you
can't
configure
it
to
any
good
value
in.
W
W
J
The
formula,
if
you
can
go
back
two
sides
that
one
having
the
configured
value
once
you've
got
started
as
as
a
minimum
can
be
awful.
You
know
it,
it's
really
unnecessary
once
you
know
your
round-trip
time
so
then
still
have
to
wait.
I,
don't
know
what
you
you
saying
this.
Was
it
200
no
200
milliseconds
was.
It
was
something
we're.
W
W
G
W
U
Hi
I'm
Brian
Trammell,
while
we're
talking
about
how
to
clamp
this
thing
so
that
it's
not
dangerous.
This.
This
seems
incredibly
dangerous
to
me
in
an
unauthenticated
header,
because
just
random
stuff
on
the
internet
can
say
oh
I,
I
would
I
would
like
to
flood
things
down
up
under
return-path
on
the
backside.
For
me,
so
I'm
actually
gonna
clamp
your
max
RTO
down
to
essentially
zero.
So
there
needs
to
be
some
sort
of.
U
I
W
Neil
Cargill
Google,
one
of
the
co-authors
of
the
draft
I
mean
keep
in
mind
that
the
the
thing
that
we
would
be
driving
down
here
is
essentially
a
term
that
has
to
do
with
the
the
variance
of
the
ax.
We
and
we've
still
got
the
the
round-trip
time
and
the
regular
you
know
K
times
the
RTT
variance
in
here.
So
the
thing
that
we're
changing
really
is
this
sort
of
artificial
one
second
value
and
we're
changing
that.
U
U
N
And
rubric
rigor
I
was
going
to
comment
about
number
representations,
but
actually
that's
been
obviated
by
discussion.
It
seems
to
me
that
you
need
a
little
bit
more
than
Bob's
one
bit.
You
also
need
to
know
what
the
what
each
ins
Ayana
granularity
is,
but
I
think
that's,
but
I
think
that's
all
you
need
to
communicate
is
we're
doing
this
and
by
the
way
the
time'
granularity
is
x
yeah.
B
So
this
is
Michael
speaking
from
the
floor,
so
the
reading
is
a
wondering
and
does
this
have
to
be
in
the
sin
because
I
mean
soon
space
is
course
so
could
there
be
a
design
where
you
basically
achieve
what
you
want
your,
but
you
negotiated
after
the
soon
okay?
That
would
be
something
I
think
you
should
think
about
the
course
and
I
don't
know
the
answer,
but
soon
spaces
cars.
So
if
you
could
do
it
afterwards,
there
could
be
value
in
at
least
thinking
about
a
mode
where
you
negotiated
after
descent.
I
think.
B
Sure,
there's
a
there's
a
great
up
here,
but
I
mean
it's
in
space
is
a
scarce
resource.
So
if
you
lose
maybe
the
first
handshake-
and
you
can't
use
it
for
that
first
handshake,
but
you
can
use
it
afterwards.
Maybe
that's
so
good
enough
for,
as
I
said
at
least
I
would
suggest
of
thinking
about
if
there's
no
optional
mode
of
doing
or
maybe
the
answer's
no
but
I,
think
it's
a
very
soon.
Space
is
cursed
so
and
you
keep
adding
things
to
the
sin
and
soonerlater
B.
B
M
R
Jenna
Inger,
going
back
to
Bob's
idea,
I'm,
not
sure
that
that
actually,
so
the
idea
of
indicating
wire
a
bit
that
that
both
endpoints
would
use
a
fraction
of
the
already
plus
indicating
the
seems
like
it's
too
much
information
that
ultimately,
both
sides
have
to
coalesce
into
exactly
this.
What
else
am
I
going
to
do
with
the
timer
granularity
or
the
other
side?
If
I'm
not
going
to
use
it
to
construct
this
particular
value?
Ultimately,
it
seems
pretty
clear
it
doesn't.
R
J
R
J
Okay,
the
reason
the
reason
why
I
didn't
think
of
that
in
this
is
the
I
mean
Brigitte,
Jeff
and
I
care
already.
Did
this
thing
where
he
was
trying
to
use
the
timestamp.
You
know,
what's
the
what's
the
resolution
of
your
timestamp
option
and
whether
what
he
had
possibilities
on
the
way
to
do
that
and
I
was
sort
of
in
my
mind,
assuming
that
had
already
been
done
amen.
J
J
J
O
J
V
V
You
know
it's
not
as
useful
as
we
can
get
rid
of
it,
but
just
by
this
right
inside
your
telecenter,
you
know
your
max
parameter
are
tedious
one
millisecond
you
configured
right,
but
if
you
can
either
up
this,
then
you
will
tie
it
to
RTD,
but
like
Neos
at
this
value
you
have
to
do
is
also
the
max
tier
I
have
to
do.
Is
your
server
side
operations
OS
delay?
Have
you
like
it
to
come
back
to
peak
by
some
data?
So
it's
not
all
about
Artie
T
on
the
right.
That's.
J
V
W
Think,
in
my
mind,
did
the
the
max
actually
sounds
a
lot
like
how
you're
thinking
of
the
timer
granularity,
because
it
the
well
because
the
it's
yeah
I
mean
there's
some
minimum
timer
granularity.
That
makes
sense
for
a
delay,
DAC
and
I.
Think
in
practice.
People
should
probably
try
to
delay
their
acts
for
that
minimum,
feasible
amount
and
then
communicate.
J
J
R
R
E
R
Bob
I
think
what
you're
saying
is:
there's
a
constant
which
is
one
second.
We
should
absolutely
get
rid
of
it
and
I
think
so
exactly
I
was
gonna
say.
Yes,
we
should
totally
do
that.
So
the
the
so
I
think
what
might
be
a
little
bit
of
confusion
is
that
what
you're
saying
is
use
G,
which
is
the
granularity,
don't
have
a
max
AG
delay,
independent
of
G
right.
R
So
or
right
or
a
mac
sack
delay
that
includes
G
and
something
else,
and
that's
the
part
that
I
think
I
disagree
on
I
mean
I.
It
seems
to
me
that
if
what
you
want
to
indicate
is
how
long
do
you
want
the
other
side
to
wait
if
it's
based
on
granularity
and
based
on
something
else,
then
you
just
ship
the
number
that
you
on
the
other
side,
to
wait
for
instead
of
just
shipping
a
granularity
and
have
the
other
side
construct
something
from
the
granularity,
because
but
yeah
I.
M
Think
you
don't
want
a
constant
value,
you
want
something
that
depends
on
the
amount
of
time
and
it
might
be
a
fraction
and
the
garage
yes,
but
you
don't
want
the
constant
value
there
you
need,
depending
out
here,
is
something
you
configure
in
your
toilet.
It's
depending
on
what
your
operation
system
is
doing.
Yes,
but
it's
also
not
a
constant.
It's,
not
a
user
game,
constant.
W
And
another
thing
I'd
like
to
inject
here
is
that
if
it's
something
based
on
the
RTT,
then
we
get
into
this
question
of
the
fact
that
the
two
sides
don't
know
what
the
other
person's
RTT
estimate
is,
and
so,
if
I'm,
trying
to
communicate
that
I'm
gonna
delight
X
by
a
quarter
of
my
RTT
estimate,
then
you're
gonna
wonder
well.
What's
your
RTT
estimate
I
have
no
idea
what
that
is
so
I.
W
J
C
I
A
result-
advanced
configuration,
makes
sense
because
somebody
actually
does
know
what's
going
on
when
you
brought
it
out
to
the
broader
Internet
that
a
priori
knowledge
is
no
longer
necessarily
there,
and
so
there
needs
to
be
some
way
to
check
that
oops.
We
goofed.
No,
it's
not
working
the
way
that
the
way
we
expect
it
to
and
therefore
what
we're
going
to
do
what's
appropriate
for
our
higher
delay
path.
I
The
round-trip
time
sound
like
a
good
way
to
go
there,
which
is,
if
you
did
something
like
this
and
then
check
the
round-trip
times
all
of
a
sudden,
oh
good,
lord,
the
round-trip
times
75
75
milliseconds.
Maybe
we
didn't
want
to
do
this.
That
would
help
greatly
to
at
least
back
out
of
this
when
you
discover
somebody's
put
it
in
the
wrong
place.
Z
I
I
just
wanted
to
say,
I
think
the
mechanism
may
not
be
perfect
as
specified
in
the
draft,
but
I
think
this
is
definitely
something
that
we
should
be
doing,
and
you
know
I
think
that's
exactly
the
kind
of
thing
that
we
can
hash
out
over
multiple
drafts
in
the
future,
but
I
fully
support
the
work.
I
know,
there's
other
people
doing
work
in
this
area
and
I
think
that
TCP
M
should
be
taking
this
on
Thanks.
M
You
could
live
in
adding
to
David's
point
so
I
I
know
that
you
did
this
because
it's
easier
for
you,
but
if
you
have
a
prior
knowledge,
a
probably
knowledge,
then
you
can
and
you
can
configure
it
everywhere.
You
also
know
what
the
other
end
is
doing.
So
you
don't
need
to
exchange
information
anymore,
say:
I,
don't
think
the
data
in
that
case
is
the
interesting
one
here.
W
Except
when
you
have
data
centers,
big
enough
that
you
can
instantaneously
upgrade
all
your
machines
to
the
next
operating
system,
provision
which
I
think
is
the
the
kind
of
situation
we
run
into.
Also
there
are
more
situations
coming
in
coming
down
the
pike
that
are
where
this
would
make
sense.
So,
for
example,
in
in
cloud
scenarios
where
you
might
have
thousands
of
machines
in
the
same
data
center,
but
they're
all
different
vendors,
different
operating
systems,
and
they
need
a
way
to
know
what
the
other
person
is
gonna
do.
R
Anger,
Google,
I
I
think
what
Jonathan
said
that
I
think.
Broadly
speaking,
the
problem
is
interesting.
I
agree
with
Bob
completely
that
the
one
second
is
arbitrary.
Random
is
not
used
in
practice,
so
it's
actually
quite
nice
to
be
able
to
change
that
and
maybe
think
about
something
more
realistic
and
more
useful
and
more
practical
that
can
be
used
then
so
the
one
second,
maybe
the
precise
mechanism
here
is
not
something
that
we
may
want
to
do
for
the
broader
internet.
I
think
it
seems
like
it's
closed
and
that
can
be
hashed
out
over
time.
B
Long
one,
okay,
so
I
think
we
had
enough
discussion
on
that.
One
I
think
there
is
some
positive
feedback
here
in
the
woman
general.
Of
course,
the
details
of
the
probably
need
to
be
reviewed
so
I
think
be
encouraged,
the
author's
to
look
into
the
feedback
that
I
got
and
possibly
come
back
to
us
with
a
new
version.
G
G
So
far,
we
have
data
from
freebsd
linux
and
windows
and
we
want
to
provide
clarification
and
updated
machism
details
at
the
key
issues
that
we
address
to
provide
better
details
on
share
tcp
parameters
and
shared
algorithms,
and
we
want
advice
on
the
limits
of
sharing
when
to
share
and
when
not,
and
also
we
want
provide
interaction
with
TCP
options.
We
have
a
data
table
for
it
and
also
we
have
added
all
the
listed
all
the
options
in
the
appendix
X
like
this.
So
we
actually
current.
G
We
are
currently
seeking
adopt
what
group
adoption
BCP
so
that
we
can
recommend
best
practices
based
on
the
current
implementation
experience
and
if
it
gets
adopted,
we
want
to
fill
out
the
TBD
s
related
to
sharing
table
and
focusing
on
the
known,
safe,
behavior,
water,
okay,
to
be
shared
and
what
a
problematic
in
the
internet
today,
and
we
want
to
leave
the
cost-benefit
decision
to
implementer
but
explain
the
aspects
of
taking
such
decision,
and
we
are
also
open
to
finding
information
related
to
other
operating
systems.
Thank
you.
B
So
this
is
Michael
speaking
this
time
is
chair.
So
then
the
situation
for
disrupt
is
as
follows:
we've
run
an
adoption
call
on
the
mailing
list.
We
didn't
get
a
lot
of
feedback
as
actually
be
got
zero
feedback,
and
that's
why
we
wonder-
or
we
would
like
to
check
in
in
the
room
if
there
are
thoughts
on
on
this
draft.
So
at
the
moment
the
feedback
that
we
got
is
honestly
speaking
and
not
really
sufficient
to
adapt
it
and
the
working
group.
N
It's
a
widely
deployed
behavior,
it's
sometimes
problematic
and
sometimes
safe
and
I,
actually
think
there
is
value
in
documenting
when
it
is
reasonable
to
configure
this
and
not,
and
of
course,
there
are
always
going
to
be
parties
out
there
who
configure
it
in
a
radically
different
way
that
aren't
talking
about,
but
you
know
at
least
documenting
the
basics
of
why
it
is
and
is
not
safe
to
do.
Share
various
various
of
this
data
has
value
so
I
think
it
is
worth
adopting.
Even
if
it's
insufficiently
controversial,
to
attract
comment.
B
B
I
will
asked
first,
if,
if
you
support
it
and
I
also
been
asked,
if
there
are
any
objections,
so
that
will
be
the
first
part
of
the
question
and
then
in
the
second
formal
question,
we
have
to
stay
Jewish
out
there.
So
there
are
a
couple
of
different
things.
What
we
could
do
here,
the
you
can
see
on
the
slides.
The
also
is
proposed
this
as
PCP,
and
it's
also
possible
to
do
this,
for
example,
as
an
informational
document.
B
B
B
So
for
the
note
takers,
there
is
no
objection,
so
there's
clearly
a
sense
in
the
room.
There's
value
in
in
documenting
this
behavior
now
coming
to
the
second
question
so
on
the
stators
so
in
in
particular
among
the
people
that
think
there
is
value
in
here
as
those
of
you
who
think
that
this
should
be
a
PCP.
Please
raise
your
hand
and
I
see.
H
Aoife
has
to
here,
I
would
suggest
in
a
discussion
that
we
should
postpone
deciding
whether
it's
a
BCP,
that
he
could
be
a
BCP.
From
my
point
of
view,
if
lots
of
people
here
say
this
is
the
right
document,
and
this
is
the
right
advice,
it
could
easily
be
informational
if
people
didn't
actually
sign
up
to
that
later
on.
Maybe
we
don't
have
to
decide.
Now
is
my
yeah.
B
Complete
you
don't
have
to
as
it's
actually
correct,
but
the
I
mean
we
don't
have
to
think
about
it
if
there's
no
support
for
it
ever
being
PCP.
So
I
fully
agree
in
this
was
of
one
of
the
options
that
I
gave
in
my
adoption
called
that
the
postponed
a
question,
but
I
still
am
in
particular
interested.
If
there's
support
for
it
possibly
becoming
a
PCP.
R
Jahangir
Google
I'm
I'm
not
very
excited
about
it.
The
coming
BCP
I'm
more
interested
in
it
being
informational
because
I
think
there's
the
the
rat
hole
of
hey.
This
is
what
these
implementations
do
now,
let's
discuss
if
that's
a
good
thing
or
not,
I'd
like
to
avoid
the
second
one,
because
I
think
the
value
in
this
draft
is
the
first
one
which
is
this
is
what
implementations
do.
G
So
I
would
like
to
add
something.
As
for
the
meeting
minutes
from
ITIF
96,
where
I
lost-
and
you
mentioned
as
well,
so
what
what
last
suggested
to
have
it
as
BCP,
like
putting
BCP
with
an
appendix
where
all
the
informational
stuff
should
be
sent
to
the
appendix
and
focusing
on
what
are
okay
to
be
shared
on
what
are
problematic
today.
So
then,
basically,
it
would
fit
quite
well
and
that
actually
we
want
to
propose-
and
we
want
to
like
we
intend
to
do.
I
I've
had
long.
R
Trouble
with
the
BCB
line,
because
we
don't
have
a
place
to
document
deployed
stuff,
we
tend
to
push
it
towards
BCB,
it's
hard
to
make
judgments
about
things
that
are
deployed.
If
what
we
want
to
say
this
is
what's
deployed.
Not
necessarily
this
not
necessarily
say
this
is
best
practice,
but
I
think
that's
that's
finagling
that
can
be
done
later.
I'd
like
to
have
a
whole
new
thing,
called
deployed
current
practice
or
currently
deployed
something
or
the
other
BCP,
but
yeah.
B
H
X
X
R
R
X
R
B
I
mean
the
just
to
be
clear:
I
mean
we
can
have
this
conversation
afterwards
that
still
I'd
like
to
get
the
sense
of
the
room
for
my
question.
We
can
hold
off
the
status
discussion
later,
but
I'd
like
to
get
a
sense
of
the
room.
How
many,
how
much
support
we
have
for
PCP
right
now
and
I
fully
understand
that
this
could
change
throughout
the
document.
You.
R
Know
I
mean
I
would
say
that
the
conversation
around
water
does
that
we
recommend,
if
you
keep
it
a
little,
if
that's
not
the
critical
part
of
that
or
if
it's
useful
it's
it's
definitely
useful
to
have
thoughts
that
the
working
group
thinks
that
you
know.
Maybe
this
is
a
good
idea,
and
this
is
not
a
good
idea
and
so
on.
It's
trying
to
have
that,
but
I
think
the
more
to
mean
the
more
the
useful
part
of
it
is
the
documentation
of
what
actually
the
current
practices.
N
And
Romero
Guardian
I,
you
didn't
get
to
asking
the
second
part
of
your
question,
but
I
actually
think
that
it's
situate,
the
feeling
I'm
getting
from
this
conversation
is
that
there
is
support
for
publishing
the
document
in
some
form
and
there
is
a
little
objection
for
to
it
being
a
BCP,
but
that
I
think
we
can
leave
it
choice
to
the
authors
as
to
which
way
they
want
to
push
it
and
lay
someone.
It
means.
B
Okay,
since
you're
running
out
of
time,
I'd
like
to
raise
the
two
questions
and
we
will
figure
out
afterwards
what
exactly
we
do
have
to
talk
or
ad
on
on
that
one.
So
the
question
to
the
room
is
so
please
raise
your
hands
if
you
think
or
if
you
think
that
this
can
be
coming
at
ECP.
So
please
raise
your
hand
now.