►
From YouTube: IETF113-TSVAREA-20220322-1200
Description
TSVAREA meeting session at IETF113
2022/03/22 1200
https://datatracker.ietf.org/meeting/113/proceedings/
B
C
E
D
D
G
D
D
All
right,
I'm
just
going
to
start
talking,
welcome
to
tsb
area
everybody,
I'm
sorry
that
we
don't
know
how
to
work
anything.
Nevertheless,
if
you
have
not
somehow
seen
the
notewell
yet,
please
take
a
look
at
the
notewell.
Most
of
us
are
familiar
with
it.
Basically,
if
you
you
know
if
ipr
is
a
thing
and
if
you
have
any
ipr
relevant
to
what
happens
today,
you
must
disclose
it.
I
invite
you
to
type
well
into
your
favorite
search
engine.
D
If
you
like,
and
investigate
that
a
little
bit
further
today,
we
have
we're
going
to
go
through
our
usual
a.d,
slides
about
the
state
of
the
area
in
a
moment
here,
and
then
we
have
a
couple
of
invited
talks
on
the
theme
of
sctp
and
I'll
say
a
few
words
about
that
later.
Are
we?
Oh?
We
have
slides.
Look
at
that.
Thank
you,
zahed,
I'm
martin
duke,
and
this
is
ahead.
Sarker
next
slide
already
talked
about
that
already
talked
about
that
and,
of
course,
I'm
open
mic
at
the
end
of
the
session.
D
As
a
brief
summary
of
the
existing
working
groups,
not
a
whole
bunch,
not
a
whole
bunch
of
big
developments
in
terms
of
big
new
work
going
on,
I
would
say
in
the
working
groups
we
do
have
some
chair
changes.
I'd
like
to
thank
john
cedorf
and
michael
scharf,
who
chaired
alto
and
tcpm
respectively,
and
a
big
welcome
to
muhammad
bukader,
and
actually
it's
not
on
the
slide,
but
ian
sweat
who
are
taking
over
alto
and
tcpm
respectively.
C
So
you
can
hear
me
right
right,
so
yeah
for
the
the
working
groups
I
am
responsible,
for,
I
think
the
dtn
yeah
recharging
has
been
done,
new
work
coming
in
and
there
is
a
session
today
after
in
the
afternoon
and
there
we
are
having
some
sort
of
like
overview
discussion
on
green
stuff,
we'll
be
talking,
so
we
might
be
uninterested
going
in
then
we
have
quick
always
championing
the
deliverables
and
new
items.
I
think
one
of
the
things
that
we
could
mention
here
like
they.
C
I
started
working
on
mp,
quick
extension
and
there
are
a
couple
of
drops.
They
went
for
the
rfc
editor
few
and
obviously
there
are
some
new
ids
on
load,
balancing
and
passion
negotiation
that
if
you
are
present
in
today's
session,
you
know
about
it.
Aramcat
has
one
working
group
document
doesn't
work
from
last
call.
I
think
this
is
waiting
for
the
schaefer
strikeout
anna
is
working
on
it
and
then
for
the
taps.
C
D
Yeah,
the
only
thing
I
would
like
to
highlight
is
in
tcpm
rfc
5681
is
most
you
know,
is
this
sort
of
the
core
loss
recovery
document,
the
sort
of
semi-modern
version
of
that
and
we're
looking
to
miss
that,
but
no
one's
really
stepped
up
to
do
that.
So
this
has
come
up
a
couple
of
times,
but
no
one's
done
the
work,
if
you're
eager
to
leave
your
imprint
on
a
fairly
foundational
document
for
tcp.
That
is
an
opportunity
that
is
available
to
you
next
slide.
Please.
H
I
D
A
D
D
On
the
rfc
side,
things
coming
out
of
the
queue
the
whole
dtn
last
charter
set
a
bunch
of
ippm
stuff,
that's
kind
of
a
grab
bag
and
all
while
it
was
not
out
of
the
tdse
area.
Technically,
I
want
to
call
your
attention
9187,
which
is
joe
touch's
document
about
secret
number
extension,
which
obviously
has
a
transport
flavor
anything
add
about
this
side.
D
D
Tsv
art,
as
usual,
we
like
to
call
attention
to
what's
happening
with
the
tsv
art.
Thank
you
to
all
of
our
reviewers.
You
can
see
there
in
parentheses
the
number
of
reviews
they've
done
in
this
last
cycle
and
I
think
the
takeaway
there
is
there's
not
an
enormous
volume
of
documents
to
read.
So
I
really
invite
you
if
you
would
like
to
get
a
bigger
picture
of
what's
going
on
the
itf
and
how
it
relates
to
what's
happening
in
in
transport.
D
C
Just
to
add
to
that
one
I
mean
I
think
we
understand
like.
Sometimes
we
cannot
make
the
review,
even
if
you're
in
this
team,
so
it
will
be
great
actually
to
you.
You
inform
magnus
of
the
other
secretaries
for
us
that
you
are
unavailable
for
a
particular
time
period
that
will
help
us
actually
to
scheduling
it
better.
So
yeah
thanks
thanks
for
the
work
here.
D
There's
no
next
slide,
oh
right,
okay!
So
let's
call
up
the
other
presentation,
so
we
have.
As
I
mentioned
a
couple
minutes
ago,
we
have
two
presentations
on
the
server
sctp.
Obviously
we
shipped
quick
quite
recently,
and
that
has
a
number
of
sctp
features.
So
some
of
you
might
be
wondering
what's
up
with
sctp
is
still
relevant,
and
I
we
have
a
couple
of
speakers
today
that
will
argue
that
it
is,
I
think,
we'll
start
with
michael
cookson
who's.
Remote
and
michael.
Are
you
there
he's
there?
J
So
I
don't
want
to
discuss
too
many
technical
details
of
http.
I
just
want
to
highlight
the
services
http
provides
and
I'm
focusing
more
on
why
things
are
provided
and
why
are
things
have
been
things
integrated
into
http,
and
that
gives
you,
I
think,
should
give
you
a
better
understanding
when
you
can
use
sctp
or
another
transport,
like
maybe
mptcp
or
quick
or
whatever.
J
So
things
started,
I
think
more
than
20
years
ago,
and
the
original
use
case
was
to
be
able
to
use
an
ip-based
network
for
transporting
ss7
signaling
messages
over
ip,
that's
telephone,
signaling,
classical
telephone
signaling.
And,
although
I'm
focusing
here
on
that,
the
use
cases
where
sctp
is
used
up
to
now
is
sometimes
still
that
and
sometimes
other
signaling,
which
has
similar
requirements.
J
So
the
ss7
stuff.
What
was
special
about
that?
It
was
what
you
transport.
What
you
deal
with
is
small
messages.
Small
meaning
100
bytes
is
is,
is
not
a
small
message
there
and
the
you
need
to
transport
them
reliable
on,
but
the
ordering
requirements
are
not
that
you
need
complete
ordering,
but
only
some
messages
need
to
be
in
sequence.
J
J
So
if
you
are,
if
you
are
delaying
the
processing
of
a
message
without
any
good
reason,
that's
not
a
good
thing,
and
the
last
issue
is
that
you
need
a
very
long
lifetime
of
the
communication
relation
and
you
need
a
high
level
of
reliability.
So
long
lifetime
means
an
satp
communication.
Regulation
can
be
up
for
a
year
or
something
like
that
and
you
to
avoid
this.
J
J
J
This
dealing
with
network
failures
is
handled
by
using
multi-homing,
so
you
have
multiple
ip
addresses
on
each
on
each
side
and
you
supervise
the
paths
that
you
want
to
know
which
path
are
working,
which
ones
are
not
working
that
in
case
of
you
need
to
fail
over.
You
fail
over
to
a
path
which
is
working
and
the
the
use
case.
So
the
the
protocol
was
developed
in
the
ietf,
so
all
the
dimensioning,
the
timers
and
that
stuff
is
selected
for
the
big
guy
internet.
J
But
this
is
not
the
parameters
which
are
used
when
you
run
this
product,
so
they
are
much
much
stricter
timers
and
this
stuff.
So
you
need
to
be
able
to
configure
that
on
a
very
fine-grained
way
and
there
is
support
for
large
user
messages,
so
you
can
transport
them,
but
that
was
not
the
focus
of
the
protocol.
So
that's
why
you
get
some
head
of
line
blocking.
If
you
actually
do
this
next
slide.
J
So
over
time,
some
of
the
limitations
of
the
protocol
were
worked
around
or
addressed.
Several
things
were
done,
pretty
simple
when
the
protocol
was
designed,
because
it
should
be
on
the
market
very
fast,
so
I
think
it
was
about
a
year
between
the
first
version
of
the
protocol
and
it
went
to
the
rfc
editor.
J
So
the
features
are
basically,
you
can
dynamically
reconfigure
the
addresses
normally
the
address
and
the
base
protocol.
The
addresses
are
negotiated
during
connection
setup,
but
you
can
change
them
over
time.
This
was
hard
to
get
through
the
ietf,
but
it's
done
you
can
increase
the
number
of
streams
and
reset
them.
This
is
basically,
if
you
you
don't
want
to
tear
down
the
communication
relation
to
just
increase
something
or
change
the
addresses
we
have
partial
reliability.
J
So
that
address
is
a
point
where
the
application,
for
example,
runs
a
timer
and
when
the
timer
runs
off
basic,
for
example,
it
supervises
the
call
setup
and
if
the
application
decides
no
it
didn't
work,
then
it
doesn't
make
sense
at
the
lower
layer
to
still
retransmit
the
messages.
So
that's
why
partial
reliability
went
in
the
base.
J
Specification
has
an
abstract
api
and
there
is
also
it
was
also
worked
on
a
concrete
api
just
to
make
sure
that
you
are
able
to
configure
the
parameters
you
need
to
be
able
to
that.
You
can
actually
do
that.
That
was
very
helpful
and
sometimes
still
an
issue
that
you
can't
tweak
some
of
the
numbers.
J
J
J
This
is
used
in
webrtc,
which
is
a
use
case
which
came
in
later,
and
large
user
messages
are
also
an
issue
there,
so
the
handling
of
large
user
messages
was
improved
to
avoid
head
of
line
blocking
and
several
stream
schedulers
were
specified,
which
is
a
local
issue
on
the
sender
side,
but
you
might
want
to
have
a
defined
behavior
when
you
run
certain
applications
and
the
way
most
common
way
to
seek
your
sctp
traffic
is
transport
layer
security.
So
there
are
specifications
for
tls
and
dtls
over
http
next
slide.
J
Yeah,
that's
the
webrtc
use
case,
so
basically,
http
is
used
to
multiplex
data
channels
and
provide
a
condition
control
for
them.
So
you
can
have
multiple
data
channels
in
webrtc
which
are
a
symmetric
channel,
so
the
properties
in
one
direction
are
the
properties
in
the
other
and
http
allows
you
to
basically
to
open
and
close
these
to
run
them
ordered
and
unordered,
and
reliable
or
unreliable,
where
unreliable
means,
the
number
of
retransmissions
can
be
limited
or
the
lifetime
of
user
messages
can
be
limited.
J
This
can
be
combined
in
in
different
ways,
so
you
can
have
unordered
but
reliable
or
ordered,
but
still
unreliable
in
some
sense,
and
this
is
sort
of
hidden
from
from
the
from
the
user
who
doesn't
see
http.
He
just
sees
or
selects
these
ordered
unordered,
reliable
properties
and
that's
it
next
slide.
J
J
I
listed
a
couple
of
them,
so
the
parametrization
for
signaling
networks
was
something
which
was
brought
up
a
couple
of
times
because
it
was
important
for
for
people
running
http
based
communication,
and
they
wanted
some
guidance
on
that.
But
the
argument
was
always
this:
that's
not
the
internet,
so
we
don't
do
that.
J
In
in
the
context
of
linux
container
stuff,
which
seems
to
use
nets-
and
if
you
want
to
run
sctp
there,
then
it
seems
to
be
an
issue
and
the
other
one
is
an
update
for
dtls
over
http
the.
There
is
a
specification
which
has
its
limits
because
it
was
written
when
only
dtls102
was
1.0
was
available
and
one
and
two
and
one
or
three
are
different
and
don't
provide
the
same
services.
J
One
is
the
document
for
udp
encapsulation
has
an
issue
which
is
written
up
in
the
document
and
in
the
draft
there,
and
instead
of
having
a
separate
document
saying
you
need
to
do
this.
Also,
the
idea
I
think
of
the
former
transport
ide
or
so
was
to
just
do
a
biz
document
to
have
one
complete
spec
for
that,
so
that
might
come
up
the
other
one
was
the
14
48
95
bis,
scp
auth,
the
algorithms.
J
There
are
only
hmac
with
shawan
and
hmac,
with
sha256,
and
during
the
discussion
for
the
dtls
biz
document,
it
came
up
to
have
also
other
algorithms.
There
maybe
obsolete
show
one
as
a
must
to
implement.
So
that
might
come
up.
I'm
not
aware
of
a
lot
of
more
issues.
There's
some
some
textual
cleanups,
but
nothing
fundamental.
J
One
could
do
improvements
for
webrtc,
simple
ones
like
you,
don't
actually
need
the
checksum,
I'm
aware
of
some
implementations,
not
using
the
checksum
at
the
http
level,
because
it
uses
on
some
platforms
a
substantial
amount
of
cycles.
You
could
do
a
fast,
open
car
style
setup
because
you
don't
need
the
cookie
protection.
Something
like
that.
You
could
do
association
forwarding
to
allow
any
cast-like
features
which
I
presented.
I
think
an
idea
if
we
go
over.
J
So
if
you
want
to
do
load
balancing
between
multiple
points,
you
can
do
that
or
I
think
erickson
brought
that
up.
You
might
want
to
consider
a
full
mesh
model,
so
in
http
the
multi-homing
is
you
don't
consider
the
source
address
peers
you
only
supervise
the
the
destination
address
and
not
the
destination
source
address
pairs.
That's
what
I
wanted
to
say
yeah,
so
that
should
give
you
an
overview.
What
the
features
of
sctp
are.
J
H
Gary
fergus,
I
wasn't
going
to
ask
a
question.
I
was
going
to
try
and
provide
a
tiny
extra
context.
We
we
looked
at,
we
looked
at
pathfillo
with
sctp
and
we
did
work
there.
We
pushed
back
on
multipath
because
at
the
time
that
wasn't
a
thing
now
it
is
maybe
that
is
also
something
that
we
could
potentially
look
at
with
their
ctp.
H
Just
because
I
push
back
once
doesn't
mean
that
this
is
a
bad
idea
similar
with
ecn.
If
ecm
becomes
popular
with
other
things,
then
maybe
it
fits
there.
So
maybe
there
are
a
few
other
things
that
I
could
see
might
appear
as
useful
things
for
sctp
and
because
we
did
them
previously
and
said:
don't
do
that?
Maybe
we'll
say
do
that
next
time,
if
they've
paused
again.
D
L
L
J
J
L
M
Sorry
I
keep
mixing
up
the
video
and
screen
share
buttons.
Okay,
thank
you,
michael
that
was
that
was
interesting.
I
had
so
you're.
I
there's
a
lot.
I
don't
know
about
sctv.
I've
never
really
used
it,
but
the
the
feature
you
mentioned
about
apart
from
reliability
and
you
know
sending
with
a
deadline,
a
partial
reliability
with
a
deadline.
M
This
reminded
me
of
one
of
the
features
I
thought
was
really
useful
about
srt
that
I
heard
about
you
know
in
the
last
in
the
last
couple
of
years,
at
some
point-
and
I
know
that
that's
had
a
lot
of
uptake
in
the
video
space.
Do
you
have
any
insight
into
like
why
sctp
was
not
sort
of
the
go-to
for
for
solving
that
problem?
Is
this
a
performance
thing
or
a
it's?
You
know
geared
around
the
smaller
messages,
and
so
it
doesn't
work
as
well
for
the
larger
messages
or
like.
M
I
Back
when
naru's
id
right,
we
had
basically
ss7
was
the
use
case,
and
there
was
also
still
some
hope
that
that
sctp
would
be
like
the
general
next
generation
transfer
protocol
and
that
really
hasn't
sort
of
happened.
But
then
webrtc
happened
and
sctp
actually
did
see
like
a
major
new
use
case
that
we
nobody
really
had
on
the
radar.
I
I'm
still
sort
of
the
problem
we
had
back
then,
was
that
we
could
never
get
adequate
review
for
these
sctp
extensions,
because
the
community
was
very,
very
small.
Has
that
changed?
I
don't
think
so
so
and
then
I
think
we're
going
to
be
fundamentally
in
the
same
situation
where
we
have
basically
nobody
with
an
interest
to
review
this
thing.
For
these
things
adequately.
I
J
I
I
J
So
a
lot
of
so
I'm
aware
of
a
lot
of
companies
in
the
telco
area
having
their
own
implementations
some
sometimes
some
p,
some
companies
even
have
more
than
one
and
with
webrtc.
There
are
multiple
other
implementations
focusing
on
that
particular
case.
So
I'm
aware
of
google,
I'm
aware
of
other
implementations
in
other
programming
languages.
D
D
And
I
I
did
a
bit
of
a
poll
and
I
think
six
or
seven
people
said
they
would
attend
a
working
group
that
did
this
now,
who
knows
what
percentage
of
the
actual
attendees
that
is,
but
it
was
a
little
bit
on
the
low
side
to
separate
it
out.
So
whether
tsvwg
is
whether
those
additional
people
in
tswg
are
actually
reviewing
the
work.
You
know
it's
hard
to
say
but
yeah,
that's
always
the
concern
all
right.
N
Us
hello,
can
you
hear
me
today,
oh
perfect,
because
I
it's
not
you?
Yes,
but
I
try
to
do
what
they
can
here
so
well.
Somebody
has
got
the
worrisor
cdp
still
use
it.
Just
look
around
you.
It
is
all
around
you.
It's
used
everywhere
in
the
world
every
day
there
are
thousands
of
new
deployment
of
scpp
because
it
is
used
in
the
radioaccess
network.
N
So
it's
not
your
mobile
phone
that
is
using
sctp,
but
the
next
hope
the
the
radio
station
is
using
scp
and
there
are
some
special
reasons
why
it
is
used
at
scdp
and
possibly
some
of
the
reasons
they
were
not
really
the
real
objective
of
the
first
design
of
the
protocol,
because
we
are
not
using
http
with
ss7
in
the
radioactive
network.
S7
is
not
there
anymore
and
we
use
it
in
a
very
peculiar
way.
N
So
let
please
switch
to
the
next
slide
and
I
will
talk
a
little
bit
about
why
it
is
there
in
front
of
you.
You
have
something
like
the
current
radio
access
network,
so
you
have
some
coresight.
You
have
some
central
sites
that
are
cloud-based
and
you
have
the
radio
site
here.
I
show
you
that
they
are
all
connected
with
the
lines
and
those
lines
they
represent.
The
lcdb
association,
the
it
is
the
control
plane.
N
So,
for
instance,
if
you
want
to
to
get
more
bandwidth
because
you
are
watching
some
movies
on
your
mobile
phone,
then
it's
your
radio
that
will
ask
to
the
network.
Is
this
user
equipment
permitted
to
do
more
bandwidth?
If
so,
then
it
will
tell
via
control
plane
to
the
radio
to
allocate
more
bandwidth,
so
that
is
more
or
less
the
the
new
way.
N
The
control
plane
is
controlling
all
the
devices
in
the
radio
access
network
and
on
the
other
hand,
this
is
not
internet.
It
is
another
network,
it's
often
on
vpn,
so
you
don't
have
you
don't
go
into
the
public
internet?
It's
often
handled
in
a
different
way
than
than
we
imagine
a
network.
So,
quite
often,
each
of
this
control
signaling
is
encapsulated
over
ipsec
for
security,
and
also
often
this
ipsec
encapsulation
is
statically
routed
in
order
to
keep
under
control
all
the
possible
faults
between
nodes
or
network
problems.
N
Some
are
single
homed.
Some
are
multi-homework
in
the
in
the
old
world.
When
we
were
doing
3g,
we
had
only
single
ohm
and
association
in
the
chain,
but
when
lte
has
been
introduced
with
4g
and
with
the
5g
as
well,
we
have
started
for
the
customer
operator
have
started
pretending
to
have
multi-owning
for
redundancy
so
that
the
network
can
be
under
control
in
a
smooth
way.
N
One
moving
from
4g
to
5g
network
has
introduced
a
concept
of
migration,
so
when
moving
from
3g
to
4g
that
there
was
no
direct
communication
in
the
run
between
those
generations.
But
between
4g
and
5g,
a
new
trend
has
been
established
so
that
we
have
a
channel
that
connects
to
the
generation,
and
this
still
is
transported
over
scdb.
N
No,
there
are
more
implementation,
but
thanks
to
the
fact
that
there
were
not
so
many
big
changes
in
sbb,
the
interoperability
between
vendor
is
quite
good
and
for
the
for
the
run
for
the
net
telecom
vendor
interoperability
is
very
important,
and
the
lifetime
of
the
sctp
is
in
this
way
tied
to
the
lifetime
of
the
ready
access
network.
So
let's
say
that
4g
will
be
still
there
for
another
10
years
and
then
5g
has
been
just
taken
over
now.
So
let's
say
that
in
2035,
scp
will
still
be
there.
N
As
I
said
before,
the
run
is
not
the
internet,
since
the
control
plane
is
very
important
for
the
operators
and
losing
the
control
plane
means
losing
the
money.
The
ip
network
is
say
rather
than
being
packet
oriented
it's
a
connection-oriented
fashion,
so
the
operator
they
take
particular
care
in
on
how
they
encapsulate
and
how
they
are
positioning,
the
security
gateway
for
for
traffic
redundancy
and
they
use
steady
crowds.
I
can
also
tell
you
that
they
don't
trust
dns.
They
assign
manually
ip
address
for
for
having
everything
under
control.
N
N
One
stream
is
used
for
generic
control
and
the
other
stream
is
used
for
providing
independent
non-head
of
locking
connection
for
other
kind
of
signaling.
Multi-Homing
is
the
feature
that
operator
like
a
lot
because
they
can
reconfigure
the
network.
Still
the
transport
network
and
still
the
run
will
be
working
smoothly.
N
So
we
are
using
timers
that
are
much
faster
than
what
is
recommended
in
the
original
rfc
and
we
take
care
of
timer
accuracy.
So
we
use
a
millisecond,
the
timer
accuracy
for
our
purposes,
and
then
we
use
scp
for
link
supervision,
even
though
this
is
not
written
anywhere
in
the
in
the
recommendation
in
the
next
slide.
Please.
N
Masteries,
one
of
the
reasons
why
we
use
scgp
is
for
latency
you.
You
don't
think
that
it
has
anything
to
do,
because
it
doesn't
start
from
user
equipment
to
user
equipment.
But
the
case
is
that
normally
in
in
lte
any
user
equipment,
a
mobile
phone
is
in
idle
mode,
so
it
doesn't
have
any
carriers
assignment
from
for
transferring
data.
So
you
think
that
you
are
connected,
but
you
are
not.
Unless
you
do
something
and
then
at
that
time
your
user
equipment
asks
the
network
for
resources.
N
So
it's
like
that
the
cable
is
unplugged
from
the
network
you
plug
in
the
cable
to
the
network.
Only
when
you
ask
for
it
and
then
the
handshake
for
guaranteeing
the
the
user
plane.
Data
requires
five
signals
between
the
ue
and
the
core
network
and
requirement
is
that
it
should
be
accomplished
in
less
than
100
milliseconds.
N
N
N
So
in
the
in
the
case
of
in
the
you
are
watching
the
super
bowl
and
you
are
at
the
stadium
and
one
of
the
radio
that
is
serving
us
with
the
stadium
loses
connection
to
the
to
the
network.
It
is
important
that
in
a
few
seconds
this
is
known
and
then
so
that
the
equipment
can
hand
over
into
another
radius
rail
station,
and
this
is
the
requirement
is
that
you
should
do
that
in
less
than
20
seconds
next
slide
piece.
I
don't
know
if
it's
my
last
slide
yeah.
N
N
D
D
J
N
No,
not
really
it
is
that
it's
difficult
to
scan
over
multiple
because
of
the
design
that
requires
this
single
point.
Doing
the
that
is
difficult
to
implement.
So
you
can.
One
association
is
a
single
point
for
the
sake,
so
it
cannot
grow
up
forever.
Normally,
it
is
limited
to
the
work
of
a
single
core.
J
F
N
N
O
N
Oh
no,
no
problem
with
windows,
sides
of
congestion
control;
everything
works
perfectly.
But
if
you
had
more
tracking
on
an
association,
then
you
will
saturate
the
capacity
of
a
single
core,
because
I
haven't
seen
an
implementation
that
can
spread
a
single
association
on
more
than
one
single
report.
It
is
because
the
way
that
the
protocol
is
designed.
D
D
L
I
think
I'm
in
I'll
speak
to
the
specific
specific
point,
and
then
I
have
a
general
question
for
the
chairs.
I
have
a
comment.
That's
more
general
on
this
particular
point.
I
think
that
it
really
depends
on
the
implementation.
If
you're
doing
it
in
user
space,
you
might
be
able
to
do
fun
tricks,
but
I
can
understand
that
with
existing
implementations
in
kernel
in
particular,
you'd
have
trouble
scaling
past
a
single
core.
L
D
So
I'm
gonna
cut
the
queue
after
michael
and
then
we'll
open
it
we'll
help
with
transition
to
open
mic
and
you're
welcome
to
keep
talking
about
sctp.
If
you
would
like
to
do
that,
okay,
so
I
should
do
that
now,
let's,
let's,
let's
have
michael,
follow
up
on
this
presentation
one
last
time,
then
we
can
open
the
mic.
J
Yes,
just
two
two
remarks:
one
is
nix
of
some
vendors
allow
checksum
offloading,
which
is
in
the
case
of
sctp
much
more
useful
than
in
the
case
of
tcp,
so
doing
the
depending
on
the
cpu.
You
have
that's,
that's,
that's!
That's
some
cpu
load,
I'm
aware
of
implementations
which
can
do
at
least
receiving
packets
in
one
thread
receiving
sending
packets
and
another
thread
to
some
way.
So
you
can
you
can
you
can
do
that?
But
that
gets
hard.
D
Thank
you,
michael,
and
thank
you
claudio
for
presentations.
They
were
very
informative.
I
certainly
learned
a
lot.
This
is
now
begins
the
open
mic
portion
of
the
session.
So
if
you
have
any
comments
at
all
about
the
transport
area
and
any
part
of
it
feel
free
to
enter
the
queue
and
we'll
begin
with
janna.
L
Thanks
again,
martin,
so
at
a
high
level,
I
think
it's
in
it's
instructor
to
think
about
the
fact
that
sctp
even
lost
his
point
earlier
about
the
fact
that
sctp
was
designed
at
a
different
time
had
different
potential
end
goals
at
the
time,
not
all
of
them
manifested
for
various
reasons.
We
understand
them.
I
think
would
be
well
today
and
I
will
say
that
we've
taken
a
lot
of
those
lessons
into
account
when
we
worked
on
quick
and
so
it's
it's
played
a
significant
role.
L
L
We
can
talk
about
features
in
general,
but
I
think
it's
much
more
interesting
to
talk
about
the
features
so
claudia
mentioned
that
sctp
is
going
to
be
in
the
rank
for
a
long
time,
and
I
appreciate
that,
but
use
of
the
protocol
doesn't
necessarily
mean
that
we
need
to
keep
developing
it
in
ways
that
the
current
use
cases
don't
need
it
to
be
developed.
So
I
would
suggest
that
going
forward
it'd
be
really
useful
to
understand
for
any
extensions
or
any
work
that
we
need
to
do.
L
C
I
I
think,
jonah,
that's
a
very
valid
point.
I
think
this
is
this
is
something
called
maintenance
and
developing
new
features
I
mean
so
in
the
maintenance
part
we
can.
We
can
have
the
protocol
there,
but
we
cannot
forget
about
it
right.
So
that's
just
one
of
the
point
products
here
we're
trying
to
make
but
yeah
when
you
are
talking
about
extensions
and
making
some
new
development
for
the
particular
protocol,
not
only
but
acidity,
but
whatever
we
need
to
think
about
who
is
the
user.
P
We
should
look
into
also
how
slightly
different
the
ideas
of
transport
are,
and
I
think
this
also
explains
a
lot
why
we
have
problems
or
why
the
sctp
community
seems
to
have
problems
with
kubernetes
so
far,
because
they
kubernetes
has
a
very
specific
idea.
What
transport
is
it,
how
it
works,
and
this
is
really
centered
on
rest
and
http,
and
not
so
much
about
what
usually
transport
people
at
the
itf
care
about.
D
J
Yeah,
I
just
want
to
second
what
jannah
said
and
in
addition
to
that,
that's
something
we
do
for
several
years.
So
none
of
the
recent
sctp
developments,
meaning
the
features
were
done
without
some
some
other
entity
requesting
that
feature.
Some
other
entity
might
be
another
working
group
of
the
ietf
or
so
so.
This
is
something
we
do
for
I
don't
know
five
or
ten
years
now.