►
From YouTube: IETF113-TSVWG-20220321-1200
Description
TSVWG meeting session at IETF113
2022/03/21 1200
https://datatracker.ietf.org/meeting/113/proceedings/
A
C
D
E
G
G
D
D
D
D
D
So
this
meeting,
like
all
the
meetings
that
the
ietf
holds,
is
covered
by
the
ietf
notewhile.
If
you
haven't
seen
this,
please
read
it.
If
you
have
seen
it,
please
look
at
it
again.
If
you
have
any
queries
about
ipr
and
what
to
discuss
in
front
of
other
people,
our
policy
is
quite
simple
and
quite
clear.
D
D
D
We're
using
the
meat
echo
mic
here,
so
this
is
your
instructions
for
using
meat
echo.
If
you
haven't
used,
it
simply
press
the
hand
button
and
we
will
see
you
in
the
queue
here:
don't
use
the
mic
icon
if
you're,
actually
in
this
room,
if
you're
using
the
qr
code
to
log
in
take
the
blue
sheets,
then
you
won't
have
a
mic
button
on
your
app
and
that's
a
note
that
we
do
need
people
to
use
the
qr
code.
So
we
can
take
the
blue
sheet
record
of
who's
in
attendance.
D
Review
comments
can
be
anything
from
people
helping
to
improve
particular
texts
to
people
raising
up
issues
to
be
discussed.
A
lack
of
reviews
probably
indicates
a
lack
of
care
that
the
document
is
finally
published.
So
please
do
review
and
if
you
wanted
something
new
to
look
at
that's
coming
up
towards
a
working
group,
last
call
there's
the
udp
options
and
dscp
considerations,
work
which
are
two
things
which
probably
could
do
with
reviews
soon.
D
So
our
achievements
and
accomplishments
are,
we
have
published
no
rfc
since
ietf112,
which
is
called
a
be
kind
to
our
area
director
period.
We
have
a
number
queued
up
to
go
to
our
area
director
and
we
have
one
id
still
at
the
rfc
editor,
which
has
been
through
review
and
will
be
published
shortly,
which
is
496
obese.
D
D
D
E
D
D
D
D
D
We've
decided
that
they're
useful
targets
and
therefore
we're
going
to
try
and
refresh
them
and
keep
them
sensible
and
try
and
hope
well
try
our
best
to
facilitate
getting
the
documents
published
before
the
milestone
is
due.
So
the
milestone
is
the
date
at
which
we
expect
this
work
to
conclude
beforehand
is
always
good.
D
G
D
Okay
and
similarly,
the
liaison
requests
on
dtls
was
encouragement
to
produce
the
document
to
submit
it
to
publication
so
that
e3
gpp
could
reference
it
and
the
gsma
relays
on
related
to
multi-path
dccp
and
their
expectations
for
that
which
we
discussed
previously
so
nothing
new.
Here
there
is
a
request
for
doing
proposed
work
on
a
new
ccid,
I'm
bringing
this
up
here
just
for
the
point
of
view
of
coordination-
and
this
is
relates
to
the
datagram
congestion
control
protocol.
G
In
addition,
I
want
to
mention
that
the
hpcc
plus
plus
draft
has
a
has
a
an
agenda
slot
in
rtg,
wg
routing
working
group.
Next,
at
next
hour,
yeah,
it's
got
some
relationship
to
routing,
but
it
probably
belongs
over
in
transport,
and
I
think
the
suggestion
is
that
iccrg
ought
to
have
a
look
at
this
in
general.
It'd
be
good
to
think
about
what
the
transport
area
ought
to
be
doing
in
the
way
of
data
center
congestion
control.
D
D
D
D
D
We
have
michael's
site
here
by
magic,
so
michael
you'll
be
on
first
to
talk
about
a
ctp
nut.
So
this
is
a
item
which
we're
encouraging
discussion
on
to
figure
out
what
the
working
group
should
do
with
a
id.
That's
been
around
for
probably
one
of
the
longest
on
our
list
and
it's
one
that
we
need
to
determine
what
the
next
steps
are.
So
michael
go
ahead
and
talk
and
at
the
end
we'll
ask
what
those
next
steps
should
be
over
to
you,
michael.
H
Yeah,
so
this
is
this
is
about
a
draft
which
has
been
around
for
a
long
long
time.
We
had
working
group
last
call
we
got
there
was
a
transition
of
the
transport
ads,
so
we
got
two
reviews
from
magnus
and
martin
and
right
now
we
have
an
alternate
proposal
from
ericsson
which
I
provided
a
link
to
go
to
the
next
slide.
H
H
But
when
it
comes
to
this
multi-homing
thing,
it's
only
a
single
port
number,
and
that
has
the
consequence
that
if
you
have
multiple
path
towards
your
peer,
if
you
want
to
change
the
part
number,
it
has
to
be
done
consistently
on
all
the
paths
so
assuming
that
the
middle
boxes
are
not
communicating
to
each
other.
This
means
you
can't
translate
the
port
number,
and
this
has
then
as
a
consequence.
What
are
you
doing
if
you
have
local
port
number
collisions?
H
H
So
this
is
basically
a
summary
of
the
comments
we
got
from
the
leds
I
haven't
marked
with
jd
says
some
of
the
comments
were
given
by
both
ads
and
some
only
by
one,
but
it
doesn't
matter.
We
should
address
them
all
or
try
to
so.
The
first
one
is
that
ip
fragmentation
handling
at
the
net
was
an
issue,
but
I
think
we
can
deal
with
that
like
using
the
same
terminology
as
done
for
udp
or
tcp.
H
H
The
the
question
was
how
to
control
the
net
friendly
behavior,
which
is
endpoints,
have
to
behave
in
a
specific
way
when
they
are
dealing
with
this
net
scenario,
and
the
idea
was
was
just
if,
if
one
of
the
local
addresses
is
a
private
one,
you
do
this
or
you
have
a
socket
option.
That's
laid
out.
We
can
make
that
clearer.
That's
not
that
complicated,
improved
multi-homing
support
was
was
asked
for
this
means
we
can
have
more
even
more
examples
showing
that
it
was
asked
for
that.
H
H
H
H
I
have
listed
possible
ways
forward.
The
the
first
one
is
to
stick
with
the
with
this
method.
We
are
currently
proposing.
Adding
the
entries
to
the
net
table
will
add
complexity,
which
is,
or
I
mean
this
is
already
not
trivial,
so
it
adds
complexity.
It
gets
complexibility,
but
we
can
address
issue
two
to
five.
H
The
nuts,
the
the
the
fragmentation
stuff
is
just
wording.
I
mean
you
can't
do
anything
wrong.
We
do
have
always
the
possibility
that
the
endpoints
do
not
support
this
additional
mode.
So
there
is
a
fallback
mechanism
on
basically
just
using
the
fallback
mechanism
taking
out
all
the
sctp
specific
things
is
a
possibility
which
would
address
issue
two
to
seven,
so
that
would
mean
don't
use
the
verification
tag,
don't
disable
restart.
H
Add
the
external
remote
addresses
to
the
nut
binding
table,
and
basically
this
comes
down
to
a
net
function
which
is
not
http
aware.
It's
just
outgoing
packets
establish
a
relation,
you
don't
change
port
numbers
and
that's
it.
The
drawback
is
that
in
case
of
a
local
port
number
collisions,
you
can't
do
anything
so
the
association
can't
be
established.
H
So
that's
the
well.
I
would
say
the
the
this,
especially
this
does
not
change
the
definition
of
the
association
in
the
endpoints,
so
this
seems
to
be
addressing
most
of
the
issues.
The
third
alternative
is
to
drop
this
document
at
all
and
go
with
the
ericsson
proposal,
or
the
fourth
way
is
to
drop
the
work
at
all
and
say:
if,
if
we
come
up
with
a
document
which
describes
an
almost
http
unaware,
not
we
don't
have
to
do
the
work
here.
D
And
my
default
option
could
be
four
or
could
be
one
or
two
I
mean
literally.
We
need
people
to
come
to
the
mic
and
say
whether
one
or
two
is
acceptable
as
a
way
forward.
We've
been
working
as
a
working
group
on
this
for
a
while
if
anyone
who's
commented
or
anyone
who
has
new
insight,
wishes
to
comment
on
whether
one
or
two
is
acceptable.
D
H
On
the
chat
colin
asked
if
there
are
people
having
large-scale
nets,
I'm
not
aware
of
that.
What
I
am
aware
of
is
an
implementation
done
by
the
australian
university
for
freebsd
and
based
on
that
they
did
experiments
and
measurements
on
scalability.
They
took
out,
they
suggested
to
take
out
the
remote
address
from
the
nut
binding
table.
I
D
H
F
F
B
K
G
F
G
H
D
H
D
Michael,
my
comment
still
is:
can
people
live
with
the
option
one
presented
here
and
can
they
live
with
option?
Two,
the
change
of
scenario
yeah.
It
was
understood
in
the
wicking
group
last
call
and
it
would
be
good
to
address
more
cases
if
it's
possible
and
we
need
to
decide
on
whether
one
or
two
are
acceptable.
D
M
H
H
D
K
K
N
Yeah
magnus
western,
my
understanding
of
this
problematic,
is
that
we
have
three
hexes
we
have
one
which
is.
Can
we
support
really
support
multi
multi-homing?
Well,
the
other
axis
is
how
many
concurrent
sessions
can
we
support
and
that's
the
third
is,
then
the
output,
so
to
say,
is,
is
how
complex
the
solution
is,
so
you
can
support
multi-homing,
but
very
few
sessions
with
relatively
low
complexity
or
you
can
go,
and
I
I
think
it's
a
question
of.
L
True,
like
any
time
you
just
use
the
ip
address
and
have
one-to-one
mappings,
you
have
problems
that
anybody
can
just
scan
through
all
the
ports,
and
now
your
your
nat
is
totally
ddos,
like
it's
totally
trivial,
to
ddos
anything
with
that
type
of
scenario.
So
I
don't
actually
really
see
how
two
works.
I
I
think
that,
as
you
dig
into
that,
you
know,
there's
no
way
to
really
tell
whether
there
was
a
conflict.
You
have
to
somehow
drop
the
packets
that
have
a
conflict.
L
Otherwise
you
have
two
two
different
things
trying
to
use
the
same
port.
I
mean
I've
seen
many
people,
not
in
sctp,
but
I've
seen
this
tried
in
udp
multiple
times
and
I've
never
seen
it
work,
and
I
can't
imagine
why
all
the
udp
problems
with
that
type
of
solution,
don't
exactly
map
over
to
sctp
as
well.
So
I'm
having
a
really
hard
time
understanding
how
to
is
a
viable
option.
H
Okay,
maybe
one
point
so
right
now:
the
the
the
idea
is
that
state
can
be
added
only
by
internal
hosts,
and
if
there
is
a
port
number
collision,
the
net
box
sends
a
packet
back,
indicating
that
so
a
node
in
the
private
network
can
can
can
do
a
ddos
by
establishing
a
lot
of
state.
Yes,
that's
true,
if
that,
if
that
is
not
a
ddos,
but
by
chance
and
the
local
endpoint
is
not
relying
on
that
particular
port,
it
can.
H
D
To
decide
one
of
these
ways
forward
and
we're
going
to
have
to
decide
shortly
after
this
meeting,
there
is
obviously
time
to
discuss
on
list
and
obviously
time
to
get
people
together
to
find
their
opinions.
But
we
do
have
to
make
a
decision,
because
the
working
groups
have
the
document
for
a
long
time.
D
D
N
N
N
Since
last
meeting,
we
have
received
some
feedback
from
liang.
We
also
hadn't
contracted
out
an
implementation
of
the
specification.
We
got
some
feedback,
we
have
implemented
some
of
these
so
far
and
it
continues-
and
I
have
to
remind
you
that
there's
two
ipr
declarations
from
ericsson
on
this
document
next
slide.
N
We
also
look
into
some
of
these
ssb.
Api
limitations
might
limit
the
sender
further,
but
shouldn't
be
an
issue
for
a
receiver,
so
a
sender
that
knows
he
can
deal
with
or
ensure
that
you
have
a
stack
that
matches
that
we
also
looked
into
stream
usage
update,
there's.
This
is
minor
in
some
sense.
But
actually
most
main
point
here
is
detail
ssdp
before
details
process.
The
message
doesn't
know:
what's
incoming,
if
that's
user
data
or
a
detailer's
message
that
has
some
impact
anyway
of
how
you
can
send
this.
N
So
we
thought
you
were
be
able
to
really
relax
the
limitation
of
how
it's
ending
and
it's
up
to
the
sender
so
to
say
to
send
on
whatever
stream
they
want
to,
because
it's
anyway
doesn't
matter
until
the
detailer
stack
process.
The
message
we
also
looked
into
shutdown
procedures
clarifying
those
we
have
a
new
section
on
http
api
considerations,
trying
to
note
what
kind
of
special
functionality
you
might
need
on
the
satb
stack
to
support
as
well
and
the
number
of
clarifications
on
various
things.
N
N
Addressing
this,
I
want
to
note.
I
mean
that
683
per
its
original
publication,
it
was
using
details,
1.0
had
less
limitation
and
what
it
has
now,
since
rc
8996
forced
details
upgrade
to
1.2
because,
for
example,
to
support
a
long-lived
sap
association
details.
1.2
has
the
renegotiation
security
issues
which
has
to
do
with.
N
N
N
N
N
But
from
my
perspective
I
think,
there's
two
realistic
ways
forward:
obsoleting
rfc
683
when
publishing
draft
src,
which
would
have
been
the
default
publishing
as
an
alternative
rfc
to
1683
without
obsoleting,
is
another,
and
that
would
allow
people
to
update
683
and,
if
etc,
if
they
want
to
do
something,
try
to
do
something
there
which
doesn't
infringe
the
ipr
or
see
what
you
can
do.
So
I
mean
683
has
limited
applicability
and
has
its
security
issues,
so
I
think
something
maybe
needs
to
be
done
anyway,
but
it's
so
yeah.
N
N
D
D
H
H
My
point
is
that,
in
my
view,
dtls
for
http
is
something
like
tls
for
tcp
or
dtls
for
udp,
so
replacing
an
rc
which,
which
is
which
you
can
implement
in
open
source
and
which
you
can
use
by
a
document
proposed
by
a
company
enforcing
its
own.
Ipr
seems
to
me
suboptimal.
I
mean
up
to
now.
We
have
every
everything
we
did
in
http
was
backed
up
by
open
source
and
at
least
when
it
came
to
working
group.
Last
call
we
had
some
implementations
and
this
is
not
possible
here.
N
N
So
we
or
at
least
two
word
speed,
is
for
no,
so
we
don't
get
stuck
in
a
situation
where
no
progress
at
all
is
made,
because
I
mean
we're
doing
this
work
to
ensure
that
gdp
has
a
reference
for
something
that
needs
to
resolve
and
and
and
ending
up
where
we
have
no
progress
and
and
just
spend
a
lot
of
time
working
on
it.
That's
not
productive
at
all.
N
H
N
H
D
I
think
I
I
can
comment
at
this
point,
so
I
will
of
course
offer
the
opportunity
for
a
ad
to
comment
if
he
wishes,
but
my
understanding
of
what
we've
talked
about
here
is
that
the
working
group
could
decide
not
to
update
six
or
eight
three
by
obsoleting
it.
So
we
we
continue.
This
work
is,
is
a
proposal
that's
on
the
table.
That
inevitably
might
mean
that
two
further
things
could
happen.
Another
id
could
emerge
which
updates
six
or
eight
three
or
by
the
time
that
this,
what
we're
considering
has
reached
fruition.
D
We
decide
that
6083
should
finally
be
obsoleted
anyway,
because
the
ipr
issues
have
been
either
gone
away
or
have
been
encountered
or
are
well
known,
whatever
the
outcome.
So
there
is
a
way
to
proceed
here,
which
means
that
we
continue
the
work
item
without
doing
the
update
with
the
penalty
that
we
may
have
to
publish
another
rfc,
either
to
obsolete
6083
or
to
update
it
as
a
parallel
spec,
and
I'm
asking
the
working
group
and
we'll
do
via
the
mailing
list,
whether
that
is
an
acceptable
way
forward.
M
M
I
it
seems
to
me
the
outcome
will
be
that
you
have
60,
83,
still
functional
and
then
a
then
a
alternative
to
60
80.
You
know
alternative
improvement
to
6083
that
will
be
used
by
some
implementations
and-
and
I
I
I
don't-
maybe
necessarily
understand
exactly
what
the
what
the
interoperability
implications
of
that
are
and
and
if
magnus
can
answer
that
that
would
be
interesting,
but
it
seemed
inevitably
we're
driving
in
that
direction.
D
Yeah-
and
we
may
have
to
update
6083
anyway
for
security
reasons,
because
the
the
security
part
of
the
spec
changes
so
things,
security,
algorithms
will
be
obsoleted,
so
that
may
have
to
be
maintained
as
a
separate
document
if
we
decide
to
go
along
that
path.
But
I
guess
we
acknowledge
this
by
going
along
this
path.
Now.
M
N
I
mean
together,
the
current
draft
is
of
the
new
proposal
is
very
clear
on
when
you're
negotiating
the
handshake
using
the
this
defined
method
for
detecting
it,
the
683
you.
Basically,
you
have
no
clear
indicator
that
you're
going
to
do
683.
Unless
you
you
see
it's
sctp
off
and
then
there's
a
detailed
handshake.
N
That's
how
you
detect
that
it's
happening
and
and
this
other
one
you're
doing
the
handshake
in
the
association
handshake,
you
will
detect
okay,
I
want
to
do
this,
so
you
know
that
this
is
and
and
if
future
proposal
could
do
the
same,
but
with
the
different
identifiers
you
could
negotiate,
which
you
are
doing.
So
I
think,
there's
at
least
power
existence
is
not
an
issue.
N
M
Excellent,
so
then,
if
I
understand
correctly,
if
you
had
a
60-83
endpoint,
well,
actually,
okay,
so
let
me
back
up
so
with
your
draft.
If
you
had
an
employee
supporting
your
draft
and
it
and
try,
they
would
not
see
this
option
from
the
pier,
and
so
it
would
recognize
what
was
going
on
with
the
6083
endpoint.
It
will
see
dtls
payloads
and
think
that
it
is
doing
6083
when
it's
actually
doing
what
your
draft
is
doing.
N
M
M
D
Right,
I
think
that's
a
a
fair
thing
and
if
that
emerges
in
the
future,
that
can
be
always
going
to
do
maintenance
of
aspects.
So
this
is
okay
as
well.
Okay,
fine
thanks!
This
proposal
will
be
taken
to
the
list
and
I'd
happily
work
with
the
people.
Who've
spoken
here,
just
to
make
sure
that
the
right
proposal
words
are
written
on
when
we
send
it
to
the
mailing
list:
yeah.
Okay.
How
are
we
doing
on.
D
N
There
was
in
time
permits
to
discuss
an
issue,
but
it's
actually
so
yeah.
I
think
people
can
read
those.
I
will
post
to
the
main
list
about
the
issues
or
other
things
when
we
work
with
it.
So
we
we
have
a
few
smaller
there's.
One
thing
with
the
first
of
those
is
around
details:
1.2
is
a
bit
annoying,
but
I
think
we
probably
have
one
some
way
forward:
we'll
have
to
figure
it
something
out,
but
yeah.
Okay,.
N
G
O
D
P
Yeah
keep
keep
going,
keep
going
one
there's
one
to
do
left
in
the
draft,
and
so
I'll
be
asking
for
input
from
the
working
group
on
how
to
address
that.
That
open
question
in
the
next
slide
is
the
so
no
no
updates
to
draft.
Since
the
last
ietf,
I
do
have
a
work
in
progress.
Draft
o3
at
this
point
only
has
some
typo
fixes
some
misspellings,
etc.
G
I'll
insert
myself
in
the
mic,
I
would
suggest
that
it
would
benefit
those
who
want
to
work
with
l4s
to
declare
victory
on
this
move
it
forward
as
an
rfc
shortly
after
or
with
the
alpharest
drafts,
and
then
immediately
open
a
bisdraft
to
capture
things.
We
learned
dirt
learned
during
the
alpha
price
experiment.
As
your
slides
show,
the
draft
is
pretty
much
stable.
I
don't
think
there's
any
major
contributions
and
I
think
getting
it
out
a
bit.
More
broadly
is
probably
a
good
thing
for
all
concerned.