►
From YouTube: Behavioral model WG Weekly 20220314 (March 14, 2022)
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Probably
time
them
out
up
to
some
point,
but
the
point
is
you
can't
even
set
it
on
the
first
pin
because
the
you
don't
know
when
the
second
pin
is
going
to
come
along.
So
that's
one
thing
or
you
can
close
the
one
direction.
That's
an
option.
You
could
close
that,
but
you
would
still
have
the
other
one
open
and
you'd
have
to
close
it
completely,
and
you
know
the
only
reason
you
do
that
is
to
save
space.
A
Tcp
to
force
something
to
close
period
is
to
send
a
reset,
and
then
there,
if
you
do,
then
the
both
directions
have
to
be
shut
down
immediately.
But
but,
if
you're
sending
a
fin,
you
have
to
wait
for
the
other,
the
application
to
end
its
it's.
What
it's
sending
and
then
send
its
own
pin
and
then
you
could
set
a
timer
waiting
for
the
ack
to
come
back.
A
D
D
D
A
If
we
write
the
behavior
model
and
it
closes
it
based
on
the
fin
and
storing
the
sequence
and
it
closes
it
based
on
that,
that
is
the
correct
behavior,
whether
you
implement
your
closing,
based
on
how
your
hardware
is
optimized
based
on
a
timer.
I
think
it's
good
discussions,
but
remember
the
behavioral
model
is
not
an
implementation.
It
is
what
drives
the
test
cases
right,
but
it's
not
the
implementation.
You
might
say
these.
A
My
hardware
just
doesn't
support
that,
I'm
going
to
use
timers
and
when
we
test
it,
if
it
tests
properly-
and
you
know-
closes
connections
properly,
we
don't
care,
but
when
we
model
it,
I
don't
think
we
should
model
it
as
as
us.
You
know
necessarily
as
a
set
of
timers
the
way
it's
being
talked
about,
because
it's
too
close
to
your
implementation,
it
should
be.
We
know
how
to
close
the
one
direction
down.
We
know
how
to
do
it
with
sequence
number.
We
know
it
will
test
properly.
That
way
we
add
timers.
A
A
A
A
So
not
as
yes
and
no
yes
for
the
most
part,
but
think
about
it,
though
a
rule
is
setting
also
is
followed
by
what
you
need
to
encap
with,
if
I'm
or
decap,
with
two
different
actions,
two
different
things
so
like
there
are.
There
are
variances
between
the
the
receiving
the
transmit
the
rules
on
timers.
You
have
to
have
to
be
the
same,
but
there
there
are
differences
in
the
rules,
at
least
in
the
in
caps
and
and
how
you
do
that.
D
But
that
is
the
that
is
separated
out
right,
general.
We
are
talking
about
complete
table
of
load
and
not
something
which
is
a
flattened
cash.
So
if
it
is
a
flattened
cache,
yes,
you
would
have
different
rules,
but
if
you're
not
talking
about
a
flattened
cache
here,
the
flow
cache
is
not
does
not
have
details
on
your
end
cap
dcap,
because
that's
in
separate
tables.
C
So
definitely
agree
that
you
know
from
the
application
point
of
view,
it
is
required
for
the
application
to
close
the
connection
and
the
direction
comes
into
picture
for
sure,
and
for
that
reason
we
have
to
keep
it
as
generic
as
possible
from
the
behavioral
point
model
point
of
view,
and
as
long
as
the
timers
are
settable,
the
application
will
be
able
to
set
it
according
to
what
it
may
need.
No.
D
This
is
not
the
application
setting
it
reshma,
like
you
know,
that's
the
thing
right.
This
flow
cache
like
even
in
our
device.
You
know
how
long
you
set
this
absolute
timer
or
replenishing
time.
It
is
a
policy
on
the
infrastructure
side
as
to
like
how
long
they
want
to
allow
any
connection
to
be
alive
and.
A
D
A
A
A
B
F
B
B
A
A
B
A
Well,
that's
that's
what
we're
talking
about
we're
talking
about
how
to
close
a
connection
so
john
sent
an
email
itemizing,
the
different
things
that
can
happen
and
why
you
need
to
close
in
a
particular
way,
and
this
stuff
is
documented
out
there
I
mean
I
was
reading
the
same
book
as
he
was
reading.
It's
all
old
stuff
right.
So
what
we're
trying
not
to
do
is
to
build
a
behavioral
model
that
doesn't
reflect
the
air
estates
or
not
even
error.
You
can
get
out
of
order
packets
and
not
only
that
you
can
get.
A
A
It
comes
back
as
an
act
then,
when
the
application
closes,
it
will
send
the
pin
hack
after
the
fact,
and
it
could
receive
multiple
acts
for
previous
frames
in
the
meantime,
even
before
it
sends
out
the
pin
act
so
and
it's
even
possible
if
it
was
fast
enough
that
get
an
act
after
the
thing
comes
up,
so
all
of
those
cases
actually
exist
in
real
life.
So
what
john
was
saying?
Itemizing
is
there's
a
way
to
cover
these
cases
and
where
all
of
these
things
will
happen.
A
And
then
just
give
one
second,
and
then
he
did
bring
up
an
email.
Just
like
I
read
too
the
fin
act
comes
later.
You
know
it
could
come
very
quickly,
but
it
may
come
after
they
finish
sending
their
packets,
which
means
later
so.
In
the
meantime,
the
reverse
direction
is
still
valid
and
flowing
until
it's
till
that
time
and
which
means
that
those
things
are
dislocated
for
a
time.
You
can
close
the
one
direction,
but
you
can't
close
the
other
direction.
A
We
may
use
a
timeout
for
that
in
case
it
doesn't
close
properly,
or
we
also
know
that
we
can
at
any
time
receive
a
reset
when
either
side
thinks
when
either
side
thinks
anything
has
gone
wrong.
They
can
send
a
reset
and
then
then
that's
a
different
occasion.
Now
you
have
to
you,
have
to
shut
both
directions
down
because
you're
not
allowed
to
say
anything
anymore,
reset
buttons,
I'm
no
longer
in
sync.
I
can
no
longer
guarantee
that
I've
received
everything,
so
you
send
a
reset.
You
shut
it
down
immediately.
A
So
all
of
those
things
he
talked
about
those
things
in
his
email.
What
we're
saying
is
we
need
the
behavioral
model
to
do
to
have
the
code
to
deal
with
it
like
he's
talking
about.
It's
not
like
a
behavioral
model.
Isn't
a
high
level
good
path.
It's
the
it's
all
of
this
and
that's
what
we're
trying
to
get
to
and
that's
why
we've
been
recruiting
people
are
designers
lately
to
to
help
and
go
and
write
this
code.
The
way
it
you
know
accurately
down
to
the
level
that
we
need
to
test
at.
A
So
when
we
finish,
we
should
have
a
set
of
test
cases
that
test
every
single
one
of
these
scenarios,
that
is
in
his
email
and
more
and
they
should
pass
and
if
they
don't
pass,
then
we
don't
have
a
golden
image
for
a
behavioral
model,
because
it's
it's
not
really
that
useful
to
us.
It
leaked
the
past
because
other
people
want
to
use
that
behavioral
model
to
test
their
hard
work.
F
F
A
F
A
F
But
right-
and
I
suggested
what
I
suggested
my
thoughts
on
like
the
timers
like-
I
think
that
there
can
be
like
three
different
timers
one
for
like.
If
you
got
a
sin
with
no
ack
like
you
could
time
that
out
quickly
right
then,
when
you're
in
the
established
state.
That's
when
you
want
to
have
like
a
lengthy
timer
and
then
when
you
get
the
second
fin,
you
can
go
back
to
a
short
timer
because
you're
just
waiting
for
that
final
act.
F
So
like
I
I
I
think
that
like,
but
all
of
the
states
are
represented
in
that
open
contract
code
yeah
mm-hmm
here
yeah,
because
I
I
my
fear
is
that,
like
we
can,
we
can
talk
about
this
and
talk
about
this
and,
like
think
that
we
understand
what
all
the
corner
cases
are.
But
I
don't
think
you
really
know
what
all
the
corner
cases
are
until
you've
been
like
burned
by
them.
Sure
yeah.
F
A
D
D
A
I
think
we
need
to
look
at,
we
do
it
today.
We
do
have
vms
and
we
have
to
set
these
things
differently,
but
we
have
default
values
which
we
we
could
agree
on
with.
Is
the
right
approach
globally
and
if
you
don't
set
it
for
eni,
then
it
will
inherit
the
default
values.
And
then,
if
you
do
it's
because
we
know
that
there's
a
particular
implementation
out
there.
D
A
He
can
go
there,
but
realistically
what
we've
been
trying
to
tell
people
is
we're
trying
to
tell
you
like
practical.
You
know
we
only
have
typically
32
e9's,
typically
on
a
cpu
today
moving
to,
but
that's
for
200
gigs.
So
let's
say
we
go
to
800
gig.
Well,
then
that
would
be
four
times
that
so
would
that
would
end
up
being
like
128..
A
Kind
of
urban
a
thousand
is
arbitrary.
We
don't
want
to
like
use
arbitrary
numbers,
because
the
32
isn't
arbitrary.
It
actually
comes
from
us
adding
up
the
band
like
every
vm
gets
a
bandwidth
and
it
connections
per
second,
and
when
we
mix
our
typical
mix
together-
and
it
so
happens
by
coincidence
that
the
typical
mix
of
bandwidth
and
connections
intersect
at
around
30.
It
was
around
30,
so
we're
saying,
32.
A
A
A
D
D
Yeah-
and
I
I
just
want
to
very
quickly
double
confirm
right,
so
we
said
this
is
not
a
flattened
flow
cache
model,
so
in
that
case
your
tables
for
all
the
encap
decap.
Everything
else
is
separate
and
what
we're
looking
at
is
a
you
know
the
flow
rule
associated
with
the
innermost
packet.
You
know
the
connection,
in
which
case
it's
a
single
flow
rule,
for
you
know
a
connection.