►
From YouTube: TCPM WG Interim Meeting, 2020-04-29
Description
TCPM WG Interim Meeting, 2020-04-29
A
A
A
A
A
A
Kind
of
note
istic,
so
if
you're
hearing
us
the
WebEx
link,
is
not
interested
in
the
etherpad
link,
is
there
there's
a
jabber
room
I
think
we
will
use
the
WebEx
chat
for
queue
management.
So
if
you
want
to
discuss
something
say
something
please
plot
a
queue
plot.
Please
put
a
Q
plus
one
on
the
chat,
but
if
you
want
to
get
DQ'd
queue,
please
state
your
name
and
make
sure
that
it's
also
correct
in
the
in
the
notes.
A
A
So
this
is
the
agenda
of
today.
We
are
in
the
way
working
group
status
updates.
Then
we
have
a
couple
of
presentations
for
working
group
documents.
We
have
RTO
considerations
from
mark
793,
biz
from
I.
Think
it's
Michael
sharp,
giving
the
presentation
like
a
West
will
talk
about
I
received
21
40
bits,
and
then
we
have
two
talks
about
accurate
ecn,
one
from
up
about
for
them
the
draft
and
one
from
ilpo
about
the
Linux
implementation.
A
And
then
we
have
a
TCP
wreck
presentation
from
each
I'm
covering
arm
the
results
of
the
working
good
last
call,
and
then
we
have
four
other
presentations
for
non
working
group
items.
The
yang
model
for
TCP
we've
a
rapidly
have
been
running
code
for
adaption
on
the
mainland
is
high
style
from
Praveen,
and
then
two
things
which
are
related
to
handling
in
TCP
one
is
about
requesting.
X1
is
about
reducing
the
rate.
These
are
the
last
two
presentations
next
slide.
A
We
have
two
changes:
I
want
to
make
sure
you're
aware
of
them.
One
is
the
TMP
TCP
working
group
has
been
closed
and
maintenance
of
these
documents
is
happening
in
this
document
is
happening.
This
working
group,
so
the
Charter,
has
been
extended
by
the
sentence
I,
which
is
written
on
the
slide,
which
means
MP,
TCP
maintenances
in
this
working
and
the
responsible
ad
has
changed,
marking
snow
in
charge.
Next
slide
are
that's
simple.
No
recent
RFC's
next
slide
the
working
group
documents
we
have
one
which
is
in
the
RCL
eater
q.
A
A
We
have
through
three
more
working
group
documents
which
are
shown
in
blue,
where
we
have
presentations
on
it
today
and
then
the
generalized
ECM,
which
hasn't
been
there's
no
presentation
on
it
and
the
tcp
do,
which
is
even
I,
think
we
don't
have
a
current
or
connective
document
on
that.
These
documents
here
are
listed
in
the
in
the
order
of
the
milestones.
So
we
are
right
now
working
from
top
to
bottom
regarding
the
the
ones
where
the
working
group
has
gone
has
been.
A
A
A
C
A
C
E
E
B
B
D
E
There
we
go
yeah,
okay,
so
let's
do
this
real
quick!
This
is
the
old
RTO
consider
documented
how
you
can
go
to
the
next
slide.
This
has
been
around
forever
I.
Looked
it
up
about
nine
years,
so
just
the
sort
of
very
brief
tour
of
what
the
document
is
and
we
sort
of
thought
we
understood
RTI
well
enough
to
get
away
from
sort
of
the
nitty-gritty,
specifics
and
move
sort
of
more
to
general
requirements
and
guidelines,
and
so
we
started
that
a
long
time
ago
and
you
can
go
to
the
next
slide.
E
This
is
a
specific
example
of
what
I'm
talking
about
so
instead
of
sort
of
an
algorithm
like
this,
so
every
specific
equation
we
can
get
to
sort
of
requirements,
an
RTO
should
be
based
on
a
set
of
round-trip
times
and
variance
to
the
round-trip
time
things
like
that.
Okay,
so
you
can
go
to
the
next
slide.
We
have
I,
don't
know
six
seven,
eight
of
these
big-picture
guidelines,
the
document
and
my
take
is
that
we've
had
consensus
on
these
for
about
nine
years.
There's
really
never
been
much
beyond
sort
of
tweaking
of
these
things.
E
Over
the
whole
nine
years
so
go
to
the
next
slide
and
the
reason
we
haven't
gotten
this
document
done
is
that
we've
struggled
with
the
positioning
of
this
document
in
this
sort
of
context
of
the
rest
of
the
RFC
s
that
are
already
there.
Okay,
so
we're
trying
to
put
some
requirements,
some
guidelines,
sort
of
on
top
of
an
existing
body
of
document.
This
is
proven
to
be
difficult.
E
Okay,
so
I
would
go
out
and
try
one
approaching
and
make
somebody
happy
and
then
put
out
a
new
version,
and
somebody
else
would
be
unhappy
with
that
positioning.
So
you
see
that
this
sort
of
we
have
these
active
periods,
inactive
periods
over
the
last
nine
years,
the
sort
of
blue
circles
there
we're
trying
really
hard
to
find
some
way
to
frame
the
context.
E
It
makes
everybody
at
least
roughly
happy
and
then
the
sort
of
red
areas
are
where
I
thrown
up
my
hands
and
just
decided
I,
don't
know
what
I
don't
know
what
the
hell
to
do
so
go
to
the
next
slide,
so
around
ietf
106.
We
had
a
couple
with
good
views
into
about
this
document.
So
the
first
one
I
want
to
talk
about
for
ease
review
and
for
yet
a
bunch
of
sort
of
smaller
comments
that
were
addressed,
but
it's
big.
E
His
big
at
the
document
was
that
it
didn't
exclusively
take
position
relative
to
the
other
arts
and
gory
and
I
exchanged
a
bunch
of
email,
and
we
talked,
and
ultimately
I
reworked
section
2
in
the
document
and
I
want
to
tell
you
how
I
don't
want
to
put
words
and
Gauri's
mouth
I
see
him
I
see
him
there
in
the
list,
so
he
can
speak
for
himself,
but
I
believe
that
these
have
addressed
his
concern.
So
let
me
go
through
the
three
bullets
that
we
added
next
slide.
E
E
For
the
most
part,
this
document
is
consistent
with
all
the
previous
RFC's,
not
for
the
letter,
but
you
know
we
used
all
of
our
previous
knowledge
to
sort
of
arrive
at
these
requirements
and
guidelines.
So
it
is
pretty
consistent,
but
this
does
not
change
anything.
That's
already
committed
to
RFC,
so
next
bullet.
E
So
this
is
for
the
document
is
really
meant
to
sort
of
to
look
to
the
future
and
provide
what
I
think
of
it
is
sort
of
a
default
or
how
we
handle
our
TOS
going
forward,
and
so
we
say
that
the
guidelines
in
the
document
should
be
used.
Capital
should
be
used
sort
of
in
the
future.
Okay,
and
then
we
got
the
next
slide,
which
is
the
third
bullet
which
says,
okay.
That
last
bullet
should
not
a
must.
Okay,
it's
fine
to
deviate
from
these
requirements.
If
you
have
a
good
reason,
that's
fine!
E
It's
a
default
position.
You
can
deviate.
I
thought!
If
you
deviate,
then
you
must
a
explain
why
you're
deviating
and
B
you
have
to
go
through
the
usual
process
and
gather
consensus
on
those
deviation.
I
think
that's
all
pretty
reasonable.
So
those
are
the
sort
of
changes
in
response
to
Tory's
comments.
You
go
to
the
next
slide.
Look
at
Donna's
comments.
E
Again.
He
sent
out
a
review
in
round
I
tip
six.
So,
though,
he's
really
been
sort
of
in
my
ear
about
this
for
for
a
coheres
now,
and
his
comment
is
basically,
why
is
this
document
centered
around
retransmission
and
it's
really
about
loss
or
loss,
detection,
okay,
sort
of
find
loss
and
and
sort
of
who
cares
if
the
action
we
take
is
to
retransmit
the
segment?
Not
we
transmit
the
segment
transmit,
some
updated,
updated
information.
So
it's
not
a
you
know,
fit
four
bit
retransmit.
E
E
So,
as
is
negative
in
the
opening
we've
just
sort
of
made,
the
working
group
last
call
there
was
a
minor
suggestion
about
one
of
the
requirements.
It
was
a
issue
of
just
an
issue
of
warding
that
will
be
fixed.
It's
not
a
big
deal,
but
there
were
four,
no
big
other
big
comments.
We
really
no
other
comments,
except
for
that
one.
So
next
slide
so
I
think
the
chairs
just
wanted
me
to
say
you
know
a
few
words
and
take
any
other
comments
that
folks
have
here.
E
Yeah,
so
the
peer
change
there
was
this
sort
of
a
problem,
a
little
problem
when
I
went
from
the
retransmit,
my
anguish
to
the
loss
detection,
language
that
I
can't
even
remember
who
flagged
it
I'm.
Sorry
I
should
remember
that,
but
it
was
just
a
little
problem
with
that
and
I
will
fix
that
and
submit
a.
A
Going
once
twice,
okay,
then
to
pub.
So
what's
that
mean
do
we?
That
means
your
submit
a
new
version
and
then
I
would
consider
it
that
the
working
class
calls
has
been
addressed.
Okay,
okay,
good!
Thank
you.
Okay!
Thank
you,
which
means.
The
next
presentation
is
about
overseas.
Seven,
nine,
three
peas
and
Western.
The
caller
is
Michael
doing
the
presentation.
D
My
assumption
and
there's
somebody
masks
insult
with
this,
so
I'd
like
to
give
a
quick
update
on
seven
on
Cerebus.
Basically
in
my
role
as
potential
document
shepherd
so
Beth
says
recently
a
update
summary
of
the
remaining
cues
on
the
list
of
the
linkers
on
the
slide
and
some
of
the
key
remaining
things
that
Wes
is
aware
of
or
summarized
on
this
slide
here.
D
So
the
first
component
is
about
the
hot
handled
which
of
bits
in
the
header
most
notably
whether
to
change
the
ANA
allocation
or
that
it
was
cool
for
King
up
the
registry,
a
bit
in
some
discussion
on
that
on
list
already,
it's
viento
who
I
put
on
that
extra
for
testing
acoustic,
leaves
the
money
and
Joe
and
of
yours.
Yes,
so
I
assume
that
is,
nobody
else,
picks
up
vessel
implement
what
has
been
discussed
so
far
on
the
list.
But
of
course
you
appeal
look
at
that
discussion.
D
If
you
free
to
comment
at
the
bottom
of
the
slide,
vessel
probably
still
wait
for
some
few
weeks,
1/2
for
further
discussion
and
enable
and
publish
another
version,
and
the
second
topic
that
has
been
discussed
is
about
a
certain
text
on
r1
and
r2
values.
These
are
thresholds
and
the
world
I
think
is
the
interweb
you
can
go.
There
was
some
questions
on
relatively
implemented
or
not,
and
I
have
checked
that
at
least
I
thank
the
Linux
tech
does
something
reasonably
similar
to
what
it's
written
in
the
RC.
D
So
for
me
at
least,
this
looks
good,
there's
only
two
chain
from
my
perspective,
but
again
maybe
others
should
look
at
that
then
third
thing:
the
topic
is
that
get
a
gateway
detection
and
that
is
about
cross
layer.
Interaction
again
show
has
commented
on
that
and
I
think
my
status
is
that
there
is
no
plan
to
change
the
document
and
finally,
there
has
been
some
discussion
on
I
think
the
listen
API
call
and
that's
described
in
internal
freebase
and
I
think
West
will
implement.
D
The
wording
suggested
a
Joe
unless
somebody
I'll
speak
slow
and
that's
it
for
the
moment.
So
I
strongly
suggest
to
the
rest
of
the
group.
We
have
a
look
at
these
four
issues
if
you
have
any
thoughts
on
that,
please
pick
up
on
the
mailing
list
so
that
we
can
sort
that
out
and
in
general.
That
lens
is
you've,
probably
seen
this
before
that.
If
this
document
doesn't
get
further
comments,
below
course
of
thinking
about
wrecking
crew,
blast
call
and
I
see
that
Mia
is
wants
to
comment.
Go
ahead.
G
Yeah
I
have
a
question:
I
lost
the
bottle
that
we
discussed
last
time
quite
a
tendency
to
change
the
registration
and
policy
for
the
head
of
it
and
at
the
time
the
discussion
was
about
how
urgent
that
might
be,
or
not
it's
not
that
urgent
anymore,
but
there
was
also
proposal.
Is
that
should
be
integrated
into
these?
This
document?
Yes,.
D
But
they're
they're,
two
different
things
so
I
think
you
have
in
other,
wasn't
your
document?
You
suggest
that
there's
and
it
makes
sense
to
clean
up
the
registry.
First
of
all,
because
the
the
header
bits
are
automated
on
a
separate
page.
First
of
all
and
then
some
of
the
research
other
bits
don't
have
even
entry
and
at
the
moment
the
proposal
is
in
79
through
piece
to
basically
clean
up
the
registry,
to
move
everything
to
one
page
and
to
be
updated
research
data
at
the
moment,
not
in
the
table,
the.
D
Policy
will
not
be
changed
by
seven
nine
three
bills,
also,
that
is
probably
entirely
out
of
scope
of
seven
nine
three
bills,
because
it
would
require
a
separate
proposed
standard
with
community
consensus
on
changing
allocation
policies.
So
this
is
only
about
basically
editorial
changes
to
the
eye
on
our
registry.
It
doesn't
change
anything
regarding
how
to
allocate
with
things
like
that,
because
that
would
most
likely
have
to
be
discussed
separately
in
a
separate
request
in
the
document
in
general,
seven
attributes
only
reflect
changes
to
TCP
that
are
already
documented
on
an
abstract.
G
I
mean
I
think
that
I'm,
okay
with
that
but
I,
think
that's
a
decision
for
the
hoop
to
make
I
mean
like.
If
we
have
this
document,
we
can
decide
to
change
everything
if
it's
reasonable
right.
So
we
could
have
a
discussion
if
we
want
to
do
the
update
of
the
policy
within
this
document
or
in
a
separate
document.
For
me,
those
okay
I
just
wanted
to
check
what
the
coupons.
D
Da
d
I
mean
I
had
really
dyes
discussion
to
have,
for
my
perspective
or
also
as
chair.
The
scope
of
this
document
has
been
very
clear
from
the
beginning,
and
the
document
only
implements
changes
on
standards
track.
So
we
can
of
course
change
that,
but
changing
this
that
would
first
be
a
scope
of
the
document
and
I
would
personally
just
suggest
not
to
go
down
that
road,
but
of
course
you
can
have
to
discuss,
but
as
that,
what
is
at
the
moment,
I
think
agreed
between
everything.
D
Everyone
who
has
commented
is
that
we
will
clean
up
the
DNI
registry,
because
I
have
in
original
perfect.
The
current
status
is
not
perfect.
We
will
move
one
table,
we
create
a
new
table
and
move
it
to
the
other,
TTT
parameter.
So
that's
the
suggestion
at
the
moment.
As
I
said,
I
mean
this
is
open
for
discussion.
It
has
not
received
a
lot
of
feedback.
D
G
D
I
think
that
is
I
mean
I,
think
that
there
has
been
a
discussion
before
on
cleaning
up
the
registry.
So
I
recall
that
it
has
been
discussed
on
the
list
before
so
there
seems
to
be
consensus
that
that's
a
good
thing
to
do
and
that
stress
in
tutorial.
It
doesn't
change
anything
from
a
standard
perspective.
So
the
proposal
is
to
do
that
in
7-9
Cerebus
and
if
we
want
to
change
the
education
policy,
I
mean
that
is
probably
a
separate
discussion.
G
A
I
Okay,
yeah
well,
five
minutes,
one
title
slide
and
one
more
slide,
thanks
Lyle,
including
better
impression
yeah.
So
that's
how
we
look
yes.
Well.
Can
you
go
to
the
next
piece
all
right?
So
what
really
happened
is
that
we
had
this
in
version
1,
which
didn't
get
much
feedback,
but
then
at
some
point
got
a
pretty
long
and
very
thorough
review
from
Microsoft
that
we
incorporated
took
us
some
time,
but
we
incorporated
it
all
and
answered
everything.
I
I
So
that's
the
reorganization
and
more
clear
discussion
that
you
see
you
mentioned
on
slide
here.
Section
sip
sees
you
there's
more
text
explaining
things
a
bit
better.
There
is
quite
a
bit
of
reformatting
tables
have
been
moved
around
and
type
or
something
corrected.
Security
considerations
and
I'll
talk
about
fingerprinting.
There
is
appendix
feed,
mentions
all
the
TCP
options
in
the
world
and
talks
about
whether
you
would
like
to
share
them
or
not,
elect
share
it
share
something
cast
something
about
them
or
not,
and
that
was
originally
meant
just
for
us
as
something
to
remember
and.
J
I
At
Bob
we
did,
we
decided
that
this
could
actually
stay.
We
phrased,
we
rephrase
things
a
little
bit
to
be
a
bit
more
fumbling
style.
Their
references
were
reorganized
and
that's
it.
What
great
people
would
read
it
and
it
would
be
even
greater.
You
could
move
on
with
that
document
to
whatever
think
the
chest
think
is
appropriate.
That's
it
for
myself.
A
D
A
Yeah
so
I
think
that
pretty
much
describes
this
situation
from
the
chairs
perspective.
If,
if
we
can
get
another
review
soon,
we
would
like
to
have
it.
If
not,
then
this
is
a
candidate
for
a
working
class
call.
Okay!
If
there
are
none
common,
no
comments,
some
questions,
then
thank
you
very
much
Michael
and
we
go
follow
up
with
Bob
on
accurate
ECM
feedback
Bob.
You
have
15
minutes,
including
discussions.
Yeah.
H
A
C
C
I,
just
very
quick
recap:
accuracy
n
is
a
way
to
get
more
than
one
congestion
signal
per
round
trip
time
out
of
the
tty
protocol
to
change
the
wire
protocol,
because
the
previous
way
of
doing
it
essentially
turn
to
toggle
on
which
stayed
on
for
the
whole
round
trip
time.
And
so
you
could
only
get
one
per
round
trip
time
and
it
involved
before
to
two
flags
and
TCP
header.
Next
slide
we're
moving
to
three
flags
that
are
used
for
the
original
negotiation
of
the
starting
that
during
the
handshake.
C
But
then
they
get
overloaded
as
a
three
bit
counter
and
there's
also
a
crazy
an
option.
Next
and
the
accurate
you
see,
an
option,
I
should
add,
is
supplementary
information,
which
is
not
essential
for
the
working
of
the
protocol,
but
you
don't
get
the
full
accuracy
without
it
right.
A
brief
update
on
the
activity
since
November
from
draft
nine
to
ten
or
there
was
a
large
number
of
what
we
might
call
minor
technical
changes,
tweaks,
etc,
a
large
amount
of
them
due
to
ill-posed
implementation,
which
is
going
to
present
straight
after
this.
C
So
I'm
not
going
to
dwell
too
much
on
some
of
those
things
other
than
give
a
bit
of
introductory
and
high-level
overview
to
help
people
or
imp
and
huge
thanks
to
Olivia
to
ill
Poe,
who
implementation
I
should
say,
was
based
on
a
vs
and
mirrors
for
going
into
it
in
such
depth.
It's
been
a
great
help
and
the
draft
is
now
much
improved
because
of
that
and
there's
also
quite
a
bit
from
other
list
discussions
that
you'll
notice
those
six
main
areas
I
headings
of
the
next
excited.
C
Essentially,
you
get
the
the
highest
version
that
both
ends
can
support
in
in
one
round
an
obvious
sort
of
capability
negotiation.
Now,
if,
for
some
reason
your
packets
aren't
getting
through,
there
is
a
recommendation
to
keep
trying
once
more
and
then
then
fall
back
to
asking
for
not
easy
n
and
the
little
red
brackets
in
the
diagram.
A
little
red
parentheses
and
that
strike
through
at
the
bottom
of
the
little
diagram
are
pointed
out.
C
In
the
bullets,
essentially,
the
parentheses
say
that
the
server
doesn't
actually
have
to
implement
3168
ecn
because
that's
not
necessary
for
the
negotiation.
Obviously,
it's
up
to
the
implementer,
whether
they
do
and
there's
no
particular
reason
why
they
shouldn't,
but
they
don't
have
to
the
crossed
out
or
ecn
on
the.
C
Sort
of
fall
back
at
the
bottom.
There
says
that
if
you
for
back
from
asking
for
accurate
ECM
because
you're
not
getting
through
for
some
reason,
maybe
the
bits
in
the
header
get
blocked
by
a
middle
box
or
something
like
that,
then
you
can
fall
back
to
not
having
easy
on
at
all,
but
you
can't
fall
back
from
accurate
ECM
to
just
e
CN,
and
this
is
the
same
in
the
other
direction
for
the
cynic.
C
If
you've
already
said
you
can
do
accurate,
easy
n,
you
can
only
fall
back
to
know
easy
and
at
all-
and
this
is
just
because
otherwise,
the
number
of
possible
combinations
of
sins
and
sins
that
are
asking
for
different
things
that
might
get
reordered
and
may
some
may
get
lost
mean
the
number
of
possible
combinations
of
states.
You
may
be
in
get
ridiculous,
so
it's
just
easier
to
keep
it
to
two
for
that
for
the
small
number
of
times
where
this
might
happen.
C
C
So
that's
essentially
what
that
bullet
says
there
that
the
first
two
bullets
say
then
the
third
main
bullet
says.
But
when
you
do
retransmit
your
sin
and
fall
back
to
non
ecn,
you
should
use
the
same
is
n
and
this
is
to
prevent
a
downgrade
attack
where
someone
else
could
copy
your
ice,
I,
ascend
and
get
in
or
sorry.
Someone
else
could
just
generate
a
randomized
n,
and
this
allows
the
other
end
to
notice
that
it's
not
the
same
I
ascend
and
therefore
kick
them
out.
C
C
That's
sent
in
the
syn
ACK
right
under
the
syn
ACK
gets
reflected
back
in
the
TCP
header
of
the
ACK
right,
so
MMB
two
tables
taken
from
the
draft,
so
the
same
encoding
is
used
to
encode
the
four
states
of
the:
u
CN
field
in
the
TCP
header
to
give
that
feedback
so
neck
next
slide.
So
that's
the
how
the
protocol
is
meant
to
work
and
we
just
tweaked
some
of
those
things.
C
The
second
point
here
is
that
we,
the
reason
we
were
trying
to
repeat
that
field
was
because
the
third
AK
is
not
reliably
delivered.
So
we
were
not
getting
reliable
delivery
of
this
mangling
detection
now,
having
removed
that,
we
no
longer
have
reliable
delivery
of
mangling
detection,
but
what
we
have
done
is
made
sure
we
at
least
get
reliable
delivery
of
the
congestion
notification.
So
if
there's
seee
on
the
syn/ack,
we
get
reliable
delivery
of
that
because
of
the
arrangement
for
showing
that,
in
the
counter
of
CES
that
start
coming
on
the
data
afterwards.
C
So
it
does
get
through
on
the
package
after
the
ACK
but
again
I'd
like
people
to
comment
or
review
the
decision.
Not
to
have
full
mangling
detection
if
that
act
gets
lost
so
then
you
would
not
know
the
server
would
not
know
whether
it's
IP,
EC
Enfield
was
getting
mangled
on
those
connections
where
the
app
gets
lost
in
the
other
direction.
Yes,.
G
C
Yeah
yeah-
and
there
are,
there-
are
a
number
of
other
things
you
can
do,
one
of
which
I've,
actually,
it
was
advised
by
a
couple
of
people.
I
know
Apple
do
this
where,
if,
if
they're
getting
C
e
continually,
they
turn
off
e
CN
on
the
basis,
but
it's
probably
mangling
and
I
can
put
a
recommendation
to
do
that
in
the
draft
as
well.
I
would
like
to
right
and
the
third
point
I
will
leave
real
power
to
talk
about,
because
he's
probably
got
more
time
than
me
to
do
it
next.
C
Assuming
that
you've
got
9c
e
marks
instead
of
one
and
so
we've
changed.
That
text
to
the
safest
at
likely
case,
which
is
a
bit
sort
of
undefined
way
of
saying,
do
your
best,
whereas
conservative
was
just
too
too
poor
and
there's
an
example
algorithm
of
how
to
do
that
in
the
appendix
which
works
reasonably
well.
C
C
So
now,
moving
on
to
the
optional
accurate
ecn
option
in
the
last
working
group
discussions
they'll
be
introduced.
This
idea
of
I
think
originally
it
was
Neil
Card
well
asked
if
we
could
make
the
order
of
the
fields
a
bit
more
optimal
for
certain
cases.
So
we
introduced
two
possible
orders
for
the
fields
and
a
way
of
indicating
on
the
first
occurrence
of
those
fields
which
order
you
are
using
as
a
general
consensus
on
that.
But
then
Michael
strongly
disagreed
with
it
on
the
list.
C
C
But,
of
course
we
have
very
limited
space
in
TTP
options,
so
any
any
individual
bite
is
something
we
have
to
be
very
careful
about
right
and
we
have
added
more
robustness
in
the
rules
concerning
when
you
send
an
accurate
ACN
option
and
I'm
not
sure
ilpo
goes
through
this.
Perhaps
if
I
can
interject.
If
he
is
going
to
say
all
this,
then
I
don't
need
to
go
down
this
list,
but
yes,
two
minutes,
including
tsk,
okay,
I'll
jump
over
it,
assuming
you
both
can
talk
about
this
next.
C
C
C
Ilpo
pointed
out
that
some
of
the
main
sort
of
extremely
obvious
behaviors
didn't
actually
have
any
normative
text,
so
we
added
that
and
added
some
text
about
what
except
of
packets
were
and
made
that
all
explicit
next,
the
other,
the
other
stuff.
There
is
not
important
editorial
stuff.
So
now
this
is
the
the
switch
from
draft
10
to
draft
11,
which
was
from
experimental
standards
track.
C
It's
just
one
side
on
this
that
we
caught
all
mentions
of
experiment
throughout
the
draft
and
made
it
not
talked
about
experiments,
remove
the
experimental
gold
section
and
added
a
complete
new
section,
giving
all
the
updates
to
RSC
31:58,
which
were
quite
organized
in
that
you
know
this
table
here,
shows
the
mapping
from
one
to
the
other.
You've
got
a
whole
section
or
subsection
in
3168
on
TCP
initialization,
which
maps
directly
to
negotiating
use
of
accurate
ecn.
C
You've
got
a
whole
section
on
the
TCP
sender
in
3168,
which
we
don't
change,
hardly
because
this
is
about
feedback.
It's
it's
mainly
about
the
receiver
end,
except
obviously,
where
it
talks
about
responding
to
count
responding
to
ECE.
We
talk
about
accuracy,
end
talks
about
responding
to
counters
instead
and
the
sender
no
longer
sits
CWR
to
say
it's
reduced
its
congestion
window.
C
You
know
so
it's
a
very
big
section:
6
1
5
there
was
a
little
bit
about
acceptable,
retransmission
packets
and
have
a
test
for
them
in
3168,
and
we,
as
I
just
mentioned,
have
now
included,
accept
your
packet
tests
or
more
explicitly
in
accuracy
n
for
all
packets,
not
just
read
transmissions.
And
finally,
there
are
a
number
of
sections
that
prohibit
the
use
of
ECT
on
control,
packets
and
retransmissions.
Now
the
accurate
ECM
draft
doesn't
change
any
of
that.
C
It
doesn't
change
any
of
those
requirements,
but
what
it
does
do
is
define
the
feedback
if
you
get
one
of
those
packets
anyway,
and
that
allows
things
to
change
in
future
and
it
should
have
been
in
3160
anyway
to
say,
even
though
we're
saying
don't
do
this,
if
you
get
a
package
like
this,
what
do
you
do?
It
should
have
been
in
there
and
it's
now
in
well,
it's
been
in
that
crease
in
for
a
long
time.
Okay,
but
there's
the
mapping
there
next
I
think
clear
on
the
last
slide.
C
I
know
there's
one
more
question:
yes,
there,
the
mangling
detection.
There
was
a
question
that
you
may
want
to
consider,
but
if
it
becomes
a
non-problem
longer
term,
there
is
a
bit
of
complexity
in
accuracy,
n
dealing
with
mangling
and
detection,
and
we
did
think
how
could
we
remove
all
that
in
the
future?
It
wouldn't
actually
be
at
all
easy.
C
C
G
Yeah
I
am
thank
you
for
all
the
work
you
did
that
you
did
most
of
the
work
here.
Looking
at
this
text
again,
I
have
two
minor
points.
One
is
about
the
siient
or
AC
rep,
behavior
and
I
realized
that
there
can
also
be
a
case
where
the
counter
actually
doesn't
change,
but
you
have
received
enough
eggs
that
it
could
have
wrapped
once,
but
two
exactly
the
same
value
again
right
and.
F
C
G
So
I
mean
an
important
point
here
is
to
be
conservative,
about
the
point
that
you
get
at
congestion
notification
and
be
less
conservative
about
how
many
markings
you
had
in
case.
That
is
important.
It
is
input
to
your
congestion
controller.
So
maybe
we
can
distinguish
that
and
work
this
clearly.
Okay,.
C
C
G
G
All
right
and
then
about
the
update
section
right,
I
didn't
realize
that
much
that
it
actually
says
everywhere.
We
were
we
update
this
section
with
section
we
have
their
this
section
with
this
section
because
they
actually
don't
think
we
update
these,
the
classic
me
CNB.
Hence
we
just
add
something.
On
top
of
the
grade
now,.
C
D
D
D
C
I
admit
I
did
felt
I
filtered
out
the
length
one,
because
I
knew
that
mayor
would
originally
didn't
like
that.
One,
maybe
mayor
can
say
something
about
this,
because
it
sort
of
a
means
you
can
have
variable
so
I've
failed
and
things
like
that
and
gone
mayor.
You
originally
didn't
like
having
different
lengths
to
mean
yeah.
G
D
C
A
We
just
want
to
be
on
the
safe
side
that
possibly
we
have
no
particular
reason
we
just
so
when
we,
when
we
discuss
this,
we
we
discussed
this
before
TSV
and
we
were
hoping
things
get
cleaned
up,
so
we
are
still
hoping
that
things
get
cleaned
up
soon.
If
that
doesn't
work
out,
we
need
to
reconsider,
but
that
was
good.
That
was
my
hope.
D
H
C
I
I
do
have
a
question
to
come
back
on
that
and
in
that
you
know
if,
if
that
goes
on
and
on
in
th
eleg
I
would
like
this
to
not
hang
on
it,
because
it's
just
what
happens
otherwise
is
then
the
chair
say
well
no
one's
interested
in
this
one
anymore.
It's
been
sitting
around
for
two
years
and
no
one's
talked
about
it
and
that's
because
we're
all
waiting
for
something
you
know.
C
A
G
So
just
I
think
there
is
no
dependency
from
equities
in
to
Alverez,
but
only
the
other
way
around
so
I,
don't
think
we
have
to
hold
it
up.
The
only
tiny
little
design
decision
that
might
depend
is
like
exactly
what
we're
looking
at
right
now
with
the
order
of
the
values
in
the
option,
but
if
we
have
a
flexible
option
or
how
to
handle
it,
I
don't
see
any
stability,
yeah.
A
K
L
One
additional
thing
why
I
had
not
wanted
to
put
this
way
yet
to
upstream,
is
that
the
you
know
if
we
make
some
wire
for
my
change,
then
our
example
related
to
this
option
point
and
then
that's
of
course
problematic.
If
there
is
some
pre-existing,
they
pair
it
with
something
else.
So
so
that's
another
thing,
yeah,
so
I'm
going
to
talk
about
this
accurate,
easy
and
Linux
implementation.
L
So
if
you
go
to
the
next
slide
yeah,
so
this
was
built
on
top
of
the
earlier
work
like
Bob
said,
and
the
initially
I
started
working
with
this
when
there
were
six
zeros
seven,
that's
your
zero
nine
trust
available
and
as
far
as
I
know,
this
is
the
first
implementation
which
actually
includes
the
support
for
a
Cartesian
option
and
I
discovered
some
technical
challenges,
but
none
seemed
to
sort
of
make
the
whole
approach
non
work
up.
Also,
in
that
sense,
we
are
going
to
go,
go
with
mode
with
minor
tweaks.
L
L
L
Might
understand,
but
what
he
said
on
the
next
slide,
so
so
bubble
already
covered
some
some
of
this.
So
so,
during
a
handshake
we
we
will
see
feedback
the
feedback,
the
easy
and
easy
and
field
of
the
opposite
side
and
or
the
opposite,
handshake
pocket
so
and
and
in
in
the
zero
nine
three,
not
easy
and
easy
encode.
Both
point
was
encoded
to
third
up
of
the
three
three
three
way:
handshake
and
also
also
of
the
first
first
data
segment.
L
So
so
these
great
additional
problems
because
they
soon
be
teased
off
and
the
reliable
data
channel,
was
provided
using
this
first
data
segment
and
it
was
twelve
people
because
because
we
in
that
case,
we
would
have
wanted
to
poverty,
AC
field
ambach
critic,
so
so
that
there
is
no
different
implementations
or
all
similar
settings.
We
also
need
to
use
the
same
same
encoding
and
cemented
just
a
warning
that
we
made
also
changes
to
this
piece
in
the
track
version
10.
So
next,
like
this.
L
And
so,
first
of
all,
there
are.
This
relate
challenges
related
to
real
transmissions
in
general,
so
so,
but
partially
covered
covered
this
in
historical
also.
So
when
the
easy
encode
point
of
the
original
and
retransmit
artists
differing,
there
are
some
scenarios
that
need
to
need
to
be
handled
which
the
drug
did
not
address,
and
since
the
since
the
one
since
then
that
is
sending
the
packet
does
not
know,
know
what
the
other
and
see
so.
This
is
anything
so
in
visualization.
Its
continuity
case
is
that
it
is
not.
L
It
is
safe,
safe
and
also
the
behavior
CE
Marking
must
consider
consider
that
case.
Bertie
poly
one
one
of
those
copies
of
the
sunic,
for
example-
has
has
this
marking.
Of
course
it's
not
yet
it's
in
the
Asian
plus
past.
If
we
enable
those,
but
this
press
would
already
handle
those
cases
and
then
then
we
come
to
this
case
very
soon.
This
is
off
so
so
they
were
quite
problematic.
So
so,
first
of
all
about
the
TX
and
rx
site
require
additional
state.
L
The
record,
though
shalt
know
accurate,
easy
at
all
and
then
relatively
small
problem.
Less
related.
The
segment
is
not
working
so
those
into
reflector.
You
have
different
header
than
the
remaining
or
the
other
other
segments.
After
it,
it's
not
possible
to
tenth
the
master
senior
chunk
downwards
and
then
the
major
problem
was
related
to
TCP
fast
over
open.
So
it's
fast
open
open
can
be
sold.
L
There
are
no
third
aquatic
first
data
segment
in
the
similar
sense,
as
we
have
for
the
non
first
open
case
so
so,
and
if
we
consider
this
this
first
bullet
so
so
when
there
are
real
transmissions,
it's
hot
hot,
actually,
it's
impossible
for
the
other
end
penalty,
but
the
other
end
is
ecstasy.
So
they
cannot
really
ugly,
but
is
the
first
first
sequence
number
or
the
first
first
pocket
at
all,
because
because
they
might
have
seen
different
things
done
and
then
of
course
also
so
this
delayed
arrival
of
the
reflective
value.
L
So
it
somehow
limits
on
the
limits.
What
decisions
can
be
made
based
on
based
on,
if
so
next
class.
This
and
we
had
different,
different
or
discussed
different
solution
cities
and
tried
to
distort
sequence
numbers
and
also
discussed
about
using
option
for
this,
but
those
were
ruled
out
so
easily
may
may
the
approach
less
complex
and
it
of
course,
has
some
downs
downside.
So
so
it
makes
the
similarly
unreliable,
but
but
basically
but
it's
still.
L
Relatively
simple
so
and
the
cool
thing
is
setting,
if
we
put
it
on
the
hood,
the
reflector
on
only
to
the
turkic,
we
can
use
the
existing
state
transition
and
krieger.
So
when
we
get
tsunami
the
wanting
and
when
we
move
the
testable
state,
that's
other
transition
that
is
interesting
to
us,
and
it
means
that
we
occasion
lose
the
boosted
modeling
direction,
but
that
feature
is
not
always
of
that
features
is
not
catastrophic
view
more.
L
Problematic
case
is,
of
course,
that
it
creates
ambiguity,
so
so
there
can
be
similar
ox
ox
later
in
the
connection
so
which
looks
exactly
like
like
like
the
first
pocket.
So
so
it
might
be
possible
that
one
in
some
is
interpreting
the
H
field
in
some
cases,
but
again
it
doesn't
seem
catastrophic,
so
the
connection
does
not
die
because
of
that
and
this
approach
was
adopted
in
the
track
version.
10
so
looks
like
this.
L
And
then,
then,
the
segmentation
offloading
had
some
so
has
some
cases
it's
good
to
bring
up
here.
So
so
the
C,
where
C
TW
are
flat.
Handing
differs
from
from
that
of
tech,
three
one:
six
68
and
the
segmentation
offloading
for
port.
For
that
clear,
clear,
speak,
CW
our
flag.
After
of
the
first
segment
Silvana,
would
put
large
large
segment
ad
or
give
it
to
the
signal
offloading
hardware
which
it
takes
takes
to
see
where
or
set
to
this
CW
are
only
for
the
first
segment
and.
L
L
L
If
the
patrolling
ends
up
brushing
after
every
segment
and
then
some
thoughts
about
the
hardware,
falling
I
didn't
actually
test
test
test
with
any
hardware
offloading,
but
but
when
people
are
that
I
think
I
understand
the
program
space
so
so
to
all
of
the
hardware
learning
there
is.
There
is
flood
added
today,
scabies
and
such
that
such
that
it
can
indicate
that
accurate,
easy
and
processing
is
required,
which
is
actually
do
nothing
sort
of,
but
because
there
is
this,
existing
CW
are
clearing
thing.
We
need
to
need
to
be
prepared
prepared
that.
L
L
And
then,
then,
then,
about
the
acquisition
options.
Also,
so
the
accurate
is
an
option,
carries
this
basically
hung
by
by
something
usually
larger
counter,
so
the
transits
that
they
are
probably
twenty,
two
bits
or
or
more
and
I
have
22
bit
fields,
not
24
32
to
the
fields
for
these
counters
and
they
some
some
the
payload
by
to
receive
or
particle
easy
encode
boards,
and
since
the
equity
seein
option
is
not
always
imparted
by
the
receiver,
the
tracker
gives
a
minimum.
L
Well,
we
also
ended
when,
when
the
option
should
be
sent,
the
implementations
must
must
or
are
expected
to
estimate
it's
not
mandatory,
but
are
expected
to
sort
of
estimated
the
counters,
while
there
is
no
where,
while
there
is
Hawks
coming
in,
which
don't
have
the
equities
and
options-
and
this
requires
error
stick
to
decide
which
counter
is
going
to
be
increased
when
you
get
enough
leach
out
without
the
option
next
slide.
Please.
L
The
Trust
says
that
one
when
they,
when
the
PC
encode
born
changes
on
the
receiver
side,
you
should
create
six
entities,
equity,
see
an
option
and
the
problem
problem
with
that
is
that
since
it,
since
the
account
count
cotton
since
the
code
point
change,
you're,
actually
increasing
the
new
counter
value
R
value
on
the
earlier
axle,
you
increase,
the
other
ones.
I
realized
I
might
actually
have
problem
in
this
figure
now,
which
I
have
not
noticed.
Oh
so.
L
L
L
No,
no,
it!
Yes,
oh
no!
No,
no,
no!
Also!
The
receivers
when
it's
sending
this
option,
it
actually
has
changed.
Chains
fall
to
protect
a
DCT
one
count
right
counter
and
the
Seabright
counters.
Also
the
sending
sign
does
not
know
which
was
the
futures
discount
or
system
is
the
one
it
should
increase
when
it
gets
next
time.
T
ik
without
the
options.
Also
under
this
data
30:38
data
bucket-
and
this
is
problem
with
any
any
of
the
eight
edges.
L
So
so
so
one
point
could
built
on
heuristic,
but
it
gets
easily
lost,
even
if
you
use
one
one
data
or
one
one,
a
crack
at
it
then,
and
reverses
to
the
wrong
run
counter
on
every
change
trigger
duck
and
solve
this.
The
change
was
made
to
the
trust
so
that
so
that
the
option
is
now
required
for
the
change
we
get
up
and
then
the
next
accuser
and
after
that's
also
in
that
later
later,
on
its.
C
H
L
L
Yeah
so
also,
instead
of
using
some
Harris
to
decide,
but
the
receivers
called
the
influence.
Next,
we
included
the
equities
and
options
OVR
discount
counter
to
be
filled
into
the
option
itself.
It's
possible
to
that
use
that
value
value
to
increase,
increase
the
correct
counter
on
the
next
episode.
You
only
need
to
get
one
one
option
true
and
then
then
the
sender
immediately
knows
what
the
receiver
is
called
the
do
next.
This,
of
course,
would
create
other
possibilities
order
these
extra
extra
bits
remaining
remaining
the
one
profit
method
needs
to
create
edit
ease.
L
If
this
is
chosen
and
this
same
field
could
be
used,
for
example,
for
the
real
dollar,
and
there
are
other
possibilities
so
that
if
there
are
no
no
white
counters
included,
if
there
is
no
a
closed
system,
then
also
for
Sadiq
count
itself,
we
used
to
do
the
white
counter
switch.
So
if
there
are
any
comments
on
this
side,
would
you
like
to
like
to
hear
our
opinions.
L
L
L
This
mobility,
with
small
small
fields,
only
24
four
bits
is
that
if
psych
was
relatively
soon
so
so,
the
track
must
ensure
that
also
to
ensure
that
that
the
counters
do
not
overflows.
Also,
the
option
must
be
included
every
now
and
then
to
handle
that
case.
So
next
slide
vision
and
then
then,
then
there
is
just.
L
Hair,
stick
in
the
in
the
appendix
there's:
algorithmic
uses
this
Delta
for
the
C,
be
so
so.
This
white
contour,
Delta
Delta,
is
used
to
rule
out
the
AC
overflows
and
and
in
order
to
run
that
outer
one
actually
needs
to
have
this
Delta
Delta
available.
So
so,
and
so
it
seems
that,
from
a
business
point
of
view
that
every
every
time
take
a
spear.
This
changed
also
also
the
include
the
options
or
relative
T
V
Delta
can
be
calculated
from
from
numbers
that
are
up-to-date.
L
A
A
A
L
C
Viii
field
is
two
three
bits
and
that
doesn't
use
bite
counting
at
all,
and
the
algorithm
is
designed
to
work
with
just
that.
The
bite
counters
are
there.
If
you
have
space
for
them
and
so
sort
of
reducing
them
to
be
less
accurate
seems
to
be
a
bit
bit
of
a
sort
of
halfway
house
that
maybe
is
a
bit
too
complicated.
A
G
Should
understand
this
specific
question
about
the
option
and
I'm
not
sure
I
actually
still
forget
it
and
the
problem,
because
at
least
if
the
seee
counter
increases
in
the
option,
it
should
also
the
opposite.
A
c
e
field
should
increase,
so
you
should
be
able
to
distinguish
those
cases
which
is
the
most
common
k
trade.
So
I,
don't
I'm,
not
sure
if
the
the
problem
is
as
big
as
you
described
it
and
then,
if
we
need
a
solution,
if
I
think
it's
the
solution,
it's
fine
to
send
basically
two
more
X
with
options.
L
Yeah
well,
it's
possible
to
use
that
button.
Then
it
means
that
you
can
use
to
two
of
the
two
of
the
easy
and
third
points
to
really
really
run
this
kind
of
heuristic,
and
another
thing
is
that
there
is
this
cross-checking
between
these
fields,
so
so
on
the
if
you
based
some
checking
checking
on
the
other
and
then
the
other
way
around.
It,
of
course,
creates
this
nasty
loop
move
of
check,
so
so
I
suppose
it.
It
might
be
possible
to
use
it.
But
there
are
these
coverage,
then
I
think.
G
We
should
look
into
that
and
also
to
the
point
that
you
cannot
distinguish
ET,
c1
and
UT
secure,
so
I
just
want
to
state
again
that
I
think
the
requirements
are
that
the
base
design
guide
we
had
at
the
beginning
was
that
we
want
to
make
sure
we
don't
lose
the
congestion
thing.
So
we
don't
want
to
run
into
the
case
where
you
gotta
see
events,
and
you
don't
get
the
information
that
it
was
there
and
you
cannot
react
it.
G
So
that's
why
we
have
to
see
in
the
header
and
that's
why
it's
important
to
always
have
to
accurate
information
about
te,
and
the
other
thing
we
discussed
very
intently
at
the
beginning
is
that
we
don't
want
as
a
requirement
to
also
check
the
order
of
a
different
map
or
to
provide
the
order,
if
there's
a
side
effect.
If
you
can
get
at
this
point,
but
it
wasn't
a
requirement.
G
A
A
F
F
So
basically,
there
are
there
three
thing
that
we
need
to
address
three
categories:
one
is
some
bugs
in
this
local
arm
and
the
other
is
some
protocol
changes
in
order
to
intensive
updates
on
the
comments
and
the
last
one
are
a
lot
of
writing
suggestions.
They
need
to
your
major
smoothly
done
rightly
so.
They
sighs
in
the
first.
F
The
first
one
is
about
that
elbow
fontelle,
that
the
loss
treatments
that
is
unclear
how
that
would
actually
work
from
the
pseudo-code,
and
there
is
a
small
bug
in
the
pseudocode
that
we
need
to
define
that
when
you
are
standing
are
we
sending
a
packet?
You
need
to
mark
the
packet
off
that
forth.
Okay,
you
need
to
reset
that
mark.
So
that's
the
box,
which
we
will
correct
that
in
the
next
iteration
and
then
we
will
put
more
words
on
how
loss
of
retransmit
detection
would
work
more
because
it
was
a
busy
next
slide.
F
Please,
the
next
one
is
comments
on
Teresa
that
it's
not
clear
how
racks
can
apply
in
the
RTO
with
public,
because
the
text
suggests
that
many
diseases
change
to
the
epoch
recovery,
but
that's
actually
not
the
case.
Wrapping
for
both
photocopies
and
also
recovering
so
we're
going
to
put
more
text.
So
here
is
the
very
simple
intuitive
example
like
why
rocks
even
matter
in
akio.
We
cover
it
because,
supposedly
it's
just
a
primer
fire
and
then
you
want
the
first
pack
a
lot
right
and
if
you
transmit
that
what
will
rock
even
matters.
F
F
I
have
very
highly
respected,
you
send
another,
or
maybe
you
send
another
ten
degrees.
So
you
total
sent
a
letter
back
one
millisecond
later
the
RTO
timer
our
fires,
and
then
he
says
you
know
what
all
the
packets
are
pending
boss.
So
this
is
clearly
unlikely
on
because
you
can
send
the
last
ten
packets.
So
if
you
think
that
why
that's
unlikely-
because
you
look
at
this
transmitted
time
of
the
stack
and
many
TCP
stack-
that
we
know
didn't-
have
this
kind
of
tips
before
this
is
exactly
the
same
principle
as
back.
F
But
you
want
to
look
at
their
lock
the
most
recent
mission
time
and
now
so
you
can
judge
whether
the
package,
like
the
loss
or
not,
and
then
you
can
put
some
reordering
window
allowing
so
that's
the
change
that
rack
would
recommend.
You
apply
for
the
TCP.
We
probably
and
essentially
the
pseudocode
is
very
similar
out.
We
put
it
here,
but
you
will
share
a
lot
of
commonality.
The
main
rack
code
so
we'll
break
that
into
some
sub,
and
this
is
also
what's
implemented,
Linux
as
well,
and
we
have
found
out
this.
F
Actually,
we
use
a
lot
of
unnecessary
transmission
ring
RTO
on
so
that's
what
we
are
going
to
put
is
the
new
rack
iteration,
a
certain
religion.
Next
slide,
please
are
the
other
thing
that
many
people
will
comment
is
that
we
should
really
take
the
reordering
timer
on
the
ship
instead
of
the
main,
because
it
asked
to
improve
a
performance
and
we
are
going
to
change
that
because
we
agree
with
both
comments
and,
to
recap,
a
reordering
panel
is
to
say
all
right.
F
This
pattern
is
not
there
to
mark
as
loss,
because
what
you're
waiting
for
the
Odin
timer
to
expire,
but
of
course,
if
there
is
no
further
app
event,
then
you
know
we
will
have
to
wait
for
IPO
and
that's
the
rack
with
a
mess
in
solving
this.
We
ordering
timer
when
the
loading
window
expires,
and
it
does
help
on
improving
the
performance,
basically
in
the
application
limited
space.
F
F
One
second
or
the
five
million
ticket.
The
idea
is
to
put
this
on
the
five
new
section
so
that
when
the
timer
is
part,
many
packets
will
be
marked
as
lost
with
confidence.
It's
more
conservative-
and
we
like
this
approach,
because
even
though
that
you
make,
but
we
transmit
a
little
bit
slower
because
you
set
a
timer,
that's
more
conservative
but
since
Rack
is
about
dealing
with
the
ordering,
we
feel
a
more
conservative
timer,
maybe
slightly
loose
on
the
performance,
optimization
if
you
put
our
trade
off
so
next
slide.
Please.
F
We
will
need
to
explain
rock
and
TLP
protocol
amore
tail
instead
of
like
for
sentence.
So
that's
what
we
then
and
also
in
marketing
suggest,
is
a
tape
of
content
yeah.
But
the
trap
is
already
very
long
and
we
are
going
to
remove
that
experiment
at
performance.
Evaluation.
I
think
it
serves
the
purpose
what
it
was
a
experimental
trap,
but
now
is
the
whole
standard
attack,
so
probably
some
that.
But
if
you
are
feel
strength
that
we
should
keep
it
there
I'm
happy
to
discuss
on
the
list
well
and
just
decide.
F
F
A
lot
of
coalification
are
questions,
I
think
the
most
important
one
is
we
offer
all
the
four
authors
have
low
intention
encourage
more
network
with
ordering
we
always
out
rack,
so
the
head
step.
We
need
verify
that
that
we
use
some
words,
things
that
would
make
it
sound
like
hey,
we
introduce,
we
want
to
have
rap
so
Network,
and
we
order
stick
to
that.
No,
that's!
That's
all
not
our
instance.
Our
intention
states,
so
we
have
fun
we
order
it
exists.
We
want
to
make
it
more
robust
to
a
final
means.
F
We
want
to
import
more
we
all
day,
because
we
all
in
by
any
time
it's
really
not
going
to
do
well
for
the
performance
under
receiver.
Side
are
particularly
so
we
will
be
more
explicit
on
that.
The
other
is
people
are
kind
of
consuming,
weeding
through
detector.
So
what's
the
dependencies
between
GOP
rag
fatty
set
limited
princess,
it's
like
all
over
the
place.
So
here
is
this
rap
requires
back
your
peewee
part
rack.
F
When
I
say
Seop
was
rather,
it
is
type
of
intimacy.
Opie
without
rocks.
Other
comes
with
a
lot
more
at
acuity
and
a
lot
more
complexity,
because
that's
what
we
did
in
Linux
before
and
then
we
decided
to
get
rid
of
that
part,
because
it's
just
the
words
that
complexity
in
the
SAP
to
deal
with
kind
of
like
outdated
stacks
that
doesn't
support
stack.
F
So
another
one
is
about
exact
and
limited.
For
instance,
they
are
both
are
recommended,
but
if
the
facts
do
not
support
that,
it's
okay,
also
more
clarity
about
our
rack.
In
judgment
of
loading
window,
for
example,
a
TCP
segment
of
rolling,
with
funky
mini
package
into
one
drop
of
young
bowls
with.
So
how
do
we
handle
that
in
more
clarity?
So
we
will
do.
That
also
is
how
the
wielding
Tyler
we
talk
about
how
we
setup
it.
But
how
do
we
cancel
those
timers?
F
So
these
are
also
important
and
then
the
nothing
is
from
the
rack
wielding
window.
We
say
initially
started
with
the
order
of
RTP,
but
if
not
we
ordering
is
detected
is
now
we
use
to
zero
and
then
how
does
that
really
work
with
that?
Oh,
we
can
also
use
super-stretch
and
the
text
is
just
not
clear
how
all
this
interacts.
So
we
are
going
to
clean
that
up
too
and
make
sure
we
clarify
how
rack
uses
or
implemented
incest.
Oh
you,
whiskey.
Next
slide.
Please.
F
F
All
this
multi
public
or
don't
work
without
citing
any
scientific
Sun
or
things
classified.
Oh
there's,
a
prevalent
of
Wall
Street
positions.
There
are
a
lot
of
pottery,
are
probables
comments,
all
that
we
will
remove
and
make
sure
that
we
don't
sort
of
touch
this
kind
of
thing
without
data,
if
anything
will
say
rubbish
to
deal
with
orderings
right,
an
unsub
network
that
we
already
could
be
very
prevalent.
F
And
our
there
are
also
things
like
offering
unclear
of
options
like
rock
candy,
Sacramento,
rock
and
optional,
or
some
people
can
be
optional
and
but
then
with
a
rack
requires
certain
stuff
to
happen,
which
does
create
confusion.
So
we'll
cut
those
text
out
and
then
there
is
like
warding
off
o.
The
underlying
networks
may
introduce
more
wielding
and
that
may
may
be
interpreted
differently
like
we
encourage
to
do
more
reorder.
That's
really
not
our
intention.
So
we'll
drop
all
these
text
objects
so
that
we
don't
create.
F
So
that's
my
last
slide
and
I
want
to
thank
all
the
viewers.
It
is
not
listed,
but
really
a
episode
is
very
thorough
review
and
we
are
going
to
do
majors
literally
on
the
text,
hopefully
soon
and
then
address
all
the
comments
individually
from
the
on
the
email
and
if
you
have
more
comments,
feel
free
to
send
us
your
comments
and
that's
it.
Thank
you.
Thank.
A
A
Then
I
would
say
sink
it.
Thank
you
I'm
Neutron,
and
we
are
looking
forward
to
getting
an
updated
document.
Thank
you
very
much.
So
this
concludes
the
part
on
of
working
group
documents
and
we
are
still
over
time.
So
if
you
can
speed
up
your
presentation,
it's
appreciated
the
next
one
is
marsh
about
yang
model
for
CCP.
J
J
J
J
The
updates
in
3
&
4
include,
of
course,
the
fact
that
we
now
officially
support
the
nmda
portion
of
a
yang
which
essentially
introduced
to
new
data
stores,
the
ones
in
blue.
They
intended
an
operational
data
store.
This
is
more
for
informational
purposes,
not
that
it
impacts
significantly
the
model
other
than
the
fact
that
all
new
models
need
to
support
it
and
that
they
don't
need
to
replicate
operational
parameters
in
a
separate
container.
J
The
second
update
essentially
defined
the
scope
of
what
we
wanted
to
include
in
the
model
it
we
wanted
it
to
be
more
than
just
groupings,
and
the
proposal
was
and
that
vehicle
into
more
detail
in
subsequent
slices.
What
we
wanted
to
include
as
a
result
of
that
change
next
slide,
please
alright,
so
coming
into
106,
what
we
were
going
to
propose
was
that
was
for
items
that
we
wanted
to
define
the
scope
or
the
Strand.
J
The
first
one
is:
should
the
model
support
TCP
statistics,
the
second
of
courses
should
have
model
all
TCP
connections
and
because
the
third
vote
is
what
security
options
should
be
support
for
TCP,
so
we
took
a
stab
and
we
actually
went
out
and
plugged
it
added
that
support
in
zero.
Four
and
I'll
discuss
the
rationale
for
each
one
of
them
in
sort
of
conflict.
J
J
J
The
second
question
is:
should
we
model
all
TCP
connections
so,
if
left
to
not,
if
he
decided
not
to
model
TCP
connections
and
the
applications
that
needed
to
look
up
a
TCP
connection
would
then
mode.
Therefore,
the
modeling
would
get
distributed
in
different
models.
Other
young
models
that
wanted
to
look
at
TCP
connections
so
best
thing
was
for
us
to
consolidate
it
in
one
place.
J
So
this
is
a
issue
that
is
new
and
the
attracting
they
say.
As
part
of
the
draft
is
today
that
TCP
common
grouping
is
which
goes
defines
the
configuration
/
TC
keep
lights
is
defined
in
another
draft,
which
is
being
tracked
in
the
networking
group,
and
so
it's
an
open
question
to
this
working
group,
but
they
would
like
to
have
it
moved
to
this
working
group.
J
The
pros
is,
of
course,
that
guess
the
common
looping
then
becomes
part
of
the
young
model.
The
downside
is
that
today
the
fedcon
is
already
made
quite
a
bit
of
progress
on
that
draft
and
is
ready
to
close
to
publishing
it.
If
we
decide
to
move
it
into
the
TCP
yang
model
of
person
of
Cozumel
s2,
all
the
existing
that
contrasts
at
references,
but
also
delay
I
guess
will
put
more
pressure
on
publication
of
the
TCP
yang
model.
J
All
right
with
that
said,
let's
move
quickly
into
I
think
what
should
be
the
last
slide
yeah.
So
why
are
we
asking
for
the
group
adoption?
Well
clearly,
there
is
a
use
case
today.
The
BGP
n
model
is
already
incorporated.
The
draft
version
of
the
young
model,
the
TCP
and
model
for
authentication
purposes,
and
also
because
of
the
authors,
have
believed
that
the
model
has
it
is
being
presented
is
fairly
mature,
or
at
least
the
work
that
should
continue
going
forward
should
be
happening
in
the
workgroup
and
therefore
we
are
asking
for
workgroup
adoption
question.
A
D
Mean
therefore,
for
this
modeler
to
use
cases
in
the
net
control
can
group,
and
you
want
the
net
core
model
at
the
moment
is
independent,
or
this
is
where
to
keep
alive
exist.
As
far
as
I
understand,
there
is
commercial
interest
in
configuring
keep
alive
through
a
yang
model,
but
that
is
at
the
moment
outside
the
specific
model
here
other
than
that
at
the
moment.
I'm
not
aware
of
any
implementation
with
doing
this
right
now,
but
given
that
this
relates
to
to
other
working
groups,
of
course,
being
implementation
sooner
or
later
could
emerge.
D
Of
course,
I
mean
I've
said
this
many
times
on
the
mailing
list.
It's
relatively
unlikely
the
typical
host
operating
systems,
value
with
en
for
TCP
configurations
or
this
mobile
by
and
large
targets,
probably
TCP
stacks
on
devices
that
you
will
see
is
for
configuration
already
water
purposes
such
as
routers.
G
Guess
I
think
I
had
I
think
I
still
in
our
question:
I'm
relatively
new
to
this
work,
because
I
think
it
doesn't
hurt
we
but
like.
If
we
adopted,
we
have
to
make
sure
that
the
model
is
correct
and
that
needs
a
little
work
and
it's
a
little
bit
of
interest
in
people
that
needs
commitment
for
people
to
do.
The
work
and
I
do
have
the
feeling
that
we
should
rather
try
to
finish
up
the
work
we
already
have
on
our
places
for
what
it
does.
This
is
a
light.
D
It's
a
little
bit
concerned
about
whether
this
this
work
is
doable,
which
is
a
regional
commensurate.
The
the
two
options
that
the
working
group
has
is
either
to
focus
this
model
relatively
narrowly
and
mostly
to
what
Mahesh
has
presented
right
now,
and
so
this
would
be
the
basically
the
model
attribute
that
are
needed.
In
other
words,
the
other
solution
is
to
basically
extend
the
model,
for
example,
or
standard
TCP
stack
configuration
in
past
meetings.
They
have
been
from
the
floor.
D
H
Is
a
response
that
50
is
in
this
video
I
would
encourage
the
working
group
to
focus
on
to
focus
the
work
on
know
these
cases.
You
know
a
couple
things
here
and
there
they're
easy
to
add
in
the
time,
but
this
is
a
potentially
very
large
project.
Tcp
configuration
space
is
massive
and
I
don't
want
to
spit
it.
Some
cycles
on
stuff
that
that
has
no
deployment
path.
H
A
N
At
this
is
praveen
today
to
talk
about
rice,
our
plus
plus,
we
have
posted
a
new
draft
version
of
this
version.
Three
recently
incorporating
some
feedback
next
slide.
Please
there's
a
quick,
so
the
problem
is
that
the
traditional,
slow
start
can
overshoot
the
ideal
centroid,
and
this
causes
massive
loss
on
the
bottleneck
buffer
and
for
neck,
and
then
we
spent
several
ITT
is
recovering
from
those
losses.
The
goal
is
to
reduce
those
losses
and
read
resulting
retransmission
timeouts
that
can
cause
a
problem
slow
completion
time.
N
So
this
is
based
on
the
original
high
start
paper,
but
which
is
only
the
delay
increase
algorithm
and
we
compensate
for
premature
exit
from
slow
start.
That
can
happen
as
a
result
of
delay
increase
for
that
we
start
using
limited,
slow
start,
which
provides
us
a
faster
ramp
compared
to
what
just
congestion
avoidance
would
have
done,
but
we
take
the
maximum
of
both
so
that
on
long
you
know
band
links.
We
can
get
better
performance
if
the
connection
runs
longer
nextly,
please
so
this
is
some.
N
Was
data
I
presented
the
lab
data
very
quickly
at
the
last
IETF
but
ran
out
of
time,
but
we
also
got
some
fraction
data
as
well
as
very
recent
about
these
numbers
like
two
days
back.
This
is
basically
every
connection
on
on
a
Windows
system.
We
were
doing
an
a/b
test.
This
includes
connections
that
are
primarily
download
as
well,
which
is
why
99%
of
connections
actually
have
very
few
out
use,
but
we
still
see
the
graph
shift
to
the
left.
N
So
we
have
fewer
out
here
so
about
0.6,
for
connections,
went
from
1
or
2
to
0
at
use
of
a
lifetime
and
point
7
connection
percent
connections
went
from
30
used.
One
out
you
to
trend
continues,
so
we
are
also
looking
at
other
metrics,
possibly
like
success,
percentage
of
loss,
recovery,
etc.
This
is
pretty
difficult
to
do
in
the
wild,
because
it's
not
like
one
workload,
it's
not
a
single
work,
but
it's
basically
just
all
TCP
connections
period.
So
this
is
ongoing
work
and
we'll
have
moved
it
over
time.
N
We
also
have
lab
data,
which
actually
shows
very
excellent
results.
So
this
is
just
with
simulating
loss
and
latency
on
basically
trying
to
simulate
van
links
and
seeing
performance
improvements
for
in
both
the
goodput,
and
we
are
also
seeing
a
lot
of
retransmission
timeout
reductions
across
all
the
tests.
Next
slide,
please.
N
So
we
already
had
a
few
reviews
thanks
to
all
the
reviewers
so
summary
of
changes,
we
had
to
clarify
the
relationship
with
ABC
the
trifle
sort
of
assuming
that,
but
we
didn't
call
it
out
yeah,
so
we
actually
have
now
incorporated
text
saying
that
this
is
to
be
used
with
appropriate
weight
counting.
We
also
clarified
when
exactly
the
algorithm
ends,
which
is
upon
encountering.
N
So
this
is
deployed
pretty
widely.
We
are
looking
into
future
optimizations,
like
maybe
using
bandwidth
or
throughput,
estimate,
to
make
this
better.
Instead
of
just
using
a
delay
signal,
that's
ongoing
work
and
then
future.
We
would
like
to
compare
all
the
possible
options
for
first
start
up
and
do
some
sort
of
a
B
testing
to
see
what
kind
of
results
we
can
get
from
that,
and
then
my
request
would
be
that
we
adopt
this
document
in
TCP
M.
N
N
G
N
Right
correct:
what
ends
up
happening
is
that
there
is
there's
less
loss
right,
so
we
spend
fewer
RTT
is
actually
spending
time
recovering
from
those
losses
and
also
the
the
congestion
window.
For
example
like
if
we
took
on
a
party
or
if
the
loss
was
massive,
then
we
would
actually
take
a
retransmission
timeout,
which
would
basically
drop
the
congestion
window
down
to
like
one
packet.
So
we
avoid
all.
F
G
N
A
A
H
N
A
A
B
I'm:
fun,
I'm;
okay,
yes,
okay,
okay,
so
one
thing
you
know
if
we
think
from
a
smell
and
you
don't
have
to
be
gripped
the
comment,
no,
because
it's
just
what
from
the
Microsoft
is
doing.
But
if
we,
you
know
change
this
data
for
experiment
or
you
might
seriously
need
to
think
about,
incorporates
a
comments
from
the
people
idea,
if
you
say
so,
doesn't
change
the
road.
If
you
have
to
see
us
to
think
about
a
change,
ROG.
H
H
A
P
Hello,
hello,
okay,
so
this
talk
is
about
reducing
the
acknowledgement
overhead
for
the
transports.
Most
of
the
work
that
we
had
done
was
in
context
to
was
not
in
context
the
TCP,
but
on
a
UDP
based
transport,
but
some
of
the
observations
that
we
caught,
we
thought
we
might
be
able
to
put
poured
into
TCP
as
well.
So
next,
like
this.
P
So,
in
the
context,
Wireless,
the
cost
of
transfer
frame
transmission
is
a
significant,
regardless
of
its
size,
so
the
interface
spacing
is
much.
It
causes
most
of
the
old
height
and
even
though
the
actor
at
packet
size
is
small,
it
still
has
a
major
impact
on
the
other
control
overhead,
as
well
as
on
the
other
wireless
spectrum.
So
this
this
problem
is
further
exasperated
because
of
I.
Add
the
newer
Wi-Fi
specification,
especially
like
Kato
2.11,
III
and
Y
pi/6,
which
which
has
much
faster
fire
rate
and
it
sort
of
accentuates
the
problem
next
slide.
P
So
I
mean
our
scenario
was
very
straight
forward:
winning
wave,
and
so
it
did
not
evolve
into
at
the
end-to-end
path
was
working
single
half
we.
We
tried
solving
the
problem
for
for
a
specific
scenario
where
we
have
a
phone
and
we
were
doing
the
wireless
protection
to
a
television
or
the
most
of
the
transfers
were
for
the
local
transport.
So
what
we
were,
what
we
found
that
TCP
a
was
resulting
in
lot
of
back
overhead,
and
this
was
degrading.
The
word
all
good
put
off
the
of
the
link.
P
We
thought
whether
it
would
be
possible
for
us
to
improvise
existing
t
sicne,
and
we
try
to
check
what
the
knobs
are
and
we
couldn't
find
any
I
mean
we
could
find
some
of
some
of
those,
but
it
couldn't
give
us
the
kind
of
expected,
a
connection
that
we
were
hoping
for
and
that's
where
that's
where
we
decided
to
do
something
about
it.
Next,
like
X
like
this.
P
So
at
that
there
are
just
two
ways
of
producing
back:
when
is
my
byte
counting,
AK
or
ABC,
and
that
is
a
periodic
AK.
So
essentially,
what
our
proposal
is
the
combination
of
these
two
and
how
do
how,
in
what
context
to
be
made
use
of
which
which
one
to
be
used
of
in
what
context?
That
is
basically
the
fundamental
point
here.
P
There
is
another
aspect
where
there
is
a
loss,
in
which
case
just
like
what
does
quick
requires
you
to
just
transfer
that
act
as
soon
as
you
receive
an
out-of-order
packet,
so
we
handle
it
that
way,
but
essentially
it
is.
The
things
are
normal.
If
there
is
less
loss
right,
then
it's
essentially
the
choosing
between
byte,
counting
and
versus
the
periodic
at
next
like
this.
P
So
this
is
what
this
is,
what
we
attempted.
So
if
the
bdp
is
smokin,
eventually
the
bite
counting
AG
gets
boost,
and
if
the
VDP
is
large,
virtually
the
periodical
act
gets
used.
So
what
happened
is
with
it
with
me.
Let
me
be
clear:
wireless
standards,
the
PDP
is
significantly
increasing
and
if
the
midi
P
is
increasing,
then
naturally
it
results
in
more
more
amount
of
Acts
getting
generated.
P
We
wanted
to
limit
this
act
by
making
use
of
periodical
act
rather
than
sending
act
on
per
on
every
a
based
on
byte,
counting
at
the
next
point
is
triggering
acts
for
an
out
of
order.
Data
reception.
This
is
this
is
the
well
known.
This
is
how
it
is
handled
in
Coke
already,
so
we
followed
the
same
and
mechanism
in
lecture
piece,
so
this
this
graph,
this
this
diagram
shows
you
how
much
of
a
reduction
in
terms
of
act
we
will
be
able
to
achieve.
P
P
The
good
put
improvements,
so
this
is
the
graph
on
the
left
hand,
side
shows
the
good
put
improvement.
This
is
the
difference,
a
difference
between
the
type
versus
the
tcp,
so
it
what
it
shows
essentially
is
equals
an
aggravated
ethical
matter.
It
has
a
good
impact
on
the
overall
good
food
of
cities
or
of
the
overall
transport.
P
P
They
may
not
necessarily
be
productive
in
all
the
situations
with
one
we
are
trying
to
see
next
slide,
please
so
one
that
naturally
arises
is
what
is
the
lower
bound
for
acts
which,
which
is
which
is
possible?
So
there
is
a
seminal
work
in
Sikkim,
basically,
which
says
that
the
middle,
a
minimum
of
two
acts
are
required
percent.
We
do
so,
ideally
in
ideal
condition
that
should
work
that
that
meant
that
that
might
work
without
much
impacting
the
to
the
transferred
performance
at
that
four
acts
is.
P
P
So
some
of
the
side
effects-
that
is
the
the
is
this
the
side
effects
of
the
ACT
inning
are
widely
documented
unit,
has
impact
on
loss
recovery.
It
has
a
contrast
with
burstiness.
In
fact,
in
fact,
the
bursts
are
significant.
A
one
of
the
side
effect
that
we
saw
was
if
the
burst
increases.
Eventually,
it
results
in
much
better
Wi-Fi
aggregation
at
the
lower
level.
P
That's
a
side
effect.
Having
said
that,
I
understand
that
this
is
not
a
gentleman
statement
it
has,
and
it
has
a
positive
impact
in
a
particular
context
whatever,
but
but
but
what
it
say
or
what
it
means
is.
It
still
has
positive
impact
in
at
least
some
in
some
context,
after
which,
here
it
is
possible
for
us
to
set
connection
specific
parameters
to
handle
such
kind
of
scenario.
P
Another
problem
that
we
faced
was
the
RTD
estimation,
so
naturally,
with
pure
number
of
I
acts
that
atieast
amasian
will
will
have
an
impact
ITT
minimum
minimum
vertical
summation
will
have
an
effect,
especially
under
under
the
conditions
where
there
is
high
jitter.
The
distance
between
the
two
devices
increases.
It
has
a
much
bigger
impact.
There
was
something
that
we
experimented
with
will
be
making
use
of
one-way
delay
and
then
approximating
it
towards
targeting
main
while
it
works
in
near
symmetric
cases,
it
might
not
work
in
asymmetric
cases.
So
it's
again,
it's
not
a
generalize.
P
It's
a
specific
specialized
solution
for
a
specific
problem
statement
that
you
are
trying
to
solve
an
X
like
this,
so
there
is
already
existing
work
at
IDF.
That's
happening,
I
wanted
to
compare
it
with
what's
happening.
Maybe
this
this
this
part
we
can
just
skip
over
X
already
there
on
the
mailing
list.
P
So
what
do
we
bring
to
the
working
group?
So
we
wanted
to
bring
our
data
set
to
the
working
group
saying
that
you
know
there
are
so.
There
are
certain
initials
which
may
not
make
sense
in
specific
scenarios
where
there
are
certain
techniques
which
can
be
used
which
can
improvise.
On
the
estimation
of
RTT
mean,
for
example,
there
are
certain
techniques
which
would
be
used
to
reduce
the
bus
stages
of
traffic.
Of
course,
spacing
can
be
used
and
PC.
P
C
So
yeah
I'm
happy
to
let
you
finish,
but
if
you're
finished
I
actually
came
in
just
saying
wanting
to
say
you
know,
we
have
to
be
very
careful
that
we
don't
aim
for
speed
in
over
latency
and
but
I.
Think
I
guess
that's
obvious.
I
guess.
The
other
point
that
I
wanted
to
make
was
that?
Okay,
where
can
you
go
back
to
previous
slide
with
it
I
think
I
can't
I,
don't
know
whether
it's
bigger
to
the
one
before
anyway,
the.
C
O
In
front
of
the
queue
here,
because
what
was
jumping
in
front
of
me,
first
I'm
observed
that
you
have
missed
the
xec
in
your
list
of
previous
work.
So
that's
basically
the
explicit
weight
that
sander
can
ask
a
receiver
to
to
thin
out
the
acknowledgments.
So
maybe
a
good
idea
to
look
at
this
as
well
and
also,
basically
in
contraction
what
the
Bob
already
said.
It
appears
to
me
that
you're,
looking
primarily
primarily
into
web
type
traffic,
the
objects
get
get
forwarded.
O
P
N
P
Not
tak
every
two
packets,
but
still
the
acting
read
at
reduction
even
after
even
after
the
underlying,
is
not
to
an
extent
where
it
actually
has.
So
we
see
that
there
is.
It
is
possible
to
further
reduce
the
role
overall,
a
quantity,
so
there
is
Wi-Fi
aggregation,
also
down
the
down
the
line
which
which,
which
will
be
the
cabbage,
will
result
in
coalescing
of
packets,
but
the
impact
that
it
has.
P
So
what
happens
is
what
we
found
is
if
the
transport
layer
is
not
in
control
of
this
reduction,
while
some
other
layer
is
doing
it
and
they
have
so
much
negative
impact
on
the
overall
behaviors,
then
then,
then,
so.
This
is
something
that
you
know.
I
think
we
should
have
put
more
objectively
in
the
character,
so
yeah.
K
K
A
M
M
Okay,
so
the
latex
is
a
mechanism
intended
to
reduce
protocol
overhead.
However,
in
some
cases,
delayed
act
may
also
be
detrimental
to
performance,
for
example,
when
a
salmon
carries
a
penalty
of
up
to
1m
stairs
and
the
message
is
not
release
it
in
a
briefly
response
and
a
second
data
segment
is
not
sent
earlier
than
the
delayed
octamer,
then
the
result
is
the
AG
get
necessarily
delayed,
which
entails
a
number
of
negative
consequences
and
also
a
sender
may
want
to
override
or
restore
use
of
the
late
part
of
the
receiver.
M
M
About
the
issues
due
to
delayed
acts,
we
have
identified
issues
in
full
name
areas,
but
for
this
slow
start,
where
congestion
window
growth
by
up
to
one
Center
NSS
per
every
act
that
covers
real
data.
That's
always
the
red
X
reduces
number
of
acts
received
by
the
sender
than
reducing
the
rate
of
congestion
with
low
growth
and
the
whole
increasing
transfer
time
decreasing.
Throughput
ABC
might
be
a
solution
to
this.
It's
already
supportive
in
several
implementations.
M
A
third
area
of
issues
is
IOT
where
it
disappears
increasingly
being
used
and
the
IOT
devices
are
significantly
resource
constrained.
So
a
sender
may
not
be
able
to
relate
memory
resources
until
the
corresponding
packet
arrives,
and
this
may
be
an
issue
for
very
constrained
devices
eventually
leading
even
up
to
packet,
drops
also
many
of
the
devices
Wireless
and
run
on
simple
batteries.
So
a
sender
may
need
to
stay
with
the
radio
interface
enabled,
which
consumes
energy
until
the
acrylic
ack
arrives.
M
Finally,
a
fourth
area
of
issues
is
that
we
might
want
to
enable
a
transmission
behaviors
beyond
the
traditional
ones,
for
example,
there's
congestion
control
for
eggs
in
RFC,
56,
9
t
and
also
there's
scenarios
with
pass
symmetric
capacity,
where
the
emperor
will
rate
limits
forward,
pass
performance
and
in
some
technologies
such
as
taxis,
mobile,
cellular
and
others.
While
this
is
kind
of
mitigated
by
applying
exhaling,
but
then
this
is
out
of
the
control
of
the
TCP
endpoints
next,
please.
M
So
we
have
derived
the
number
of
requirements
for
a
potential
solution
to
control.
The
latex
first
is
the
descender,
but
mechanism
should
be
sender
trigger
no
control,
because
the
assumption
is
in
their
nose
when
you
laid
eggs
should
be
overridden.
Then
we
stand
that
the
mechanism
should
work
at
the
persimmon
granularity,
as
even
within
a
connection.
Perhaps
this
big
traffic
and
for
part
of
it,
the
attacks
work
is
intelligent
for
the
rest,
maybe
not.
F
M
Also,
the
new
mechanism
should
have
as
good
below
box
traversal
properties
as
possible,
and
it
should
allow
a
safe
return
to
normal
delay
tax
operation.
Also,
it
should
minimize
impact
on
existing
or
future
TCP
functionality,
and
we
understand
we
should
avoid
hacks.
The
sleeve
is
about
optimal
and
performance
issues,
and
also
we
may
want
to
consider
using
controls
is
the
receiver
may
be,
can
unhonored
the
behavior
is
at
the
center
and
then
there's
a
ridge
of
possibilities
of
what
can
happen
at
that
moment
shut
up.
So
next,
please.
M
Well.
We
have
also
collected
a
number
of
potential
solutions
that
have
been
suggested
since
we
started
working
on
this
space,
so
the
first
is
acts
CC
where
the
sender
tells
the
receiver,
which
is
the
ad
ratio
to
be
able
to
access
C
uses
to
do
TCP
options
for
that
and
well.
We
want
to
maybe
take
into
account,
which
is
the
impact
of
the
overhead
of
that
and
also
little
box
traversal
of
duty
see.
The
options
is
often
regarded
as
bad,
then.
M
M
New
actual
option
having
similar
semantics
as
the
Apple
flag,
alt,
another
approach
would
be
reusing,
existing
TCP
header
fields.
However,
then
progress
that
semantics
may
become
overloaded
and
finally
well,
there
are
hacks
which
entail
some
performance
issues
and
also
cleanliness
issues.
So
next
please:
well,
we
have
summarized
the
solutions
and
there
whether
they
satisfy
our
satisfactorily
address
the
requirements
and
well.
The
main
conclusion
is
that
no
ideal
solution
appears
to
exist
at
the
moment.
There's
a
number
of
trade-offs,
so
X,
please.
K
K
So
so
what
I'm
saying
that,
because,
as
well
that
was
put
up,
I
was
very
much
opposed
to
it,
and
there
was
one
or
two
reasons
why
that
document
made
a
good
RFC.
The
list
of
issues
I
saw
in
the
first
issues
list.
I,
don't
believe
you
I,
don't
believe
that
these
are
real
issues,
I'd
like
to
discuss
those
on
the
list
and
because
things
vary.
This
is
this
is
something
I
think
that
is
dangerous
to
pursue
and
I
think
we
need
to
talk
much
more
about
it
before
you
consider
working
group
adoption.
A
C
A
good
point
in
help
submit
it
was
me
that
originally
suggested
picados
that
he
turns
his
proposal
for
the
airport
thing
into
a
requirements
document
on
the
basis
that
so
many
people
were
saying.
Oh
I,
don't
like
this
mechanism.
I
prefer
this
one,
and
it
was
no.
No
I
prefer
this
one.
What
about
this?
One
I
thought!
Well,
you
know
we're
never
going
to
get
through
this.
C
Why
don't
we
do
what
colors
have
started
to
do
here
so
I
hope
people
like
the
approach
of
trying
to
pull
together
everyone's
ideas
as
to
what
we're
trying
to
do
before
we
try
and
solve
the
problem
and
that's
what
I
particularly
would
like
I
adopted
by
the
working
group.
If
you
like
it,
whether
this
draft
itself
is
ready
for
adoption,
I
think
it's
a
good
start,
but
I
that
I.
A
F
Agree
there
is
a
lot
of
it
could
be
done
on
the
axe,
but
I
think
I
also
want
to
second
go
is
that
you
know
we
need
to
you
know
on
there
at
like
two
traps
on
this
right,
and
they
are
somewhat
don't
have
only
compliment
each
other
so
which
is
step
back.
Look
at
the
traps
in
detail
and
then
discuss
before
we
rush
to
adoption.
O
So
this
is
Richard
or
one
last
comment.
We
have
had
the
experience
that
that
this
problem
of
delayed
eggs
and
though
certain
circumstances
really
is
a
major
latency
issue
and
so
I'm
more
in
the
camp
of
having
the
ability
to
do
something
about.
This
would
be
good,
so
I'm
not
saying
that
that
one
or
the
other
solution
is
better
or
proper,
but
I
think
we
need
to
have
the
discussion.
A
Microtube
hasn't
any
video
I
agree.
We
need
the
discussion
on
the
mating.
This
comes
we're
two
minutes
overtime
already,
but
Richard.
If
you
say
you
have
experienced
this,
it
would
be
really
great
if
you
could
provide
some
information
about
the
scenario
on
the
setup
or
whatever
you
are
experienced
movies.