►
From YouTube: IETF109-INTAREA-20201119-0730
Description
INTAREA meeting session at IETF109
2020/11/19 0730
https://datatracker.ietf.org/meeting/109/proceedings/
A
Carlos,
so
we're
going
to
start
with
with
a
few
virtual
meeting
tips
and
etiquette,
so
please
join
the
queue
before
participating,
we'll
recognize
you
and
give
you
the
word
so
that
we
don't
overstep
each
other
mute
your
microphone.
Unless
you
are
speaking
and
preferably
turn
off
your
video,
if
you
are
presenting,
you
can
turn
it
on,
but
otherwise
please
turn
it
off
so
that
we
can
save.
A
Bandwidth
next
slide,
please
so
not
well.
This
is
the
usual
not
well.
We
are
holding
an
official
itf
meeting,
so
you
agreed
to
follow
the
ietf
processes
and
policies.
A
A
We
just
lost
your
screen
awesome,
so
you
are
acknowledged
that
you
are
abiding
by
the
ietf
processes
bcps
and
that
and
you
are
aware
that
your
contributions
are
going
to
be
recorded.
That
minutes
are
going
to
be
taken.
Your
presence
is
going
to
be
locked.
A
A
Yes,
okay,
thank
you!
So
coming
back
scribes,
please
contribute
online
to
the
minutes.
At
the
code
dmd
and
joel.
I
just
to
confirm:
can
you
help
us
with
the
minute
or
was
it
only
described
for
the
other.
A
Okay,
so
we
will
need
someone
to
help
us
with
the
minute
it
could
be
many
people.
A
A
A
We
have
note
takers
great
and
your
presence
is
being
locked.
So
if
we
can
move
to
the
next
slide,
this
is
agenda.
For
today,
we're
going
to
have
vlad,
presenting
a
small
update
to
the
socks
up
version
six
protocol.
Then
we're
going
to
have
maxine
presenting
three
slides
pascal,
which
she
covered
ppp
ehausia
with
the
two
flexible
ip
drafts,
and
if
we
have
time
we
will
have
lorenzo
presenting
the
per
application
networking
considerations
any
bashing
to
the
agenda.
G
Hi
can
can
you
hear
me
yes,
so
I
was
genuinely
surprised
to
see
items
3,
4
and
five
on
the
agenda,
those
so
as
someone
who
follows
kind
of
both
the
transport
and
interiors,
these
really
feel
like
transport
documents,
and
I
feel
like
both
of
them
were
just
renamed
or
sorry.
Two
out
of
the
three
of
them
were
just
renamed
from
like
documents
aimed
at
quick.
So
I
would
like
to
ask
like
why
are
these
in
interior,
like
they're,
about
like
more
transport
properties
than
anything
else?
In
my
understanding.
A
Well,
I
see
my
team
on
the
cues
a
little
while
he
was
joining
so
if
you
can
take
that
max.
H
Yeah,
of
course,
can
you
hear
me?
Yes,
yes,
okay,
so
those
three
documents
define
an
application
protocol
for
quick.
So
as
such,
I
felt
the
they
were
appropriate
for
interior
and
I
contacted
the
chairs
giving
given
this.
H
Of
course,
those
documents
existed
before
so
they
were
as
targeted.
We
could
say
to
the
quick
working
group,
but
they
they
are
not
touching
on
transport
properties.
They
are
just
an
application
protocol.
On
top
of
so.
G
Oh,
I
I
see
our
ad
is
coming
in.
C
C
G
Okay
thanks,
I
was
just
genuinely
curious
and
I'm
excited
to
see
the
presentations,
because
I
I
I
mean,
as
you
know,
I
am
a
mask
enthusiast.
So
I'm
very
much
excited
about
this
topic.
I
was
just
very
surprised
to
see
it
here.
I
I
almost
personally
missed
it.
I
wasn't
expecting
to
see
it
here
at
all
so
yeah.
Let's
maybe
continue
the
discussion
in
that
slot.
Then
thank
you.
A
So
quick
status
update,
we
had
the
two
rfcs
that
had
been
published,
the
discovery,
provisioning
domains
and
data
rfc,
88.01
and
ip
fragmentation
considered
fragile
8900.
A
We
also
have
the
generic
udp
encapsulation,
which
is
at
on
at
the
isg
in
ada
evaluation
status,
all
right
so
since
we're
a
few
eric.
Yes,
you
want
to
say
something.
C
A
Yes,
fair
enough,
thank
you
very
much.
Yes,
we
saw
your
review
and
so
we're
waiting
for
feedback
from
from
the
authors.
So
now
moving
on
a
small
update
on
on
the
stocks
v6
vlad.
Are
you.
A
A
A
A
A
A
Here
we
can
see
your
your
screen
now.
Okay,
can
you
hear
me
now?
Yes,
we
can
hear
you
right
here.
You
go
moving.
A
A
right
so
vlad
has
made
a
great
yeah
small
update
and
the
adoption
is
still
called.
The
adoption
call
is
still
open.
We
did
see
some
some
mild
support
for
this,
but
we
would
like
to
see
a
little
more
support.
As
you
recall
this
this
slide.
This
draft
has
been
going
on
for
quite
a
bit,
and
vlad
has
already
presented
a
few
times.
He's
had
a
positive
feedback
and
also
he's
had
an
implementation
that
he
has.
He
has
already
published.
A
So
please,
if
you
can
and
if
you
agree,
send
a
message
to
the
list
to
adopt
this
draft.
We
would
like
to
see
that
we
are
also
planning
to
send
it
to
sag
sec
dispatch
and
mask
to
let
them
know
that
the
the
draft
is
around
and
and
get
some
more
support
so
that
we
can
adopt
it
and
move
it
forward.
A
H
Yes,
okay,
can
you
hear
me?
Yes,
yeah?
Okay,
thank
you,
so
so
yeah
thank
you
for
giving
us
the
opportunity
to
present
our
proposal
for
tunneling
internet
protocols
inside
quick.
H
H
So
our
proposal
is
split
in
three
documents
which
we
will
describe
separately
so
first,
we
will
give
an
introduction
to
quick
so
that
all
participants
are
kind
of
on
the
same
page,
a
short
introduction
too
quick,
and
then
we
will
move
on
to
describing
the
the
main
document,
which
is
quick
tunnel
and
then
two
optimizations
to
our
proposal
next
slide.
H
So
for
for
this,
for
this
introduction
too
quick,
I
have
not
taken
all
the
the
details
of
quick.
I've
just
picked
a
few
relevant
items
that
I
think
are
interesting
in
the
context
of
creating
a
tunnel.
H
It
has
a
one
rtt
authenticate
handshake
mode
by
default,
but
it
can
also
do
zero
tt
session
resumption,
with
some
weakened
security
properties
and
one
key
aspect
of
quick
is
that
all
application
data
is
is
encrypted
and
most
of
the
control
data
is
encrypted
and
those
two
things
give
some
kind
of
immunity
to
most
of
the
metabolic
interference,
which
is
a
very
nice
property
for
transport
protocol.
H
There
are
two
ways
of
conveying
application
data
in
quick,
so
there
is
one
which
is
which
are
streams
which
are
reliable
in
order
either
unidirectional
bi-directional
byte
streams,
but
there
is
also
more.
There
is
datagrams
which
are
unreliable
message,
so
it
provides
services
equivalent
to
tcp
and
tls,
but
also
adds
this
datagram
mode.
H
H
H
So,
let's
look
now
at
under,
let's
look
at
a
packet
sequence
diagram
to
to
see
what's
going
on
to
convey
those
packets
at
the
quick
level.
So,
first
we
have
a
quick
handshake
and
we
defined
the
qtlpn
to
identify
our
proposal,
and
so,
as
indicated
by
the
the
quick
specification,
we,
the
client
put
this
alpn
token
to
negotiate
the
application
in
its
first
packet
to
the
to
the
concentrator
and
the
concentrator
eventually
echoes
this
token,
to
complete
the
negotiation.
H
So
we
have
still
a
quick
handshake
and
then
once
the
quick
handshake
is
done,
the
packets
that
the
client
would
like
to
send
to
the
concentrator
are
put
inside
diagram
frames.
So
you
can
see
that
packet
a
is
put
inside
the
datagram
frame
and
this
packet
will
be
forwarded
to
the
concentrator
that
will
be
forwarded
by
the
concentrator
to
the
server.
H
When
returning
packets
arrive
to
the
concentrator,
they
are
put
back
inside
that
everyone
frame
and
sent
to
the
client
in
this
mode
of
operation.
We
don't
provide
means
of
distinguishing
the
type
of
packet
that
is
conveyed.
So
we
will.
We
rely
on
out-of-band
signaling,
which
makes
the
proposal
very
simple
next
slide.
H
There
is
also
another
feature
of
the
tunnel
mode,
which
is
the
ability
to
report
access
network
availability.
So
if
we
take
our
example,
our
previous
example
in
which
we
we
send
packet
a
after
a
quick
handshake.
No,
let's
say
that
the
client
net,
the
client
notice
that
the
network
is
unstable.
H
So
when
the
network
is
becoming
unstable,
the
client
has
the
ability
to
signal
this
to
the
concentrator
using
access
report
tlv,
which
is
a
tlv
we
defined,
and
so
here
in
our
example,
the
client
sends
this
access
report
tlv
over
a
quick
stream,
a
uni-directional,
quick
stream
to
indicate
to
indicate
that
the
network
is
currently
unstable
and
so
the
concentrator,
given
that
it
has
this
signal,
is
free
to
decide
what
to
do
when
incoming
packets
arrive.
So
we
have
incoming
packet
b
at
this
point.
It
knows
that
the
network
is
unstable.
H
The
clan
can
signal
this
also,
and
so
it
sends
this
access
report
tlv
with
the
signal
indicating
that
the
the
network
is
back
and
here
in
our
example,
the
concentrator
has
buffered
the
packet
and
it
can
transmit
the
packets
next
slide.
H
So
so
that's
basically
it
for
the
the
first
mode.
Should
we
either
stop
here
for
clarification
question,
or
should
we
move
on
to
the
other
mode.
A
If
that's,
okay,
maybe
maybe
move
to
the
other
modes,
and
then
we
can
take
all
questions
at
the
end.
Please.
H
H
Okay,
then
now
we
are
going
to
describe
the
tunnel
session
mode
next
slide,
so
the
tunnel
session
mode
operates
in
a
similar
reference
environment.
But
this
time
we
consider
multi-ohm
clients
so
a
client
that
is
attached
to
several
access
network.
So
it
could
be
a
client
with
wi-fi
and
5g
interfaces,
but
it
also
it
could
also
be
a
client
with
an
ipv4
and
an
ipv6
stack.
H
H
So
this
is
our
proposal
for
the
tunnel
session
is
to
use
two
separate
connections
next
slide,
but
there
is
also
something
else
that
we
could
do,
which
is
establish
an
mp
quick
tunnel
connection
and
use
the
two
different
sub
subflows,
if
you
like,
or
path
to
forward
packets
to
the
concentrator.
H
But
we
prefer
to
describe
the
the
previous
solution,
which
is
the
two
separate
quick
connection,
because
it's
it's
simpler
and
there
is
still
a
lot
of
work
to
do
on
mp,
quick
for
it
to
become
a
reality.
So
next
slide.
H
So
let's
look
at
those
two
separate
connections
solutions,
so
the
session
the
tunnel
session
mode
allows
to
group
them
in
a
not
in
a
logical
session.
So
in
our
example,
we
can
see
a
green
connection
a
and
a
b
and
blue
connection
b.
H
H
Later
it
can
use
messages
that
we
define
in
the
draft
to
request
a
new
session
from
the
concentrator
and
associate
the
blue
connection
to
this
very
same
session,
and
what
this
allows
is
to
it
allows
the
concentrator
to
do
packet
reordering
across
the
connections,
because
it
knows
that
those
two
quick
tunnel
connections
are
belonging
to
the
same
session
next
slide
so
to
perform
on
or
allow
rather
the
packet
reordering.
H
We
define
a
slightly
a
slightly
more
complex
encoding
of
the
packet
inside
the
quick
diagram
frame,
which
also
allows
to
identify
the
type
of
packet
that
is
being
conveyed.
So
here
we
can
identify
layer,
3,
packets
or
even
layer,
two
packets,
as
the
the
first,
the
first
16
bits
of
this
encoding
is
the
protocol
type
as
defined
in
the
other
type
minor
registry.
So
we
can
identify
any
network
level
packets,
but
we
can
also
identify
an
ethernet
frame
itself
by
using
a
transparent,
ethernet,
bridging
for
example.
H
So
this
is
the
first
field
of
the
of
this
encoding
and
then
the
the
second
16-bit
field
is
an
opaque
value
which
can
be
used
for
reordering,
which
we
call
the
packet
tag.
We
will
see
an
example
with
this
on
the
next
slide.
H
Next
slide,
please
so
using
those
sessions
and
using
this
packet
tag,
the
client
can,
for
example,
if
the
client
want
to
send
multiple
packet
to
the
constraint
reader,
it
can
leverage
this
packet
tag
to
encode
the
transmission
sequence
or,
for
example,
a
timestamp
which
allows
the
concentrator
to
do
reordering
across
the
tunnel
connection.
So
here
it
sends
packet
a
with
tag,
one
and
then
packet
b,
with
tag
2
on
the
on
the
blue
connection
and
then
package
c
with
tag
3..
H
H
So
so
this
is
it
for
the
tunnel
session
mode.
Now
we
will
look
at
the
last
mode
of
operation,
which
is
the
stream
mode
next
slide,
and
I
know
something-
that's
probably
come
to
your
mind.
Is
that
those
two
approaches
that
we've
seen
have
one
key
advantage,
which
is
to
be
able
to
convey
many
types
of
protocols,
but
one
drawback,
which
is
the
bite
over
it
in
it
introduce
and
in
the
cases
of
tcp
byte
streams.
This
can
be
quite
high
next
slide.
H
So
here
we
have
this
tcp
packet,
actually
an
ip
packet
containing
a
tcp
packet
that
we
would
like
to
to
convey
over
the
the
tunnel.
If
we
are
using
the
tunnel
session
mode,
we
have
to
add
those
two
fields
before
the
packet.
Next
slide
then
put
it
inside
the
datagram
frame
next
slide
and
then
put
this
diagram
frame
inside
a
quick
packet,
and
so,
if
we're
dealing
with
a
lot
of
traffic
this
over,
it
can
be
significant
next
slide.
H
So
here
we
have
the
client
that
sends
so
so
the
client
that
would
like
to
establish
tcp
connection
to
the
final
destination
will
use
messages
we've
defined
in
the
draft
to
open
a
new
tcp
connection
from
the
concentrator.
H
So
it
sends
this
tcp
connect
tlv
on
a
new
stream
to
the
concentrator,
and
this
will
get
translated
by
the
concentrator
to
a
syn
packet
next
slide
when
the
synap
comes
back,
the
concentrator
also
does
the
translation
in
reverse
and
sends
a
message:
tcp
connect,
ok
to
the
client
to
indicate
that
the
connection
has
been
successfully
established.
We
also
provide
tlvs
for
all
other
means
of.
So
if
the
the
connection
doesn't
succeed,
if
the
connection
solution
doesn't
succeed,
we
also
provide
a
tlvs
for
that.
H
So
after
the
connection
has
been
established,
the
byte
stream,
the
tcp
by
stream,
is
simply
copied
over
the
the
quick
stream.
So
we
can
see
the
client
would
like
to
send
some
some
data
over
the
byte
stream
and
sends
it
in
the
stream
it
gets
copied
to
the
tcp
connection
and,
in
the
same
way,
returning
data
from
the
final
destination
to
the
concentrator
over
this
tcp
connection
gets
copied
to
the
quick
stream
next
slide.
I
H
Closure
events,
so
when
the
tcp
connection
closes
with
a
fin
packet,
we
close
one
way
of
the
stream
and
then,
when
the
when
the
client
would
like
to
close
the
the
connection,
it
closes
its
own
way
of
the
of
the
stream,
and
this
gets
translated
to
a
thin
packet
next
slide.
H
So
so
this
was
basically
it
for
the
the
stream
mode,
and
this
leads
us
to
the
conclusion.
So
we've
seen
that
quick
can
be
used
to
convey
many
networks
protocol.
H
We
think
that
there
is
an
interest
in
considering
multi-ohm
clients
from
the
start
of
the
from
the
start
of
the
work
of
on
a
tunneling
protocol
and
to
do
and
so
to
to
solve
this
problem.
We
defined
an
application
protocol
to
convey
internet
protocols
inside
quick
and
it
splits
in
those
three
documents,
and
there
exists
already
a
prototype
as
part
of
the
pique
paper,
but
we're
working
on
a
more
fully
fledged
prototype
that
we
hope
to
be
experimenting
with
soon
and
probably
show
you
some
results
at
some
point.
H
Of
course,
contributions
and
correlations
are
welcome
on
the
github,
but
maybe
let's
take
a
question
from
the
participants
first.
Yes,
thank
you
very.
A
Much
max
so
we
have
a
couple
of
questions.
We
have
five
minutes
for
questions
so
david.
G
This
is
the
last
one.
Oh
okay,
great
sorry,
I
was
looking
ahead
on
the
thing
and,
like
the
you,
have
a
next
slide
in
your
deck
that
I
find
somewhat
amusing,
but
that's
what
I
was
going
to
ask
about.
So
this
is
david
kanazi
mask
enthusiast.
G
This
sounds
a
lot
like
mask
to
the
point
where
it
pretty
much
is
mask
so
take
like
the
entire,
like,
especially
your
stream
mode,
where
you
present
it
as
something
new.
If
you
look
at
it
from
the
perspective
of
an
ipsec
tunnel.
Yes,
this
is
new
and
useful.
Absolutely
it
is
useful
to
have
a
stream
level
abstraction
instead
of
a
packet
level,
abstraction
I'm
totally
with
you
there,
except
we
already
have
this.
G
It's
called
the
http
3
connect
method,
it's
already
completely
done,
and
so
I
don't
understand
why
there's
a
new
draft
that,
like
does
a
bunch
of
work,
to
do
the
same
thing.
So
can
you
clarify?
H
So
so
I
have
two
things
to
bring
so
first,
I
I'm
not
sure
if
you
were
offended
by
the
I
didn't
say
new,
but
that
was
not
my
intention.
H
The
draft
quick
tunnel
exists
for
a
long
time,
it's
kind
of
it.
It
arrived
nearly
when,
when
the
first
mass
proposal
arrived
also
but
yeah,
let's
look
now
at
the
real
technical
things,
so
yeah.
The
the
key
difference
I
see
is
that
the
mask
is
defined
at
a
h3.
You
know
that,
of
course,
and
in
our
case
we
define
a
simple
binary
protocol
on
top
of
quick,
and
I
think
the
two
have
advantages
so.
G
H
G
But
it's
like
it's
not
an
order
of
magnitude
simpler
than
h3,
so
yeah
it
is
simple,
I'm
not
denying
that
it
is
isn't,
but
I
so
so
I
like.
I
totally
agree
you
like.
You,
have
a
different
thing
and
you
if
it
were
just
your
proposal,
it
would
make
sense,
but
why
this
proposal,
when
we
already
have
something
that
works.
H
G
So
from
the
and
the
mask
chairs
can
well
eric
is
in
the
queue
so
I'll
all
defer
to
him
on
that
point,
but
the
when
we
wrote
the
charter
for
mask
the
idea
was
start
simple
and
build
up.
So
you
know
with
in
protocol
design
in
general,
you
don't
want
to
tackle
17
different
problems
at
the
same
time,
because
that
makes
it
almost
impossible.
So
what
we
decided
with
mask
is
we
started
with
connect
udp,
so
it
allows
you
to
forward
udp
packets.
Just
like
connect
does
for
tcp,
it
does
udp.
G
G
If,
like
we
have
clear,
you
know,
use
cases
and
benefits,
and
I
think
that's
like
a
natural
progression
instead
of
trying
to
do
all
the
things
at
the
same
time,
because
there's
kind
of
the
dependencies
where
you
know
when
you
change
one,
you
have
to
redesign
the
other
and-
and
I
think
you
know
the
in
these
ideas
of
like
having
those
multiple
paths
and
maybe
making
mask
path.
Aware
or
even
you
know,
quick
pathway,
which
is
discussions
that
we're
having
in
the
quick
working
group
is
useful.
G
I'm
not
sure,
that's
a
good
reason
to
like
kind
of
reinvent
the
entire
application
layer.
Just
because
mass
doesn't
have
everything
we
need
today.
I
think
it
might
be
worth
it
to
bring
this
energy
to
mask
and
see
how
we
could
fit
every
all
of
your
use
cases
and
needs
into
mask,
and
I
do
realize
I'm
really
sounding
like
I'm
trying
to
sell
masks
here,
but
it's
just
it's
just
weird
to
try
to
reinvent
something
when
we
have
something
there.
H
G
I
All
right
can
I
go
no
all
right
yeah,
so
I'm
very
much
accurate.
What
david
was
saying?
I
think
you
know
just
for
this
group
as
we
are
considering
it.
I
think
this
should
absolutely
not
be
done
in
interior
because
it's
duplicating
what
is
already
in
the
charter
of
another
working
group,
and
we
don't
want
those
separate
efforts.
I
Mask
is
already
building
proxying
and
tunneling
over
quick,
and
so
we
should
go.
There
have
the
conversation
there
and
if
there
are
things
that
we
don't
think
are
correctly
in
the
charter,
you
can
have
a
rechartering
discussion
and
have
the
discussion
that
goes
up
to
the
isg
and
you
know
goes
through
all
of
that,
but
don't
just
duplicate
the
work
because
it
doesn't
fit
into
the
charter
as
it
is
today,
as
people
have
mentioned
already,
you
know
the
stream
mode,
it's
identical
to
connect.
I
When
you
looked
at
the
draft,
it
essentially
does
connect,
but
it
doesn't
do
things
like
being
able
to
connect
with
a
name.
So
it's
like
a
just
kind
of
a
lesser
version
of
connect,
and
I
think
these
points
here
about
saying
that
h3
is
not
too
much
overhead
or
it
won't
support.
Some
of
these
other
features-
I
don't
think
that's
true,
and
particularly
like
recently,
I've
been
working
on
for
doing
mask
interop,
a
very,
very
minimal
version
of
h3
that
you
can
run
that
doesn't
have
to
do
other
things.
I
If
you
only
want
to
use
it
for
proxying
and
tunneling,
it
can
be
extremely
simple
and
maybe
it
would
be
worth
kind
of
going
through
the
exercise
of
writing
down
a
minimal
guide
for
how
to
do
that.
Maybe
that's
a
draft,
that's
informational,
but
you
know
if
you
want
help
kind
of
figure
out
how
to
make
this
very
thin
and
lightweight.
C
C
So,
and
it
looks
like
pretty
much
like
a
mask
thing,
so
my
current
thinking
is
to
get
a
meeting
with
the
interior
chairs
and
the
mask
chairs-
maybe
not
next
week,
because
it's
thanksgiving
and
the
responsibility
for
those
two
groups
and
see
what
we
do.
But,
honestly,
right
now
it
looks
like
it's
really
a
mask
document
and
could
be
used
by
the
mass
cooking
group
as
an
input
again
nice
piece
of
work.
C
A
E
I
pretty
much
agree
with
eric
said,
and
I
don't
have
much
to
add
just
to
say
that
several
of
the
points
not
just
the
the
multi-pass
part
but
the
connecting
several
quick
connection
to
the
same
server.
It's
a
much
harder
problem
than
what
is
presented
here.
If
you
consider
server
pools.
So
it's
much
better
to
tweet
that
inside
mask
or
inside
quick
than
to
try
to
do
it
on
the
side
and.
I
J
I
don't
wanna
reiterate
everything
that
was
said,
although
I
generally
agree
with
it.
I
think
there
was
some
discussion
about
this
last
march
on
the
mask
mailing
list
and-
and
I
think
the
the
reception
was
generally,
that
that
yeah,
this
kind
of
thing
is
something
that
that
mask
is
looking
at.
J
So
I
would
encourage
you
to
come
there
and
and
let's
talk
specifically
to
the
multipath
stuff,
when
we
were
charting
chartering
mask,
we
basically
said
mask
and
the
ability
to
connect
and
do
datagrams
and
ip,
and
all
of
that
is
somewhat
orthogonal
to
whether
you're
doing
that
with
multi-path,
quick
or
multiple
quick
connections
over
multiple
paths.
J
So
I
don't
think
I
I
think
we
were
not
trying
to
get
in
front
of
the
discussion
happening
in
the
quick
working
group
about
multipath
and
all
of
that,
so
I
don't
think
we
wanna
to
turn
mask
into
a
another
place
to
to
have
that
discussion.
Let's
have
the
discussion
with
everybody
who
needs
to
be
involved,
but
there's
nothing
in
mask.
That
is
that
is
anti-multi-path.
A
Okay,
thank
you,
vidi.
K
Can
you
hear
me
yes,
yes,
I
just
have
a
very
quick
question
about
the
scheduling
on
the
different
paths,
so
I
remember
seeing
the
slide
where
we
were
sending
packets
on
from
you
know,
different
network
interfaces
to
the
concentrator,
but
I
didn't
see
the
response
part.
So
how
is
the
scheduling
described
in
the
draft
like?
How
does
it
decide
on
which
path
to
send.
G
A
L
L
L
The
question
maxime,
it
wasn't
directly
maxim.
It
was
directed
at
the
chairs,
I'm
asking
if
the
transport
area,
directors
or
the
mask
chairs
or
the
quick
chairs,
where
any
of
those
consulted
on
these
documents
being
presented
here.
Of
course,
you
don't
need
to
consult,
but
it
might
help
if
you
did
consult
them
toward
having
these
sorts
of
conflicts
in
the
future.
A
Well:
okay,
thanks!
We
take
that
as
an
advice
and
to
answer
the
question:
no,
we
we
did
not
consult
and
we
we
look
at
the
protocol
and
basically
the
decision
as
eric
said,
because
it
was
talking
about
tunnels.
We
said:
okay,
we
can
hear
it,
but
the
decision
on
adopting
or
anything
would
have
to
be
taken
afterwards
and
then
right
now,
you've
already
got
the
the
feedback.
J
But
thanks
for
the
feedback,
okay,
there,
there
was
some
conversation
about
this
kind
of
use,
case
and
stuff.
I
think
last
march,
but
I
haven't
seen
anything
since
then,
although
I'm
happy
to
be
wrong.
A
Okay,
thank
you.
So
we
need
to
move
on
to
the
next
presentation.
So
if
you
have
any
more
comments,
please
send
them
to
the
list.
A
E
B
Cool
okay,
so
sheik
is
a
new
rfc
8724
that
was
designed
at
the
lp1
working
group
and
juan
carlos
is
an
active
member
of
that
group
and
I'm
sharing
it.
B
And
so
we
talk
with
with
eric
we,
we
kind
of
went
through
the
possibilities
and
we
found
that
lp1
was
actually
not
chartered
for
looking
at
chic
over
ppp.
B
So
we
we
kind
of
decided
to
to
move
into
interior
and
propose
the
work
at
interior.
So
certainly
this
this
work
takes
needs
two
kind
of
of
specialties.
We
need
like
ppp
experts
and
we
also
need
chic
experts.
So
certainly
it
cannot
be
done
fully
in
our
working
group
and
we
really
expect
collaboration
between
rp1
and
interior,
but
in
terms
of
charter.
The
work
belongs
here
so
that
that's
why
it's
been
proposed
here.
B
Why
do
we
want
shakeover
ppp?
Because
if
we
have
ppp,
obviously
we
have
several
links,
so
we
can
get
the
traditional
rvx
links
and
we
can
get
3gpp
etc.
We
also
can
benefit
from
ppp
over
ethernet
wi-fi
so
with.
Basically,
we
can,
through
p,
through
check
of
our
ppp.
We
can
basically
deploy
shake
over
anything.
So
that's
why
we're
so
interested
in
doing
it
to
enable
it?
It
doesn't
take
a
lot,
but
we
need
to
to
signal
a
new
compression
mechanism
for
ppp
already
has
two
compression
mechanisms
defined.
B
So
it's
just
like
a
third
one
that
that
we
look
at
and
we
propose
to
signal
check
as
basically
so.
A
new
value
for
this
compression
type
and
chic
requires
a
data
model
where
you
you
provide
the
compression
rules,
it's
completely
stateful
protocol,
where
every
byte
kind
of
maps
something
in
a
rule.
So
we
need
to
provide
the
rule,
and
the
idea
is
in
this
compression
header
that
ppp
has.
B
We
can
actually
provide
the
url
of
of
the
where
the
data
model
is
located,
because
it's
very
important
that
both
the
ends
of
the
compression
at
the
exact
same
vision
of
this
data
model
next
slide.
Please,
okay!
So
what's
new
in
the
draft
first
thing
is
we
kind
of
to
keep
things
simple
and
that's
just
an
attempt?
B
We
kind
of
propose
to
force
the
size
of
what
we
call
the
rule
id,
which
is
basically
this
the
index
of
of
the
mapping
table,
which
says
exactly
how
you
compress
this
particular
packet.
B
We
proposed
to
fix
it
as
two
bytes,
so
so
we
get
everything
by
the
line
and
it
looked
like
having
14
bits
to
index
the
rules
for
a
given
flow
that
that
looked
like
enough.
If
you
want
to
start
another
flow,
then
you
can
always
start
another
ppp
session
now
we'll
see
later
in
the
slides.
But
the
big
question
we
have
is:
if
we
force
the
rule
id
size
to
be
aligned,
and
now
we've
got
all
these
compression
residues.
B
B
So
what
we
did
with
this
new
version
is
add
fragmentation.
Initially,
there
was
no
fragmentation
in
shakeover
ppp
because
we
are
saying:
hey
ppp
applies
to
two
links
where
normally
you
don't
have
a
frame
size
limitation,
but
then
then
we
looked
at
it
from
a
different
angle
and
took
requirements
from
from
industrial
control
loops,
and
things
like
that,
where
you
would
like
to
schedule
frames
and
if
you
want
to
schedule
frames,
you
may
want
to
align
them
to
a
very
specific
size.
B
So
it's
much
easier
to
schedule,
and
if
you
want
to
do
that,
then
the
there
might
be
cases
for
some
industrial
protocols
where
whatever
size
you
decide
like
120
bytes
or
something
does
not
fit
everything,
and
in
that
case
you
might
need
to
divide.
You
know
the
frequency
of
your
updates
by
two
but
allow
two
fragments
or
even
three
fragments.
If
you
really
wanted
to
so
to
be
able
to
maintain
this
very
small
frame
size,
we
basically
said.
Oh
then,
let's,
let's
use
the
fragmentation
that
chick
has
next
slide.
B
So
so
the
biggest
problem
we
have
left
is:
is
this
padding
thing
normally?
The
way
shake
would
work.
Is
that
when
you're
not
fully
beat
allied
line?
I'm
sorry,
then
you
put
some
padding
at
the
end
of
everything,
but
here
what
we'd
like
to
do
is
compress,
maybe
most
of
the
beginning
of
the
packet.
But
then,
if
in
this
control
loop,
there
is
kind
of
a
measurement.
B
You
would
like
to
leave
the
measurement
uncompressed
at
the
end
of
the
packet.
So
we
would
like
to
be
able
to
signal
that
up
to
this
point,
you're
compressed
and
then
after
that,
you're
not
compressed,
and
if
we
look
at
this,
then
the
that
means
that
the
the
padding
has
to
be
between
the
compressed
piece
and
the
uncompressed
piece
next
side.
Please
so
that's
pretty
much
where
we
are
and
the
discussion
we
want
to
add.
B
Do
we
want
to
to
maintain
the
rule
of
a
fixed
size
and
then
have
to
introduce
padding
between
the
compressor
and
compressed
or
change
slightly
the
way
she
copyright
or
maybe
find
a
trick
that
makes
it
fit
in
a
generic
format.
So
here
I'm
giving
you
how
the
the
flow
would
work.
So
basically,
there
are
two
switches
or
two
endpoints
which
which
operate
shake
the
compression
compression
and
decompression
on
the
other
side,
and
basically
the
first
thing
that
needs
to
happen
is
is
to
agree
on
the
rule
set.
B
That's
why
we
need
this,
this
url
in
the
ppp
negotiation
and
then
the
url
will
be
negotiated
through
through
the
discovery.
B
Next
slide.
Please
so
you
see
this
option
two.
Basically,
I'm
sorry
back
one
slide.
I
did
not
mention
one
thing
backward
slide,
please
yeah.
So
so
basically
the
first
thing
is
the
endpoints
must
look
at
one
another,
so
there
must
be
a
discovery
and
then
what
I
mentioned
earlier
is
illustrated
here
is
the
ipv6
cp
configuration
request
would
have
this
option
to
which
size
this
new
compression
protocol
check
and
do
url?
That's
that's.
Basically
what
I
was
saying
earlier
next
slide.
B
This
is
just
for
illustration:
let's
go
to
the
next
yeah,
so
there
we
go
basically
calling
for
adoption.
I
guess
I
mean
the
the
like.
I
said
this
work
has
to
be
done
in
collaboration
with
rp1
and
for
the
tiny
details
of
how
we
do
the
rules
and
stuff
that
would
be
done
with
help
you
and
support,
but
from
here
we
really
need
to
to
agree
on
on
the
value
of
doing
shakeover
ppp
and,
if
so,
then,
getting
this
this
document
adopted
and
then
I
would
like
feedback
on
is
it
incorrectly?
B
Do
we
need
more
justification
for
why
we
are
doing
this
work
like
applicability
statement?
Is
there
anything
else
you
would
like
to
mention
this
document?
So
that's
basically
the
open
questions.
A
Okay,
thank
you
very
much.
So,
as
pascal
mentioned
in
the
beginning,
this
actually
applies
a
lot
to.
I
A
Technology
in
the
work
that
is
being
done
in
the
lp1
group,
but
the
applicability
brings
it
to
to
interior.
So,
even
though
the
expertise
is
mainly
there,
we
wonder
if
ever
this
moves
forward,
one
adopted
here
in
interior.
So
if
you
click
on
the
show
of
hands
bar,
we
are
asking
a
question.
We
would
like
to
know
how
many
people
have
read
the
draft,
so
if
you
can
click
on
the
on
the
bar
chart
of
the
mythical
and
please
raise
your
hand
if
you
have
read
the
draft
or
do
not
raise
your
hand.
F
A
Okay,
so
we're
gonna
stop
it
there.
We
have
4
19
and
1
18.,
so
we
still
don't
have
that
many
people
reading
the
draft
again
this
is
this
is
a
draft
and
a
technology
that,
even
though
it's
been
discussed
at
length
in
lp,
one
it'll
be
nice.
If
you
guys
can
take
a
look
since
this
is
something
we
would
like
to
eventually
adopt
in
interior.
A
So
please
take
a
look.
Send
your
comments
and
possible
answer
the
questions
that
pascal
is
asking
on
the
mailing
list.
N
Yes,
I'm
here,
can
you
hear
me?
Yes,
okay,
thanks
for
the
time
to
present,
this
proposal
is
for
the
flexible,
app
address,
address
structure
for
the
new
scenarios,
I'm
ihoja
from
huawei.
Next,
please.
N
The
first
slice
is
for
the
gap
and
then
I
analysis,
the
ipv6
has
become
the
core
protocol
of
the
entire
communication
system
and
increasing
network
scenarios.
Long
phone
tcp
ip
for
global
range
abilities-
and
we
know
ip
address-
is
designed
as
to
hold
the
only
topology
semantics.
Only
and
here
we
do
see
a
lot
of
new
scenarios
which
prefers
a
flexible
ip
address,
and
this
is
for
a
new
routing
capabilities.
N
N
So
we
should
define
the
flexibility
here
and
we
do
post
a
potential
orientation
here.
We
we
see
that
the
feasibility
could
include
multi-semantics
and
it
could
be
lens
variable
and
the
location
for
this
new
scenarios
we
see
is:
it's
called
the
age
networks.
We
we
do
use
that
new
address
structure
at
the
limited
domain
is
like
in
the
graph
in
the
right
side.
The
backbone
should
be
the
internet,
ipva
sex
and
the
flexible
ip
should
be
located
at
the
edge
of
the
network
and
the
logic
position
of
the
flex.
N
It's
called
the
6lowpan
it's
facebook,
but
it's
not
perfect
because
they
have
a
lot
of
action
likes
compression
and
decompression,
so
that
could
introduce
extra
energy
consumption
or
resource
consumptions,
and
such
compression
actions
may
lead
to
the
network
delays.
So
for
such
scenarios,
if
we
use
a
flexible
address,
address
structure,
we
can
use
a
shorter
address,
maybe
a
shorter
packet
heater
that
could
contribute
to
energy
consumption,
energy
saving
and
we
can
use
appropriate
gateway
to
translate
from
the
ipv6
and
the
flexible
iphone
structure.
F
A
Few
more
minutes
you
want
to
take
questions
here.
You
want
to
go
through
a
couple
of
more
slides
before.
N
I'd
like
to
talk
question,
I
will
go
through
all
the
the
name
of
the
scenarios.
The
the
second
scenario
is
for
c
line
networks.
We
can
use
geolocation
and
for
for
low
energy
consumptions.
This
is
a
new
scenarios
and
the
next
scenarios.
Next,
please.
Next,
it's
for
the
dynamic
resources.
N
We
can
use
flexible
structure
to
encoding
identifier
and
it's
good
for
us
to
to
provide
quality
of
service
and
next
please,
and
we
can
use
a
flexible
structure
to
encode
the
new
identifier
and
to
identify
users
or
devices,
and
it's
good
for
the
network
to
allowed
to
directly
allow
or
deny
traffic
based
on
the
based
on
the
privilege.
And
next,
please.
N
N
B
I
just
want
to
mention
that
there
was
some
inextitude
on
what
was
said
about
six
low
payments.
So
six
japan
enables
to
forward
compressed
packets.
You
can
do
that
in
the
with
the
mesh
forms
and
with
rfc813h.
B
You
can
also
do
that
in
in
the
right
over
mode,
so
you
can
always
forward
six
loop
and
packets,
even
if
they
are
fragmented,
because
now
you
have
rfc89
30
and
8931,
which
enable
to
forward
fragments
as
well.
So
so
the
the
point
that
you
you
should
you
could
not
forward
six
clockwise
compressed
packet
is
not
exact
yeah.
So
that's
the
major
thing
now
6lowpan
is
not
a
flexible
address
structure.
It
is
a
compression
right,
so
you
can
always
come
back
to
normal
ipv6.
So
so
it
does
not
really
compare.
N
A
Thanks
ron.
D
I
realize
that
you
have
some
use
cases
that
require
additional
information
in
ipv6
headers
you've
proposed
encoding
it
in
an
ipv6
address
and
even
making
variable
length.
Ipv6
addresses
the
problem
is
once
you
make
an
ipv6
address,
variable
length,
it's
no
longer
ipv6,
it's
something
else.
So
I'd
recommend
that
you
think
about
encoding.
This
extra
information,
someplace
other
than
the
destination
address,
maybe
use
extension
headers.
If
that
doesn't
work.
Well,
maybe
what
you're
working
on
is
something
that
is
not
ipv6
as
much
as
I
hate
to
say
it.
N
Yes,
yes,
it's
not
exactly
ipvsx
or
it's
it's
not
similar.
F
O
Thanks
very
much
for
your
presentation
and
for
ending
with
such
a
clear
question:
are
these
scenarios
reasonable
for
flexible
address
structure?
And
I
think
the
answer
is
basically
no,
and
I
think
that
it's
known
for
three
kind
of
reasons:
one
programmatic,
one,
architectural
and
and
one
sort
of
from
a
policy
basis.
O
The
programmatic
one
is
you're
trying
to
do
a
whole
bunch
of
different
things
and
you've
picked
one
particular
tool
and
said:
I'm
going
to
use
this
tool
to
do
all
of
these
different
things
and
the
result
of
that
is
you're
going
to
end
up
one
making
the
tool
less
optimal.
For
its
original
usage,
too.
O
All
of
the
different
things
you're
trying
to
do
are
going
to
be
across
purposes
as
you're
trying
to
fit
them
into
the
new
structures
within
the
existing
tool.
And
the
result
of
it
is
exactly
the
architectural
problem
that
that
that
occurs
and
that
you
note
in
your
slide
that
you're
going
to
have
to
gateway
and
that
those
gateways
will
not
actually
be
part
of
the
internet.
O
Those
will
be
networks
which
connect
to
the
internet
through
a
gateway,
because
you
will
not
be
able
to
pass
from
the
gateway
portion
through
the
rest
of
the
internet
if
there
is
no
gateway
on
path,
that's
capable
of
understanding
the
distinctions
you're
trying
to
make
within
it.
So
I
I
think
that
this
is
not
only
not
a
great
idea
from
the
point
of
view
of
an
addressing
architecture.
It's
actually
a
terrible
idea
from
the
point
of
view
of
keeping
the
internet
a
single
unitary
internet
working
layer.
O
Lastly,
some
of
what
you
want
to
do
is
actually
contrary
to
the
policy
that
the
itf
has
set
out
for
encouraging
further
privacy
in
the
network,
particularly
encoding
user
identifiers,
into
an
address
space
so
that
they
must
be
carried
through
the
network
is,
is
sort
of
initial
to
the
work
that's
been
done
in
the
security
area
and
by
the
iad
to
foster
more
security
in
the
network.
So
I
I
think
the
best
thing
to
do
here
is
really
to
pick
one
of
these
use
cases.
O
You've
got
the
satellite
use
case,
see
if
there
are
use
cases
or
that
you
can
take
one
and
figure
out
the
best
tool
for
that,
because
there
may
be
some
of
these
that,
if
you
pull
them
into
the
lego
bricks
you
can,
you
can
generate
something
useful
from
them,
but
trying
to
build
all
of
this
with
a
single
tool
is,
is,
I
think,
both
going
to
be
very
difficult
and
the
wrong
idea.
Thank
you
very
much
for,
for
your
time
again,.
N
Thank
you.
Thank
you
for
comments.
I
guess
that
scenario
is
just
located
as
a
limited
domain
and
the
age
of
the
network,
so
it
could
be
experimental.
So
we
try
to
just
develop
the
prototype
for
the
h
network
and
for
the
just
force
more
scenarios,
more
networks
to
make
it
to
see
if
it
works
or
not.
We
hope
it
could
be
start
from
the
experiment.
A
Okay,
so
thank
you
very
much.
We'll
have
to
stop
the
meeting
here.
Unfortunately,
we
didn't
have
time
to
to
go
through
the
last
presentations,
but
please
continue
the
discussion
on
the
list,
thanks
everyone
for
your
patience
and
cooperation
with
these
meetings.