►
From YouTube: IETF111-TSVAREA-20210730-2300
Description
TSVAREA meeting session at IETF111
2021/07/30 2300
https://datatracker.ietf.org/meeting/111/proceedings/
A
A
A
A
One
is
a
dispatch
type
discussion
about
draftsy
or
route,
which
is
a
document
that's
currently
in
the
independent
stream
that
has
some
sort
of
transport
implications
and
we'll
see
if
there's
interest
and
then
lastly,
and
then
secondly,
co-app
has
been
plugging
away
in
the
art
area
for
a
while.
I
think
most
of
you
know
what
co-op
is.
B
A
A
A
Here's
the
update
on
all
of
our
working
groups.
The
most
salient
issues
here-
are
that
both
alto
and
dtn
are
in
the
midst
of
recharging
processes
a
little
further
along
the
dtn,
and
also
that
vijay
garbani
after
seven
or
eight
years
is
stepping
down
as
one
of
the
working
group
chairs
us
they're
going
to
go
to
two
chairs
for
the
time
being.
A
So
thank
you,
vj
for
everything
you've
done
for
your
working
group
and
the
area
and
the
itf,
if
you're
out
there-
and
I
don't
think
you
are
notably
probably
a
pretty
red
letter
moment-
is
793
bis.
The
venerable
spec
for
tcp
is
is
going
through
itf
last
call
right
now.
So
that's
that's
a
pretty
big
moment
and
thank
you
to
wes
and
the
other
contributors
for
moving
that
document
through
right.
Anything
else
that
you
would
like
to
highlights
ahead.
C
C
A
A
This
is
our.
Did
I
skip
a
document
page?
I
think
I
did
yes,
so
some
some
very,
very
important
things
made
it
to
rfc
in
the
in
the
previous
interval,
mainly
the
whole
back
of
batch
of
quick
hp,
3's
delayed
for
kind
of
well.
It
was
bureaucratic
document
reasons,
but
now
maybe
there's
a
little
bug
they
have
to
fix.
A
Hopefully
that
won't
take
too
long
and
the
other
one
was
9065,
which
is
the
the
transport
encrypt
draft,
which
was
a
long
and
torturous
route
but
congrats
to
the
to
the
authors
there
for
for
getting
that
through,
and
we
only
added
two
documents
to
the
queue.
Although
another
batch
of
five
or
six
will
be
coming
in
shortly,
I
believe.
A
I
I
you
know
as
an
ad,
I
find
it
extremely
helpful
when,
when,
when
members
of
the
team,
you
know
conduct
early
last
car
reviews
of
documents
to
give
us
a
little
another
set
of
eyes
from
transport,
these
documents
are
okay
and
I
encourage
you
to
contact
magnus
or
wes
if
you're
interested
in
this,
of
course,
is
rejoining
the
tsv
art
after
being
rad
for
a
number
of
years,
but
to
contact
either
him
or
wes.
If
or
for
that
matter
of
the
ads.
A
If
you're
interested
in
joining
the
tsv
art,
the
number
in
parentheses,
is
how
many
drafts
they
had
to
do
in
the
last
cycle,
and
I
I
think
the
evidence
is
strong.
This
is
not
an
incredibly
onerous
workload.
So
if
you
would
like
to
expose
yourself
to
a
little
bit
more
of
what
the
itf
is
doing
outside
the
area,
I
think
tsv
art
is
a
good
way
to
do
that,
while
being
very
helpful
to
your
friendly
area
directors.
So
thank
you
to
our
review
team
and
that's
it
for
the
the
administrivia.
E
So,
let's
go
up
good,
so
thank
you
very
much.
This
is
my
10
minute
summary
of
what
this
dropped
or
what
this
technology
is
about
root.
This
id
that
is
being
discussed
and
there
is,
is
being
reviewed
and
go
to
the
next
slide.
So
what
I
would
like
to
do
is
just
like
in
in
five
six
minutes,
provide
you
the
summary
of
what
is
the
background.
Is
this
technology?
How
does
it
relate
to
adaptive
streaming
technologies?
E
What
is
real
time,
object
delivery,
so
the
relation
of
it
with
ip
multicast
and
other
existing
technologies
like
3gb
and
uml,
and
how
does
it
relate
to
atsc
and
ub?
Then
I'll
discuss
briefly?
What
is
the
status
of
this
currently
this
id
and
what
are
the
next
steps
that
we
would
like
to
do
moving
forward?
E
So
very
briefly,
the
relation
of
this
root
protocol
is
to
the
adaptive
streaming
technologies.
So
here
I'm
showing
the
high
level
architecture
of
dash,
which
is
the
dynamic
adaptive
streaming
or
http
the
amp
extended,
but
it
is
equally
applicable
to
other
adaptive
streaming
technologies
like
apple
hls,
so
this
standardization
in
mpeg
was
happening
in.
E
2010
and
the
high
level
you
know
how
this
technology
works
is
that
this
is
driven
via
http
server.
So
you
segment
the
content
that
you
want
to
stream
and
put
it
on
an
http
server.
The
various
qualities
of
the
content
and
each
quality
is
then
segmented
into
small
chunks
of
data,
one
or
two
seconds
each,
and
then
there
is
a
mpd
or
a
manifest
file
that
describes
this
content
that
is
also
put
on
the
http
server.
So
the
basic
technique
is
that
you
switch
all
the
smartness
to
the
client
side.
E
E
So
then,
okay,
this
is
http
driven
technology
and
then
all
of
a
sudden
it
was
quite
a
big
or
important
drive
to
use
the
same
content
over
ip
multicast,
and
there
are
then
a
lot
of
obvious
questions
that
arise
that
you
know
why
dash
is
designed
for
http
based
mechanism,
and
the
notion
of
adoption
is
adaption
is
in
any
case
quite
a
bit
alien
to
this
multicast
delivery.
So
why
would
anybody
want
to
do
this?
E
Obviously,
the
the
highest
level
or
the
important
aspect
is
to
exploit
the
commonality
of
ecosystem,
which
is
easy
speak.
Is
you
want
to
reuse
the
content
that
that
content
providers
have
so?
This
is
the
biggest
headache
that
you
would
like
to
use
the
same
content
that
you've
used
for
just
you've
generated
for
unicast
that
you
can
deliver
the
same
content
over
multicast.
At
the
same
time,
you
could
reuse
your
players
and
all
the
rest
of
the
ecosystem
that
is
common
with
the
unicast
for
the
multicast.
E
And
the
right
hand
side
you
would
like
to
do
the
same
thing
over
ip
multicast.
So
obviously,
when
you
want
to
support
the
same
thing
that
you
that
is
working
on
unicast
over
ipv
multicast,
you
need
a
different
protocol
stack.
So
there
are
some
question
marks
here
and
for
the
sake
of
simplicity,
let's
say
the
most
common
deployment
where
you
just
pick
one
quality
of
video
and
you
stream
it
over
ibm
multicast.
E
This
was
existing
at
that
time,
and
this
was
this.
Protocol
is
used
for
ib,
multicast,
delivery
of
files,
and
now
you
know
the
the
most
straightforward
approach
that
was
adopted
was
to
use
flute
to
deliver
dash
because
dash,
as
we
described
a
few
slides
earlier,
is
a
large
in
symbol
of
files.
So
well,
fluid
was
used
to
deliver
files
and
then
you
could
use
fluid
over
udp
or
ip
multicast
to
you
know,
I'd
be
multicasting
small
chunks
of
files
to
to
the
clients.
E
One
of
the
difference
that
you
can
note
is
that
dash
is
obviously
built
for
http
streaming,
so
this
this
comes
with
that,
with
the
assumption
that
the
delivery
is
reliable.
But
in
this
case
of
udp
it
is
not
so
then
you
have
to
use
the
mechanisms
of
forward
error
correction
together
in
fluid
or
unicast
repair
to
guarantee
that
you
know
the
the
player
that
is
working
on
the
highest
level
can
assume
that
the
content
is
delivered.
E
E
Because
flute
traditionally
was
designed
for
delivering
a
very
large
files,
typically
over
their
updates
and
like,
and
so
it's
kind
of
heavy
on
the
amount
of
metadata
that
it
uses
for
a
given
file,
and
the
difference
now
with
dash
is
that
you
have
a
very
large
number
of
small
files.
You
just
consider
just
one
audio
visual
representation
with
one
second
chunks
of
data,
then
360
files
in
one
hour,
so
the
amount
of
metadata
kind
of
stacks
up
and
also
the
real-time
delivery
constraints.
E
E
Some
optimizations
were
implemented
in
in
the
sense
that
the
metadata
was
reduced
significantly,
so
that
it's
much
better
adapted
for
this
very
large
number
of
small
files
and
some
of
the
mechanisms
to
do
this
was
to
embed
the
the
metadata
into
the
packet
header
itself
and
not
having
these
to
to
stream
a
large
amount
of
metadata
together
with
the
files.
That
is
the
traditional
approach
in
flute.
E
So
this
is
the
reference
to
the
atsc
specification
that
was
done
in
2019.
The
publication
was
20
2019
here
it
says
2014
where
the
whole
thing
started
and
so
on.
So
this
was
the
initial
standardization
of
root
in
atsc
yeah.
Here,
I'm
just
comparing
the
protocol
stacks.
So
we
said
earlier
on
that
the
commonality
of
the
formats
enable
also
this
notion
of
hybrid
delivery,
that,
since
you
have
the
same
format,
you
can
deliver
it
over
unicast
and
multicast
at
the
same
time.
E
C
E
E
There
are
lcd
packet
headers
and
the
header
extensions
there
are
file
related
metadata.
What
is
this
location,
which
is
size?
This
can
be
either
embedded
into
the
packet
itself
or
it
can
be
a
separate
file
as
an
eftt,
and
then
there
is
some
service
level
sig
ceiling
required
to
set
up
the
session.
What
are
the
ip
addresses,
the
ports
and
so
on
so
forth?
So
this
would
be
the
metadata
and
then
the
main
data
is
sent
over
this
lcd
over
gtp
ip.
E
On
the
receiver
side,
you
do
the
source,
object,
recovery
and
there's
optional.
This
fec
or
repair
object
protocol.
So
you
optionally,
you
you're,
sending
these
repair
objects
that
you
receive
and
you
can
use
these
repair
objects
to
optionally
repair,
your
received
source
data
and
then
once
the
repair
is
done,
you
put
the
objects
into
this
application
object,
cache,
which
is
then
delivered
to
the
application.
E
E
Actually
we
kind
of
realized
this
before,
but
it
was
quite
strongly
felt
during
the
standard
edition
that
we
were
referring
to
the
root
protocol
in
atsc,
but
the
atsc
annex
was
probably
not
the
best
independent
reference
source
for
root.
Why?
Because
how
it's
specified
in
atsc
in
the
annex?
It
is
heavily
linked
to
the
atsc
a331
service
layer
and
you
know,
would
it
be?
If
you
pick
up
atsc.
E
E
We
were
referring
to
very
exact
sub
clauses.
We
even
had
to
some
sometimes
reproduce
text
of
the
specification
to
make
it
clear
and-
and
that
was
the
time
I
mean
even
it
was
a
bit
before-
but
that
was
very
clearly
established
to
us
during
standardization
in
that
group-
that
we
need
an
independent
referenceable
document
and
the
best
place
for
that
would
be
the
ietf,
and
this
brought
us
to
this
internet
draft
that
we
provided
here
and
what
is
its
current
status.
E
So
I
just
noted
that
this
was
the
reason
that
we
wanted
to
use
root
in
various
stos,
and
currently
this
draft
is
it
in
is
it
is
in
its
second
review
and
we
are
receiving
the
idf
feedback
from
the
usual
review
cycle.
We
are
also
getting
feedback
from
atsc
currently
on
the
random
access
signaling
aspects
of
the.
What
does
what
are
documented
in
this
draft?
E
We
are
also
getting
some
independent
feedback
from
individual
contributors
who
read
the
draft
they're,
providing
us
some
feedback
they've,
come
to,
learn
it
from
atsc
or
itf
or
different
places,
and
we're
getting
some
feedback.
So
what
is
the
status
of
the
feedback
integration?
We
received
some
very
nice
feedback
from
different
people.
Also
rfc
editor.
These
were
addressed.
There
was
some
early
review
feedback.
This
was
addressed
in
version
2..
E
We
have
first
external
feedback
review,
that's
still
not
completely
addressed.
We
will
get
second
review
feedback
that
needs
to
be
implemented.
So
these
are
the
feedback
that
that
we
are
seeing
very
close
to
the
horizon.
That
we
are
that
we
expect
to
receive
there's
some
atsc
feedback
that
is
still
to
be
implemented.
E
One
of
the
important
questions-
or
I
think
the
main
questions
that
I
would
like
to
answer
in
my
slide,
is:
why
did
we
go
for
the
standards
track?
Why
we
want
to
do
it
as
an
independent
submission,
and
the
main
reason
for
us
is
that,
as
as
it
has
been
commented
that
the
purpose
of
this
internet
draft
the
root,
proto
aspect
in
a
clean,
referenceable
or
standalone
document,
but
these
aspects
have
already
been
specified
in
atsc,
so
we
didn't
see
that
we
had
to
do
some
new
standardization.
E
We
were
just
like,
okay
take
whatever
is
existing
and
it's
an
important
aspect
that
whatever
we've
see
it
has
already
been
commercially
deployed
by
various
tv
manufacturers,
and
we
just
want
to
make
sure
that
we
don't
change
anything.
What
is
in
what
the
route
they
have
used
so
far.
So
this
is
why,
if
choose,
if
we
change
it,
then
it's
going
to
break
compatibility
and
from
qualcomm
side
we
have
continued.
E
We
continue
to
investigate
in
various
sdos
that
everything
is
interoperable
and
also
a
minor
aspect
is
that
this
is
not
an
independently
depo,
a
deployable
internet
standard.
So
you
need
a
service
layer
to
make
it
work.
So
in
that
case
it
would
be
an
atsc
service
there
or
dvp
service
there
or
anything
later.
So
I
see
there
is
some
question
from
adrian
and.
G
This
is
not
sort
of
asking
permission
or
anything
like
that
to
publish
in
the
independent
stream
it's
rather
the
other
way
around
and
after
useful
reviews
and
comments
from
jorg
and
gauri,
who
I
see
is
in
the
queue
after
me,
it
seemed
like
a
really
good
idea
to
make
sure
that
the
transport
area
was
aware
of
this
and
give
a
chance
for
the
area
to
say
no
look
really.
We
would
like
to
work
on
this
and
we
want
to
push
it
through.
If,
if
that's
what
I
want.
H
Yeah,
I
just
wanted
to
say
thank
you
for
bringing
your
talk
here
and
it's
it's
really
good
to
hear
people
wanting
to
publish
specs
for
the
things
that
they've
made,
and
I
just
appreciated
you
bringing
your
talk
here.
I
follow
the
working
dvd.
I
follow
the
work
here
in
flute
and
thank
you
thank
you
just
for
bringing
this
here.
H
E
B
B
Hello,
can
you
hear
me?
Yes,
yep
cool
yeah,
it's
kind
of
echoing
what
gory
just
said
like
thanks
for
seeing
this
bringing
this
here
and
letting
us
know
about
three
years
ago,
I
was
involved
in
some
dvd
work
where
we
were
weighing
up
the
the
multicast
transport
protocol.
Fluke
was
an
option.
It
was
an
option,
so
some
other
things
are
on
the
table
as
well
and
yeah
like
the
root
stuff
was
really
thorny
to
like.
If,
if
we
were
trying
to
use
this,
yes
it's
defined
in
a
document,
but
not
very
easy.
B
So
it's
like
I
left
that
work,
but
it's
really
cool
to
see
how
you've
progressed
on
and,
like,
I
think,
just
making
this
an
informational
document
would
would
go
a
long
way
without
lots
of
changes
and
all
of
those
things.
I
do
wonder
if,
like
in
the
future,
if
you
were
to
continue
to
rev
root
and
like
have
a
root
v2,
whether
that
work
would
be
like
where
that
work
would
be
done.
B
Given
that
you
have
a
document
here,
we
see
in
other
places
in
things,
like
maybe
hls,
for
instance,
that's
predominantly
led
by
apple
that
they
they
continue
to
work
on
their
their
specs
and
then
bring
bring
a
version
back
to
the
ietf
to
be
published
again.
So
something
like
that
for
root
could
probably
work.
I
don't
know
but
yeah,
I'm
I'm
happy
to
take
a
look
at
the
document.
Now
I
know
exists
in
the
ietf
and
maybe
suggest
some
editorials
or
whatever.
E
Thank
you,
yeah.
I
think
this
we
expect
something
similar
happening.
So
as
I
was
mentioning,
we
are
getting
feedback
from
atsc
and
the
idea
would
be
that
you
know
these
are
the
guys
who
currently
most
heavily
deployed
this,
that
if
there
is
a
new
need
or,
for
example,
this
random
access
aspect
that
we
are
looking
on
into
currently
that
it's
formulated
and
defined
there,
and
then
we
bring
it
back
to.
B
I
I
One
question,
I
think,
would
would
there
be
any
value
in
making
a
sort
of
standards
track
service
layer
that
could
be
done
on
the
internet
at
large
and
is
there
would
that
be
an
appropriate
document
to
to
set
up
here
regardless
of
the
you
know,
I
think
it
makes
sense
if
you're
just
writing
down.
What's
already.
I
E
I
mean
yeah,
it's
it's
it's
a
great
idea.
It's
it's
just!
It
needs
to
be
investigated.
You
know
what
are
the
use
cases,
what
kind
of
verticals
we
are
focusing
on
to
have
this
to
have
the
standard
so
yeah?
I
think
it's
a
good
idea,
but
we
have
to
see
who
are
the
people
who
are
interested
in
doing
something.
I
I
If
there's
any
sort
of
crossover
with
other
domains,
especially
then
it
might
be
really
valuable
to
have
to
have
this
kind
of
thing
available
on
on
multiple
channels
so
yeah,
I
guess
I'd
I'd,
encourage
following
up
on
nothing
on
that
question.
If
that's,
if
that's
on
the
table-
and
certainly
you
can
contact
me
to
chat
about
it-
I
have
a
few
things
on
my
plate,
but
but
this
might
be
something
that
could
make
the
cut
for
me
great.
I
E
Yes,
so,
based
on,
I
think
the
feedback
I've
also
got.
I
think
the
next
steps
for
me
are
still
the
same.
I
didn't
notice
something
different.
I
get
some
further
very
nice
inputs
that
people
would
like
to
review
this.
So
my
next
steps
already
were
completing
integrating
reviews
getting
more
reviews
and
then
following
the
publication
in
itf
as
the
informational
rfc.
So
I
see
that
this
state
stays
the
same
and
yeah
that's
the
close
of
my
talk.
Thank
you
very
much
for
that.
C
E
C
F
C
A
B
J
J
J
Now
things
have
always
been
on
the
internet,
so
iot
is
maybe
not
not
a
good
description
of
what
we
are
actually
focusing
on.
The
work
usually
has
been
focused
on
constrained
node
networks,
so
essentially
we
we.
We
have
a
situation
where
our
nodes
are
constrained.
The
nodes
have
to
live
with
very
little
power,
they
have
memory
on
the
order
of
a
couple
dozen
kilobytes.
J
They
have
very
little
space
for
call
complexity
and
so
on,
and
it's
the
constraints
on
the
nodes
that,
in
the
end,
influence
the
constraints
on
on
the
network
so
that
there
are
constrained
networks.
So
if
you,
for
instance,
have
two
tanks
running
through
some
field
and
they
want
to
communicate,
they
may
have
network
constraints,
but
these
are
really
no
constraints
and
tanks,
don't
have
them
as
much
as
say
a
light
switch.
J
So
the
important
observation
is
that
not
all
nodes
are
constrained,
so
we
don't
assume
that
we
we
have
to
make
every
function.
Work
on
on
16,
kilobyte,
ram
node,
but
iot
networks
need
to
be
able
to
accommodate
these
constraint
nodes
so
so
that
that's
really
the
interesting
part,
and
what
happens
is
that
we
just
have
this
immense
scaling
up
in
the
number
of
nodes
and
that
we
know
how
to
do
to
scale
up.
That's
the
easy
part.
J
J
There
is
a
yellow
boundary
where,
where
the
internet
technologies
essentially
still
can
be
used
unchanged,
even
if
we
have
constrained
limitations
of
them
and
then
there
is
some
point
where
you
actually
have
to
change
the
internet
technologies
themselves
and
by
by
pushing
this
yellow
bar
a
little
bit
to
the
left,
we
can
get
a
lot
of
surface
under
this,
this
graph
of
complexity
and
count
of
implementation.
So
it's
really
worth
doing
that.
J
So
the
first
activity
that
that
I
would
explicitly
explicitly
call
iot
started
in
2005
the
six
low
pen
working
group.
This
essentially
was
an
observation.
There
is
this
network
called
80215.4
that
can
send
packets
up
to
80
bytes,
and
we
really
don't
want
to
send
a
40
byte
ipv6
header
over
this
network.
So
we
need
a
little
bit
of
more
than
usual
work
to
actually
make
this
reasonably
performant.
J
J
J
J
They
are
connected
to
a
border
router
by
a
bottle
router
to
the
general
internet,
but
all
six
low-pan
nodes
know
that
that
they
are
in
a
six
floor
panel.
So
all
paths
through
a
six
load
pattern
terminate
in
at
least
one
six
lopen
nodes,
so
the
other
side
may
be
a
corresponding
host
somewhere
in
the
general
internet.
But
one
one
end
knows
it's
a
six
loop
and
node.
So
we
can
make
a
lot
of
simplifying
assumptions
here
today.
We
would
call
this
a
limited
domain
according
to
rfc879,
because
we
have
this
boiler
router.
J
It
finally
was
written
up
in,
in
the
sixth
hand,
book
in
2009
and
and
15
years
later,
in
an
rfc,
and
this
means
that
we
really
can
do
strange
things
in
in
this
space
because
it's
a
limited
domain
and
we
have
been
doing
stranger-
things
which
are
fragment
recovery,
which
is
the
word
that
has
been
used
to
smuggle
a
layer.
2
win
transmission
scheme
by
the
transport
area.
J
So
there
is
rfc
8931
which,
if
you
remember
my
attempts
to
get
local
optimizations
or
path
segments
things
started.
It's
essentially
loops
for
six
lopez.
So
we
do
re-transmission
on
layer
2.5,
for
the
simple
reason
that
if
you
have
to
fragment
things
and
not
all
of
these
fragments
arrive,
then
you
are
really
wasting
energy.
J
J
J
So
we
we're
talking
about
megabits
per
second
and
here,
but
for
second
terabits
per
second,
but
they
are
talking
about
networks
with
six
millibits
per
second
sustained
throughput
in
at
least
one
direction,
and
that
means
your
header
compression
has
to
be
much
much
better
and
that
has
been
addressed
by
the
ap
when
working
rubens
called
static,
static
context,
header
compression,
so
you
wouldn't
even
think
about
congestion
control,
because
you
can
only
send
a
couple
millibits
anyway.
So
what
would
that
mean?
J
And
you
probably
know
about
that
net
and
and
the
the
spin
of
the
raw
working
group
who
are
doing
deterministic
networking,
which
essentially
again
is
the
limited
domain
technology
and
raw
is
essentially
doing
the
same
thing
over
wireless,
and
this
is
actually
doing
all
the
things
that
that
we
want
about.
You
shouldn't
be
doing
in
rfc
3819.
J
Actually,
in
the
iot
world
we
do
need
transports,
of
course,
but
much
happens
on
top
of
udp,
because
there
are
so
few
opportunities
to
actually
send
and
so
on.
Udp
is
often
the
appropriate
protocol
on
top
of
ip
and
trying
not
to
call
it
a
transport
protocol
and
we'll
see
when
I
get
to
co-op
in
the
next
slide
how
that
works.
J
But
of
course
you
can
use
tcp
even
in
constrained
node
networks,
at
least
if
they
are
not
too
constrained,
and
there
is
a
recent
rfc
that
actually
describes
how
tcp
can
be
used
productively
in
the
iot
and
that's
used
a
lot.
There
is
a
non-itf
protocol
called
mqtg
that
is
based
on
tcpe
and
that
is
used
in
a
lot
of
iot
networks
and
and
that's
good
that
we
finally
have
written
up
how
to
use
tcp
in
this
space.
J
J
J
J
Want
to
do
take
10
years,
so
we
put
the
transport
functions
in
the
application
there
protocol
and
that
is
correp
constrained,
duplication
protocol,
which
was
approved
four
years
later
and
published
a
year
later,
because
we
didn't
think
too
much
about
misreps.
We
are
now
much
more
aware
about
avoiding
misreps,
as
you
probably
are
as
well,
and
so
here
the
idea
was
to
to
do
this
based
on
udp,
mostly
with
dtls,
as
as
a
security
protocol.
J
J
You
have
binary
exponential
back
off
if
the
first
attempt
doesn't
go
through
and
if
you
ever
need
unacknowledged
transfer
that
is
limited
to
a
parameter.
The
parameter
usually
is
one
byte
per
second,
so
that
that's
useful
data
rate
in
the
iot.
So
that's
what
we
thought
might
be
a
good
basis
for
for
unacknowledged
transfers.
J
So
you
don't
send
megabits
per
second
into
funeral
so
that
that's
basically
the
the
idea
having
an
application
protocol
that
is
lightweight
enough
on
the
network
that
you
can
run
it
without
actually
coming
up
with
a
special
transport
protocol,
and
I
should
probably
add
that
coip
is
a
rest
protocol.
So
like
http,
it
has
a
client
server
operation
with
operations
like
create,
read,
update,
delete
and
it
uses
the
rest
architectural
style,
which
was
described
by
roy
fielding.
J
The
initiative
is
on
the
client
and
so
on,
and
we
try
to
minimize
the
state
on
the
server
and
well.
Http
cannot
do
that
because
there
is
a
tcp
connection,
so
you
you
always
have
state
on
the
server,
even
if
the
http
protocol
may
not
be
too
aware
about
that,
but
corb
really
tries
to
minimize
the
amount
of
state
that
is
on
the
server,
because
the
server
is
likely
to
be
a
very,
very
constrained
sensor
that
you
query
using
a
get
operation
now.
J
Sensors,
of
course,
sometimes
have
new
data
so
that
there
is
a
notification
mechanism
that
is
needed,
and
you
know
that
http
has
various
notification
mechanisms
that
are
all
hilariously
complicated
and
we
decided
we
wanted
to
have
those
in
the
protocol
and
not
as
backpacks
on
top
of
the
protocol.
So
we
put
in
a
fifth
operation
notification,
so
you
can
send
a
get
together
with
an
observe
option,
and
that
means
give
me
the
data
now,
but
also
give
me
the
data
each
time
it
changes.
J
J
J
Configuration
cannot
fill
a
line.
You
never
get
more
than
one
packet
in
a
flight.
Everything
is
lockstep
and
you
cannot
even
adjust
your
rto
to
a
faster
network,
so
binary
back-off
kind
of
deals
with
slower
networks
almost,
but
you
cannot
adapt
to
a
faster
network.
So
if
you
have
a
packet
loss
of
30
percent,
because
your
your
low
power
network
really
has
interference
problems,
you
have
pretty
bad
performance
and
the
idea
was
to
do
a
congestion
control
protocol
that
is
essentially
based
on
6298,
and
so
it
has
a
very
simple
state.
J
That
would
be
a
problem,
so
we
got
stuck
with
that
in
2018
and
probably
have
to
recover
it
at
some
point,
there's
also
an
alternative
proposal
called
phaser,
which
was
unveiled
when
when
coco
get
got
kind
of
stuck
but
yeah,
that's
also
currently
stuck
because
the
authors
are
apparently
doing
something
else.
Okay,
I
just
wanted
to
mention
it,
because
congestion
control
is
something
that
transport
of
course
is
interested
in,
and
that
might
come
back
at
some
point.
But
the
last
thing
I
really
wanted
to
talk
about
is
the
the
block-wise
aspect
of
transport.
J
J
So
you
really
need
to
be
able
to
work
in
this
significant
distress
situation
and
that's,
of
course,
a
kind
of
congestion.
So
you
can't
really
use
basic
the
the
usual
congestion
control
mechanism
because
they
will
just
notice.
Oh
there
are
way
too
many
packets
on
this
link.
So
let's
send
the
data
very
very
slowly,
and
you
know
that
tcp
occasionally
gets
into
these
states
where
it
doesn't
really
make
any
progress
at
all
anymore.
J
J
B
J
7959
the
standard
clockwise
mechanism-
it's
no
longer
strictly
lockstep,
so
you
you
actually
can
send
several
packets
at
once.
It
can
recover
blocks
that
were
lost,
so
we
are
kind
of
in
the
fragment
recovery
space
that
we
already
covered
in
in
sixth
law
pen
and
the
whole
set
of
parameters
that
govern
all.
This
is
now
actually
negotiated
between
peers.
J
So
this
is
a
very
different
approach
from
the
normal
approaches
and
it
only
works
when
again,
you
are
in
a
kind
of
limited
domain
situation.
So
normally
you
have
a
dots
channel
to
some
upstream
provider.
So
you,
you
have
a
pretty
good
idea.
What
is
behind
between
you
and
your
upstream
providers?
You
may
be
able
to
actually
negotiate
this
in
a
more
meaningful
way,
but
it's
it's
a
rather
different
beast
from
from
co-op.
So
it's
robust,
I
would
probably
call
it
aggressive.
A
Thanks
carsten,
so
it
was
the
core
new
block
proposal
that
really
kind
of
caused.
I
had
an
eye
to
say:
we
should
really
take
this
to
the
area
because
it's
becoming
very,
very
transporty.
If
you
take
a
look
at
that
draft,
that's
already
through
the
isg,
but
I
mean
I
would
be
interested
in
people's
thoughts
about
the
state
of
this
work
and
if
we
need
to
stage
some
sort
of
intervention
as
an
area,
I
guess
is
the
way
to
say
it
right.
K
Thanks
carson
for
the
presentation,
but
to
me
this
presentation
made
it
even
more
clear
that
using
cope
for
a
use
case
like
dots,
is
just
not
a
good
fit.
It
wasn't
designed
for
this
kind
of
use
case.
It
was
designed
for
small
data
transmissions
in
in
domains
where
you
have
like
better
control
than
on
the
internet,
and
even
so
like
some
of
the
features
might
be
exactly
what
the
dots
people
want.
J
I
K
It
would
have
worked
because
they
would
probably
have
needed
to
design
the
dodge
protocol
differently
right.
So
that's
why
I'm
saying
I
would
I
would
wish
we
have
would
have
detected
this
much
earlier
in
the
process,
because
that
has
like
a
lot
of
implications.
Changing
that
right
now
is
too
late.
I
understand
there
are
so
many
dependencies,
but
maybe
the
initial
choice
here
was
was
the
problem.
A
J
I
think
this
is
well.
You
never
know
whether
it's
going
to
be
a
one-off,
because
there
may
be
other
people
who
also
have
a
situation
where,
where
they
need
something
like
this,
so
that
it's
now
an
attractive
protocol,
as
we
used
to
say
so,
other
people
may
might
find
it
and
say:
oh
yeah,
that
solves
our
problem.
That's
let's
use
that.
But
again
we
have
to
be
very
cognizant
that
it
is
meant
for
limited
domains
and
it's
not
something
you
you
would
run
on
the
general
internet.
A
Well,
limited
domains
may
be
one
of
the
most
hated
terms
in
the
itf,
but
fair
enough.
Like
I
I
I
I
do
wonder
that
if
this
is,
you
know,
I
mean
looking
at
the
taps,
working
group
and
some
other
things
have
really
kind
of
broadened.
My
my
my
thought,
my
definition
of
what
transport
is,
and
it
feels
like
co-op,
is
becoming
a
full-fledged
transport
that
needs
to
be
evaluated
as
such,
but
I'll.
Let
mira
talk
now.
K
I
just
wanted
to
comment
on
the
term
limited
domain,
because
I
was
heading
this
comment
on
my
on
my
heart
all
the
time.
I
don't
think
that's
the
right
term
here
right
and
the
way
limited
domain
is
used
is
or
like
in
the
in
the
respective
drive
that
was
published
on
the
ise
stream
was
like
something
that
is
connected
to
the
internet,
but
can
be
somehow
controlled
or
not.
J
Yeah,
I
noticed
that,
despite
87.99
being
published,
we
don't
quite
agree
on
what
their
limited
domain
is,
but
I
I'm
not
so
much
interested
in
the
term.
I'm
I'm
interested
in
being
able
to
to
do
things
I
wouldn't
want
to
do
on
the
general
internet
as
long
as
I
can
make
sure
they
are
not
done
in
the
general
relationship.
K
Yeah
definitely,
and,
as
you
explained
very
well
like
this-
was
the
constraints
that
co-op
was
designed
with
right.
It
was
like
in
a
domain
where
you
have
a
different
referral
control
and
it
was
so
not
the
public
internet
and
it
was
for,
like
a
very
specific
traffic
type
and
trying
to
apply
cope
as
a
general
transport
to
other
use
case
scenarios.
I
think,
really
needs
more
work
and
maybe
also
more
transport
eyes.
K
If
that's
happening,
then
we
should
definitely
take
this
on
in
the
transport
area,
but
I'm
not
sure
where
this
is
going.
I
hope
that
actually
dots
dot
was
just
like
one
single
case,
and
this
is
not
general
pattern
that
we're
seeing
not
because
cope
is
a
bad
protocol,
but
because
coke
was
designed
with
so
specific
constraints
in
mind,.
J
A
My
understanding
of
dots
was
there's,
not
necessarily
a
limited
domain
that
that
you
know
you
have
a
you,
have
a
server
somewhere
that
could
be
under
attack
and
then
there's
a
an
inline,
not
an
inline,
but
some
sort
of
like
third
party
service
that
I
actually
topologically
quite
far
from
from
the
server
but
but
regardless.
I,
I
guess
the
takeaway
here
carson
is
just
as
somebody
who
is
involved
in
this
co-op
work.
A
A
You're
always
welcome
to
come
back
and
let
us
know
what's
going
on
and
we
can
bring
it
to
here
to
and
and
hopefully
that
will,
but
hopefully
that
will
avoid
some
of
the
worst
outcomes
in
terms
of
doing
things
that
transport
area
would
not
recommend.
But
thank
you
very
much
for
your
presentation.
Are
there
other
any
other
comments
or
questions
in
the
queue
about
this?
A
I
don't
see
any
so
carson.
I
appreciate
you
putting
this
together.
I
learned
a
lot.
I
mean
this
iot
stuff
is
really
sprawling
and
it's
great
to
see
the
high
level
thing
to
orient
people
to
the
space,
because
I
think
it
may
be
coming
back
to
us
to
hear
more
about
later,
so
this
orientation
will
be
a
wonderful
thing
to
point
through
point
two,
and
this
also
gave
us
a
ton
of
those
you
in
the
jabra
a
ton
of
interesting
cheese
and
toaster
puns.
So
there's
that
too.
So,
thanks
for
that
everybody.
A
D
I
have
the
last
two
to
ietf
meetings.
I
usually
wait
till
the
the
agenda
settles
down
before
I
upload
stuff
into
my
calendar
and
that
that
means
that
I
usually
miss
the
80
office
hours
for
tsv,
because
they're
the
week
before.
I
wonder
if
you
guys
have
thought
about
also
offering
something
the
week
after
just
because
you
know
it's
a
long
time
from
now
until
the
week
before
ietf
won
play,
but
I
I
know
you
will
do
the
right
thing
and
I'm
I.
D
A
You
well
thank
you,
spencer,
zaha
and
I
are
both
gonna
be
on
vacation
next
week,
so
we
will
not
be
holding
office
hours.
That
said
like,
if
you,
if
you
have
something
that
can't
wait
by
all
means,
email
us
and
we
can
arrange
an
appointment
prior
to
prior
well
before
112..
I
will
also
actually
use
this
occasion
to
pitch
there's
a
tsv
area
mailing
list,
tsv
area
at
ietf.org,
if
you're
not
on
it,
you're,
not
getting
direct
email
from
your
ads.
A
A
A
H
A
A
I
I
will
say
that
the
iesg
is
encouraging
interim
use
over
this.
This
pandemic
thing
as
long
as
it
lasts
because
of
the
limited
number
of
meeting
slots.
We
are
we've
limited
groups
to
two
hours
and
our
thought
was
that
you
know
as
chairs
and
some-
and
I
think
I
sent
an
email
to
this
effect,
but
for
the
interest
of
anyone
who
didn't
doesn't
remember
that
or
didn't
see
it.
The
intent.
A
That
really
are
good
for
the
greater
community
and-
and
we
asked
our
chairs
to
kind
of
filter
that
stuff
and
if
you
had,
if
you
had
more
than
two
hours
of
material
to
put
the
stuff
that
which
community
into
the
main
meeting
and
the
rest
of
the
interim,
so
yes,
please
do
interims.
I
don't
think
the
volume
is
so
large
that
we
need
to
deconflict
things.