►
From YouTube: TSVWG Interim Meeting, 2020-04-08
Description
TSVWG Interim Meeting, 2020-04-08
C
D
D
We
we
have
the
ITF
not
well,
and
even
though
this
is
a
rather
odd
way
to
perhaps
go
about
doing
ITF
the
ITF
not
well
does
apply
so
make
sure
that
you
are
familiar
with
it.
Basically,
it
requires
you
to
think
carefully
before
you
speak,
so
you
consider
IPR
implications.
If
you
already
understand
this,
that's
fine!
If
you
don't,
then
look
at
this
slide.
This
may
help
you
understand
what
the
implications
are.
D
There's
some
instructions
here,
you
probably
have
seen
at
least
a
little
bit
of
this,
because
you've
got
this
far
but
the
way
in
which
we're
going
to
run
this
is
using
multiple
tools.
We
have
the
WebEx
itself.
We
will
be
using
the
video
feed
to
share
a
little
bit
of
the
presenters
and
we
will
be
showing
the
slides
and
in
the
chat
room
that
goes
with
this
WebEx
chat
room.
We
will
use
primarily
for
my
the
queue.
So
we
don't
wish
to
have
discussions
on
that
chat,
pls,
yus,
plus
Q,
minus
Q.
D
D
D
D
D
We
have
to
win
the
jabber
session,
so
we
shall
be
able
to
use
Java
and
we
are
going
to
try
and
watch
the
queue
and
other
things
you
can
help
with
we're.
Always
looking
for
reviewers
for
working
group
draft,
we
have
a
number
of
drafts
coming
up
to
a
working
group.
Last
call
please
look
for
these.
Please
review
those.
Please
also
take
chance
to
review
any
other
documents
you
find
being
discussed
and
or
just
appearing
on.
The
list.
Reviews
are
what
makes
this
process
work.
B
Of
completed
working
group
items,
we
now
have
three
rfcs
on
the
extensions
to
the
forward
error
correction
framework
to
accommodate
the
the
RLC
coding
RFC
numbers
are
there:
Vincent
has
been
very
patient.
It's
been
a
long
adventure
they're
out.
Let's
see
that
gobbledygook
in
the
middle
of
the
slide
is
announcing
that
the
infamous
web
RTC
cluster
238
is
about
to
enter
all
48,
which
means
our
one
draft.
As
part
of
that
cluster
has
been
lingering
in
the
RFC.
B
Datagram,
a
PMT
UD
is
in
IAS
G
review
three
IDs
with
Raghu
chairs
authors
after
work,
let's
call
our
our
our
all
mine
for
some
reason.
The
first
two
drafts
easy,
an
encapsulation
for
lower
layer
protocols
and
ECM
for
tunnels
that
use
shim
headers.
We
have
rough
consensus
on
the
list
as
to
what
the
fragmentation
text
needs
to
say.
Bob
needs
to
find
the
copious
spare
time
to
write.
It
I
need
to
find
the
copious
spare
time
to
review
it.
The
drafts
will
be
revised.
B
The
crucial
thing
is
these
drafts
have
the
line
with
RSC
3168
ecn
requirements
on
we
assembly,
and
then
we
can
separately
decide
whether
we
want
to
with
3168
to
to
improve
that.
This
should
be
a
text
exercise.
That's
what
her
confidentiality
impacts.
Your
Shepherd
thinks
we
are
getting
close
to
done
with
the
text
bashing.
With
luck,
we're
gonna
have
one
more
revela
straf
that
will
finally
bash
the
text
insert
the
mentions
of
whatever
else
needs
to
be
mentioned,
and
then
I
will
I
will
write
the
ship
report
and
make
this
Martin's
problem
next
slide.
B
B
B
H
B
Announcement
to
the
list
of
what's
going
to
go
into
the
ship
to
to
to
the
Shepherd
report,
which
includes
sending
sending
your
views
on
the
draft
and
David's
Knaus
views
on
the
draft
to
eye-to-eye-to-eye
TFS
call,
which
I
think
is
the
more
appropriate
forum
to
work
to
work.
Those
out.
Okay,
I,
don't
agree
that
process.
B
H
B
D
D
what
item
is
relevant
here
and
we
worked
with
Mark
Coleman
the
main
author
when
we
did
the
UDP
guidelines
some
while
ago,
and
so
the
working
group
has
already
published
a
document
that
is
supposed
to
be
consistent
with
this
more
detailed
document
and
I
would
recommend
that
you
read
it
and
please
send
discussion
of
this
to
TCP.
M
is
a
joint
working
group
last
call
they
would
love
to
hear
feedback.
D
One
has
been
around
for
as
long
as
I
can
remember,
which
is
the
nut,
support
document
and
I
believe
that's
pretty
near
finished
now
and
expect
a
working
group
must
call
of
that
very
soon.
There's
also
the
SCTP
base
update.
This
is
mainly
an
update
of
the
text
of
the
spec
to
include
the
errata.
It's
not
intended
as
a
major
change
to
our
CTP
in
any
way.
D
Please
review
it
in
that
with
that
thinking
that
this
is
not
intended
to
be
a
major
change,
but
it
is
important
time
to
clean
up
the
spec
and
completely
wording
in
there.
So
it's
a
good,
solid,
spec
and
I
comments
still
supported.
The
next
read
other
will
do
what
you
must
call
of
that
when
we
come
to
those
two
items
in
the
meeting
shortly,
I'll
be
asking
for
people
to
volunteer
to
review
these
the
L
press,
trust
which
we
discussed
in
the
second
interim
meeting
or
will
come
to
those
later
rather
than
today.
D
These,
then,
are
the
list
of
Woodruff
IDs,
which
are
currently
with
the
working
group,
not
support
a
CTP
base
spec
these
three
alpha
s
drafts
the
non
queue
building,
PHP
draft
UDP
options
and
the
tunnel
congestion
feedback.
There
are
a
number
of
individual
drafts
which
I
mentioned
on
this
slide.
In
fact,
there
are
more
than
this,
but
this
just
calls
out
some
of
those
individual
drafts
which
are
waiting
currently
in
the
sidelines
to
enter
TS
vwg
feel
free
to
comment
on
any
of
these
on
the
list
use
the
list
to
talk
about
them.
D
We're
interested
in
appear
on
your
thoughts
on
these
drafts.
There
are
two
drafts
at
the
top
which
I'd
like
to
just
call
out,
and
the
socks
protocol
is
an
in
area
document
and
as
far
as
I
know,
it's
proceeding
in
int
area.
In
the
absence
of
the
Vancouver
meeting
and
some
point,
this
will
be
working
group
last
told
with
this
working
group
and
because
socks
is
something
that
is
not
just
interior.
It's
the
binding
between
the
interior
and
putting
two
interior
pipes
together.
So
it's
something
that's
relevant
to
TS,
vwg
and
they're.
D
Looking
to
us
for
the
transport
clue
to
review
that
document,
the
second
document,
the
reassignment
of
system,
points
to
the
iesg
and
there's
a
nob
working
group.
Internet
draft
was
put
forward
to
propose
changes
to
their
Ayana
process
for
system
ports
and
it
went
through
the
ITF
lost
whole
process
and
a
number
of
different
things
appeared
and
this
document
is
going
to
be
recycled
and
revised
and
a
decision
made
on
document
proceed.
It's
not
a
TS
vwg
were
tightened,
but
it
is
close
to
some
of
the
stuff
that
TS
vwg
is
done
in
the
past.
D
I
B
D
D
D
D
This
is
something
that
Joe's
revising
I'm,
not
aware
that
Joe
is
going
to
make
a
presentation
at
the
meeting,
and
he
is
about
to
put
in
a
set
of
revisions
to
deal
with.
A
queue
of
things
have
been
asked
since
last
IETF
and
he
used
a
new,
revised
ID.
So
I
don't
know
whether
when
we
the
June
deadline
or
not,
but
certainly
by
June,
the
thing
should
be
in
a
pretty
good
shape.
B
Yeah
what's
happening
here
is
the
some
reason
we
accidentally
got
the
milestones,
separated
in
practice.
The
draft,
the
top
of
the
screen
in
East
and
encapsulation
guidelines
and
the
graphical
the
6040
update,
are
paired
and
they
will
be
revised
together
and
sent
off
the
i8
to
the
iesg
together
next
month,
or
so
all
other
things
permitting.
D
D
D
D
Well,
we've
done
most
of
our
announcements
and
heads
up
we're
going
to
say
a
little
bit
about
the
plans
for
the
second
interim
I
expect
that
to
be
worse-
and
hopefully
he
does
too,
and
we
then
put
up
to
the
SPT
Pete
Rouse
transport
working
group
drafts
on
protocols
and
a
couple
of
individual
drafts
that
are
looking
for
some
guidance
by
the
working
group.
These
two
drafts
need
a
halt,
so
we'll
be
interested
in
knowing
your
views
on
whether
they're
interesting
material
to
work
upon.
D
D
Okay
slide
about
so
we
won't
do
it.
The
next
agenda
slide.
I
think
this
is
the
agenda
for
the
second
interim.
This
is
a
little
bit
further
out
and
the
in
trends
in
on
Monday,
the
27th
of
April
and
we're
going
to
focus
this
particular
interim.
Just
on
the
l4s
and
ecn
topic,
particularly
focusing
in
on
ECT
one
usage.
D
D
Okay,
so
recap,
and
if
you
haven't
yet
done
so
there
are
blue
sheets
available
in
etherpad.
Please
make
sure
you
do
sign
in.
If
you
can
use
Java,
we
can
use
Java
for
remote
chat.
I,
see
some
Java
going
on
in
the
main
WebEx
chat,
because
more
people
are
joined
there.
We'll
try
and
make
this
work.
If
you
do
want
to
talk
at
the
mic,
make
sure
you
put
plus
Q
into
the
main
WebEx
chat.
I.
D
D
A
I
Okay,
so
this
is
there's
really
two
drafts
that
this
affects,
and
it
was
a
comment
from
Jetta
touch
during
the
working
group.
Last
call
to
say
what
about
fragmentation
and
reassembly
internals.
The
drafts
are
primarily
about
tunnels,
not
fragmentation
and
reassembly,
and,
as
David
has
pointed
out
and
I've
pointed
out,
the
two
are
often
often
come
together,
but
they're
they're
orthogonal.
So
anyway.
Let's
next
slide,
please
with
so.
The
top
level
point
here
is
that
RFC
3168
already
mentions
what
to
do
about
reassembly
and
essentially
aims
to
preserve
the
time
of
HTC
n
mark.
I
It
is
that
cuddle
doesn't
aim
for
a
specific
time
between
marks.
It
just
uses
time
and
and
then
and
then
it
adjusts
the
time
until
it
balances,
and
so
no
it's
no
particularly
different
process
to
adjusting
probability.
It
just
adjusts
a
thing
and
the
apps
to
use
time,
and
so
the
actual
time
between
the
marks
isn't
special
and
actually,
as
you'll
see
in
the
next
example.
It
causes
unfairness
to
try
and
preserve
the
mark
time
between
the
marks.
I
I
So
it's
the
tunnel
is
fragmenting,
so
you
end
up
with
twice
as
many
packets
in
the
lower
flow
I'm
looking
at
the
top
picture
top
off
this
picture,
so
with
a
certain
percentage
markings
28.2%
over
2,000
packets
per
second,
you
get
four
marks
per
second
for
the
second
flow.
That
means
and
the
way
3168
does
the
reassembly
we're
assuming.
This
is
3168
reassembly.
I
This
one
uses
a
F
key
Shatila
as
the
aqm,
so
this
time
it
forces
the
the
closed
all
at
the
same
rate
and
because
the
scheduler
forces
there
and
so
effectively,
TCP
reverse
engineers.
The
percentage
marking
them
in
the
F
key
scheduler
to
make
sure
that
they
all
have
equal
rate
and
I've
shown
three
flows
here,
a
B
and
C,
and
one
of
them
or
the
top
one
is
ads
on
the
previous
slide,
slightly
smaller
than
1500
bytes.
I
So
the
the
upshot
of
that
is
with
what
we've
got
to
sort
that
out.
So
what
we'll
do
in
these?
This
update,
shim
draft
and
easy
and
in
kept
guidelines
draft
is
just
say
the
fragmentation
reassembly,
the
end
of
scope,
these
about
tunneling
and
fragmentation.
Refueling
reassembly
is
orthogonal
to
that.
I
We
will
mention
that
3168
discusses
ECM
fragmentation
and
reassembly,
but
we
won't
give
it
as
a
normative
reference
it
with
informative
reference
and
we'll
update
3168
fragmentation
and
reassembly
separately.
If
that
and
that'll
be
a
draft
that
has
to
be
adopted
in
all
the
rest
of
it
and
they'll
be
a
short
one
of
he
is
to
update
3168
as
a
produce
standard
track
draft,
and
that's
it.
B
That's
a
process
and
I
believe
that
we've
pretty
much
agreed
on
slightly
longer
descriptions
of
the
of
the
mention
RFC
3168
discuss,
DC
and
frag
and
reassembly
text
on
the
list.
It's
a
little
bit
tricky
to
write
because
you
essentially
essentially
want
to
say
that
you
got
if
you
want
to
figure
out
how
to
do
it
now
go
see
3168.
D
B
B
B
D
I
L
What
has
to
be
done
still
reviewed
the
document
and
provided
a
list
of
issues
which
are
well
editorials
might
be
not
the
right
term,
but
look
at
text
changes.
Something
like
that
in
a
detailed
way.
So
I
have
to
go
through
this
and
address
these
most
likely.
I
will
put
in
the
revision
of
when
that's
done
and
then
another
format
change
has
to
happen.
L
Originally
4960
was
written
in
XML.
The
ROC
editor
changed
it
back
to
n
Roth
when
I
got
it
for
the
base,
I,
converted
n
off
to
be
two
of
the
XML
in
a
very
strange
way
to
preserve
the
end
of
formatting,
and
then
it
will
be
reformatted
to
v3
and
I
will
take
out
all
the
hex
to
make
it
look
like
enough
stuff.
L
L
B
D
D
Including
a
pointer
mark
I,
don't
I,
don't
think
my
chronic,
oh
okay,
you
paste
that
in
so
I'm
expecting
a
very
small
section
somewhere,
which
says
the
changes
between
496
old
days,
and
this
are
documented
here
in
this
RFC.
Additionally,
there
are
two
bullets:
three
bullets.
Whatever
of
changes:
okay,.
B
D
D
Working
progress
line
just
for
complete
transparency
is
going
through
every
use
of
an
RFC
two
one,
one
nine
key
word
and
checking
that
the
the
text
there
is
completely
watertight
a
couple
of
places.
There
are
it
some
days
that
research
will
have
parts
of
the
document
which
I
just
wanted
to
turn
and
make
sure
that
they
were
completely
clear
and
so
I
suspect
this
shouldn't
raise
questions,
but
if
they
do
I
guess,
Michael
will
discuss
them
on
the
list
as
usual,
yep
Peter.
L
F
D
Good
ready
good,
and
by
that
time
we
will
need
reviewers
for
this
document.
So
if
you're
a
person
who's
been
reading
this
as
soon
as
Michael
pulse
the
v2
to
v3
conversion,
we
look
people
to
go
through
the
fine
comb
and
we
look
people
to
volunteer
to
do
that
in
the
working
group.
Last
call
so
and
as
soon
as
that,
second
revision
is
published.
We're
looking
for
people
to
read
that
text
and
check
it
in
detail.
L
There
came
up
the
suggestion
to
include
a
module
and
that
was
provided
by
Mohammed
and
it
was
included
they
a
XML
sources
were
converted
from
v2
to
v3.
So
I
used
this
document
as
an
exercise
to
do
this
conversion,
and
we
had
some
comments
from
Maxime.
A
lot
of
comments
from
Maxim
I,
try
to
address
them
and
the
result
is
revision.
16
next
slide.
L
L
So
the
drawback
is
that
in
this
case
the
net
would
just
drop
the
packet.
The
end
note
would
have
to
run
into
timeouts
multiple
times
and
then
this
that
what
the
stack
does
is
give
given
any
indication
to
the
application
and
then
the
application
has
to
read
trigger
another
Association
set
up
and
that's
something
I
don't
like.
So
that's
the
technical
thing,
any
preference
is
there.
So
I
would
like
to
make
the
life
most
simple
for
the
application
he
wants
to
allow
this
for
a
narrative
from
an
application
and
I.
L
L
L
D
Line
of
thinking
and
suggest
you
propose
to
the
working
group
some
text
which
says
if
this
is
a
shirt.
This
is
the
reason
why
you
should
do
it
I'm
a
little
bit
interested
in
looking
at
both
options
here,
because
having
the
must
for
something
was
to
require
the
protocol
mechanism
to
be
transmitted
from
the
knot.
Is
it
reliable?
So
the
must
isn't
really
that
helpful
to
the
huge.
If
you
inject
a
packet
that
may
or
may
not
finally
reach
the
end
point
I
want.
L
L
We
talked
about
net
devices
in
the
document,
and
this
is
done
in
RFC
to
663
and
RFC
for
787
and
moment
suggest
to
use
net
function
because
that's
the
term
using
RFC
six,
eight
eight
eight.
There
are
even
other
documents
which
use
simply
net
in
the
sense
of
being
an
acronym
not
for
network
address
translation,
but
using
it
as
an
acronym
for
network
address
translator.
So
what
should
we
do?
I?
Don't.
B
D
C
Actually,
I,
don't
care
I,
don't
have
any
I
would
say
it's
the
the
commit
is
really
minor.
It
just
pick.
The
one
which
is
I
would
say
your
your
favorite
one
and
then
to
be
consistent
with
the
I
would
say
through
the
document
it
will
just
go
to
I
would
say
D
the
use
of
device
is,
as
for
people
will
implicitly
mention.
That
is
something
which
is
really
I
would
say,
hardware
why
we
are
mainly
dealing
with
with
with
I
would
say
with
the
software
component.
C
That's
the
the
initial
current,
but
more
basically,
actually
one
of
the
comments
they
would
like
that
you
you
would
cover
it.
I
would
say
in
the
new
version
was
about
the
fragmentation
because,
for
instance,
in
your
document
you
Monday
to
have
I
would
say
the
fragmentation
to
be,
and
must
be,
I
would
said:
reassembly
must
be
supported
by
the
night
devices
itself.
C
This
is
not
something
that
we
have
today
for
all
the
I
would
say:
ID
the
net
flavors
we
have
in
India
in
the
field,
only
one
exception
about
the
net
64,
which
requires
to
do
the
reassembly,
so
I
think
that's.
You
need
to
have
more
discussion
that
part
to
to
have
the
implication
of
having
the
I
would
say.
D
the
net
function,
s
F
to
the
door
assembly.
C
How
the
memory
will
be
I
would
say,
control
I,
see
that
there's
a
lot
of
I
would
say
complications
to
to
do
that
on
on
the
device
you
check,
some
consideration,
and
so
on
so
I
would
I
would
I
would
say
so.
The
fragmentation
form
is
more
important
than
the
I
will
say
the
terminology
one.
So
I
would
like
you
that
if
this
is
possible
as
you
can,
you
can
cover
that
in
the
next
version,
with
more
attention
I.
D
Okay,
so
Michael
or
theirs,
or
whoever.
What
should
we
do
with
fragmented
packets,
SCTP
kind
of
expects
the
IP
layer
to
help
with
its
fragmentation?
It's
one
of
the
functions
in
the
SCTP
spec,
so
we
could
write
and
explain
that
this
is
something
that's
important
or
you
could
just
allow
a
nut
to
break,
not
send
these
packets,
in
which
case
you
will
get
dirty
Graham
dropped.
Is
that
what
we're
talking
about.
L
L
L
L
So
if
you
so
path,
MTU
discovery
helps
you
to.
If
the
MTU
drops,
you
will
figure
that
out
and
you
will
adopt,
but
in
setp
one
if
you
have
sent
a
packet
which
is
larger
than
the
path
I'm
to
you,
because,
for
example,
the
path
MTU
was
immediate
for
some
reason,
shrank
I
said
he
might
not
be
able
to
read
fragment
the
path
to
to
be
built
the
packet
in
a
smaller
way.
So
it
then
it
relies
on
a
small
amount
of
time
for
a
fragmentation
and
reassembly
to
work
once
it
learn.
L
L
And
that's
alright!
We
soft
one
might
also
wanted
that.
We
don't
use
public
address
for
the
address
of
the
external
side
of
the
net.
We
use
external
side
and
then
we
change
the
the
terminology
for
the
for
the
other
end
point
from
external
to
remote
and
that's
consistent
and
he's
fine
with
it,
and
so
I
can
change
that.
D
M
Also
in
the
process
risked
most
the
comments
that
had
been
made
during
the
IP
I
kept
105
meeting
and
on
the
mailing
list
around
that
time.
It
was
one
set
of
comments
that
we
didn't
tackle
and
that
drastic
or
zero,
which
was
leading
to
interoperability
with
Wi-Fi
and
spendy,
Wi-Fi,
multimedia
or
edca,
and
that
was.
G
M
At
then
followed
after
craft
zero,
so
draft
one
which
we
just
published
about
a
month
ago
now
we
wrote
that
Wi-Fi
improper
ability
section
introduced
some
new
requirements
to
provide
safeguards.
There
were
some
concerns
or
around
the
potential
for
in
Wi-Fi
the
NQ
b
code
point
to
be
created
in
a
way.
M
That's
not
that
doesn't
comply
with
the
eight
with
the
p
HB
requirements,
so
it
actually
gives
it
priority
over
best
efforts
or
default
district
code
point
which
was
in
cuba
graph,
has
a
requirement
of
not
introducing
a
priority
difference
between
the
two
and
and
so
a
number
of
safeguards
were
added
into
Wi-Fi
section
and
some
recommendations
on
configuration
of
edca.
In
order
to
eliminate
that
those
issues
there
are
also
a
few
editorial
changes
that
we
took
care
of
in
draft
a
one
but
that's
published
for
a
month.
M
M
Detail
in
the
draft
around
operation
in
certain
situations,
so
first
one
being
existing
DF,
CP,
remarking
pathologies,
there's
some
studies
and
then
two
distant
past
about
ways
that
district
code
points
were
manipulated
or
mangled
in
transits
and
not
in
the
common
way
of
just
bleaching
to
zero,
but
but
actually
modification
of
particular
bits
in
the
in
the
yield
and
so
some
discussion
of
sensual
impact,
but
that
might
have
on
in
nqb
treatment.
It's
needed.
M
There
are
a
number
of
shoulds
in
the
draft
and
we
don't
provide
much
detail
on
with
the
ramifications
of
not
complying
with
those
shorts
make
a
couple
of
them.
We
do
but
several
of
them.
We
don't
so
work
there
and
then.
Lastly,
on
the
slide
here,
further
alignment
with
HB
spec
guidelines
provided
in
our
C's
2474
2475
I've
got
a
little
big
tail
on
the
next
line.
That
shows
what
stuff
to
do
on
that.
B
Next
slide
Greg:
this
is
David
one
more
work
item
which
I'm
gonna
sign
to
myself
the
Shepherd,
and
that
is
this
would
be
a
good
time
since
we're
approaching
completion.
Do
we
check
the
selection
of
the
default
default
dscp
for
this
PHP
and
that
I
think
that's
my
responsibility
Shepherd
to
to
kick
that
discussion
off
on
the
list.
Thank
you.
M
B
M
M
Many
of
these
we
I
think
have
already
taken
care
of.
There
are
three
I
highlighted
that
we
definitely
need
to
do
some
work
on,
and
then
there
are
a
few
that
are
close,
but
maybe
you
don't
exactly
comply
with
the
expectations
like,
for
example,
putting
things
in
the
into
appendices
rather
than
having
them
in
the
main
body
of
the
raft.
C
D
From
my
point
of
view,
I
be
interested
in
peeing
out
the
disk
of
core
point
selection,
a
separate
topic
on
the
email
list
and
let's
try
and
confirm
that
we've
got
the
right
discord
points
and
it
what's
in
the
right
way.
It
seems
like
something:
that's
orthogonal
to
the
specification,
the
PHP,
so
we
could
probably
separately
call
that
and
the
list
just
get
some
people
to
see
whether
we
all
agree
with
the
analysis
and
then
perhaps
even
we
can
provisionally
allocate
that
DF
VP
to
this
document.
I
agree.
I
need.
D
D
You're
bringing
this
here
so
I'll
do
a
little
bit
of
a
prelude,
and
this
working
group
used
to
not
do
nut
stuff
because
we
had
a
behaved
working
group
and
then
the
behaved
working
group
did
the
clever
thing
of
plotting
and
asking:
where
did
all
the
work
go
and
the
answer
was
the
work
came
to
TS
vwg,
which
is
fine,
and
then
suddenly
we
end
up
with
a
new
transport,
and
so
do
we
need
a
document
about
quit
and
how
it
worked
resolution
to
the
behaved
document.
Do
we
need
guidance
for
this?
D
E
E
E
E
E
Though
going
the
other
side,
one
thing
that
we
are
facing
in
quick
community
is
that
some
rounding,
our
tech,
architectures
and
data
centers
route
based
on
the
five
couple,
so
that,
if
there's
any
sort
of
address
change,
whether
it
be
an
a
providing
or
or
a
intentional
migration,
the
Packer
will
end
up
at
some
other
server.
So
there's
a
lot
of
work
to
kind
of
solve
this
problem.
E
One
thing
someone
might
try
to
be
quote-unquote
helpful
and
have
the
net
monitor
the
connection
IDs
and
then,
if
there
is
a
net
new
binding
that
changes,
the
address
simply
rewrite
the
source
address
to
allow
it
to
route
correctly
back
to
the
correct
server.
Well
number
one.
This
won't
work.
If
the
connections
view
changes,
so
it
eliminates
the
intention
of
migration
case
and
secondly,
when
there
is
any
sort
of
address
for
change.
There's
a
there's,
a
whole
process
to
validate
that.
E
It's
a
correct
that
it's
a
accurate
but
in
fact
something
that
be
that
the
there's,
an
actual
change
in
the
address
of
the
client
and
not
some
sort
of
hijack
attempt
and
all
those
mechanisms
occur
in
the
crypt.
Though,
and
if
you
mask
that
from
the
end
server,
then
it's
not
going
to
get
perform
all
those
checks,
that's
kind
of
creating
a
security,
vulnerability.
E
E
E
Another
option
to
be
just
to
have
this
thing
lived
forever
as
an
expired
individual
draft
and
have
to
click
off
strap
just
link
to
it
as
an
information
reference
for
some
background,
just
put
in
a
the
TLDR
version
in
the
abstract
and
point
to
this
for
further
discussion.
We
could
make
it
a
standalone
RFC
if,
if
people
have
the
energy
for
that-
or
we
just
drop
this
because
not
really
important,
they
need
to
document
so
again,
I'm
open
reviews
and
I'm
open
to
input
on
what
we
should
do.
This.
B
N
Think
we
should
definitely
no
matter
what
happens
to
this
document.
Add
something
to
the
ability
draft,
a
quick
and
to
this
document
at
that
point.
I,
don't
really
care
about
any
more.
If
this
is
a
known,
RFC
or
just
an
expired
draft,
I'm
also
fine
having
it
and
I
am
RC,
but
it
should
definitely
be
mentioned
in
the
benefit.
But
you
put
it
correct.
I.
D
Think
you're
right,
I
think
the
magic
bility
doesn't
have
to
include
this.
Then
the
question
is
whether
David's
comment
is,
is
something
that's
important?
In
other
words,
will
the
nut
implementers
read
something
shortened
or
a
half?
We
want
to
do
that
because
that's
a
really
bad
idea,
interesting,
okay,.
J
I
I'm
convinced
that
not
implement
it
necessarily
reads
it,
but
I
think
we
should
write
it
anyway,
because
I
think
it's
important
to
document
what
the
right
thing
to
do
is
whatever
or
not.
It
has
a
whole
lot
of
effect
in
practice.
I
would
also
suggest
that
this
includes
some
some
quite
clear
statement
to
remind
people
that
not
all
UDP
traffic
is
quick.
O
Yeah
so
I'm
I'm
plus-one
on
the
short
standalone
document,
I
think
that
that's
the
right
thing
to
do:
I'm
plus-one
on
RFC,
because
I
I
agree
with
the
statement
that
was
made
that
the
net
vendors
aren't
going
to
read
this,
but
the
net
fenders
are
not
the
primary
intended
audience.
In
my
opinion,
it's
people
who
would
be
showing
this
to
the
offenders
who
are
who
are
the
opposite
of
net
fenders
and
plus
one
on
the
mention
of
of
an
ops
area
of
the
office
of
management
draft
mentioning
this
so
I
think
I.
O
D
D
D
Thank
you.
If
this
close
ahead,
I
will
give
you
the
caution,
return
since
I'm,
currently
wearing
the
Hat,
and
we
will
have
to
coordinate
closely
with
quick.
So
it
it's
not
a
matter
of
where,
where
you
do
this
and
I
wig
nor
the
other
ones.
So
it
will
have
to
be
something
that
I
deem
it
to
church
talk
with
together
or
the
choo-choo
start
talking,
and
so
tell
us
what
you
would
like
to
do.
Next,
Martin
I.
E
Think
the
feedback
has
been
pretty
uniform,
so
I
will
pursue
this
I'll
have
a
chat
with
Magnus,
about
which
working
group
this
best
lives
in
between
quick
in
here
and
I,
will
take
the
comment
and
then
a
Mira,
Mira
and
I
can
work
on
just
getting
a
reference
into
the
quick
ops.
Draft
I
mean
further
moment,
will
point
to
this.
This
ID
and
we'll
see
where
it
goes
from
there
and.
E
B
This
moves.
If
this
moves
forward
into
uwg,
the
TSU
teachers
will
need
to
coordinate
with
the
quick
chairs.
I
I,
don't
know
that
I
sort
of
quick
chairs
on
the
in
on
on
the
list.
So
somebody
probably
need
nice,
nice
game.
A
heads
up
there
that
we
had
this
discussion.
Martin
I,
think
that
might
be
you.
D
B
This
draft
has
been
floating
around
for
a
while
now
it's
on
version,
2
3gpp
had
a
very
negative
reaction
to
this.
When
it
first
appeared,
we've
hadn't
had
some
discussions
with
some
of
3gpp
folks
and
their
view
is
no
longer
quite
as
negative,
although
we're
still
not
at
least
speaking
speaking
as
a
chair,
I
think
not
yet
sure
exactly
what
the
purpose
of
this
is
isn't
how
to
position.
It
I
believe
the
value
of
this
draft
intended
audience
who's
supposed
to
use
it.
How
does
it
relate
to
the
3gpp
standards?
P
Thank
you.
So
let
me
give
you
a
bit
more
context,
because
here
indeed
this
is
important
and
you
will
see
on
the
next
site
why
the
first
welcome
will
still
be
cold
on
this
on
this
draft.
But
what
we're
looking
at
here
is
a
case
which
starts
to
be
emerging
where
Yui
device
may
have
to
compute
and
pass
through
a
network
one
going
through
the
3gpp
realms.
You
know
that's
LTE,
5g,
etc.
You
name
it
and
the
other
one
is
going
through
an
unlicensed
type
of
network,
which
is
typically
relying
on
these
surfs.
P
So,
in
other
words,
you
have
some
traffic
going
through
the
3gpp
domain
and
typically,
what
happens
there
is
that
there
is
a
dialogue
between
an
enterprise
and
a
carrier
by
which
they
agree
upon
a
certain
type
of
treatment
for
a
certain
type
of
traffic
and
a
certain
type
of
devices
that
is
taken
care
of.
But
then,
if
those
devices
have
two
connections-
one
for
example,
going
also
to
Wi-Fi
what
we
see
that
those
implementers.
Those
enterprises
would
like
to
as
much
as
possible,
but
tend
to
apply
the
same
type
of
treatment.
P
Qos
treatment
on
the
leg.
That's
going
through
the
observe
domain
of
the
bottom
leg
that
you
see
on
the
screen
here,
so
that
there
is
a
higher
chance
that
when
this
traffic
reaches
the
enterprise
or
the
cloud
application
that
the
enterprise's
is
using,
those
two
legs
perform
in
ways
are
somehow
somewhat
comparable.
And
this
is
difficult
because
the
3gpp
logic
uses
a
system
which
is
relying
on
structure
like
q,
CI
q,
fi
v
qi,
depending
on
on
the
generation
you
talked
about,
which
is
much
richer.
P
I
must
say
that
than
the
gscp
values
that
we
use
in
your
based
on
our
c-45
94,
for
example.
So
what
we
attempt
to
do
in
this
draft
is
to
offer
mapping
you
know,
structure
that
could
allow
those
implementers
to
look
at
the
qci
and
say
oh
qci
blah
seems
to
be
matching
intent.
Blah,
and
this
in
this
serve,
seems
to
be
matching
what
we
could
use
as
marking
blah
the
SCP
value
XYZ
in.
P
As
a
matter
of
fact,
we
find
that
in
many
cases
those
QC
eyes
are
new
enough
that
in
the
deserve
domain,
we
don't
have
the
equivalent.
So
what
we
did
there
was
to
try
to
create
a
structure
of
mapping
whatever
possible
and
whenever
not
possible,
conclude
that
the
implementers
would
have
to
implement
in
the
disturb
domain,
probably
some
markings
that
would
be
new.
You
know
concluding
that
there
is
no
clear
mapping
that
could
be
used
from
this
QC.
P
You
know,
use
this
draft
to
map
the
qci
getting
gifts
or
marking
that
was
fairly
and
clear.
In
fact,
you
know
the
draft
itself
was
not
any
clear
on
any
of
those
those
framework
environments.
Also,
we
didn't
say
if
it
was,
you
know
supposed
to
be
something
that
could
be
suggested
as
a
possibility
and
would
be
in
the
informational
tract
or
if
that
would
be
a
stereo
track.
You
know
making
it
mandatory
every
time
that
would
happen
so
needled
reception
was
called,
and
we
understood
very
well.
Why
so?
We
worked
on
draft
number.
P
Two,
where
we
try
to
make
the
context
much
clearer
and
of
course,
we
were
intending
to
preach
to
present
that
that
didn't
happen
in
the
space
to
face
at
all.
So
we
had
a
third
contributor
joined
us
who
helped
us
also
add
some
recommendations
for
5g
q
ice
elements,
which
are
another
qfi
in
static.
You
eyes,
based,
for
example,
on
the
GS
23
501
next
slide,
please.
So
here
we
are
today
with
a
set
of
possible
recommendations
which
are
clearly
qualified
as
being
informational.
P
We
do
not
need
to
know
to
force
this
on
anyone,
but
because
we
have
multiple
enterprises
that
implement
with
us
other.
You
know
through
the
common
and
health
vendors
or
you
know,
through
their
own
negotiation,
with
inhale
vendors,
those
dual
connections
and,
as
we
see
these
as
growing
growing
permanently,
we
would
like
to
you
know,
offer
you
know
the
community
a
common
way
of
seeing
those
mapping
possibilities
so
that
when
they
receive
a
qci
from
you
know
the
5g
or
LTE
link.
P
They
have
an
idea
of
how
they
would
be
treating
the
traffic
going
through
that,
if
serve
domain,
to
try
to
match
some
intent,
which
would
be
your
clothes.
If
not,
you
know
entirely
identical,
because
I
don't
think
it
is
entirely
possible,
but
at
least
close
in
intent
to
what
they
will
be
be
receiving
from
the
carrier
side.
So
at
this
point
you
know
what
we
would
love
to
see
is
people.
P
You
know
looking
into
this
draft
providing
commands
first
on
whether
this
framework
that
we
specified
is
clear
enough
to
show
that
we're
not
you
know,
dictating
any
mapping
21
and
certainly
not
you
know,
talking
to
3gpp
asking
them
to
do
work,
but
also
help
us
see
if
the
mapping
we
propose
makes
sense
or
not.
In
particular,
you
will
see
if
you
take
the
time
to
read
this,
that
some
of
the
maps
are
isometric,
which
means
that
we
have
one
DHCP,
that
you
know
clearly
Maps
the
intent
of
a
qfi.
P
But
when
we
go
the
other
direction,
we
couldn't
find
the
same
intent
on
the
on
the
way
back,
so
we
have
a
bucket
that
falls
well,
but
that
bucket
doesn't
really
fit
the
pipe
to
go
the
other
direction.
So
we
do
have
some
cases
where
we
have
a
symmetry
in
the
mapping.
It
seems
to
us.
You
know
when
the
folks
in
my
company,
working
in
the
3gpp,
who
are
more
universe
and
I,
am
into
the
3gpp
logic
behind
the
30s
I.
You
see
I
that
this
is
unavoidable,
but
you
know
intellectually.
P
This
is
not
very
satisfying
because
we
have
this
impression
that
things
are
not.
The
type
doesn't
have
the
same
structure
in
both
directions,
so
we
would
also
love
to
get
feedback
on
those
to
see
if
anyone
has
issues
with
that
asymmetry
on,
if
anyone
has
some
recommendations
on
how
these
symmetries
would
be
solved,
if
they
need
to
be
so-
and
that's
pretty
much
where
we
are
I.
G
G
Your
draft
with
the
mapping
yet,
but
there
is,
has
been
an
effort
active
for
some
time
to
make
a
way
to
communicate
such
services
across
domain
boundaries
and
to
negotiate
a
marking
for
them
at
the
at
at
that
boundary.
So
I
would
encourage
you
to
maybe
take
a
look
and
consider
whether
there's
a
way
to
do
it.
That
way.
P
P
You
know
based
on
SLA,
so
there
is
not
always
direct
mapping
between
what
the
UE
could
be
marking
as
dscp
with
what
the
carrier
would
be
allocating
as
curious
and
actually
like
UCI,
but
you
know
that
there's
maybe
definitely
a
way
maybe
to
to
carry
that
information
across
the
mind.
So
I'll
read
that
traffic
carefully.
Thank
you.
I.
D
Guess,
like
the
church
would
be
interested
in
feedback
about
whether
you
think
the
BGP
community
for
to
us
marketing
draft
in
some
way
touches
on
what
you're
doing.
Even
if
you
are
choosing
a
different
approach,
because
we
should
liaise
with
these
people
in
the
IETF
is,
if
they're
doing
something
at
least
a
little
bit
similar
yeah.
O
O
O
P
M
O
As
people
are
doing
the
the
okay,
what's
the
3gpp
thing
where
you
are
dropping
local
trio,
diverting
local
traffic,
going
to
a
wife
on
a
LAN
or
something
like
that?
Whatever
that's
called
you,
may
you
may
be
hitting
a
few
different
unlicensed
path
path
segments,
not
just
one
so
I
think
that
that
that
encourages
I
like
this
draft
when
it
came
out
which
is
doesn't
matter
to
anything
but
I.
O
Think
I
think
that
if
the,
if
it's
the
case,
that
different
unlicensed
links
may
be
using
different
markings
without
any
guidance
at
all,
I
think
I
think
that
that
argues
a
bit
more.
That
moving
this
forward
is
a
good
thing
to
do,
because
you
know
here
you're
kind
of
kind
of
losing
fidelity
with
you
know
the
intended.
O
O
P
F
P
So
I'm
expecting
exactly
to
a
point
that
we
have
a
stable
draft
to
which
we
may
have
to
add.
You
know
some.
You
know
updates
for
a
6g
or
or
or
traffic.
You
know
that
that
can
come
as
a
as
critical
for
the
village
of
5g,
so
yeah
I
mean
waiting,
there
will
be
a
stable
foundation
and
then
a
need
for
a
date,
but.
O
O
It
seemed
like
to
me
that
publishing
this
as
an
RFC
would
be
a
good
thing
to
do,
because,
again,
the
intended
audience
isn't
just
people
who
are
running
3gpp
networks
and
if
they're
using
you
know
if
everybody
is
working
the
same
on
the
unlicensed
links
in,
but
that
might
be
a
that
might
be
a
helpful
thing
to
do
to
so.
You
know,
I
mean
this
is
an
informational
draft,
and
you
know
it
doesn't
have
any
more
standing
than
anybody
else
who
is
doing
if
serve.
O
Q
Q
So
do
you
anticipate
in
that
case
or
any
recommendation?
I
have
not
checked
your
updated
draft,
any
recommendation
that
that
scenario
should
use
the
same
marking
what
the
operator
used
for
the
other
link,
because
that's
a
clear
distinction,
because
if
it
is
managed
by
the
same
operator
right
or
configured
by
the
operator,
they
may
not
use
the
different
kinds
of
a
scheme.
P
Yeah,
thank
you
severe
and
Michael.
Thinking
is
that
carriers
know
what
they
are
doing.
So
if
they
are
in
control
of
both
links,
you
know
they
are
perfectly
capable,
without
any
draft
from
from
from
our
side
to
decide
if
they
want
to
profit
one
of
the
paths
or
if
they
want
to
treat
equality
both
pass
and
in
which
case
you
know,
they
will
apply
whatever
marking
they
think
is
relevant
to
make
that
those
to
pass
equivalent.
P
So
you
know
this
is
not
typically
a
case
where
this
graph
would
be
useful.
I
would
say,
address
this
graph
more
useful
when
an
enterprise
has
an
SLA
negotiation
and
dialogue
with
a
carrier
at
the
end
of
which
they
have
a
view
of
what
qcr
case
I
could
be
used
and
they
would
be
in
control
of
the
other
link
and
what
it
would
like
to
do
is
to
align
the
auto
link
to
the
3gpp
treatment.
If
it's
a
one
entity
controlling
both,
you
know
they
can
do
like.
P
P
L
P
P
B
Go
say
a
couple
of
things:
first
is
process
wise,
historically
RFC
45
94
started
out
as
informational
unclear.
How?
Why
do
we
adopt
it?
If
we
were
to
revise
and
update
45
94,
it
has
been
sufficiently
widely
adopted
that
it
would
likely
be
issued
as
a
best
current
practice,
and
that
would
be
a
plausible
path
forward
for
this
document
issue
it
as
informational.
If
it
goes
into
widespread
use
and
proved
useful
in
its
context,
comple
245
94,
then
perhaps
it
it
has
the
opportunity
to
come,
become
a
BCP
down
down
the
line.
B
D
M
M
The
first
time
I
take
a
look
at
this
draft
and
I
had
a
question
on
section:
6,
I
I,
any
considerations.
It
indicates
that
the
document
is
allocating
14
district
code
points.
It
also
describes
them
as
being
pool.
One
code
points
I
point
out
that
only
one
of
them
actually
is
a
full
one
code
point
yeah:
there
are
thirteen
code
points,
six
of
them
are
pool
2,
which
are
for
local
use,
and
seven
of
them
are
three
I
guess.
P
M
D
The
chairs
have
noticed
that
and
I'm,
also
not
as
a
chair
on
this-
that
we
don't
normally
allocate
large
numbers
of
dscp
to
two
people
in
RFC
and
they're
more
a
conserved
resource
that
we
expect
people
to
work
it
out.
So
we
we
will
need
to
revisit
the
number
of
12
points
and
and
how
we
deal
with
it.
But
the
first
point
of
action
for
you
probably
to
check
out
other
and
to
check
the
current
status
yeah.
Q
One
of
the
points
Greg
mentioned
you
know
I
forgot
to
mention
that
that
is
what
is
the
very
critical
point
that
needs
the
greater
review.
I
would
also
like
to
add
the
other
organization,
with
our
experience
like
Etta's,
which
is
the
American
telecom
standards.
They
also
in
their
specification,
is
some
of
the
mapping,
which
is
not
even,
of
course,
registered
with
the
AIA
now,
so
the
history
of
3gpp
also
the
way
they
have
defined.
Q
They
provided
the
flexibility
for
the
operators
to
do
their
in
the
in
their
own
network
when
they
are
not
interpreting
being
with
others
right.
So
assigning
this
the
code
points
the
Ayana
and
then
globally
used.
We
have
to
be
a
little
bit
careful
and
make
sure
that,
okay,
what
other
standards
are
not
using
and
they
are
now
recommending
in
their
specification,
which
we
believe
would
be.
You
know
a
difficult
task
for
us
and
that's
the
reason.
Q
D
B
D
P
If
I
may
a
note
on
that
Severus,
thank
you
and
I
think
that
there
are
two
different
types
of
organizations
logics.
One
is
where
vendors
like
carriers,
for
example
interoperate
with
each
other
within
you,
know
their
respective
domains
and
I
think
I
earn
thirty
four,
and
yet
that
you're,
referring
are
working
towards
that
goal
and
another
one
is
when
traffic
leaves
their
domain
to
be
sent
back
to
the
serve,
which
is
the
domain
where
we
are
concerned
here,
because
you
know
we're
not
within
carrier
exchanges.
P
Here
we
are
leaving
the
carrier
domain
and
we
try
to
have
a
parallel
path.
That
has
the
same
value
and
it
seems
that
these
organizations
have
not
treated
that
case.
I
are
34
by
the
way
is
very
limited
to
a
certain
number
of
subsets
for
essential
traffic
types,
but
has
not
expanded
into
you
know
all
the
year
q
SI
o
q,
CI
n
q
fi.
Precisely
because,
as
you
say,
carriers
are,
you
know
big
guys,
you
know
what
they're
doing
so
they
can
interrupt
with
each
other.
P
Q
You
have
actually
pointed
out
correctly,
so
that
is
remembered
the
early
on
we
mentioned
about
that
if
it
is
really
pacifying
that
these
are
the
use
cases,
it
is
referring
to
right
and
what
Greg
mentioned
that
in
this
draft,
you
are
asking
for
a
large
number
of
Ayana
code.
Points
which
are
M
is
the
universally
interoperable
right.
So
that's
what
I
am
mentioning
that
we
have
to
be
careful
and
get
a
good
read
from
every
organization
see
if
there
are
right
and
I
will
also
look
at
that.
E
P
So
in
this
graph
we
do
both
we
try
to
map
to
existing
the
scps
as
much
as
possible,
but
we
also
conclude
that
some
traffic
types
defined
by
3gpp
just
don't
have
an
equivalent
in
you,
know
RFC
4994
or
any
other,
defining
30
types.
And
then
we
conclude
that
the
new
DCP
would
be
needed
differently
to
translate
the
same
intent
on
the
other,
serve
domains.
B
P
D
B
Spence,
this
is
even
easier
this.
This
is
not
going
to
be
a
standard
track
document.
Therefore
it
cannot
allocate
the
cannot
allocate
DSC
peace
will
stop.
That
suggests
that
the
right
thing
for
the
author's
to
do
is
to
suggest
places
where
new
dscp
should
be
useful
and
right.
Separate
docks
to
separate,
contain
docks
to
allocate
them
based
on
individual
use,
so.
B
O
D
D
This
whole
idea
of
doing
working
this
space
was
presented
to
the
working
group
and
a
draft
was
written.
People
have
talked
about
it,
I'll
talk
more
today
and
clearly.
This
sort
of
work
requires
various
pieces
of
expertise.
It
requires
expertise
in
understanding
how
the
technology
works,
and
it
requires
expertise
in
understanding
how
vendors
and
other
standards
bodies
are
using
that
technology.
D
It
will
also
require
some
standardization
decisions
if
we're
going
to
specify
anything
new.
This
is
quite
a
big
thing
to
start
so
I,
don't
think
the
working
group
will
actually
start
any
of
that
activity.
Yet
I'm
hugely
interested
in
the
discussion
about
this
and
in
making
progress
in
the
right
direction,
because
if
people
are
not
arguing,
I
think
we're
heading
in
a
good
place.
David
do
you
want
to
add
anything
I.
B
D
P
B
E
D
Think
we
need
to
see
another
read
before
we
can
actually
make
that
call,
because
we
were
so
pleased
that
people
were
throwing
poison
darts
at
this
inspiring
fireball.
So
the
chairs
would
like
to
see
another
revision
and
Jerome.
You
got
some
feedbacks
or
and
I
think
you
know
some
of
the
things
to
doing
that
and
in
the
meantime
we
will
touch
base
with
the
3gpp
liaison
in
the
IETF
just
to
make
sure
that
they
now
think
this
is
not
really
horrible
because
they
thought
it
was
really
horrible.
B
D
D
And
in
that
case,
and
thank
you
so
much
for
participating
and
personally
I
would
rather
have
dr.
Vancouver,
but
and
and
wherever
you
are
I
wish
that
you
you
stay
well,
you
you
get
better
if
you
need
to
get
better
and
thank
you
for
your
participation,
we
will
follow
up
this
meeting
by
the
email
list.
Please
use
the
media
email
list
and
we
will
have
another
interim
later
this
month,
but
until
then
goodbye
thank.