►
From YouTube: DASH HA Working Group Call 20220510 (May 10, 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
So
if
you
remember
last
time
we
talked
about
requirements
and
agreed
to
to
start
discussing
the
state
machine
of
our
protocol,
and
I
want
to
iterate
over
a
few
things
that
before
diving
in,
I
think
are
worth
mentioning
so,
first
of
all
the
protocol
we
are
designing
that
is
intended
to
synchronize
a
state
between
two
between
two
systems.
It
is
a
best
effort
protocol,
but
it's
not
a
lossless
one,
meaning
that
two
peers
sending
data
to
one
another:
they
they
are
not
required
to
retransmit
anything.
A
First,
one
is:
we
want
to
maintain
a
session
because
there
is
no
external
signaling
about
the
state
of
the
other
peer.
So
it
is.
I
think
it
is
important
for
us
to
maintain
this
state
ourselves,
meaning
some
kind
of
the
keep
alive
or
something
like
that
and
second
is
exchange
the
data
itself
and
the
data
exchange,
of
course
relies
on
the
session
state.
A
A
As
we
all
know,
we
are
planning
for
1
million
cps
and
up
so
that
there
is
so
usually
what
happens.
Is
that
the
regular
flow
is
you
have
a
body
session
maintained,
even
if
you
have
that
offloaded
eventually,
event
gets
to
the
control
plane
and
based
on
that
event,
control
plane
updates
the
state
of
the
data
plane.
A
What
we
want
to
achieve
is
some
kind
of
the
integrated
solution
where,
based
on
the
bfd
event,
not
really
bfd,
but
our
flow
synchronization
protocols,
events,
the
state
of
the
data
plane,
will
be
updated
accordingly,
without
without
interaction
with
the
control
pane.
So
I
think
it's
also
worth
to
mention
in
here
that
the
state
of
the
I
I
think
this
is
in
the
in
the
requirements
page,
but
I
will
just
reiterate
it
over
here.
The
state
of
the
data
plane
is
updated
without
a
control,
plane,
intervention.
B
B
How
do
you
do
that
like?
Is
it
tcp
or
is
it
something
else,
but
I
think
making
the
assumption
that
there's
no
re-transmission
or
no
sequence
number
is,
is
putting
a
lot
of
constraint
on
what's
to
follow.
In
other
words,
like
the
actual
state
synchronization-
and
I
think,
like
you,
have
to
look
at
this
within
the
context
of
the
actual
state
synchronization,
and
I
think
you
might
come
back
to
this
and
say
you
know
what
it
might
be
better
to
come
up
with
some
way
of
doing
a
reliable
transport
of
the
messages.
A
So
two
points
about
that
number
one
is
that
we
don't
have
a
monolithic
state
in
the
system
right.
Every
message
is
supposed
to
update
about
independent
changes
or
independent
flows.
We
don't
have
any
correlation
about
that
flow,
so
message
lost
the
message
at
the
time
t
minus
1
that
was
lost
does
not
affect
in
any
very
message
set
sent
at
the
time.
T0.
B
Well,
so
one
of
so
one
of
the
problems
is
that
the
two
directions
of
a
connection
can
be
on
two
different
dpus,
and
you
know
if
you're
going
to
you
know,
send
state
from
one
dpu
to
another.
Dpu
you
can.
If
that
state
is
lost
in
the
transport
from
one
dpu
to
the
other
dpu,
then
you
might
not
handle
the
reverse
direction
correctly
right.
B
A
B
That's
right,
yeah,
I
I
I
mean
I
actually
have
a
write-up.
I
was
planning
at
some
point
to
like
make
it
public
on
how
you
could
do
this
in
a
very
simple
protocol,
because
this
is
like
this
is
kind
of
a
constrained
environment.
In
some
ways
you
know
like
the
latency
between
these
two
dpus
should
be
very
low.
B
B
B
I
wouldn't
just
rule
out
that
that
that
you're
not
going
to
do
something
reliable,
because
I
think,
like
you,
haven't
taken
it
to
the
conclusion,
which
is
like
look
at
like
the
six
state
updates
that
you
might
have
to
do
per
connection
and
try
to
understand
like
what
will
happen
if
any
one
of
those
is
lost
and
like
it,
it's
like
you
can
go
through
each
one
of
those
and
say
okay.
If
the
first
message
is
lost,
what
happens?
Okay?
B
If
the
second
message
is
lost,
what
happens-
and
I
think
what
you'll
find
is
that
there
are
like
cases
that
are
very
difficult
to
deal
with
if,
like
those
messages,
are,
are
lost,
and
I
don't
disagree
that,
like
the
next
message,
would
supersede
it
but
like
you
might
not
even
get
to
the
next
message.
If,
if
you've
gotten
the
flow
into
some
bad
synchronization
state.
C
C
D
C
More
or
less
going
in
line
with
what
you're
talking
about
but
having
a
reliable
protocol
there
would
be.
You
know
more
than
beneficial,
of
course,
because
then
we
can
keep
the
overhead
low
and,
while
still
knowing
that
those
two
states
are
actually
being
transferred,
so
I
I
will
definitely
publish
it
for
this
work
group
consideration.
C
B
C
B
C
Okay,
well,
I
think
we're
we're
both
kind
of
going
in
the
same
direction,
though,
that
you
cannot
chew
up
more
than
half
the
bandwidth
just
for
sinking
connections,
that's
crazy
and
that's
the
the
direction.
If
we
start
sending
every
every
all
six,
packets
or
even
their
headers,
I
don't
care
over
individually
that
chews
up
way
too
many
packets
per
second,
and
so
we
talk
about
cps
in
this
group,
but
that
that's
assuming
we,
the
assumption
is
that
we
have
high
pps.
C
B
I
would
be
happy
to
release
the
paper
I
wrote
too.
I
think
it's
complementary,
because
I
don't
get
into
what
the
details
are
of
the
individual
state
updates
and
what
the
states
are
mine
is
more
about
how
to
make
the
transport
of
the
state
updates
reliable
and
how
to
how
to
do
that
in
such
a
way
that,
because,
like
even
if
you
reduce
the
bandwidth
gerald,
it's
still
high
bandwidth.
B
This
is
still
like
a
very
high
bandwidth
requirement
here,
and
so
you
want
to
be
able
to
do
that
reliable
transport
with
like
as
efficiently
as
possible.
So
like
I,
I
would
be
happy
to
release
mine
mine's,
not
in
a
mine's
a
word
document.
I'd
have
to
convert
it
to
a
form
that
I
can
do
like
a
pull
request,
but
I
think
it's
complementary
what
you're
saying
what
I'm
saying?
What
like
what
my
paper
addresses
and
what
your
paper
addresses
yeah.
E
F
E
F
E
Yeah,
okay
thanks.
I
just
thought
it
should
be
mentioned,
so
I
you
know
we
know
where
to
put
it
in
the
scheme
of
things
so
to
speak,
it
seems
like
what
you
know
right
now:
we're
kind
of
almost
doing
a
deep
dive
into
the
into
this
part
of
the
overall
aha
project.
You
know
it's
one
design
aspect.
I
wonder
if
we
ought
to
look
at
what
the
various
design-
let's
say:
tasks
are
in
the
group
and
there
may
be
parallel
efforts.
E
A
That's
yeah.
We
started
to
talking
about
that
last
time.
You're
right,
chris
state
machine
is
only
one
of
them.
There
is
also
flow
synchronization
or
what
you
call
the
flow
table
management
failover
scenarios.
Maybe
if
someone
else
can
think
of
something
we
can
add
it
in
here
as
well.
So
we
can
split
this
up.
C
C
B
C
E
I
think
yeah,
it's
probably
too
early.
I
was
just
thinking
ahead
a
little
bit
at
some
point.
If
we
find
we're
arguing
over
the
number
of
angels
on
the
head
of
a
pen
so
to
speak,
yeah,
we
should
step
back
and
go
what
tasks
can
we
unblock
right,
I'll,
be
blocking
tasks
and
unblocking
tasks,
but
that's
probably
today's
probably
not
the
time
to
do
that,
but
we
should
keep
looking.
E
C
C
C
C
Yeah,
so
that
connection,
you
know
we
have
another
group
that
is
defining
like
you
know.
What
does
the
connection
state
machine
look
like,
and
that
is
what
we're
trying
to
in
a
sense,
that's
what
we're
trying
to
synchronize
is
the
table
that
is
associated
with
each
tcp
state
machine
or
each
flow
state
machine
that
that
we
have,
and
so
it's
the
actual
real
time.
D
C
You
you
can't
go
back
into
like
a
connection,
can
only
be
started
at
the
beginning
of
a
connection
right.
You
can't
lose
something
and
then
say:
well,
just
you
don't
have
the
information
to
establish
that
connection
in
the
slow
pass,
so
it's
lost
and
what
will
happen
is
the
end.
Points
will
eventually
figure
that
out
they
will.
They
will
send
a
reset,
probably
eventually
figuring
out,
that
this
connection
is
no
longer
there
and
then
re-established,
but
we're
in
between
that,
and
so
we
have
we,
you
know
we're.
C
We
aren't
an
endpoint
we're
in
in
the
network
and
it's
our
state
that
we
most
worry
about,
because
that's
what
we're
building
and
if
you
do
lose
the
fact
that
there
is
a
connection
you
can't
like
in
the
middle
of
the
connection,
just
kind
of
recreate
it
with
a
slow
path.
You
just
don't
have
that
information
that
only
came
with
the
beginning
of
the
tcp
connection.
A
C
C
It's
kind
of
full
proof
in
that
you
you
send
everything
to
the
secondary
and
then
the
secondary
will
loop
it
back
to
the
primary.
We
will
then
pass
it
on
to
the
end
point
in
that
mode,
at
least
for
the
at
first.
The
sin-
I
don't
know
if
the
rest
of
them
really
need
to
do
that,
but
that
mode
we
should
have
as
mode
one
and
it's
you
know
it's
kind
of
a
mode
that
we
already
have
tested.
C
It's
not
efficient,
but
it
is
very
easy
to
prove
that
it
works
and
then
what
we're
talking
about
here
as
a
group
is
mode
in
which
is
not
mode
one
mode,
the
next
mode,
and
you
know-
and
we
could
improve
on
it
over
time,
so
they're
calling
it
mode
end,
because
we
could
say
mode
two
and
then,
but
there
might
be
a
mode
three.
Somebody
thinks
up
even
better
way.
So
I
just
wanna
to
keep
in
mind
what
my
michael's
probably
describing
a
little
bit
more
like
mode
one
and
mode.
C
A
C
A
Yeah
I
understand,
but
that
it's
not
probably
the
optimal
one,
but
the
necessity
for
what
he
was
talking
about
was
because
it
is
asymmetric,
it
will
land
on
different
appliances.
You
will
need
to
make
sure
that
both
appliances
will
learn.
The
connection
before
the
reply
will
will
learn
every
right,
we'll
learn
the
syn
packet
before
we.
We
get
the
reply,
because
reply
will
go
to
another
appliance
at
it
and
it
may
not
yet
know
about
the
existence
of
that
connection.
So
we
cannot
make
those
two
events
asynchronous.
B
A
B
Now
you
can
imagine
that
there's
a
race
condition
right,
a
race
condition
between
whether
the
peer
gets
the
message
or
gets
the
synack
first.
Okay.
Now,
if
you
were
to
assume
that,
like
let's
say,
99.999
percent
of
the
time,
it
gets
the
message
first,
because
there's
a
very
low
latency
path
between
the
two
dpus,
then
you
could
say:
okay,
in
that
case
it
works
because
it
was
in
the
correct
state
when
the
syn
act
came.
B
Okay
now
you
could
say
like
what
about
in
the
point:
zero
zero
zero
one
percent
case
where
the
message
arrives
late.
Well,
in
that
case,
the
syn
ack
will
be
dropped
because
because
you
you,
if
there's
no
flow
in
your,
if
there's
no
connection
in
your
connection,
table
and
you're
getting
a
syn
act
packet
like
a
syn
ack
is
in
a
packet
that
allows
you
to
create
a
new
connection.
So
you
would
drop.
You
would
just
drop
that
syn
ack
and
it
would
be
recent
yeah
and
then.
B
Reset
and
by
the
time
it's
reset
like,
of
course,
you
would
have
reliably
gotten
the
state
from
the
original
dpu
so
like.
I
think
that
there
are
race
conditions,
and
I
think
that,
like
maybe,
we
have
to
make
some
assumption
that
the
latency
between
the
two
dpus
is
like
much
much
less
than
the
latency
of
the
network
between
the
two
endpoints
and
therefore
those
those
race
conditions
are
almost
never
a
problem
and
when
they
are
a
problem,
you
have
to
look
at
what
actually
will
happen.
C
The
other
thing
is,
I
don't
understand
it's
not
going
to
go
back
to
the
secondary
appliance.
It
has
a
longer
path,
so
I'm
not
understanding
that
could
only
mean
the
primary
build
between
receiving
the
sin
and
and
then
goes
dark
all
of
a
sudden
withdraws.
It's
it's
itself
from
the
network,
which
would
take
a
long
time.
It's
almost
an
impossibility
for
that
to
happen.
B
So
I'm
not
even
understanding
that
case.
No,
no,
I
think
gerald.
I
think
it
was
our
understanding
that,
like
you
have
two
dpus
that
are
ecmp'd
and,
like
you
know,
the
ec
ecmp
decision
in
one
direction
might
be
different
than
the
ecmp
decision
in
the
other
direction.
So,
like
the
two
directions
of
a
connection
you
know,
just
in
normal
operation
may
end
up
on
the
two
dpus.
B
B
It
seems
like
in
the
nat
case.
It's
almost
has
to
be
that
way
because
there's
no,
you
know
the
the
the
you
know
the
the
packets
have
like
different
addresses,
depending
on
the
directions.
They're
going
so
like
there's
almost
no
way
that
they
could
be
steered
to
the
same
dpu
in
the
nat
case
and
and
maybe
in
other
cases
as
well.
Yeah.
C
B
So
like
it
really
like
the
number
of
connection
like
state
synchronization
messages
like
I
was
saying
earlier,
like
I
think,
if
you're
thinking
like
purely
like
each
connection
is
active
on
one
dpu
and
passive
on
the
other,
dpu
then
like
you
might
be
able
to
reduce
the
number
of
like
state
updates.
But
when
you
have
like
the
connection
split
across
the
two
dpus,
I
I
don't
think
you
can
really
you
like.
I
don't
think
you
can
really
minimize
it
that
much.
C
Yeah,
I
not
thought
about
the
asymmetric
case,
the
active
passive
case,
which
is
what
we
do
today,
because
we
don't
do
economic
today,
but
when
we
do,
you
know,
ecmp
may
may
change
that.
So
it's
just
something
I
have
to
go
back
and
think
about.
Okay,
I
was
thinking
as
being
active
passive,
in
which
case
I
know
you
don't
need
to
track
all
the
states,
but
I
understand
what
you're
what
you're
getting
at.
B
C
C
We
can,
I
don't
think
mike,
has
all
the
answers
either.
It's
just
a
matter
of
gathering
all
the
the
facts
and
it
people
should
publish
any
paper.
You
have
on
your
thoughts
and
then
we'll
just
refine
them
right,
and
you
know
mike's
not
gonna.
Tell
you
exactly
how
to
build
this
thing
right
because
he
didn't
build
it
in
the
first
place
right,
so
this
is
done
by
a
by
a
vendor.
C
So
let's
just
submit
some
papers,
give
something
for
people
to
look
at
talk
about,
discuss,
refine,
we'll.
We
will
end
up
in
the
right
place,
but
I
don't
think
that
we
should
not
publish
papers
just
because
somebody
finds
a
hole,
publish
the
papers,
so
we
find
the
holes
and
then
then
we'll
figure
out
how
to
plug
those
holes
and
just
go
through
the
processes.
It's
not
a
it's,
not
abnormal.
C
I
will
check
with
michael
for
sure
on
this
asymmetric
and
try
to
like.
We
should
draw
out
some
of
this
stuff
as
part
of
the
requirement
it's
like.
When
does
it
become
asymmetric,
and
what
does
that
look
like
and
that
that's
something
that,
from
a
requirements
point
of
view
like
we
should
have
those
kind
of
drawings.
C
You
know
passive,
active
and
then
this
asymmetric
thing
like
we
had
those
drawings
up
front,
and
you
know
how
we
how
we
believe
that
message
flows
are
going
to
go.
Then
it
would
be
much
easier
for
people
to
build
solutions
against
it.
I
think
we're
missing
the
beginning
stages,
so
I'll
talk
to
michael,
we
should
get
some
drawings
of
ecmp
is
nuts
and
and
how
that
was
different
than
always
going
through
the
same
dp,
which
is
what
we
do
today
right.
D
So
I
remember
publishing
some
hld
in
the
sonic
side
to
make
sure
both
the
flows
ends
up.
You
know
handling
in
the
same
appliance.
I
think
there
is
a
order,
ecmp
feature
that
we
have,
and
I
don't
know
if
that's
in
place
on
the
leap
side,
maybe
you
know
the
getting
the
I
mean
landing
the
reverse
direction.
Traffic
on
the
different
templates.
You
know,
may
not
be
the
case
that
we
need
to
worry
about.
C
If
you
have
an
interesting
paper,
we
can
read.
Can
you
just
like
just
do
a
pr
saying,
here's
an
interesting
article
that
you
should
read
owen
mind
reading
it
just
as
part
of
the
exercise
that
for
us
to
be
reading
as
much
as
possible
as
we
develop
this?
That's
a
good
idea
of
somebody
else's
thought
about
something
similar
to
this
as
background
that'd
be
good.
A
Now
I
think
the
sonic
use
case
is
that
if
we
have
a
row
of
t1
switches,
they
will
all
perform
identical
hashing.
I
think
that
that
was
the
idea
there,
but
here
we're
talking
about
two
different,
looking
headers
in
two
directions,
which
is
impossible
for
the
switch
to
understand
to
hash
to
the
same
destination.
D
D
A
A
But
again,
I
also
agree
with
gerald
gerald's
point.
What
I
don't
understand
I
didn't
expect
there
to
be
ecmp
to
the
appliance
because
decision
to
which
appliance
it
goes,
is
done
by
the
bgp
path
and
the
active
one
has
shorter
path
so
yeah.
Maybe
there
is
something
to
to
clarify.
Do
we
want
to
support.
C
C
C
It's
sometimes
just
like
assigning
anything
like
vms
to
servers
when
you
have
large
and
small
vms.
Sometimes
you
put
a
couple
of
bigger
ones
on
and
then
a
few
little
ones
and
you
have
like
eight
cores
left
over,
but
nobody
asked
for
an
eight
core
bm,
and
so
it
gets
wasted.
It's
the
same
with
e
and
I's.
C
Well,
we
can
do
that
because
we
we
hold
a
bit
of
the
connection
state
on
each
one
of
those
gpus.
Therefore,
you
know
a
big
eni
spread
over
three
gpus
looks
like
something
three
times
smaller
as
far
as
the
dpu
is
concerned,
other
than
the
policy,
but
the
connection
state
and
the
connection
tables
are
divided
now,
and
so
you
can
get
better
bin
packing
when
you
do
ecmp
in
theory
right.
We
don't
do
it
today,
but
that's
the
theory
that
you
can
get
better
bin
packing,
which
makes
the
overall
cost
of
the
system
lower.
C
So
that's
what
he's
talking
about
like
I
said
we
don't
do
it
now,
but
it's
something
we
want
to
do
so
since
it's
something
we
want
to
do.
We
have
to
think
about
it.
Now
so
say
it's
actually
just
not
something.
I
was
thinking
about
personally
when
I
wrote
my
paper,
so
I
have
to
go.
Read
them
here:
okay,.
B
B
B
B
Okay,
so
again,
I'm
thinking
of
reliable
right,
where
this
is
like
a
like
a
stream,
it's
reliable
between
the
two
dpus
and
like
in
that
case,
like
you,
might
need
multiple
streams
like
one
stream.
That's
going
to
you
know
from
you
know
one
port
of
the
dpu
and
a
different
stream
going
to
the
different
port
of
the
dpu,
so
that
so
that
you
don't
like
consume
all
of
these,
like
the
bandwidth
associated
with
with
synchronizing
state,
isn't
all
on
one
port
of
the
dpu.
B
So,
like
I
don't
think
it's
I.
I
don't
necessarily
agree
that
it's
outside,
like
the
scope
of
the
protocol.
I
think
it's
like
there's
a
protocol,
and
then
you
say,
okay
like
I
need
to
run
like
n
instances
of
this
protocol,
and
you
know,
half
of
my
connections
will
go
through
this
instance
and
another
half
of
my
connections
will
go
through
this
instance
for
the
purposes
of
kind
of
balancing
this
bandwidth
across
the
ports
of
the
dpu.
B
C
B
B
A
B
A
B
Then
that's,
okay,
you
know
you
just
can't
take
all
of
the
synchronization
updates
for
a
single
connection
and
randomly
spray
them
across
your
two,
your
two
synchronization
path,
so
you
have
to
like
find
it,
and
I
think
you
know
that
could
be.
You
know
like
a
vendor
decision
of
like
you
know
how
they
decide.
You
know
which
which
path
they
decide
to
use
for
for
their
connection
updates.
B
B
I'm
just
saying
it's
up
to
the
vendor
the
vendor,
I'm
just
saying
it's
up
to
the
vendor
when
he
goes
to
when
he
goes
to
send
synchronization
updates
for
a
connection
to
pick
one
of
the
paths
and
send
it
over
that
path,
and
as
long
as
that
connection
always
uses
that
path,
then
that's
fine
and
it's
like
it.
I
don't
think
it's
critical
that
each
vendor
choose
the
path
using
the
exact
same
decision
logic.
B
B
If
it
were
tcp,
you
know
like
you,
it's
typical
that,
like
for
very
high
bandwidth,
you
can't
achieve
like
a
tcp
connection
of
very
high
bandwidth.
You
might
have
to
have
parallel
tcp
connections,
so
I
think
like
I.
I
don't
think
we
should
assume
that
that,
if
we're
doing
a
reliable
transport
that
all
synchronization
messages
will
go
through
the
same
stream.
B
No,
no,
no,
I'm
not
saying
that
you
can
absolutely
like
coalesce,
like
multiple
connections
into
the
same
packet
and
send
that
packet.
All
I'm
saying
is
that
a
given
connection
always
goes
through
the
same
path
that
you
don't
like,
send
the
sin
event
through
one
path
and
the
you
know
some
other
event
through
a
different
path,
but
when
you're.
C
B
C
B
Teacher
haven't
got
the
sensor
each
each
dpu
right
so
like,
like
you
know,
maybe
you
know
the
control
channel
between
the
dpu
says:
hey,
let's,
let's
set
up
our
with
each
other
and
when
you
go
to
set
up
the
aha
you
say
I'd
like
to
have
you
know
eight
streams
for
h
a
and
the
other
end
says
fine.
Yeah
eight
streams
sounds
great:
let's
set
up
the
eight
streams
and
start
sending
our
our
synchronization
messages
over
those
eight
streams.
A
F
C
Of
what
the
messages
look
like
or
anything,
we
need
multiple
streams
so
that
we
don't
have,
because
you
may
have
four
ports,
then
you
just
definitely
don't
want
to
go
over.
You
know
one
one
of
those
parts,
so
I
think
it's
valid.
We
want
to
prevent
that
from
happening
and
spread
the
messaging
across
all
the
ports
evenly.
C
I
think
that
I'm
not
sure
anybody's
disagreeing
with
that,
because
that
just
makes
common
sense
now,
whether
you
need
you
know
this
next
statement
of
you
know:
sequence,
numbers
and
whatnot.
That's
a
different
debate.
That's
actually
almost
getting
back
to
the
the
debate
about
what
the
messages
should
look
like
and
how
they
should
be
tracked
and
the
connection
state
machines.
This
is
like
two
completed
different.
No.
B
No,
no
gerald,
I
I
don't
think
it's
completely
different,
because
I
think
like
what
the
messages
look
like
is
kind
of
like
the
payload
of
this
reliable
transport,
like
the
reliable
transport,
is
like
a
different
layer.
It's
it's
the
layer,
that's
trying
to
transport
these
messages
reliably.
The
messages
are
just
payload
within
this
transport
and
I
think,
like
we
could
debate
like
how
to
do
a
reliable
transport
law.
But
if
you
just
take
tcp
as
an
example
like
if
we
said
hey,
you
know
what
tcp
is
a
reliable
transport
every.
B
It
works
like.
Let's
just
use
that
as
the
transport
for
these
messages
like.
I
would
argue
that
if
you
were
to
build
a
dpu
that
could
do
three
million
connections
per
second,
then
then
you
would
have
like
a
certain
packet
rate
and
bandwidth
like
that
you
would
have
to
satisfy
and
like
can
one
single
tcp
connection
satisfy
that?
Maybe
what?
B
If
someone
built
the
dpu
that
could
do
100
million
connections
per
second,
I
don't
think
you
could
have
a
single
tcp
connection
that
could
handle
like
that
kind
of
like
packet
rate
and
and
bandwidth.
So
I'm
just
making
the
point
that,
like
that,
if
it
turns
out
that
the
bandwidth
and
packet
rate
of
this
reliable
transport
is
extremely
high,
then
you
might
have
to
split
it
into
multiple
streams
in
order
to
even
implement
it.