►
From YouTube: IETF114 RAW 20220727 1400
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
I
make
that
10
o'clock
by
my
laptop
but
I,
don't
know
how
accurate
my
ntp
sources
so,
hello,
everybody.
Let's,
let's
start
the
meeting
a
few
people
can
dribble
in
at
the
back.
It's
absolutely
fine,
so
this
is
reliable
and
available
Wireless
raw.
This
is
not
the
wrestling
organization.
This
is
actually
an
ietf
working
group.
A
So
if
you're
in
the
wrong
meeting
now's
your
chance
to
leave
and
take
your
plastic
chairs
with
you
sorry
budget,
so
Eve
unfortunately
wanted
to
be
here
in
person,
but
can't
make
it
so
she's
dialed
in
remotely.
So
you
just
have
me
in
the
room,
but
I
think
that
should
be
a
pretty
good
combination
for
for
both
of
us.
So
first
off
this
is
an
ITF
working
group
meeting,
therefore
covered
by
the
note
well
I'm,
hoping
by
Wednesday.
A
You
will
have
at
least
come
across
a
note
well
before
I
am
not
a
lawyer,
but
as
I
am
led
to
believe
by
people
who
are
basically,
this
means
anything
you
contribute
at
the
microphone
or
in
the
chat
or
submit
to
the
mailing
list
is
covered
by.
You
are
releasing
that
IPR.
If
you
have
any
concerns
over
this,
please
consult
the
references
in
the
note.
Well,
please
look
at
it
as
a
serious
document
and
try
and
avoid
making
any
mistakes.
A
If
you
are
unsure,
don't
say
anything
read
the
note
well
and
then
say
something
this
is
freely
available
in
various
places
in
the
ITF.
So
I
suggest
you
go
back
and
look
at
it
if
you
haven't
read
it
before,
and
this
is
a
list
of
of
reference
to
the
various
important
parts
in
here,
including
code
of
conduct
as
well
as
copyrights,
Etc.
A
So
important
tips,
given
this
is
hybrid
meeting,
we
have
people
in
the
room
and
we
also
have
people
remotely
and
in
order
to
ensure
that
we
can
maintain
a
single
cue
for
comments.
Etc
I
recommend
everyone
in
the
room
uses
the
meat
Echo
either
the
on-site
tool.
There
are
QR
codes,
liberally
scattered
around
the
room
which
take
you
straight
to
the
on-site
version
of
the
the
tool
which
allows
you
to
join
the
queue
and
get
yourself
out
of
the
queue
quite
quickly
and
easily
those
of
you
well.
A
It
seems
a
bit
strange
thing
to
say
those
of
you
who
are
at
home
dialed
into
meteco.
You
need
to
dial
into
meteco,
but
if
you're
listening
to
the
audio
streams,
there
is
meteca
which
gives
you
a
nice
video
conferencing
facility,
and
you
can
see
the
slides
as
well.
Information
on
that
I
believe
we
put
on
the
next
slider
up
yeah.
Here
we
go
so
information
on
how
to
get
access
to
meet
Echo
is
available
via
the
data
tracker
and
the
the
agenda
also
has
links
to
it
as
well.
A
So
good
news
we
don't
have
to
fill
in
blue
sheets
anymore.
It's
all
automatically
done
through
your
log
into
the
various
me
take
of
things.
We
we
haven't
integrated
note
taking
facility
built
into
meet
Echo.
We
would
like
people
to
use
it.
A
Please
make
sure
that
someone
is
collaboratively
recording
some
minutes
if
anyone
wants
to
put
their
hand
up
and
say,
I
want
to
be
the
main
driver
of
that.
That
would
be
great.
Otherwise,
please
ensure,
if
you're,
making
a
point
at
the
microphone
that
your
name
is
spelled
correctly
in
the
minutes
and
that
the
the
meat
of
what
you
were
trying
to
say
is
also
recorded
in
the
minutes,
just
so
that
there's
no
confusion
at
a
later
date.
A
The
link
to
the
built-in
hedge
dock
tool
is
also
on
this
slide,
as
well
as
there's
a
convenient
button
in
meteco.
As
ever,
we
have
a
mailing
list.
It's
rawatf.org,
if
you
need
to
contact
the
chairs
for
any
reason,
there's
raw
hyphen
chairs
at
ietf.org.
That.
B
A
So
oh
formatting
has
gone
great
our
agenda
for
today,
the
intro
by
myself
and
Eve
and
Eve.
Please
just
jump
in.
If
you
have
any
comments,
it's
always
difficult.
A
We're
going
to
kick
off
with
a
discussion
about
the
eldax
draft,
which
is
has
gone
to
the
isg,
has
had
a
number
of
review
comments
and
I'm
looking
at
John
rad
here,
because
I
think
we
just
need
to
have
a
grown-up
conversation
with
you
about
what
do
we
do
now,
because
we've
got
a
bit
stuck
between
the
authors,
the
chairs,
the
working
group
as
a
whole
and
the
iesg
reviewers,
and
we
need
to
think
of
a
way
forwards
here.
There's
been
some
discussion,
but
I'd
really
like
to
get
that
resolved.
A
A
So
Pascal's
got
a
nice
big
slot
to
talk
about
that,
because
I
think
it's
the
meat
of
of
of
the
working
group's
work.
At
the
moment
we
got
a
Wi-Fi
update
from
Jerome,
Ori,
I,
believe
or
being
French.
It
may
just
be
Henry
I'm,
sorry
if
I've
mispronounced,
your
name
talking
about
what
IEEE
are
doing
in
terms
of
reliability
in
the
in
the
Wi-Fi
specs
that
are
coming
Carlos,
has
got
a
short
presentation
on
the
on
the
latest
updates
to
the
use
cases
document
what's
happening
with
that.
A
That
I
have
an
apology
to
make
there.
It
was
looking
for
a
document
Shepard
for
a
while
it
was
ready
to
go
to
isg
and
the
chairs
dropped.
The
ball
on
that
it
should
be
getting
a
write-up.
It
should
be
ready
to
go
pretty
soon,
so
hence
just
a
quick
one
from
from
Carlos
he's,
also
presenting
about
the
multi-domain
extension.
So
that's
reasonably
new
work,
and
that
will
be
interesting.
A
So
looking
forward
to
that
and
then
Bob
muskowitz
has
asked
for
a
15-minute
slot
to
talk
about
transports
that
would
run
over
a
raw
slash
debt
net
Network.
So
once
we
have
built
this
technology,
we've
got
the
control
planes
in
place.
We
can
start
to
lay
down
some
reliability
from
end
to
end.
A
How
do
we
make
transports?
Not
do
the
dumb
thing
on
top
and
then
break
all
our
hard
work,
so
I
can
see
that
being
interesting
contentious.
It
may
not
be
a
perfect
topic
for
raw,
but
it's
a
great
place
to
start
the
discussion
and
I'm
glad.
We've
got
a
couple
of
ads
in
the
room
because
I
imagine
there'll
be
a
discussion
about.
Does
this
get
shut
across
to
transport
Etc
and
then
we've
got
30
minutes,
Open
Mic,
which
will
turn
into
30
minutes
of
we've
eaten
that
time
by
overrunning
constantly.
A
A
C
C
As
you
heard,
we
are
hoping
to
get
some
advice
and
guidance
around
what
our
next
steps
are
for
the
ldocs
document.
The
use
case
document
is
awaiting
the
the
write-up.
C
Oh
no
sorry,
the
use
cases
is
also
in
the
review
phase,
but
it's
the
raw
Technologies
document
that
awaits
the
write-up.
C
We
have
had
these
multiple
interim
meetings
to
make
progress
on
the
architecture
document,
and
so,
fortunately
it
is
shaping
up
and
we
have
segregated
the
framework
which
is
sort
of
the
future
facing.
What
do
we
do
from
the
architecture
which
kind
of
outlines
what
the
problem
statement
is.
C
The
RAW
oam
support
document
is
also
making
progress.
That
is
something
that
has
in
a
previous
Incarnation,
been
separate,
separated
from
the
detnet
oam
document,
which
has
been
making
steady
progress.
C
We
also
have
an
industrial
requirements
document
that,
although
it
is
expired
at
the
moment,
we
did
get
confirmation
from
the
authors
that
they
are
going
to
renew
that
document
and
we
felt
that
it
was
pretty
close
to
submission,
or
at
least
ready
for
working
group.
Last
call
as
Rick
had
indicated.
C
There
are
some
other
documents
that
are
under
consideration
that
are
more
recent
documents
and
the
there
are
three
of
those
these
fall
into:
Carlos's
Camp,
The,
Joint
selection,
the
raw
joint
selection
document
that
is
related
to
the
Mec
technology
and
then
a
more
General
MEC
technology
draft
and
a
multi-domain
draft.
That
again,
we
will
have
a
little
bit
of
discussion
about
it
here
today,
and
it
also
is
getting
some
discussion
elsewhere.
I
believe
there's
some
discussion
about
multi-domain
in
the
detnet
agenda
as
well.
A
Oh,
okay,
no
worries
so
just
a
quick
update
on
where
we
are
in
terms
of
the
chartered
Milestones
short
answers
we're
about
halfway
purely
by
count,
so
we've
got
a
sufficient,
which
is
good
for
a
working
group.
A
To
be
honest,
we
still
have
a
few
more
things
to
to
get
ready
for
the
iesg
one
major
document
that
that
we
will
approach
towards
the
end
of
this
Charter
cycle
is
or
actually
we
can
start
working
on
now,
if
there's
people
who
are
interested
in
contributing
to
it
in
the
charter
there
has,
there
is
a
line
to
say
the
working
group
will
produce
an
evaluation
of
existing
ietf
Technologies
and
produce
a
gap
analysis
document.
A
So
this
is
all
about
not
Reinventing
the
wheel
and
coming
up
with
unique
Solutions,
based
on
our
understanding
of
the
problem
space,
but
understanding
what
the
ietf
has
already
got
in
its
toolbox
to
solve
some
of
these
OEM
issues.
Some
of
these
control
plane
issues.
Some
of
you
know
this
may
cross
over
entities.
A
This
will
definitely
cross
over
into
debt
debt
and
to
make
sure
that
we're
not
inventing
yet
another
protocol,
because
we
didn't
talk
to
anyone
else
so
volunteers
to
start
that
document
or
some
way
to
collaboratively
work
on
that
document
and
it's
quite
an
important
Milestone
and
I
just
want
to
highlight
that
to
people.
Otherwise
we
are
taking
off
Milestones,
which
is
good,
so
50
through.
A
Okay,
so
now
we
will
start
on
the
main
agenda,
so
I
think
first
up
is
ldax
with
Niels.
If
you
are
online
I
hope
you
are
I,
think
I
saw
you
earlier.
I
will
share
your
slides
and
pass
you
control.
D
E
D
It
but
that's
a
different
story:
let's
focus
on
version
11,
because
the
main
changes
were
made
so,
as
already
said,
yes,
not
well
I
think
you
covered
that
extensively.
D
Here's
the
the
abstract
or
basically
the
front
page
and
compared
to
last
time
we
added
one
very
important
sentence,
and
that
is
the
intent
of
this
document-
is
to
introduce
ldx
to
the
IDF
Community,
raise
awareness
on
related
activities
inside
and
outside
of
the
ITF
and
to
seek
expertise
in
shaping
the
shift
of
Aeronautics
to
AP.
So
what
we
want
to
say,
as
authors
of
this
document,
is
that
we
do
not
bring
ldx
as
an
externally
defined
data
link
to
the
IDF
and
then
expect
that
the
ITF
standardizes
the
data
link.
D
But
what
we
want
to
do
here
is
basically
inform
the
ITF
and
seek
Council
on
that.
The
entire
aeronautical
communication
is
now
transitioning
from
previously
analog
to
proprietary
Solutions
now
to
the
IP
world,
and
basically,
the
new
data
links
defined,
such
as
ldx
and,
as
I
said.
We
wanted
to
raise
awareness
and
and
seek
counsel
on
how
to
proceed
here,
and
this
is
why
we
thought
it's
very
important.
To
mention
that
right
there
in
the
abstract,
with
the
intent
of
this
document,
is,
as
you
can
see,
there
were
quite
some
changes
since
last
times.
D
Every
blue
dots
is
one
big
change
actually
and
because
we
got
so
many
reviews,
and
actually
we
really
have
to
thank
the
isg
here
for
for
their
hard
work,
because
I
think
in
the
end
it
was
like
40,
word
pages
of
emails
and
and
comments,
and
we
incorporated
all
of
the
requested,
updates
and
I
try
to
summarize
them
in
in
the
in
the
major
issues,
and
those
were
that
one
question
is
that
how
is
ldx
actually
interacting
with
IPv6,
and
also
that
there
was
a
request
on
details
on
the
frame
structure
and
protocol
again.
D
Then
several
big
issues
that
were
mentioned
were:
what
is
the
intent
of
this
document?
What
do
we
want
to
do
and
does
it
pass
consensus
borrow
set
by
the
RFC
8789?
D
That's
something
that
the
authors
cannot
decide.
This
will
have
to
be
decided
by
the
ads
or
the
isg,
and
also
the
the
security
part
had
to
incorporate
IPv6
cons,
security
concentrations
over
ldx
and
there's
another
issue
that
came
up.
Unfortunately,
many
of
the
aeronautical
standards
are
behind
the
paywall,
so
for
a
further
review
we
can
give
out
those
documents
by
some
special
access,
but
unfortunately,
as
I
said,
these
are
behind
the
table.
So
it's
really
hard
to
review
the
document.
D
If
we
cite
them
directly
so
here
the
the
main
answers,
so
what
is
ldx
ldx
is
actually
a
layer
too.
A
link
layer
technology
that
is
standardized
currently
with
the
international
civil
aviation
organization
and
the
intent
of
this
draft
is
basically
to
introduce
the
IP
supporting
data
link
to
the
ITF
Community,
because
simply
saying
here's
a
400
page
document
specifying
ldx
have
fun
with
it.
Didn't
really
didn't
really
seem
like
a
good
idea.
Then.
The
second
part
is
that,
as
I
said,
current
aeronautical
Communications
is
transitioning
to
the
IPS.
D
That's
the
Internet
Protocol
Suite
that
is
currently
also
defined
at
the
Iko
and
ldx
will
be
one
of
the
access
Technologies
enabling
that
part.
D
D
That's
basically
a
chat
application
between
the
aircraft
and
the
Groundswell
pilot
and
air
traffic
controller,
and
this
cpdlc
was
secured
by
dtls,
and
so
yes,
everything
was
done
by
IPv6
and
how
that
worked
was
that
ldx
defines
1536
byte-large
user
data
packets,
in
which
then
the
IBM
36
traffic
is
encapsulated
and
because
Ikea
decided
that
the
transport
protocol
should
be
UDP
in
any
case.
So
basically,
this
is
how
it
Stacks
up
them.
D
Then
the
the
handovers,
because
there
was
one
question.
We
also
demonstrated
that
during
the
last
two
weeks
they
are
seedless
and
and
basically
transparent
to
the
Appellate.
So
you
switch
from
ground
ground
station
to
another.
You
don't
see
any
hiccups
on
the
data
link,
so
you
don't
really
experience
large
latency
if,
if
like
you're
transitioning
from
one
ground
station
to
the
other,
it's
just
you
switch
over
and
the
packets
go
through,
and
you
notice
basically
nothing.
D
Then,
as
I
said
with
the
future
communications
infrastructure
with
the
different
data
links.
Ldx
is,
is
a
part
of
that
already
mentioned.
That
and
the
important
thing
here
is
that
there's
also
a
Mobility
solution
envisioned
now
for
the
in
IP
Mobility
solution
and
vision
for
the
entire
thing.
So
for
the
flight
campaign
we
used
for
the
Access
Network
payment
V6
and
then
for
the
FCI
multi-link
concept.
There's
current
work
going
on
to
use
a
list
based
Mobility
solution
for
switching
between
FCI
links.
D
However,
this
is
not
a
part
that
is
obviously
standardized
Itself
by
ldx,
but
is
is
some
idea
that
ldex
will
play
a
part
in
then
the
last
two
things
ldx
as
a
link
layer
has
security
defined
for
user
and
control
plane
so
before
an
aircraft
can
actually
successfully
communicate
with
ground.
D
Protecting
the
the
necessary
control
messages
over
the
air
gap
and
the
last
Point,
as
I
already
said,
so
for
future
reviews,
or
in
case
anyone
in
the
audience,
is
interested
for
reviewing
this
document.
We
can
provide
the
standards
behind
the
paywalls
for
review
purposes.
Only
now,
I
use
already
a
lot
of
my
time.
So
let
me
be
brief.
With
with
the
rest
of
the
presentation,
what
did
we
change
in
the
text?
So,
as
I
said?
First
part
in
the
introduction?
What
is
the
actual
intent
of
of
this
document?
D
I
would
recovered
that
the
second
part
was
so.
We
were
asked
that
determinology
chapter
2
should
be
renamed
acronyms
and
also
we
streamlined
that
the
next
part
was
that
we
would
ask
what
sources
are
available.
What
standards
are
available?
Where
can
find
out
hey
house
IPv6
over
either
eldex
or
any
other
multi-link
candidate
handled?
So
we
added
in
the
references
were
applicable
and
also
to
the
FCI,
and
it
states
the
links.
D
Then
the
applicability
I
already
said
that
so
within
the
ldx
access
network,
local
Mobility
solution
will
be
payment
V6
and
within
the
sci,
the
global
Mobility
solution.
We
were
implemented
on
top
of
lisp
and
we
had
some
questions
about
the
AP
and
T,
which
is
that
you
can
use
ldx
also
for
navigational
purposes,
and
if
you
have
several
class
stations-
and
you
know
the
channel
quality,
you
know
their
exact
position.
You
can
basically
navigate
VIA
aldex,
which
has
also
been
demonstrated
already.
2019.
D
next
part
was
how
is
the
setup,
so
this
is
with
the
characteristics
here.
On
the
right
hand,
side,
the
the
H,
the
ATN
is
the
aeronautical
traffic
Network.
So
that's
where
traffic
controllers
put
in
their
traffic,
then
the
air
ground
router,
is
interface
to
the
access
network.
D
Then
we
have
the
several
ground
stations
connected
by
a
control
plane,
but
also
user
plane,
and
the
ground
station
is
the
actual
ldex
ground.
Radio
connected
to
the
aircraft
done
for
the
protocol
stack
I
would
refer
to
the
draft
if
you're
interested
in
finding
out
more
details,
but
we
updated
that
now
to
include
all
kind
of
control
traffic
which
hasn't
been
included
before
about
reliability
in
the
availability
of
a
clarified
that
priorities
are
managed
by
the
diffserv
classes.
D
Csr1
is
the
lowest
priority
series
of
highest
priority,
so
we
have
prioritization
between
eight
different
traffic
classes,
that
ldx
supports
and
multiple
ground
stations
available
visible
to
the
aircraft
at
the
same
time.
So
for
the
cell
planning
it's
absolutely
possible,
let's
say
one
ground
station
is
down
for
maintenance.
The
the
signal
power
is
strong
enough
that
I
think
if
even
foreground
stations
within
the
same
regions
are
cut
out.
D
You
can
then
seamlessly
simply
switch
to
the
fifth
and
still
continue
Service
as
usual
for
security,
something
very
important
that
I
wanted
to
mention
here.
So
what's
the
security
requirements
for
ldx
and
to
put
it
in
a
nutshell,
to
provide
a
secure
Channel
between
the
Airborne
radio
system
and
the
peer
radio
access
endpoints
on
the
ground
to
ensure
authentication
Integrity
of
air
ground
message,
exchanges,
so
basically
entity
authentication
falls
under
this
category
and
then
establishing
Keys
deriving
them
and
using
them
to
secure
especially
authenticity
and
integrity
of
their
Grant
messages.
D
Now,
I'm,
at
the
end
of
my
presentation
and
now
my
questions
to
through
the
chess,
so
we
worked
extensively
on
on
this
document
over
the
last
three
months.
I
think
we
covered
every
every
aspect
that
we
could
cover
by
the
comments
and
now
the
question
is:
how
do
we
proceed
from
here
on
out?
So
thank
you
very
much
for
your
attention
and
I'm
really
happy
for
a
short
discussion.
A
A
So
a
pole
of
the
room
and
online
quite
quickly,
I'm
going
to
try
and
see
if
I
can
use
the
polling
button.
Actually,
how
many
people
have
read
this
document,
not
necessarily
the
latest
version,
but
a
version
of
this
document
and
we
use
the
show
hands
tools.
So
we
can,
we
can
have
you
read
ldx
question
mode.
A
A
The
next
question
really
was:
is
this
document,
which
is
a
description
of
the
ldx
technology
of
relevance
and
as
I
understand
the
author's
pitch
that
is
written
to
be
relevant
to
the
raw
working
group
and
the
ietf
as
a
whole,
so
that
we
can
understand
the
capabilities
of
ldax
as
an
input
to
any
deterministic
networking
over
wireless
media
mediums
that
we
might
want
to
do
I
think
that's!
The
purpose
is
not
to
say
this
is
ldx's
and
ietf
Technology
it's.
This
is
ldax.
It
could
be
useful
as
part
of
this
larger
L3
stuff.
F
On
Lou
louburger
I
suggest
you
redo
the
poll.
Some
of
us
were
not
on
the
tool
and
you've
now
jumped
to
39
people
in
the
room.
Oh,
my
Lord.
A
G
G
No
I
think
you're
fairly.
Looking
at
me,
it's
but
right.
So
you,
you
highlighted
exactly
the
right
question,
because
all
of
the
other
things
that
nil
summarized
in
his
presentation
essentially
take
care
of,
essentially
all
of
the
discussed
comments
that
were
that
were
gathered.
There
was
one
procedural
one
that
was
up
to
me
to
take
care
of,
and
that
one
is
also
sorted.
So
really
the
question
comes
completely
down
to
do.
We
have
consensus
within
this
working
group
that
this
is
something
that
we
want
to.
G
Basically
all
the
stuff
you
just
said
yeah
so
and
as
far
as
I
know
as
again
as
you
summarize
to
date,
we
don't
really
have
a
documented
trail.
That
says
so
so
I
think
the
way
to
break
that
Log
Jam
is
if
everybody
who
raised
their
hand,
which
is
a
decent
number
of
people,
and
it
certainly,
as
you
said
larger
than
two
would
take
the
additional
time,
maybe
this
afternoon,
to
write
a
short
email
to
the
list
expressing
their
comments.
G
You
know
whether
good
bad
or
indifferent
about
the
the
suitability
of
moving
the
document
forward
and
Publishing
it
that
would
help
tremendously
and
I.
Think
that
if
that
is
done,
I
don't
foresee
a
problem
I
mean
assuming
that
the
consensus
is
positive,
of
course,
but
if
that
all
happens,
I
don't
see
any.
You
know
structural
difficulty
with
go
ahead,
going
ahead
and
moving
to
publication.
G
That,
of
course,
assumes
if
you
know
I'd.
Forgive
me,
I
haven't
gone
in
and
reviewed
all
of
the
changes,
and
so
you
know
I
we'll
need
to
go
and
negotiate
with
each
person
who's
ready
to
discuss
and
ensure
that
they're
satisfied
with
the
resolution
of
their
discuss,
but
I
I,
you
know
I
have
confidence
that
that's
possible.
A
H
I
am
being
dragged
screaming,
not
necessarily
kicking
more
into
this
space,
as
my
work
in
ik
all
and
look
I
have
not
given
this
document
the
full
review
that
I
need
to
give
but
I've,
given
a
very
cursory
view
so
far
and
I'm
wondering
if
you
know
I,
don't
want
to
delay
things
necessarily,
but
perhaps
some
text
as
consideration,
guidance
and
raw
in
what
the
experience
of
ldax
provides
to
Raw
in
general.
H
A
We
have
a
use
cases
document
which
does
draw
out
some
of
the
avionics
use
cases
and
and
does
make
mention
of
ldx.
We
also
have
the
Technologies
document,
which
does
a
broad
view
across
Wi-Fi
Technologies
and
also
you
know,
5G
Etc.
It
also
includes
a
section
on
ldx,
so
I
think
some
of
that
information
already
exists,
but.
A
I'm,
looking
at
Nielsen
the
camera
to
to
see
if
he
has
any
feedback
on
that,
does
that
make
sense
to
you
Niels
or
do
you?
What
do
you
think
about
that
suggestion?
First
off,
can
you
put
that
text
on
the
mailing
list?
Please
evidence
of
value
discussion
right.
H
A
I
Well,
I
just
wanted
to
say
something
to
it.
Yes,
that's
right,
there's
a
linkage
between
those
two
documents
and
within
our
ldx
version,
we
have
a
cross-reference
to
the
other
document
as
it
was
requested
and
discussed
within
the
different
itfs
before
there
is
a
cross,
a
reference
completely
into
these
use
case
stuff.
A
H
H
A
Thanks
does
anyone
else
have
any
comment
on
ldax,
I'm,
gonna
I'm
gonna,
reiterate:
please
make
comments
to
the
mailing
list,
so
there
is
evidence
that
we
have
considered
and
discussed
this
I
wanna
I'll.
Add
one
extra
comment:
sort
of
targeted
towards
the
ads,
not
particularly
John,
but
any
others
who
will
be
listening
to
this
recording
at
some
later
date.
A
I
can
foresee
other
documents
like
this,
probably
not
as
long
or
as
complete
about
other
Wireless
Technologies
and
how
they
are
applicable
within
the
Raw
landscape
appearing.
You
know
something
about
perhaps
how
to
use
the
ultra
low
ultra
low
latency
5G
capabilities,
how
to
use
TSN
in
an
elegant
way.
A
Those
will
still
be
documents
talking
about
other
people's
Technologies,
but
will
be
valid
inputs
to
whatever
control,
plane
protocols
or
other
OEM
bits
and
pieces
we
develop
in
raw.
So
this
isn't
a
unique
case
as
I
see
it.
It
just
happens
to
be
the
first
one,
so
cool.
Thank
you
very
much.
Niels
I
will
try
and
find
out
what
I'm
doing
with
miteko
and
Pascal
I
think
it's
over
to
you.
If
you
are
online
I
can't
see
you
on
the
list.
J
Sorry,
yes,
so
there's
one
thing,
Rick
is
that
you
know
Luke
suggested
that
and
he
was
right
right
that
I
I
should
have
included
his
words
or
the
discussion
that
we
started
in
the
mailing
list
in
the
slides
and
I
was
in
the
process
of
doing
that,
and
then
mostly
done,
but
I'm
not
fully
done
and
the
new
slides
with
you
know
the
only
difference
being
the
inclusion
of
what
of
you
know
what
I
could
after
discussion
with
Lou
they're
only
on
my
desk,
so
the
the
best
way
for
me
would
be
basically
to
present
from
my
desk.
A
J
J
Okay,
so
we
we
don't
have
that
much
time,
considering
what
we
need
to
discuss
thanks
to
balash
and
Lou
actually
for
the
most
piece,
but
also
due
to
the
discussions
that
that
we've
been
having
in
the
interim
Etc,
so
I
will
pass
the
classical
introduction
to
the
architecture.
J
Just
remember
that
we
are
defining
a
UDA
Loop,
where
we
basically
observe
and
act
in
order
to
adapt
to
the
physical
condition
and
mostly
of
the
wireless
medium,
because
that's
the
wireless
which
really
changes
very
rapidly
versus
you
know
what
we
experience
traditionally
in
wire,
and
so
we
we've
done
28
years
ago.
We
decided
to
split
the
architecture
and
the
framework
understanding
that
the
architecture
is
more
of
what
we
intend
to
do,
and
the
global
kind
of
scope
and
Broad
picture
blueprint.
J
Whatever
of
what
you
want
to
do,
whereas
the
framework
is
more
on
how
you
know
which
techniques
we
put
in
place,
which
draft
we
develop,
etc,
etc.
So
the
framework
as
we
Define
it
is
mostly
something
that
will
be
available
in
the
end
of
our
project,
whereas
the
architecture
is
the
thing
that
we
need
to
provide
at
the
beginning
of
the
project,
to
scope
it
and
and
provide
the
directions
that
we're
taking.
J
So
since
the
split
we
did
a
number
of
additions-
and
we
are,
we
were
we've
been
discussing
since
last
age-
of
whether
we
are
ready
for
our
group.
Let's
go
I
think
we
are
mostly
ready
and-
and
the
kind
of
review
I
just
got
from
balash
for
me-
is
the
level
of
what
Google
Plus
call
with
you.
Now
that
mostly,
on
the
other
hand,
what
we
got
from
Lou
needs
to
be
debated
a
little
bit
more
and
I.
J
J
The
things
that
change
the
things
that
we've
detailed
more
and
then
I'm
not
100
sure
that
this
level
is
the
one
that
balance
has
reviewed
effectively
but
with
at
the
end
time,
we
discussed
that
we
needed
to
provide
more
information
about
how
rofits
versus
lower
layers
and
how
row
fits
within
that
net.
J
So
ISRO
a
piece
of
that
net,
for
instance
like
so
some
new
components,
some
new
subsets
of
of
that
net
and
effectively
that's
how
we
position
Raw,
knowing
that
at
the
moment,
rho
is
Rich
altering
but
was
not
so
far
working
on
the
controller
plane
and
effectively.
We
are.
J
We
hope
that
map
will
be
working
on
the
control
plane,
because
row
needs
needs
new
functions
in
in
the
new,
basically,
control
plane
function,
cpfs
in
that
net,
so
we'll
be
fully
within
that
net
when
that
net
is
shut
out
to
work
on
the
cpf
as
well.
For
now,
we
kind
of
indicate
a
row
control
sub
layer
where
the
PSE
stands
and
also
the
the
interaction
with
the
the
pce
that
will
provide
the
possible
subtracts
for
going
around
different
types
of
failures.
J
So
we
basically
Act
in
this
Contra
plane
and
we
we
act
in
the
service
sub
layer
where
we
we
take
actions,
for
instance,
for
parallel,
and
we
also
get
the
result
of
our
OEM
observes
and,
and
we
act
in
the
forning
sub
layer.
Mostly,
you
know
us
users
of
OEM,
so
this
is.
This
is
the
architecture.
Now,
when
you
focus
on
the
PSC,
the
PSE
is
mostly
in
the
control,
sub
layer
and
well.
J
This
is
how
I
see
it,
but
something
that
we
need
to
debate,
because
basically
the
piece
the
PSC
makes
decision,
it's
it's
controlling
and
it's
the
companion
of
the
PC.
So
in
my
view
it
makes
sense
to
to
consider
the
PLC
as
control
sub
layer.
Now
the
text
is
not
fully
homogeneous
with
that,
and
even
the
rewrite
that
we
were
discussing
for
the
abstract
is
not
fully
homogeneous.
J
Is
that
so
we
we
need
to
agree,
and
that
would
be
one
point
of
discussion
basically
on
this
structure,
it
kind
of
fits
within
the
commands
from
banash.
So
how
do
we
position
within
that
net?
So
we
are
within
that
net,
but
exactly
in
more
details
do
we
have
PCF
well,
cpf
control
plane
function.
Do
we
have
a
sub
layer
and
what
do
we
do
in
the
in
the
death
net
service
layer
under
the
net,
for
example?
J
J
J
We
mostly
discussed
the
model
where
the
PSC
is
at
the
Ingress,
and
there
is
some
kind
of
source
right
information
inside
the
packet
to
indicate
what
to
do
next,
but
the
architecture
is
is
wider
than
that.
You
could
effectively
learn
from
OEM
inside
the
relay
and
make
decision
for
the
rest
of
the
way
inside
the
relay.
F
Go
ahead,
Luke
sure
I
I,
my
intent
was
actually
to
wait
until
you
sort
of
went
through
your
material
before
jumping
into
the
questions
that
really
had
been
on
the
list.
But
you
said
you
want
to
discuss
this.
Now
am
I
understanding
you
correctly
or
do
you.
J
F
Okay,
so
on
this
slide,
there's
two
fundamental
pieces:
I'm
going
to
go
with
the
smaller
issue
first
and
then
get
to
the
larger
one,
and
maybe
I'll
take
the
larger
one
after
Carlos
to
give
him
a
chance
to
you
know
not
to
hog
the
queue
so
the
smaller
one.
It
was
a
question
that
just
I
added
in
this
mail
from
yesterday,
which
is,
is
Paro
or
the
arq
piece
required
or
not
for
raw.
J
J
So
if
we
in
terms
of
architecture
is
part
of
the
architecture,
because
we
need
to
see,
we
need
to
say
what
the
PSC
does
now
in
terms
of
definition
of
the
PSC,
as
you
can
see
on
this
Slide,
the
PSC
is
control.
The
bio
is
service,
so
you
could
say
well
in
the
architecture
it
fits
in
the
global
Road
design.
We
need
to
to
specify
it
in
terms
of
components.
It
doesn't
belong
to
the
PSE
it
it's
it's
controlled
by
the
PLC.
Does
it
make
sense?
Is
that
is
that
your
view
so.
J
F
Actually,
looking
at
your
slide,
so
wherever
you
look,
this
works
for
me,
it's
interesting,
you
said:
A
is
for
act
in
the
document
it
says.
A
is
for
R,
A
or
Q.
F
F
J
Two
flavors,
okay.
So
no
let
me
answer
that.
Please,
okay,
so
the
the
we
it's
it
needs
to
be
abstracted.
Executively,
that's
one
place
where
you
will
be
very
helpful.
We
don't
do
arq
in
row.
We
signal
possibly
some.
These
are
r
q
behave
Behavior
to
the
lower
layer.
If
the
lower
layer
can
consume
that
and
do
something
out
of
it,
it
will.
If
we
cannot,
if
it
doesn't
care,
we
cannot
pass
that
information
to
the
lower
layer.
It
worked,
but
it's
for
us,
it's
kind
of
an
abstract
thing.
J
We
don't
know
how
the
lower
layout
that
they
are
q
and
we
don't
do
arq
at
the
row
layer.
It's
just
some
information
like
like,
and
that's
part
of
my
response
to
balance
as
well.
I
think
you've
got
this
point
in
common.
How
comes
that?
Parallel
discuss
this
thing
that
look
like
to
the
lower
layer.
We
just
hit
the
type
of
Piezo
that
we
expect
and
if
the
lower
layer
support
something
supports,
an
API,
it's
like
the
L2
triggers,
but
the
other
way
down.
F
J
Okay,
let
me
let
me
revise
the
document
in
this.
I
mean
I
need
to
somebody.
Please
write
that
down,
but,
yes,
we
need
we
need,
and
if
it
was
listed
in
your
latest
thing
in
latest
mail,
I
need
to
answer
that.
But
basically
that's
that's
the
way.
I
view
it
yeah.
If
we
aren't
saying
that
we
need
to
to
look
at
that
text
and
make
sure
that
we
we
say
that.
A
F
Yeah
so
sure
we'll
see
what
happens,
I
actually
have
more
substantive
comments,
I'm
going
to
wait
until.
A
L
Yes,
I
have
just
a
kind
of
a
request
that
I
think
for
for
me,
maybe
for
other
people.
It
will
be
helpful
exercise
to
try
to
do
an
example
of
how
this
architecture
view
will
work
like
with
actual
you
know
and
and
notes
of
flow,
and
how
that
will?
L
What
what
type
of
interactions
that
will
imply
in
a
what
I
would
call
Pure
Roy
scenario
and
what
I
will
call
a
row
plus
dead
net
scenario,
which
may
have
implications
also
in
the
multi-domain
thing,
because
we
can
consider
a
dead
net
pure.net
wire,
a
scenarios,
one
domain
and
a
more
Wireless
scenariosa
another
domain,
but
for
me,
will
be
next
very
useful
at
ssis
and
I
think
it
may
help
other
people
and
the
discussion
to
have
that
type
of
example.
L
J
J
Some
of
them
are
very
new,
and
so,
but
when
we
go
through
these
drawings,
maybe
I
can
you
know,
ask
you
if
that's
a
good
start
for
what
you
want
to
achieve
or
if
what
you
want
to
achieve
is
completely
new
versus
what
we
already
have
in
both,
in
both
cases,
I'm
completely
open
yeah
that
we
don't
I,
don't
want
to
go
too
far,
because
if
we,
if
we
give
too
much
details,
we
are
in
the
framework
framework
world
right
and
if
maybe
what
you
what
you
want,
we
should
start
writing
it
in
the
framework,
but
not
the
architecture.
J
L
A
And
at
the
same
point
and
I
agree
with
with
Carlos
on
this
I
think
having
those
diagrams
is
important,
whether
they
go
in
this
document
or
the
framework
is
a
secondary
matter,
but
I
think
it
gives
us
some
scope
for
Clear
understanding
of
as
we
progress
a
point
of
order.
Pascal
do
you
want
to
take
more
questions
now
and
yes
is
your
question
about
this
particular
slide
or
is
it
a
more
General
one
because
I
think
Lou's
question
is
more
General
yeah.
E
J
Was
loose
big
command
and
I
I
think
we
need
to
hear
it
because
Lou
has
been
very
polite
to
go
to
the
end
of
the
queue
but
and
then
you
know,
if
you
think,
I
I'll
take
it.
You
know
it's
going
to
be
your
choice.
If
you,
if
you
think
that
this
slide
that
we
are
presenting,
is
the
one
that
fits
your
discussion,
then
let's
take
it.
Otherwise,
maybe
we
can
hold
it
till.
We
have
a
better
slide
for
it.
F
Yeah
I
I
haven't
looked
through
your
package,
so
I
don't
know
which
side
is
best,
but
it's
a
general
comment
about
my
comment
is:
is
an
architectural
and
like
Janos
or
I
shouldn't,
say,
architecture
more
fundamental
is
you're,
defining
a
whole
lot
of
new
terminology
for
things
that
already
exist
in
the
ITF,
and
you
know
Rick
said
at
the
beginning.
One
of
the
things
we
want
to
do
in
our
reviews
is
try
not
to
invent
new
terminology
and
new
things
for
stuff.
J
Have
yeah
from
your
commands,
typically
on
the
te
thing
so
I
have
that
slide,
and
that's
really
one
of
the
reasons
why
I'm
presenting
from
my
desk
as
opposed
to
the
package,
that's
already
there,
because
you
know
you
basically
interviewed
me
that
I
should
have
done
that
like
yesterday,
and
there
was
a
lot
of
my
in
my
plate
since
then
so
I
I
was
not
finished
to
be
able
to
push
it
in
time.
For,
for.
J
So
this
is
a
picture
that
is
newer
right,
and
this
is
also
a
discussion
that
we
add
at
the
interim
is
how
does
row
fit
within
that
net?
And
if
you
remember,
we've
got
two
major
use
cases,
one
where
we've
got
that
net
service
end
to
end
and
row
just
integrates
with
that,
in
which
case
we
do
the
control
and
our
additions
to
the
death
net
Services.
J
Basically-
and
you
know
if
we
ignore
that
we
do
some
special
stuff
in
oam-
and
we
we
agree
that
maybe
the
oam
is
completely
part
of
that
net
and
whatever
we
do
is
rid
of
it
in
netnet,
then
we
can
really
abstract
this
as
end-to-end.net
Services
scattered
row,
plus
sorry
that
net
forwarding
end
to
end
that
net
services
in
in
some
nodes,
which
are
called
relays
and
in
those
relays
we
expect
row
as
well
and
then
row
control,
maybe
only
a
decrease
or
possibly
also
optionally,
at
the
relays
if
if
the
PLC
is
distributed,
so
this
is
one
model,
that's
the
one
that
we
use,
for
instance
in
in
the
case
of
a
mesh
where
we
build
what
we
call
a
track
and
then
for
which
there
is
this
discussion
about
terminology.
J
So
so
that's
one
model
and
that's
the
most
classical
model
outside
now.
There
is
another
model
that
we
didn't
have
at
the
beginning,
that
but
number
of
people
insisted
that
we
work
on
it.
J
It's
the
model
where
row
mostly
controls
the
RAM
and
the
Run
by
run
I
mean
the
radio
access
network
Wi-Fi,
and
there
was
a
picture
of
my
ballast
actually
in
in
just
the
email
he
sent
two
days
ago,
where
you
can
see
the
the
device
like
the
user
equipment
or
something
doing
5G
or
doing
Wi-Fi,
and
possibly,
if
it's
a
robot
having
a
fiber
as
well
and
deciding
which
network
to
use
and
depending
on
the
access,
that's
using
that
net
may
be
available.
J
End
to
end
might
be
available,
but
not
falling
I
mean
might
be
available
only
all
the
way
to
the
the
end
of
the
5G
network,
but
not
across
the
internet,
to
the
application,
which
is
more
like
this
picture
or
could
be
just
not
there,
and
so.
If
it's
not,
there
then
not
end
to
end,
then
we
cannot
provide
them
to
end
guarantees
and
for
at
least
for
timeliness
and
and
time
latency
quantities.
We
cannot
provide
them
because
we
really
depend
on
that
net
and
our
layers
to
provide
timeliness.
J
Basically,
in
that
case,
row
is
still
useful,
because
row
can
do
end
to
end,
or
am
you
know,
between
the
Ingress
and
system
and
degrees
and
system
and
measure
whatever
it
sees,
depending
on
which
Access
Network
it's
using
the
replication
across
Wi-Fi
5G?
Whatever
is
needed,
and
you
know
if
it
finds
that
using
two
Wi-Fi
interfaces
is
enough
and
5G
is
expensive
or
on
the
control.
E5G
is
so
much
more
reliable
that
you
know
we
could
shut
all
the
other
interfaces.
J
I,
don't
know,
then
it's
going
to
be
the
PSC
making
that
decision
and
using
only
the
relevant
Network.
So
in
that
case
the
PSE
is
still
useful,
even
if
we
don't
have
that
net
end
to
end.
This
is
like
I
said
the
access
use
case,
and
we
we
have
it
in
our
Prime
statement
and
so
for
now
we
we
still
support
it.
In
that
case,
we
don't
well.
J
We
still
see
our
design
as
in
within
that,
but
it's
not
with
that
net
end-to-end
service,
and
so
we
don't
have
latency
currencies
now
more
subtle
variations
which
are
not
Illustrated
in
the
architecture
and
so
I
drew
them.
J
J
We
don't
have
that
net
forwarding,
we
might
have
TSN
or
it's
just
that
the
link
layer
provides
enough
warranties
in
terms
of
latency
Etc
between,
for
instance,
is
10
gig
and
we
have
limited
traffic.
So
so
we
have
good
enough
forwarding
between
the
the
end
system
and
the
first
Hub
that
net
Edge
node
and
the
traffic
is
basically
on
control,
just
through
the
you
and
I,
and
it's
not
basically
what
we
currently
have
defined,
but
the
architect
devnet
architecture
allows
for
Less.
So
in
the
future
we
could
Define
the
uni
interface.
J
That
is
enough
for
the
net
Edge
node
to
control
the
end
system,
and
so
this
this
is
a
variation
where
we
can
still
get
guarantees
across.
You
know
all
the
way
to
the
end
of
whatever
that
net
forwarding
supports.
If
there
is
an
internet
piece,
then
there
is
no
guarantee
end
to
end.
If
the
internet
on
the
right
is
just
the
access,
then
we
can
still
provide
qualities.
J
So
basically,
if
that
picture
is
symmetrical,
so
so
I
don't
know
if
it
makes
sense
to
to
add
this
picture
I'm
willing
to
edit.
If,
if
you
tell
me
to
do
to
do
that,
it's
it's
a
variation
of
the
previous
ones.
J
Important
is
row
is
not
the
in
in
the
forwarding
sub
layer,
so
we
don't
provide
or
below
so
we
don't
provide
warranties
like
latency.
It
comes
from
a
good
interaction
between
the
transport
layer
above
us
or
the
application,
whatever
provides
the
packet,
and
you
know
how
the
source
of
patriarch
transport
application
respects
the
contract
that
we
have
with
the
dead
net
layers
and
basically
that
net
forwarding
and
lower
layers
which
basically
can
consume
that
traffic.
You
know
when
it's
being
passed
and
forward
it
forwarding
it
down
the
end-to-end
across
to
that
metronic
plane.
M
I
sure
can
yeah
so
just
for
understanding,
so
I
am
somewhat
confused
with
your
term
uni
access.
We
have.
J
M
Okay,
I
I
am
also
concerned
about
the
uni,
because
here
we
have
end
to
end
that
net
so
also
the
end
system.
They
are
speaking
that
net,
so
why
you
are
calling
Edge
node
the
debt
not
only
serve
is
node,
it
should
be
a
relay
node
and
then
system
is
definitely.
J
J
And
so
and-
and
you
know,
the
uni
is
when
the
Ingress
Edge
is
effectively
not
doing
the
edge
system.
So,
for
instance,
if
the
edge
system
is
a
PC
and
this
PC
is
not
capable
of
that
net,
but
the
first
switch
is
or
the
first
router
over
the
access
the
one
Hub
device
is
then
the
uni
interface
is
basically
how
the
PC
will
negotiate
the
creation
of
a
bus,
for
instance,
how
the
when
the
path
is
installed.
The
PC
will
know
and
also
whatever
pacing
method
is
done
between
that
net
and
and
the
other
PC.
M
J
J
Okay,
so
so
so,
let's
go
so
better
since
you're,
there
right
so
so,
I
I
just
noted
your
three
questions
and
what
I
answered
on
the
main,
English
I
know
it's
a
lot
of
text,
but
it
is
because
I
just
copied
paste
that
basically
the
question
answer
and
I
I
answered
on
the
mailing
list
as
well,
so
we
could
prepare
for
the
discussion,
and
this
is
very
related
to
the
point
that
Lou
just
made
and
So
my
answer
to
loose
stance
and
I.
Think
that's
that's
I!
J
M
I
do
not
fully
agree
with
that,
but,
based
on
your
presentation,
I
think
that
you
are
not
defining,
for
example,
with
a
part
of
a
data
plane
functionality,
but
only
a
controller
for
those
data
plane
functionalities.
So
maybe
that
would
work
for
some
further
discussion.
J
Yeah
we
we
can
improve
the
text
on
Pio.
The
first
step
would
be
to
make
sure
that
we
are
in
sync
on
the
intention,
and
then
we
can
review
the
text
to
make
sure
that
it
fits
that
intention.
I
seem
to
I
understood
that
Lou
and
I.
We
have
the
same
view
and
that
view
is
what
I
try
to
write
here.
J
And
basically
LS3
is
always
working
on
abstraction
of
Health
too
I
mean
that's
what
it
is.
It
is
an
abstraction
of
L2
now,
because
radios
are
very
dynamic,
we
need
to
have
to
add
dynamic,
state
or
information
or
control
in
this
abstraction
and
perio.
The
difference
between
pario
and
pre-off
is
pretty
much
that
we
signal
that
those
Dynamic
things
and
that
can
be
in
one
directional
to
triggers
like
receive
signal
strikes.
You
know
in
quality
TX
in
the
other
direction.
It
could
be.
Please
try
to
do
as
many
retries.
J
Please
send
it
as
a
Mac
layer
multicast,
so
there
will
be
more
than
one
node
receiving
it
and
that's
basically,
what
we
we
call
the
over
Hearing
in
the
O
of
Mario
is
basically
controlling
the
fact
that
instead
of
sending
unicast
you
send
multicast
and
the
receivers
that
expect
the
packet
will
be
listening
to
the
multicast
pack.
So.
M
J
I
M
J
A
E
I
just
wanted
to
edit
one
piece
on
this,
like
what
you
said
verbally
I
had
the
same
confusion
like
and
what
you
said
verbally
was
more
helpful
for
me
than
than
the
email
list
and
everything
I've
been
following.
I
I
really
had
a
thorough
review
of
the
document.
I
had
to
follow
the
emails
and
I
I
think
the
API
is
a
key.
It
is
not
there
in
the
document
and
the
two
direction
aspect
of
the
API.
E
J
J
F
Lou
Berger
I'm
glad
I
waited
because
I
had
two
fundamental
points
and
yanos
just
made
the
second
one
much
more
eloquently
than
I.
Could
you
know
the
fundamental
point
is
that
the
document
reads
as
if
all
the
elements
described
related
to
Paro
are
being
done
by
raw,
as
opposed
to
being
controlled
by
raw
and
being
done
by
a
lower
layer
technology.
That's
really
not
clear
in
the
architecture
and
that's
a
that's
a
huge
fundamental
Point
thanks
that.
J
A
A
Where
you
know
Carlos
is
saying
some
really
good
diagrams
would
help
draw
out
the
discussion,
I'm,
hearing
people,
saying
Pascal,
you're
being
very
clear
when
you're
answering
the
questions,
but
somehow
that
Clarity
is
missing
from
the
document,
so
I'm
I'm
I,
don't
have
a
good
proposal
on
how
to
get
that
Clarity,
but
I
think
there
needs
to
be
more
work
on
this
document
and
I'm
kind
of
looking
at
the
people,
such
as
yanish
and
Carlos
and
and
Lou
to
to
to
drive
a
little
bit
to
assist
Pascal,
who
you
know
what
it's
like
when
you
write
your
own
document,
you
understand,
implicitly
what
you've
put
down
because
you
wrote
it,
but
as
an
outsider,
digging
through
other
people's
language
can
be
a
little
harder.
A
J
A
B
A
J
So
we
need
to
move
on
so
modeling
of
radio
components.
I,
think
we've
discussed
that
I
was
not
sure
what
you
meant
by
it's,
not
the
way,
the
lower
your
do
it,
if,
if
you
meant
the
5G
networks,
which
appears
as
a
virtual
switch
in
that
case
completely
back
to
us
now,
my
suggestion
was
to
improve
the
discussion
on
the
interaction
with
the
lower
layers,
which
is
exactly
what
we
have
been
discussing
here.
We
have
a
dependency
section.
J
We
could
also
describe
you
know
that
dependency,
the
apis
or
something,
and
the
fact
that
tario
controls
the
arq
and
the
over
nearing
functions,
but
does
not
do
them
just
like
death
net
expects
the
the
lower
layer
Shapers
or
something,
but
that
does
not
do
them
just
a
very
fast
feedback.
J
Okay,
okay,
so
I
thought
you
were
doing
TSN
only,
but
okay
so
related
to
q1.
J
So
so
you
seem
to
be
seeing
in
a
position
with
the
non-row
sub.
Network
can
be
neglected,
so
I
don't
know
how
to
work
this
and
then
again,
I
can
use
some
help,
but
this
was
referring
to
to
this
picture.
Early
on.
Where
you
know,
a
set
of
the
network
is
not
controlled
by
that
net.
The
piece
that
we
cannot
call
the
internet
and
the
way
we
we
operate
in
that
case
is
we
measure
the
end
to
end
oam.
J
Basically,
and
whatever
happens
you
know,
whatever
price
we
have
to
pay
is
built
on
the
first
half
of
the
access.
So
basically
we
do
as
if
the
access
was
responsible
for
all
the
latency
was
responsible
for
All
Digital
was
responsible
for
all
the
Hops
all
the
laws,
even
though
they
are
only
observed
and
to
end,
and
it
could
be
buffer
upload
in
the
internet.
J
It
could
be
congestion
loss
in
the
internet
Etc,
but
since
we
don't
have
that
net
end-to-end
to
guarantee
that
the
service
will
be
fair
will
be
correct
all
the
way
down,
we
can
only
say
we
need
to
select
an
access
interface.
Let's
select
the
access
interface
that
provides
the
best
and
to
end
result.
So
that's
what
we
had
in
mind
in
in
that
the
known
rows
of
network
can
be
neglected
in
the
computation.
J
So
you
can,
you
know,
push
the
latest
slide
on
the
repo,
but
so
one
of
those
points
was
the
term
row
and
we
already
discussed
that
that
didn't
train
last
time
and
basically,
what
is
role
they
aren't.
Another
way
of
doing
this
is
of
asking
this
is:
is
the
ISRO,
the
UDA
Loop,
or
will
there
be
more
because
today
the
architecture
is
the
udal
right?
J
It
describes
the
UDA
Loop
and
provides
more
information
about
the
PSC
because
it
does
not
exist,
but
we
also
provide
information
about
parallel
Etc
because
we
are
defining
the
whole,
including
OEM,
etc.
For
observe
and
question
is:
is
this
UDA
Loop
wrote
everything
everything
about
row
and
only
row,
or
is
this
I'm
sorry.
J
Sorry
I
was
called
twice
I
had
to
tell
the
guy
that
will
go
back
so
so
so,
basically
for
me,
if
we,
if
raw
does
not
reach
out
to
our
River
row,
is
the
UDA
and
rho
is
basically
what
we
have
in
this
document.
On
the
other
hand,
if
some
people
consider
that
row
will
reach
out
to
work
on
other
stuff
which
are
related
to
wireless
and
make
it
more
reliable
available
some
other
ways,
then
maybe
the
name
of
this
document
is
not
correct.
J
A
I'm
gonna
I'm
gonna
jump
in
the
queue
myself
now
and
then
Luke
and
have
a
go.
This
is
Rick
here,
yeah
I
I
understand
the
reference
to
udon.
This
is
actually
going
back
to
a
common
cast
and
made
in
the
chat
here.
Yes,
UDA
is
a
great
fundamental,
but
I
think
we're
all
fairly
familiar
with
the
fact
that
this
is
a
control
Loop.
We
are
making
a
decision
receiving
feedback
on
what
is
occurring.
J
A
A
result
of
that
vision
and
updating
that
decision
and
in
a
wireless
Dynamic
Network
that
is
required.
Some
could
say
that
in
a
in
a
fixed,
fixed
wire
net
environment
that
complete
Loop
is
not
needed,
you
can
make
a
plan
and
push
it
down.
Lou
is
shaking
his
head
saying.
Actually
you
do
need
that
Loop
anyway,
yeah.
J
A
J
Yeah,
so
should
this
document
this
document
is
limited
right
now
to
UDA.
We
that's
the
only
thing
it
discusses,
so
maybe
in
the
future
we'll
be
doing
more
stuff
in
this
case,
but
most
of
how
will
we
call
it
because
this
architecture
document
is
limited
to
the
UDA.
So
my
question
is:
if
row
is
more
than
the
UDA,
then
this
document
is
probably
not
the
raw
architecture.
It's
the
raw
UDA
architecture.
A
For
me,
I
think
so:
yeah
I've
stepped
out
of
the
out
of
the
line
and
let
loose
because
I'm
watching
the
clock.
F
So
I
now
ought
to
react
to
the
conversation
that
just
happened.
The
slewburger
UDA
is,
you
know,
a
a
a
philosophical
definition
or
it's
a
high
level
definition
of
reacting
and.
J
F
F
To
me
it
doesn't
add
a
whole
lot
to
to
use
the
term
UDA,
but
it
doesn't
also-
and
it's
like
okay
sure,
I
accept
it,
but
I,
don't
think
it's
something
fundamental
to
Raw.
I,
don't
think
it's
fundamental
to
the
document.
I,
don't
think
it
frankly,
I,
don't
think
it
adds
a
lot,
but
I
also
don't
think
it
hurts.
So
you
know
I
I,
but
if
you're
saying
this
is
only
the
the
raw
UDA
architecture,
I,
don't
understand
the
difference
between
the
raw
architecture
and
the
raw
UDA
architecture.
J
J
E
An
additional
comment
on
on
what
is
role
and
I
could
not
articulate
this
before
your
presentation
helped
and
the
figures
like
showing
road
service
and
that
not
service
and
I'm,
not
sure
that
we
are
making
us
service
to
the
industry
by
distinguishing
this
too,
like
even
even
the
text
on
this
on
the
on
the
side
copied
from
from
the
architecture
was
like.
E
My
view
was
that
for
layer
3
like
IP,
that
is
end-to-end
one
service
like
a
connectivity,
which
we
used
to
call
that
net
service
and
I
thought
that
what
we
are
doing
in
a
row
group
is
is
defining
the
wireless
segment,
the
wireless
subnet
segment
on
how
to
achieve
this
end-to-end
deterministic
service.
And
if
you
now
like,
we
introduce
the
third
one
like
we
have
TSN
service
for
the
DSN
subnet
for
layer
2,
and
we
have
the
dotnet
service,
as
defined
by
the
net
networking
group.
J
E
A
I'm
going
to
conclude
this
now
because
we're
running
out
of
time,
but
this
is
useful,
very
useful
and
we
need
to
take
it
to
the
mailing
list.
I'm
going
to
make
one
last
comment
about,
is
raw
UDA
or
is
raw
bigger
than
UDA
and
I'm
gonna.
Do
that
in
reference
to
the
Charter
we
have
been
chartered
for
12
to
18
months
and
we've
already
taken
two
and
a
half
years.
I
would
suggest
that
the
ooda
loop
and
that
traditional
reactive
control,
plane
feedback
loop
is
what
we
were
chartered
to
work
on
as
raw.
A
If
there
is
some
exciting
new
way
of
doing
it,
using
machine
learning
and
and
predictive
modeling
or
whatever
that
would
be
another
working
group,
it
would
definitely
be
a
retartering,
so
I'm,
looking
at
my
A.D
to
tell
me
I'm
wrong
and
I'm.
Looking
at
my
co-chair,
to
tell
me
I'm
wrong,
but
I
think
we
do
Huda,
that's
enough
for
us
now
and
I.
J
A
A
J
Decision
so
I
keep
the
slides
for
the
next
entry
and
I
really
thank
you
for
all
this
discussion,
I'm
looking
forward.
You
know
for
helping
getting
things
written
the
right
way,
so
at
least
we
we
seem
to
be
in
sync
on
the
intention,
and
that's
great
I
mean
we
are
not
that
far.
That
means
we
are
not
that
far.
A
So
Eve
I've
lost
track
of
the
agenda
because
I
lost
my
DNS
for
some
reason,
so
my
loss
next,
isn't
it.
C
Yes,
it's
Carlos
and
I
guess
Carlos.
If
you
wouldn't
mind
we
are
needing
maybe
we've
assigned.
You
have
two
talks.
C
A
C
No,
it's
also
on
the
internet.
C
A
C
Okay,
so
it's
not
a
local
problem
and
of
course
Carson
is
also
remote,
so
perhaps
it
is
Jerome's.
C
C
He's
just
yeah,
maybe
he's
coming
back
in
maybe
what
we
do,
since
we
are
pressed
for
time,
Carlos.
N
Very
sorry,
I
I
I
thought
everything
was
working
until
I
tried.
N
I'll
you've
got
I'll,
go
two
minutes
shorter
to
take
up
for
the
for
the
time.
Thank
you
very.
D
N
There's
a
lot
of
things
going
on
in
2018.
That
may
be
of
interest
to
us,
a
quick
reminder.
First,
on
on
how
things
are
articulated
over
there.
You
know
there
is
the
main
eight
to
the
11
working
group
at
the
IEEE,
which
has
Amendment,
which
are
developed
every
you
know.
Often
each
of
them
has
a
letter
sequence,
we've
done
all
the
A's
already
and
all
the
alphabets.
So
we
are
in
the
ebf
b
e
j
Etc
and
then
on
the
other
side,
there
is
the
Wi-Fi
Alliance,
which
has
certification
programs.
N
N
The
programs
that
are
typically
making
a
lot
of
noise
are
those
that
improve
performances
and
those
their
name
Wi-Fi,
plus
something
we
are
a
generation
seven.
So
you
may
have
heard
of
a
Wi-Fi
six,
that's
probably
what
you
have
at
home,
which
is
a
set
of
a
certification
that
implement
the
standard
which
is
802.11
ax.
So
in
the
iqbee
right
now
we
are
in
the
Next
Generation,
which
is
8
to
11
b
e.
This
amendment
will
have
still
a
few
years
to
go.
It's
a
slated
to
finish
by
2024.
N
You
know,
beginning
of
2024,
which
you
know
seems
long,
but
you
know
we're
discussing
of
scale.
We
have
about
the
same
scale
structure,
the
IEEE
where
most
of
the
work
is
down.
Now
they
have
to
make
sure
they
tighten
all
the
nuts
and
all
the
bolts
and
that
takes
typically
a
year
and
a
half,
so
it's
pretty
crystallized.
What's
going
to
be
in
be,
and
the
Wi-Fi
lens
I
started,
a
group
called
Wi-Fi,
seven
that
is
going
to
certify
several
elements
of
it.
N
The
reason
why
I
mentioned
this
is
because
in
11b
there
is
a
new
feature
which
is
called
mlo,
which
is
multi-league
Operation,
by
which
you
see
the
illustration
at
the
bottom,
a
device.
Typically,
your
station
can
create
two
links,
two
connections
to
an
access
point
and
have
a
single
identity
over
these
two
links,
which
allows,
of
course,
a
better
reliability.
N
The
initial
days
of
mlo
were
creating
the
intention
of
allowing
this
mechanism
across
multiple
access
points,
but
they
realize
that
that
implied
a
lot
of
coordination
requirements
between
access
points
and
there
was
a
lot
of
complexity
and
they
realized.
They
would
not
have
time
within
the
time
imparted
to
be
to
finish
that,
so
they
Park
that
so
in
even
the
mlo
functions
against
one
single
access
point:
two
radios,
for
example,
five
gigahertz
and
2.4
or
6
gigahertz.
So
you
know
that
increase
the
reliability
of
operations
on
one
side.
N
There
are
plenty
of
other
things
in
be,
and
previous
generations
are
very
targeted
toward
better
reliable
ability.
Among
other
things
in
be,
there
is
what
they
call
a
plink
of
dma,
which
essentially
allows
an
access
point
to
schedule
a
plane
traffic
from
multiple
stations
at
the
same
time-
and
you
know
allocating
some
slots
for
these
these
sessions.
This
can
be
part
of
a
negotiation
between
the
station
and
the
access
point
which
makes
the
process
you
know
very
reliable
in
terms
of
providing
the
stations
then
with
at
the
time
it
needs
for
the
need.
N
The
the
the
mechanism
is
still.
You
know
congestion
based,
so
it's
not,
you
know
purely
controlled,
but
it's
it's
much
better
than
what
we
had
before
so
b
as
I've
done
a
lot
of
good
things,
but
things
are
are
left
to
be
solved.
In
particular,
this
mlo
structure
against
multiple
access
phones
is
something
that
was
left
for
what
I'm
going
to
call
8-11
generation
eight.
So
that's
going
to
be
eight
to
the
11
B,
something
z
x
y,
depending
on
where
they
land,
where
this
group
is
formed.
N
But
that's
the
Next
Generation
after
be
that
we'll
have
to
address
this
coordination
between
access
points
for
analog
and
that's,
of
course,
very
important
for
us,
because
if
you
have
a
device
that
moves
you
want
not
only
to
have
better
reliability
into
one
access
point,
but
also
make
before
break
so
create
a
connection
to
the
next
AP.
N
So
you
already
have
a
connection
As,
you
move
from
one
access
phone
to
the
other.
In
short,
you
have
zero
delay
in
the
roaming
and
zero
loss.
So
that's
the
goal
in
parallel.
Three
things
are
happening
that
may
be
of
interest
for
this
group.
One
of
them
is
that
they
realize
that
many
iot
devices
start
connecting
to
Wi-Fi
and
several
of
them
are
battery
operated
and
the
ID
is
to
maintain
the
battery
as
long
as
we
can.
N
N
One
is
recharge
a
battery
if
you
have
operated
battery
device,
but
also
use
this
Ambient
Energy
to
reflect
back
energy
to
a
system
which
is
somehow
very
similar
to
what
you
have
in
stores
with
this
entire
theft
system,
where
there's
sort
of
cord
that
radiates
back
energy
from
from
the
gate
and
that
allows
you
know
the
system
to
detect
that
something
is
being
taken
out
of
the
store.
This
is
important
for
us
because,
of
course,
harvesting.
Energy
from
the
environment
is
good.
N
Introducing
systems
on
the
same
frequency
that
are
going
to
be
radiating
back
energy
for
other
purposes
might
create
some
difficulties
in
coexistent
with
Wi-Fi
devices,
so
everybody's
keeping
a
very
close
eye
on
what
exactly
is
amp
group
is
going
to
be
doing.
You
know
just
harvesting
energy
or
also
introducing
noise,
so
to
speak
in
the
Wi-Fi
world.
N
Another
one
is
something
which
is
probably
derived
from
the
6G
initiative,
where
machine
learning
is
being
introduced
as
being
a
very
important
component,
so
here
as
well,
there
is
the
ID
that
optimization
and
reliability
in
Wi-Fi
is
only
going
to
happen.
N
If
there
is,
you
know,
smartness
in
the
coordination
between
the
access
phones
and
the
stations,
so
in
July
as
well,
another
group
has
formed
which
is
called
AIML,
which
is
essentially
artificial,
intelligence
and
machine
learning
for
Wi-Fi,
and
the
goal
here
is
to
examine
how
you
know
each
side
can
use
machine
learning
tools
to
improve
the
conditions
of
the
the
of
the
cell,
so
that
in
you
know,
it
implies
reliability
for
us,
but
also
exchange
between
the
clients
and
the
access
points
on
machine
learning
things-
and
here
we
think
of
you,
know
metrics
and
statistics,
so
that
one
side
can
do
better
computation
or
exchanging
provisions
and
predictions
and
models.
N
So
that's
two
groups
that
are
very
interesting
another
one
which
I
think
is
useful
for
this.
One,
for
this
group
here
is
not
created,
yet
it's
a
group
that
is
likely
to
be
created
because
it
was
approved.
Each
question
was
approved
in
July
and
that's
what
is
called
ultra
high
reliability
study
group.
So,
in
the
Wi-Fi
nomenclature
we
have
80
to
11
nomenclature.
We
have
typically
first
a
topic
interesting
group
TIG,
where
people
discuss
whether
a
topic
is
of
interest
to
enough
people
that
we
want
to
dig
further.
N
If
the
conclusion
is
yes,
then
we
create
a
study
group
that
studies
exactly
what
could
be
done
there
in
82.11.
that
typically
lasts
for
about
a
year
and
at
the
end
of
the
SG,
a
task
group
is
created
to
actually
do
work.
So
here
you
know
improving
on
on
Wi-Fi
condition
is
so
obvious
that
they
didn't
have
the
need
to
create
a
TIG.
They
created
directly
a
studio
group.
Well,
that's
going
again
to
be
created
in
September.
It
was
approved
in
July,
and
you
see
the
list
of
target
areas
here.
N
So
this
mlo
between
access
point
is
likely
to
be
taken
by
these
groups
as
well.
But
you
see
on
the
list,
they
are
going
to
work
on
many
items
which
are
going
to
be
of
interest
to
us.
So
you
know
if
anybody
here
is
interested
in
those
topics,
please,
you
know
reach
out
to
the
IEEE.
You
know
it's
a
like
the
ITF,
it's
the
individual
driven
organization.
N
We
also
have
Liaisons
and
all
these
things
so
that
we
can
continue
exchanging
and
see
if
there's
anything
in
8.11
that
this
group,
in
particular,
can
do
that
could
be
of
interest
to
Rob
for
your
reference,
I
added
a
few
links
to
IEEE.
As
you
know,
all
the
documents
are
publicly
available,
so
those
are
a
few
documents
that
may
be
of
interest
for
our
conversation.
Let
me
pause
there.
So
I
don't
take
any
much
more
time,
I'm
very
happy
to
answer
questions
if
there
are
any
or
pass
the
ball
to
Carlos.
A
Thank
you
very
much,
Jerome,
there's,
no
one
actively
in
the
queue
at
the
moment.
Just
in
for
time
purposes,
can
you
take
your
questions
to
the
list
for
Jerome
absolutely.
L
Okay
from
this
video
I
think
for
the
use
cases
we
can
even
skip
the
slides,
because
the
summary
is
very
short:
we
didn't
do
any
updates
since
last
ITF,
because
we
were
in
the
Publications
process
and
well,
we
discussed
before
that.
It
would
be
so
basically
just
to
report
that
the
outsources
are
ready
to
to
to
tackle
any
comment
that
results
from
from
that
the
IGA
evaluation
on
the
on
the
sepharden
process.
So
we
can
jump
to
the
to
the
next
one
and
then
we
we
save
some
time
so.
A
Quick
nudge
to
our
ad
that
document's
been
waiting
in
the
isg
review
queue
for
a
couple
of
months.
Now.
Let
me
just
yep.
G
So
this
is
part
of
my
Mia
culpa
email
that
I
sent
out
to
at
least
my
chairs
earlier
this
week,
which
is
yes
I'm
behind
on
my
queue
and
I
am
working
to
move
things
along
faster.
Thank
you
for
your
efforts,
I'm
trying
to
match
them
thanks.
L
And
then
the
Royal
multi-domain
that's
a
work
that
is
ongoing
and
that
we
will
have
also
a
kind
of
separate,
more
high
level
discussion
in
dead
net
tomorrow.
So
next
slide
please.
So
we
are
here
that
in
the
working
group
we
have
been
mostly
focusing
on
a
single
domain.
At
least
we
didn't
touch
specifically
multiple
main
aspects,
although
this
discussion
that
we
have
with
Pascal
before
about
the
raw
and
dead
net.
To
me,
that's
part
of
the
multi-domain
aspects
that
we
need
to
tackle
because
Technologies
may
be
considered
different
domains.
L
So
we
justify-
or
we
motivate
in
the
document,
that
there
are
different
scenarios
in
raw
that
require
of
multiple
domains
again
meaning
domain,
something
that
is
a
technology
or
an
administrative
domain,
or
both
things
you
may
have.
We
may
have
different
Technologies
animation
domains
and
they
react.
L
This
draft
is
to
motivate-
and
this
will
already
fulfill,
that
purpose-
the
discussion
on
what
are
the
potential
gaps
if
any,
that
needs
to
be
tackled
for
multi-domain,
maybe
the
the
conclusion
is
that
everything
is
important:
fine
in
terms
of
architecture,
Orient
mechanisms,
control,
plane
mechanisms
and
if
something
is
needed,
maybe
explore
potential
solution
in
this
particular
document.
There
is
a
kind
of
solution
sketch,
but
the
main
goal
is
to
motivate
a
discussion
on
the
gaps
not
to
actually
discard
the
solution.
Yet
next
slide
please.
L
So
this
is
an
exemplary
scenario.
We
have
two
different
domains
in
the
slide.
It
switched
its
own
pce
and
there
are
kind
of
multiple
potential
gaps
that
we
need
to
Target.
On
the
one
hand,
we
need
these
two
domains
to
discover
and
set
up
an
interconnection
that
may
be
done
with
a
different
solution
or
maybe
already
in
place,
and
even
with
that
connectivity
in
place,
we
will
need
to,
for
example,
have
inter-pca
work.
L
There
are
documents
in
ATF
for
inter-pce,
so
the
idea
is
to
check
if
what
is
there
is
sufficient
or
not
for
rotted
net
purposes
and
then
check
if
we
need
to
have
some
inter
domain
PSE
coordination
or
API
to
support
this
scenario
again,
this
is
ongoing
discussion.
The
document
is
proposing
a
solution
in
the
next
slide
that
we
I
will
not
go
into
the
details,
because
this
is
just
as
let's
go
to
the
next
one:
I'm,
sorry,
a
potential
solution.
L
But
again
the
idea
here
is
to
discuss
on
on
the
cards,
so
we
can
go
to
the
next
one,
which
is
the
last
if
I'm
not
wrong.
So
yes,
is
there
any
interest
in
looking
into
this
again
looking
into
whether
this
is
a
problem
or
not.
If
this
is
a
problem,
then
we
can
discuss
whether
there
are
solutions
that
can
be
done
in
ATF
and
in
which
working
group
this
related
and
an
actual
internet.
L
We
have
a
companion
document
looking
more
at
the
high
level
and
the
net
level
trying
to
explore
the
gaps
and
I
also
benefit
from
the
opportunity
that
to
to
mention
that
we
are
going
to
have
a
new
project
funded.
That
is
very
much
stacked
into
these
points
and
also
into
what
their
own
presented
about
the
use
of
AI
to
predict
in
a
dead
net
raw
environment.
L
So
maybe
that
we
can
bring
more
content
really
to
that
into
that
net
and
raw
and
what
the
the
idea
is
to
get
feedback.
Do
you
think
guys
that
this
is
a
relevant
problem
to
to
work?
We
will
have
discussion
tomorrow
on
that
net
as
well,
and
if
so,
please
join
us
to
to
continue
working
on
the
documents.
A
Thank
you,
Carlos
personally,
I
think
this
is
really
important.
Work
I
think
you
can't
just
have
a
single
domain
solution
and
expect
it
to
work
everywhere.
I
with
my
chair
hat
on
would
like
to
be
led
by
work
happening
in
debtnet
and
build
on
it
to
make
it
work
in
a
raw
environment.
I
think
that's
the
best
way
to
work
on
it
and
I'm.
Looking
at
Lou
at
the
mic,
let's
keep
it
snappy,
but.
F
Yeah
yeah
I'm,
going
to
agree
with
I
agree
with
everything
you
just
said:
I
think
if
we
clean
up
the
architecture,
it'll
actually
help
because
but,
for
example,
the
enter
PSC.
We
already
have
cross
domain
protection
mechanisms
in
the
larger
te
body
of
work
that
we
can
just
Leverage
perfect.
A
Thank
you
very
much,
Carlos
Bob.
Thank
you
for
being
patient.
You
almost
have
your
full
time
so
well
done
everyone
else.
We're
going
quick.
H
H
It
is
called
best
effort
for
for
a
reason,
I've
worked
in
Ada
211
802
15.
Wireless
links
are
amazing
that
they
work
as
well
as
they
do,
but
there
are
times
when
the
mail
must
go
through
segue
here
to
a
picture
of
a
mailman
going
through
blinding
snowstorm.
H
Don't
expect
internet
to
fix
your
problems?
Yes,.
H
H
And
if
it's
smart
or
dumb
internet,
we
can
do
better
smart
things
with
a
dumb
internet,
it's
cheaper
for
the
internet!
If
we
don't
put
this
internet
as
pricer
at
the
endpoints
in
the
applications
cheaper,
but
never
ending,
close
to
AP
to
is
better.
But
how
can
you
change
the
stack
and
sometimes
we
do
need
to
fix
things
in
the
internet,
make
it
smarter,
like
red.
We
designed
red
one
day
during
the
day,
and
we
pushed
it
out
that
night.
It
was
that
fast
because
we
needed
it.
H
You
compute
the
fact
on
the
datagram
chop
into
pieces
minimally,
three
pieces,
two
for
the
datagram
one
for
the
fact
and
send
these
multiple
pieces
and
then
reconstruct
the
datagram
from
the
pieces
received,
and
you
have
your
your
message:
you
have
a
high
reliability
on
a
low,
lower
reliability.
Network
take
advantage
of
a
technology
that's
around
since
1960.
H
and
apply
it
here
at
the
IP
datagram
level,
the
IB
datagram
level
to
limit
the
total
data
sent.
Yes,
we
can
do
this
above
transport.
We
can
do
this
in
the
application,
but
then
we'll
end
up
having
more
data
more
chance
laws,
do
it
at
the
IP,
datagram
level
and
I
think
better
things
can
be
accomplished
as
a
result
and
can
manage
the
cost
on
the
constrained
links
one.
So
here's
an
example,
this
very
simple
example
things
that
we've
done
with
with
reach
Solomon
reach.
H
Solomon
was
created
back
in
1960.,
so
IP
datagram
is
n
bytes
long
and
make
it
even
for
Simplicity
and
the
fact
thus
is
n,
divided
by
two
bytes.
So
each
datagram
is
40
bytes
for
the
IPM
header,
plus
M
plus
n,
divided
by
two
bytes.
So
your
total
is
120
plus
3
and
over
two
is
what
you
set
to
get
the
message
across
note
that
it's
cheaper
to
send
the
packet
twice.
H
If
your
IP
datagram
is
less
than
80
bytes
long,
if
I
figured
so
they
had
one
just
send
it
achieve
your
reliability
by
sending
the
message
twice
and
there
are
smarter
texts
out
there
and
otherwise
do
it.
If
you
have
a
low
reliability,
you
may
like
break
the
message
into
five
pieces
and
have
three
effect
frames
interspersed
between
to
get
to
recovery.
H
The
beauty
of
this
approach
is
end
to
end.
There
is
no
Global
Effect
defined
no
mandatory
to
implement
what
is
your
reliability
you're
trying
to
achieve
between
those
parties?
That's
effective
use
and
it
can
be
dynamic.
You
can
change
the
effect
based
on
your
what
you're
experiencing
when
you're
experiencing
or
how
critical
that
male
is
to
get
through
next.
H
H
Next
header
see
my
presentation
this
afternoon
in
the
lpwan
about
this
subject:
use
the
Chic
rule
ID
to
include
the
the
black
number
lower
two
bits:
if
there's
only
like
four
packets
and
then
apply
signals
in
cheek
on
needing,
must
deliver
so
the
application
says
this
must
be
use
a
Chic
Rule
and
seek
does
the
fact
comes
to
the
other
side,
the
seek
module,
then
does
the
reassembly
and
then
passes
a
proper
transport
layer.
So
there's
a
way
we
can
do
this
if
we
provide
seek
as
and
see
my
presentation
this
afternoon.
Next.
H
H
The
internet
needs
to
respect
Chic
as
an
IB
protocol
number
that
may
be
a
hard
one-
hopefully
not
just
dropping
it,
because
it's
a
new
IP
protocol
number
and
select
the
fact
which
will
work
plug
it
into
Chic
and
we'll
need
some
help
here
to
do
this
sort
of
thing
and
then
run
tests
over
question,
reliable
links
and
measure
the
success
improvements.
H
So
it
would
not
be
a
long
stretch
of
work
to
say,
does
applying
Forward
Air
correction
at
the
IP
datagram
level
increase
our
reliability
of
delivery
of
important
messages,
regardless
of
what
the
wireless
link
May
might
be
doing
course.
Wireless
sync,
don't
forget
that
the
fourth,
what
I
think
we'll
be
doing
or
what
red
may
be
doing
in
your
environment,
and
so
next.
A
O
Co-Chair
of
a
group
that
we
closed
a
few
months
ago,
which
was
about
that
we're
coding
and
we
did
look
into
exactly
what
you're
saying
read
Solomon
by
the
way
is
not
a
really
good
solution
for
the
type
of
long-term
and
very
large
data
sets
we're
looking
at
also
Reid
Solomon
requires
to
wait
for
the
whole
the
whole
block
to
be
delivered
before
you
can
actually
start
decoding,
which
means
that
there's
an
awful
delay,
Network
coding
research
group
identified
a
number
of
solution.
O
The
problem
that
we
had
is
that
there's
a
lot
of
these
Solutions
were
protected
by
IPR,
and
you
need
to
take
that
into
account
either
IPR
licensing
issues
I
agree
with
you
that
the
the
good
one
which
is
in
open
source
for
has
been
an
open
source
forever.
Israel
Solomon,
but
I,
don't
think
Reid
Solomon
is
going
to
help
you
here.
It's
not
good
for
for
long
long
sequences.
O
So,
while
I
completely
agree
with
you
that
adding
fuc
could
increase
the
reliability
and
actually
I
would
actually
as
a
as
a
professional
in
that
field,
that
would
actually
say
it's
yes,
but
I.
O
Think
Reed
Solomon
is,
as
I
would
say,
the
lowest
common
denominator
and
there's
been,
like
you,
said,
30
years
of
research
on
things
that
are
better,
so
I
would
like
to
know
what
are
their
Solutions
if
you,
if
you
look
that
are
not
block
codes,
block
codes
are
extremely
bad
for
the
type
of
solutions
that
are
looking
for
raw
because
we
need
to
have
on-the-fly
decoding
and
there
are
on
the
Fly
decoding.
If
you
look
in
actually
in
the
transport
area,
there's
been
a
number
of
rfcs
on
related
codes.
O
Like
I
said,
some
of
them
are
protected
by
IPR,
some
of
them,
maybe
more
more
open,
I.
Think
there's
probably
some
of
this
IPR.
That
has
now
expired,
but
I
am
surprised
that
you
call
it
tada,
because
it's
not
tada,
it
needs
a
it's,
a
very
good
evaluation
of
what
is
needed
and
what
are
the
again,
the
impairments
of
of
Licensing
and
and
IPR.
H
H
So
it's
it's
potentially
a
very
short
thing:
you're
applying
it
to
and
I
only
stumbled
on
dealing
with
this
problem
two
weeks
ago.
So
my
time
in
research
on
this
is
absolutely
minimal.
I've
not
done
the
proper
research
on
the
different
facts
which
are
available
which
may
be
best
I,
just
grabbed,
something
which
was
just
easy
for
me
to
use
this
presentation.
H
And
and
I'd
be
loved
to
talk
with
you
and
work
with
you
and
to
be
able
to
come
with
something
which
is
appropriate
to
use
that
that
will
work
better
I.
Only
like
I
said:
let's
grab
the
first
thing:
I
could
grab
just
to
put
it
in
and
explain
what
could
be
done
and
what
the
approach
would
be.
The
next
step
is,
let's
get
real
agree.
O
Anything
that
works
with
wireless
and
Wireless
type
of
error
patterns.
It's
obviously
helped
by
some
form
of
error
coding
at
the
packet
level
at
the
datagram
level
or
even
lower
I'm,
not
disagreeing
with
you
here,
but
I
will
say
that
there
are
already
rfcs
in
the
transport
area
and
we've
had
a
research
group
for,
for
you
know,
I
think
close
to
10
years.
So
I'm
surprised,
I
was
surprised
that
you
did
not
mention
that
body
of
work,
I'm.
A
You
Marie
very
valid
point,
and
this
goes
back
to
my
my
comment
at
the
start
of
the
session-
is
there's
loads
of
ietf
Technologies
out
there
perfectly
valid
for
you
to
bring
this
Bob
I
I'm,
going
to
give
Pascal
and
Liu
a
chance
to
to
join
the
queue,
but
I
think
yes,
as
you
admit,
you
grabbed
to
read
Solomon
it
was.
It
was
an
obvious,
easy
candidate
for
a
short
time.
This
is
a
classic
example
of.
Let's
understand
what
else
is
out
there,
but
thank
you.
Pascal
go
ahead.
J
So
yeah,
you
know
about
I,
have
three
reactions.
First,
that
would
be
with
the
lp1
chair
hat
on
I
really
love
the
idea
that
you
want
to
use
check
to
actually
probably
do
the
fragmentation
and
then
add
some
more
data,
which
would
be
the
Redundant
data,
basically
that
the
Chic
layer
would
would
use
before
you
know
fully
expanding
the
the
packet
I
really
love
that
idea.
It's
really
nice
extension
to
shake.
We
are
not
charted
for
that,
but
I
hope
that
you
know
I
will
push
to
to
get
that
shot.
J
J
This
approach,
second,
is
I,
love,
also
the
fact
that
Niger
they
came
in
and
mentioned
the
work
in
transport,
because
at
the
last
interim,
we
discussed
that
a
lot
of
the
things
that
we
expect
in
the
dead
net
architecture
at
the
service
layer
are
typically
done,
usually
in
transport
layers
and
the
that's
my
point
of
view
and
not
necessarily
agreed
with
everybody
right.
So
my
my
own,
my
own
ad
I,
don't
know
whatever
things
like
ordering.
It's
something
that
typically
does
and
transports
will
do.
Some
transports
will
do
and
reliability
fact
or
air
QR.
J
What
is
also
a
transport
and
end-to-end
transporter
your
thing,
which
is
exactly
you
know.
We
are
doing
end-to-end
reliability
here,
so
this
is
typically
a
transport
thing,
and
so
yes,
we,
we
probably
need
to
have
this
discussion
at
some
point
of
what
of
the
definite
features
of
the
service
layer
are
really
layer
three
versus
without
effectively.
J
There
are
layer
four,
and
if
you
want
to
expand
the
work
on
them,
should
that
work
happen
at
transport
or
Internet
area
so
that
that's
the
second
reaction
and
yeah
the
third
one,
which
is
yes,
the
death
net
architecture
includes
effectively
the
sort
of
operation
that
you
have
and
row
expects
that
not
only
adding
fact
but
also
Distributing
the
different
objects
that
you
generate
over
different
path.
J
So
they
you
know
if,
even
if
there
is
like
a
solid
block
on
the
path
of
one
of
your
three
things
as
long
as
two
of
them
pass,
then
you
make
it
through
and
two
two
to
three
just
one
number.
It
could
be
five
to
seven
or
anything
like
that,
but
the
idea
of
taking
one
big
packet
could
be
8K
or
whatever
fragmenting
it
in
two
case,
because
that's
your
that
net
service
guarantee
and
getting
six
subject
of
two
case
and
then
sending
that
over
a
row
that
net
that's
expected.
J
That's
really
the
sort
of
thing
we
want
to
do
and
in
particularly
Wireless
that's
really.
The
sort
of
thing
I'd
like
to
see
happen
so.
A
Thanks
Pascal
Lou.
F
A
Just
to
Rick
adding
a
chair
comment:
I,
don't
believe
unless
there
was
a
compelling
reason
that
raw
would
disagree
with
any
network
coding
that
was
built
for
detnet,
unless
there
was
a
compelling
reason
why
it
didn't
work
for
wireless.
We
would
just
inherit
that
yeah.
J
B
Adam
Whitaker
another
thing
on
this
too
I
agree
with
Marie
completely
on
the
transport
stuff
and
I
was
actually
looking
at
Bob's
stuff
earlier,
and
the
first
thing
I
thought
of
was
Norm.
B
A
So
I'm
going
to
add
one
last
piece
to
this
with
my
chair
hat
on.
Thank
you
Bob.
This
is
a
source
of
a
valid
discussion.
Yes,
there
is
lots
of
pre-existing
work
out
there.
It
is
relevant
to
us
because
it's
a
common
problem
in
Wireless
as
you
get
package
drop.
Yes,
it's
relevant
to.net.
A
Thank
you
for
bringing
it
I
want
to
raise
the
follow-on
question
which
I
thought
you
might
have
addressed,
but
you
didn't,
which
is
probably
are
subject
to
be
chewed
over
by
everyone
in
the
room,
which
is
we
can
build
these
reliable
deterministic
networks
using
a
combination
of
debt
net
and
raw,
where
traffic
flows
have
a
certain
scheduled
bandwidth
with
latency
and
and
controlled
packet
size,
and
then,
if
I
run
TCP
over
it,
the
sliding
window
is
going
to
ignore
everything
and
drop
all
the
packets
automatically.
A
What
transport
should
be
recommended
to
run
over
these
systems
from
a
general
perspective?
So
you
don't.
Unless
you
are
your
Navy
broadcast
company,
where
you
you
have
your
own
technology
to
run
over
it,
that's
fine!
That's
a
self
problem!
What,
if
I'm
a
kind
of
a
small
startup
or
a
man
on
the
street
and
I
just
want
to
do
some
resty
kind
of
thing
over
a
deterministic
network
for
some
reason,
what
protocol
do
I
use
for
my
transport
and
that's
an
open
question
to
me.
It
is
someone
got
the
answer.
Tell
me.
H
A
It's
it's
a
that
would
be.
My
question
is:
do
we
educate
TCP
to
understand
this?
Is
that
then
a
debt
net
function
or
do
we
need
a
different
transport
and
from
the
experiences
for
things
like
sctp
uptake
with
middle
Boxes,
Etc
is
always
an
issue
I'm
watching
the
clock.
We
have
one
minute
for
any
other
business
thanks,
Bob
you're.
A
You
all
anyone
else
have
Carson
has
jumped
to
the
EQ
go
ahead.
Oh
sorry,
Pascal's
first
go
ahead.
Pascal
then
jump
jump.
J
Yeah
I
I
think
our
role
here
is
not
necessarily
to
educate
TCP,
but
mostly
to
figure
out
the
sort
of
things
we
would
like
to
see
happen,
a
list
kind
of
all
the
services.
We
could
imagine
that
we
would
like
to
transport
to
be
doing
and
then
pass
the
big
piket
to
transport
area
and
say:
okay,
what
do
you
have
for
us?
You
know.
J
K
There
is
still
an
end-to-end
argument
here
and
a
lot
of
people
seem
to
think
that
that
we
can
change
IP,
so
every
datagram
that
is
ever
sent
actually
arrives
and-
and
that's
not
going
to
happen
so,
let's
not
try
to
to
change
the
IP
service
model,
and
given
that
IP
runs
on
a
concatenated
network,
we
will
always
have
the
situation
that
various
parts
of
the
network
have
different
cost
structure
in
in
actually
achieving
that
reliability,
and
that
really
has
a
lot
of
implications
for
the
service
model.
A
B
Time,
yeah
very
quick,
agreed
with
everything
that
Carson
just
said
and
also
skips.
Tp
is
another
great
thing
that
should
be
utilized
here.
A
Okay,
I'm
gonna
close
the
meeting.
Thank
you
very
much
everybody
for
attending
in
person
or
remotely,
hopefully,
we'll
see
more
of
you
in
person
in
London,
because
it's
always
nice
to
see
people
face
to
face,
but
stay
safe
and
we'll
see
some
of
you
at
the
interims
communicate
on
the
mailing
list.
Please
State
your
support
for
ldax.
If
you
have
support
for
ldx,
it's
important
to
get
that
work
moving.
Otherwise,
thank
you
very
much
enjoy
the
rest
of
your
day.
C
K
Yeah
you
can
leave
so
that's
a
signal
that
the
meeting
is
no
longer
running.