►
From YouTube: IETF111-DOTS-20210729-2030
Description
DOTS meeting session at IETF111
2021/07/29 2030
https://datatracker.ietf.org/meeting/111/proceedings/
A
So
hello,
everybody,
it's
30
minutes
to
midnight
on
my
clock,
it's
my
vocab
time
and
your
time
my
worry.
It's
did
also
concert
signaling
working
group,
dots
and
I'm
seeing
that
we
can
start
so.
A
A
Blue
sheets
are
collected
automatically,
we
need
a
volunteers,
we
need
one
javascript
and
we
need
to
know
takers.
So
anyone
who.
A
A
Okay,
no
volunteers.
A
A
And
what
about
javascript?
I
think
we
have
very
few
participants
and
we
have
a
chat.
We
deco
integrated
chat
window.
A
A
A
A
A
Let's
quickly
go
through
the
working
row
draft
status,
so
we
have
since
the
last
itf
we
have
one
review
published,
it's
dutch
use
cases,
rfc
8903,
it
was
published
on
may
22nd
and
we
have
several
working
group
items
remaining
and
the
signal
channel
draft
he's
been
in
the
itf.
Oh
sorry
in
the
lc,
editor
queue
and
the
controller
filter
rules.
It's
also
inside
fft
editor
queue,
but
it
is
waiting
for
permission.
Reference
to
a
new
signal,
channel
draft
and
signal
channel
called
home
is
an
isg
evaluation
status
and
the
dots
telemetry.
A
We
also
have
telemetry's
cases
draft.
It's
the
only
remaining
working
probe
documents
that
is
being
actively
developed
and
also
multi-homing
considerations,
drought
that
is
very,
very
slowly
developed
by
the
working
group.
There
is
very
little
discussion,
but
hopefully
the
last
region
of
the
draft
has
some
significant
changes,
so
I
think
that's
all
for
the
draft
status
update
and
we
can
go
to
presentations.
C
C
C
Okay,
so
essentially,
is
that
things
are
moving
through.
There's
a
review.
Some
good
comments,
a
couple
of
things
in
particular
to
do
with
port
assignment.
So
we
tried
to
explain
that
call
home
was
different,
a
completely
different
thing.
C
This
is
in
the
signal
channel,
but
we
ran
into
using
yet
another
port
as
part
of
the
challenge,
so
in
may
2021
we
actually
withdrew
the
port
request
just
to
stop
this
blocking
going
forward
with
the
recommendation
that,
if
both
dots
and
dots
call
home
is
hosted
on
the
same
server
that
we
just
used
distinct
point
ports
to
listen
to
what's
taking
place
there
so
because,
currently
just
waiting
now
there's,
I
think,
there's
a
tele
chat
coming
up
on
august,
the
12th
or
something
on
this
one.
C
Here,
it's
just
to
kind
of
progress
it
forward,
because
it's
kind
of
stuck
just
needing
more
yeses
to
help
go
through
next
slide,
so
yeah.
So
I
don't
know
ben
whether
you've
got
any
comments
on
this,
but
I
know
that
there's
now
tele
chat.
You
may
want
to
make
some
comments
like
to
be
able
to
move.
B
There
was
one
thing
after
another,
but,
as
you
know,
I
did
get
to
put
it
on
the
agenda
for
the
next
telechap,
which
is
august
12th,
and
so
I
think
he
had
quoted
the
it
needs
four
more
yes
or
no
objection
positions
to
be
approved
and
that's
just
sort
of
the
property
of
the
isg
ballot
procedures.
B
So
we
need
for
standards
track
documents.
We
need
two
thirds
of
the
80s
to
be
yes
or
no
objection
before
we
can
approve
the
document,
because
standards
track
document
is
supposed
to
be
a
high
quality
thing.
That's
gotten
a
lot
of
review,
and
so
the
expectation
is
that
all
the
80s
that
haven't
looked
at
it.
Yet
we'll
look
at
it
in
the
next
couple
weeks
and
ideally
because
it's
already
been
looked
at
so
much,
it
should
be
pretty
straightforward
to
get
those
approvals
in,
but
there's
always
some
chance
that
the
new.
D
C
Genuine
then
yeah,
we
will
update
the
document
accordingly
to
handle
whatever's
been
raised,
not
a
problem
at
all
yeah,
so
we're
just
hopeful
that
things
can
move
forward
on
this
one
at
some
point,
but
I
understand.
A
Yeah,
it's
an
unusual
situation,
at
least
for
me
and
just
as
a
new
isg
evolution
means
that
there's
those
directors
that
have
already
expressed
their
opinion
about
this
draft
and
have
no
objection
ballot
will
re-evaluate
and
probably
change
their
mind
to
some
other.
I
don't
know
some
new
comments
or
or
only
romanian
ballots
will
be.
A
I
don't
know,
discussed
or
reviewed
well
for
those
for
those
area,
directors
that
have
already
reviewed
this
drought.
Will
this
rare
review
of
this
drought
or.
B
C
C
A
A
Yes,
thank
you
very
much
ben
and
thank
you
jim.
So
next
presentation
is
that's
multicommon
yeah
and
it
is
john
again
or
not.
C
C
Okay,
so,
basically
with
the
multi-homing.
Is
that
there's
been
very
little
change
since
some
time
back,
but
it's
just
that
they're
all
kind
of
minor
minor
changes,
updating
some
new
references
because
things
have
become
rfcs,
etc.
I
did
a
review,
and
just
after
that
just
came
some
clarification
of
thought
and
stuff.
But
again
the
changes
are
very
relatively
minor
against
more
references,
there's,
no,
nothing
pending
nothing
outstanding!
The
text
is
stable
from
you
know
our
perspective.
A
So,
as
far
as
I
understand
you
don't
expect
any
major
changes
to
this
dropped.
C
C
Yeah,
it's
it's
just
so
we
go
forward
for
that.
It
just
is
handling
different
connections
to
different
service
providers
and
all
the
kind
of
combinations
of
their
office.
So
it
really
is
just
giving
good
concrete
examples
of
things
that
need
to
be
sort
of
thoughts
and
done
and
made
to
work
properly.
A
Okay,
I
think
we
can
issue
working
robust
call
after
idf
is
finished
well,
after
some
time,
after
probably
in
a
week
or
two
yeah,.
A
C
Okay,
again,
I've
been
volunteered
well,
I've
worked
quite
a
lot
with
this,
so
I
know
this
one
fairly.
Well,
so
no
we
got
onto
the
interrupt
testing.
Sorry
I've
we
can
do.
There
was
a
yeah
we're
going
to
interrupt
testing.
Do
you
want
to
do
this?
One
academy.
F
Yeah,
I
don't
think
the
order
of
the
presentation
is
correct.
A
It's
probably
the
wrong
order
of
my
slides,
but
well
just
it.
It
must
be
just
quick
block.
A
C
C
Okay,
so
some
of
the
background
here
is
that
we
we're
adding
extra
telemetry
into
information
into
dots
and
we're
using
the
dot
signal
channel.
But
the
real
challenge
is
the
telemetry
data
will
not
fit
into
a
single
ip
packet.
It
has
to
be
split
across
multiple
packets.
C
Now,
as
far
as
co-op
is
concerned,
rfc
7959
handles
that,
but
it
only
does
it
with
confirmable
transfers.
It
only
recommends
it
for
use
with
confirmable
transfers,
but
the
issue
we
have
with
dots
is
that
we
need
to
use
non
confirmable
because
there
may
be
a
flooded
pipe
or
something
like
that.
We
need
to
be
able
to
recover
from
that.
C
So
if
we
can
just
move
to
the
next
slide
out
of
that,
a
new
draft
is
in
the
post
is
being
written
and
is,
is
pending,
going
through
the
queue
or
sitting
on
another
rfc,
but
basically
it
added
in
the
support
for
transferring
large
blocks
of
data
using
non-confirmable.
C
As
I
say,
that's
in
the
editor
queue
at
the
moment
just
waiting,
and
it
defines
some
new
session
parameters
which
can
be
negotiated
to
fine-tune
these
transfer
of
data,
and
we
currently
have
libco
app
support
for
actually
running
the
new
block
or,
as
is
known
now
as
the
q
blocks
type
stuff.
So
we
can
go
to
the
next
slide.
C
So
there's
some
additional
parameters,
so
those
of
us
that
are
familiar
with
co-app
will
be
things
like
act,
timeouts
and
so
on,
just
to
be
able
to
deal
with
the
condition
control,
but
there's
some
additional
ones
that
have
been
introduced
for
this
quick
blocks
stuff
to
make
it
work
there.
So
what
we've
done
if
we
go
to
the
next
slide.
C
We
want
to
take
those
additional
parameters
and
augment
the
standard,
rf
8782
bis
for
the
additional
congestion
control
parameters,
and
so
within
this
particular
draft
here
we
just
show
the
augment
in
the
yang
model
module,
and
then
we
give
some
examples
for
you.
So
it
really
is
just
extending
the
ability
to
be
able
to
negotiate
things
like
act
timeout
with
a
new
one
called
non-timeout.
So
that's,
essentially
all
it's
doing
there.
So
next
slide
yeah.
C
We
would
like
adoption
of
the
draft,
if
that's
a
probably
just,
is
literally
adding
in
this
half
dozen
set
of
parameters
that
can
be
negotiated
negotiated
when
the
signal
session
configuration
is
set
up.
So
it's
not
making
any
changes
to
the
protocol
other
than
the
the
yang
mod
module
being
enhanced
sitting
in
there.
So
we're
just
looking
for
an
adoption
of
the
thing.
It's
a
very
simple,
very
straightforward
draft.
I
don't
know
who's
had
a
chance
to
look
at
it
at
all.
A
A
F
So
I
answered
the
interrupt
testing.
Then
we
do
agree
with
the.
We
need
the
new
block
options
so
also.
We
need
to
wait
to
negotiate
the
default
values
for
the
block,
the
cube
lock
to
one
and
two
options.
So
I
do
some
this
draft.
A
F
E
Okay,
so
I
will
explain
the
plate
point
of
a
dot
telemetry
use
case
draft
on.
E
Next
next
strike:
okay,
oh
yeah,
so
this
is
update
points
of
draft
to
we
extracted
use
cases
already
included
in
the
telemetry
spectrum.
E
E
And
update
points
of
draft
zero:
three:
are
we
modified?
Just
some
needs
a
next
breeze.
E
A
A
A
F
Yeah,
this
is
economy
again,
so
can
hear
me.
F
Okay,
so,
as
I
said,
we
did
the
interrupt
testing
of
dot
q
block.
So
this
time,
I'd
like
to
present
the
result
of
inter
interrupt
testing,
then
I
and
john
did
interrupt
testing
this
tuesday
and
wednesday.
Okay
next
slide,
please
so
here's
a
plan.
So
the
target
draft
is
the
latest
version
of
draft
idf
core:
u
block
the!
Then
the
interoperability
was
tested
between
two
entities.
One
side
is
from
me
call
dot,
which
is
open
source
dot
implementation
by
entity.
F
F
We
mainly
tested
the
cases
of
qbook2,
which
is
a
bulk
communication
from
dot
server
to
those
clients
which
is
described
in
section
10.2
of
the
draft.
Then
this
is
a
quick
recap.
In
short,
it
was
successful.
The
both
ends
use
the
exact
same
lip
gloss
library
forked
by
germs.
So
that
is
one
of
the
reason
it
was
successful.
But
now
the
gland
successfully
recovered
the
whole
body
of
to
make
a
whole
body
of
the
dot
message
by
q
blocked
mechanism,
even
with
certain
rate
of
packet
loss.
F
Next,
like
please,
then
again,
as
john
said,
he
had
the
advantages
and
designs
of
q
block.
First,
it
supports
non-confirmable
message
to
tackle
with
ddos
unidirectional
network
pipelines.
F
F
In
this
case,
there
is
no
packet
loss
between
those
client
and
server.
Then,
for
example,
dot
client
is
my
side
and
dot's
server
is
john's
side.
Then
they
communicate
each
other
over
the
internet.
F
Then
the
bulk
get
rest.
Requests
of
support.
Resources
from
the
dot
client
is
communicated
over
co-op.
Then
q
block
2
get
request
with
non
torrigas
consecutive
responses
from
dot
server.
So
this
is,
there
is
no
problem
with
keyblock
to
communication
over
the
internet.
Then
next
splice
next
right.
Please.
F
Then
we
tried
to
simulate
the
asymmetric
packet
loss
of
the
ddos
attack,
so
we
manually
imposed
a
symmetric,
random
packet
loss
in
the
pipe
by
ib
tables,
then,
as
described
in
the
draft,
the
communication
packet
from
dot
server
to
client
has
a
chance
to
be
lost,
lost
in
the
flight,
so
that
then
the
sum
of
packets
from
those
server
got
lost
then,
which
was
noticed
by
the
dot
client
in
timeout
mana.
F
Then
the
client
asks
for
the
missing
blocks
in
the
additional
request,
so
it
is
actually
simulated
in
the
interruption
area
next
slide.
F
Please
then
here
is
the
summary
of
the
interrupt
result
in
without
loss
cases,
the
dot
client
successfully
received
the
entire
body,
which
is
larger
than
max
payloads
payloads.
Then
every
max
payload
count
gives
congestion
control
pulse.
If
no
continued
response,
then
also
we,
it
revealed
that
it
only
requires
fewer
packets
compared
with
block
existing
blocks,
which
normally
requires
conformal
message
of
god.
F
Then,
with
those
cases
yeah,
it
is
surprising
that
it
successfully
recovered
entire
body.
Even
with
this
one
to
10
percent
packet
loss
rate.
Also,
it
requires
fewer
packets,
so
it
means
a
reclaim
of
the
missing
block
blocks
is
requires
only
one
packet
to
get
the
to
indicate
the
missing
blocks.
F
Then
we
found
a
few
lip
gloss
bugs,
but
they
are
now
fixed.
Then,
however,
I'd
like
to
introduce
those
bugs
to
share
the
notions
next
slide.
Please,
okay,
then
first
one
is
about
the
method
to
be
used
in
the
blocked
communication,
cube,
blocked,
communication
and
also
blocked
communication.
F
F
Then
I
had
john
reached
the
conclusion
that,
when
requesting
the
additional
blocks
to
while
requesting
the
missing
blocks,
which
is
key
blocked,
then
the
request
method
is
the
same
for
the
next
blocks
as
the
initial
request,
even
if
it
was
open,
so
this
is
also
applicable.
So
not
this
is
not
only
from
keyblock,
but
also
to
existing
block.
F
Then
it
is
for
it
is
to
indicate
the
resource
is
same
to
the
dot
server.
F
In
order
about
the
distinguish
this
distinguishing
the
messages
between
the
new
message
or
the
existing
message
so
intra
get
for
the
entire
body,
which
is
number
zero
and
morbid
is
it
could
be
misunderstood
by
the
crop
server
as
a
request
for
the
remaining
missing
blocks
of
the
previous
blocked
response.
F
So
concrete
in
the
conclusion
I
get
with
num
zero
and
more
important
set
should
be
treated
as
a
request
for
the
entire
new
or
refreshed
body.
So
in
the
draft
it
is
clearly
noted,
like
in
draft
4.4.
Section
number
should
be
requests
for
the
entire
body,
but
the
testing
we've
got
confused
about
the
interpretation
of
this
message,
so
it
is
now
fixed.
So
there's
no
problem.
A
So
my
question
just
to
clarify,
as
far
as
I
understand
you
both
use
the
same
implementation
of
kublock
modified
e-cop
library.
So
it's
not
to
independent
implementation
or
not.
F
So,
from
a
keyboard
perspective
yeah
that
is
not
independent.
However,
the
communication
of
what
is
using
the
different
implementations,
I
mean
we
use
the
we
thought
communication
over
club,
so
in
that
sense
they
are
independent.
C
Yeah,
it's
correct
that
that
libco
app
does
a
lot
of
the
handling
of
the
the
draft
itself
and
you
could
argue
that
the
draft
and
libco
app
are
kind
of
tied
together
because
that's
how
the
giraffe
evolved
with
libeco
being
developed.
C
But
as
cannabis
said
during
the
testing,
is
that
even
with
you
know,
15
packet,
loss
and
stuff,
there
was
not
any
significant
delay
of
the
data
actually
arriving,
despite
various
packets,
getting
lost
and
so
on.
So
yes,
most
of
it's
held
in
the
libco
up
layer.
There
is
a
little
bit
of
application
requirement
done
on
both
sides
to
make
use.
Tell
the
subsystem
that
we
want
to
go
and
use
q
block.
A
C
Yeah,
certainly
yeah
when
the
the
core
rsc
is
approved,
then
we'll
just
make
reference
to
that
in
the
telemetry
document.
We
refer
to
it
anyway
as
a
suggestion,
but
it
may
be.
We
need
to
tweak
the
language
there,
but
strongly
recommending
that
it
gets
used
as
opposed
to
this
is
you
know
under
develop
available
or
whatever.
A
A
So
I
want
to
talk
a
little
bit
about
the
updating
of
our
charter
and
so
ben
thinks
that
the
charter
should
be
more
concrete
about
the
documents
that
the
group
is
developed,
because
there
are
plenty
of
a
lot
of
common
words
and
very
little
on
the
last
paragraph.
Describes.
Documents
in
the
group
is
concerned
with
so
actually
I've
already.
A
To
the
list
of
milestones-
and
it
is
waiting
for
our
ad
approval
milestones-
and
actually
I
don't
have
a
new
words
for
the
charter-
a
new
text
for
the
charter,
a
big
text
for
each
other
handy.
B
B
And
just
to
give
a
little
bit
more
background
on
that,
I
think
the
current
charter
text
was
written
several
years
ago,
and
now
we
have
we've
published
rfc,
8782
and
8783,
and
so
the
core
specifics
of
what
we
were
trying
to
do
are
now
published.
B
And
we
may
not
need
to
have
as
much
introductory
material
about
the
general
scenario
and
the
general
technology
because
that's
already
published-
and
it
may
be
time
to
revisit
you
what
we
say
that
we're
going
to
be
working
on,
because
we
already
did
a
lot
of
what
we
originally
said.
And
now
we
have
some
new
things,
some
different
things
that
we're
working
on
and
if
we
want
to
to
document
that
so
that
the
isg
and
external
consumers
can
get
a
better
picture
of
what
we're
currently.