►
From YouTube: IETF105-TSVWG-20190725-1000
Description
TSVWG meeting session at IETF105
2019/07/25 1000
https://datatracker.ietf.org/meeting/105/proceedings/
C
B
Is
debit
like
you'll,
be
witness
just
a
moment
why
sandy
is
Renault
from
Java?
Wear
your
TS
v,
WG
coaches-
and
this
is
the
ITF
not
well
the
IETF
not
well
is
worth
reading.
It's
not
that
exciting,
but
it's
important
to
realize
the
IP
are
procedures
for
the
documents
that
we
bring
to
the
working
groups
are
the
comments
you
bring
at
the
mic,
and
please
do
please
do
this,
especially
with
any
technology
of
which
you
are
aware,
because
it
will
be
important
as
we
go
through
the
standards
process
as
you're
discovered
tomorrow.
B
Please
volunteer:
if
you
wish
to
be
enough.
Tacky
today
we
have
1.
Knots
will
be
taken
either
part
by
Theresa.
We
need
a
JavaScript
for
this
session
and
we
have
one
so
the
wrote
comments
revolved
questions
will
be
relayed
from
Java.
If
you
intend
submitting
a
new
draft,
please
consider
inserting
the
TSV
WG
tag
after
your
name
in
the
draft
name,
so
that
we
see
the
draft,
and
we
know
that
it
is
relevant
to
this
particular
group.
B
B
B
So
now
to
what
we've
done
recently,
what's
always
good
to
report,
we've
done
real
work.
The
LEP
HB
draft
has
now
become
RFC,
Saar,
FC
862
to
the
new
code
point
and
is
defined
in
that
and
is
now
in
the
eye
on
a
registry.
This
is
a
nice
result,
because
this
particular
document
is
actually
being
talked
about
by
other
people.
Other
people
are
referring
to
it
already.
So
that's
good.
B
We
have
4
internet
drafts
in
RFC
early
to
q2
on
the
effect
subject,
the
fact
framework
extension
and
the
FEC's
sliding-window
RLC,
which
we've
been
through
this
working
group
for
some
time.
I
did
a
third
one
which
talks
about
the
pseudo-random
number
generator
where
upon
which
their
base.
So
these
three
form
a
group
together
in
the
rst
air
to
cure
a
new
contribution.
The
old
contribution
is
the
diffserv
and
WebRTC
QRS,
which
is
still
residing
on
a
mystery.
I
think
cluster,
two
three
eight
and
we
are.
D
So
it
took
two
tries
to
get
these
drafts
through
working,
the
blast
call.
May
it
call
prefer
for
for
not
doing
good
job
in
the
first
one.
The
drafts
are
now
through
last
call
they're,
mostly
revised,
except
the
second
draft,
which
is
the
RFC
6040
update
shim.
There
was
some
brand
new
text
written
on
fragmentation
after
working
group
last
call
completed.
That
text
needs
review.
There
was
just
a
comment
this
morning
that
the
text
problem
at
text
may
be
problematic.
I've
sent
out
a
comment
suggesting
that
is
a
concern.
D
B
D
F
B
B
Okay,
the
transport
header
confidentiality
impacts
draft
will
be
presented
at
this
meeting,
and
we
mentioned
previous
meeting
that
this
would
be
the
time
to
working
group
must
call
it
so
that
will
be
discussed
at
the
current
meeting.
The
DPL
PM
tud
draft
has
been
ongoing
for
some
time.
It
is
nearing
working
group
us
call.
It
is
not
ready
yet,
but
it
might
be
ready
before
the
next
meeting.
Okay,.
D
D
Beyond
that
six
additional
working
group
drafts
going
to
talk
about
today,
the
SCTP
of
this
draft.
There
are
the
three
out
fresh
grass,
a
UDP
options
and
tunnel
tunnel
tunnel
Jessen
feedback.
I.
Think
combination
of
feedback
is
not
on
the
agenda
this
time.
It's
not
on
the
agenda
for
discussion
this
time
around
the
the
quorum
mechanism
in
that
draft
is,
is
stable
of
and
it
will
progress
as
other
drafts
that
are
taking
advantage
of
it.
Progress
on
the
SCT
peanuts
is
also.
B
D
B
So
there
are
a
number
of
transport
related
traps
and
I
think
it
is
very
useful
to
call
these
out.
Please
transport
issues
in
other
working
groups
and
please
bring
them
back
here
if
you
need
to
be
discussed.
One
of
these
is
the
path
MTU
discovery,
hop-by-hop
option,
which
was
proposed
as
a
working
group
item
in
six
months
idea.
Obviously
this
is
a
mechanism
to
it
with
path,
MTU
discovery,
so
it
is
relevant
to
transport,
discuss
that
in
six
month
lease
there's
an
ipv6
reservation
protocol.
You
don't
say
anything
about
this.
D
This
was
presented
several
I'ts
roie
tf's
ago.
The
authors
are
continuing
to
work
on
this.
It
will
will
reappear
at
some
point.
It's
not
on
this.
This
I
guess
agendas.
It's
not
it's!
It's
not
none!
Somebody
for
an
update.
Moving
on
to
the
next
one.
We
have
an
elf
forest
and
diffserv
draft.
This
might
be
part
of
the
discussion
tomorrow
morning,
depending
on
which
of
five
dozen
directions.
That
discussion
actually
actually
goes
in
and.
B
B
D
Okay,
more
transfer
laid
rash,
ecn
and
nsh.
This
is
draft
over
in
SF,
see
that
it
that
is
going
to
make
use
of
the
congestion
congestion
feedback
draft.
We
have
a
couple
of
drafts
on
low-latency
DOCSIS.
This
is
just
FYI
baba,
believe
the
Bob
and
Greg
I
believe
these
are
likely
headed
to
the
independent
submission
editor
for
publication,
roughly,
as
is
describe
what
this,
what
this
running
code
actually
does.
B
B
There
was
previous
work
presented
on
lower
a
number
of
IETF
and
this
evolved
and
this
workers
being
now
made
historic
by
a
new
internet
draft
which
is
on
nqb,
which
will
be
discussed
so
that
comes
back
as
an
QB
and
ed
Carriere
documents
and
there's
a
tunnel
MTU
considerations,
document
and
empty
use
are
so
important
for
tunnels.
So
please
read
and
contribute
to
that.
B
There's
a
fragmentation
fragility
document,
which
is
proceeded
through
interior,
explaining
where
fragmentation
becomes
fragile
under
Sox
protocol
version,
6,
which
is
being
presented
at
many
eye
tests
in
the
int
area,
and
we're
going
to
mention
that
again
here,
because
that
could
be
something
that
has
many
transport
aspects.
So
we'll
talk
about
that
later
in
the
meeting.
D
To
SCTP
drafts
that
are
that
are
being
are
being
worked
on,
as
you
do
submissions
right
now,
one
is
multipath
draft
and
the
other
is
there's
a
draft
on
the
retransmission
as
draft
on
the
retransmission
time
out
of
interest
and
SCTP.
These
are
out
these.
Well.
Perhaps
please
take
a
look
comments
to
the
list.
D
Ok,
so
now
we
get
to
the
agenda
we're
going
to
run
with
agenda
up
in
a
little
bit
the
bashatt
document
complication
a
testosterone
review
is
coming
up
next
and
then
a
bunch
of
drafts,
UTP
options
are,
is
expected
to
be
well
one
of
the
more
interesting
items
on
the
agenda
tomorrow
is
more
drafts,
including
l4
s
and
l4
s.
Nsc,
ok
milestones
would
be
go
through
very
quickly.
First,
two
drafts
we've
just
talked
about
the
objects
there
with
the
chairs
after
working
group
last
call.
D
We
need
to
deal
with
the
fragmentation
text
before
they
can
be
submitted
to.
Our
aging
is
G,
as
for
publication
request.
Okay,
next
three
drafts
are
the
l4
s.
Grass,
no
point
talk
about
milestones
here
until
we
have
the
what
we're
doing
about
the
discussion
tomorrow.
Okay,
we
have
three
slot
three
drafts
that
the
intent
is
to
try
to
get
get
done
between
now
and
the
Singapore
ITF.
D
The
setp
knack
is
probably
not
gonna,
not
gonna.
Make
that
Joanne
milestone
weeks.
I
think
that
one,
it's
not
quite
ready
for
your
glass
call
we'll
have
a
discussion
about
that
a
little
bit.
The
other
two
drafts
are
believed
to
be
closer.
If
working
group
glass
call
July,
August
September
dates
may
be
aggressive.
All
three
of
those
are
likely
to
t
be
working
group
last
call
before
the
next
IETF
meaning
and
the
remaining
grass
the
SCTP.
D
This
draft
is
currently
estimated
for
end
of
this
year
that
may
move
out
and
the
other
two
gates
on
the
other
two
days.
Phone
just
and
feedback
and
transfer
officer
for
UDP
are
reasonable.
Guesses.
At
this
point,
we'll
figure
out
what
reality
looks
like
in
Singapore,
okay,
so
here's
here's,
here's
the
agenda
to
go
to
go
bash.
It
we've
mostly
run
through
item
one
on
doggie
size
charter
and
updates.
D
D
Datagram
pmq
discovery
and
then
and
then
a
UDP
options.
Draft
we're
hoping
you
are
going
you
got
to
draft
is
there's
been
a
lot
of
discussion
on
the
list,
we're
hoping
to
have
it
have
a
bit
of
design
discussion
and
see
if
we
can
chart
the
path
forward
on
a
number
of
a
number
of
the
design
issues
that
come
up
cut
the
list
in
the
AirTrain
fashion,
new
work
work
from
the
writing
area
working
group
on
QoS
management
is
a
couple
couple
of
drafts
that
we
talked
about
briefly.
D
Qcr
and
gift,
sir,
were
actually
probably
not
kind
of
a
technical
conversations
draft,
because
there's
been
some
updates
in
3gpp
IETF
leadership
discussions
that
is
likely
to
be
a
very
short
status
announcement
about
what
stay
that
draft
is
and
what's
going
to
happen
with
it,
and
then
the
non-coding
flows
draft
mention
earlier
Friday.
Oh,
we
have
fun.
This
is
this
slide
is
going
to
be
interesting.
They'll,
oh,
let
the
l4s
crafts,
including,
are
we
gonna
take?
Are
we
ready
to
go
to
work
group
last
call
on
them?
D
What
do
we
need
to
do
and
there's
any
discussion
around
transports
for
elf,
forts
and
cell
force
is
supposed
to
enable
different
transport
behavior.
We
need
to
discuss
what
what
what
is
the
value
of
transports
use
l4s
then
we
have
some
cash
experienced
though
the
three
drives
listed
there,
discussions
gonna
focus
on
the
first
two.
The
TCP
M
draft
is
here
mostly
for
completeness
in
that.
If
SCE
moves
forward,
they're
going
to
that
they're
going
to
need
to
do
some
TCP
level
signaling
bets,
they
grab
proposing
how
to
do
it.
I'm
not.
D
H
B
B
B
B
I
B
B
J
B
B
K
K
K
K
Thomas
Fossati
gave
us
a
bunch
of
suggestions
on
how
to
clarify
the
text,
primarily
here
talking
about
improving
the
various
introductory
sections
and
also
gave
some
suggestions
for
how
to
address
the
the
issues
which
we
raised
in
the
draft.
In
particular,
he
had
a
bunch
of
I
think
really
good
ideas
about
potentially
using
machine
learning
to
solve
some
of
the
problems
and
they'd
be
able
to
identify
the
traffic.
K
We
tend
to
think
that.
Well,
this
is
potentially
a
good
idea.
It's
it
would
be
expanding
the
draft
too
much
to
add
that
sort
of
material
to
it.
So
so
it's
what
we
think
is
the
right
thing
to
do
here
is
to
keep
this
draft
focused
and
identifying
the
problem
and
leave
other
drafts
to
recommend
solutions
for
the
problem.
So
we
just
don't
keep
this
focused
on.
This
is
what
the
the
concern
is.
K
We
also
got
a
bunch
of
feedback
from
Tom
Herbert
couple
of
a
couple
of
issues
here.
One
was
on
the
the
utility
of
adding
extension
headers,
such
as
connects
headers
to
to
carry
measurement
information,
and
his
feedback
was
that
he
believes
that
the
draft
underestimates
that
the
value
and
over
States
their
disadvantages
I
mean
yeah.
We
certainly
agree
with
him
that
these
types
of
mechanisms
can
be
used
to
carry
these
sort
of
measurements.
Information,
I,
don't
think,
we've
seen
so
much
deployment.
So
it's
hard
to
evaluate
that,
but
it
in
the
end.
K
K
H
B
H
H
C
K
Know
what
to
think
of
that
I
mean
the
idea
here
is
the
working
group
or
whoever
it
is
designing?
A
protocol
may
make
an
explicit
statement
that
we
are
going
to
declare
these
features
of
the
protocol
stable
for
all
time,
and
you
know
if
you're
building
devices
which
look
at
the
protocol,
you
you
can
assume
that
these
things
will
not
change
and
we
reserve
the
rest
of
its
to
change
and
I
guess
the
quicken
variants
would
be
the
the
topical
example
of
that.
L
K
L
C
L
D
K
H
H
C
M
Malthus
there
was
a
time
when
there
were
some
people
in
a
misguided
effort
to
prevent
steganography
and
our
protocols
wrote
a
lot
of
code.
A
lot
of
documents-
and
things
said
things
like
you
have
to
enforce-
must
be
0
in
your
middleboxes
sure
this
was
ugly
as
far
as
I'm
concerned.
It's
deliberate
ossification,
I
think
that
tone
has
been
reduced,
but
there's
always
the
opportunity
for
somebody
to
say
it's
always
a
1
there.
M
B
B
K
Off
topic,
but
the
greasing
stuff
is,
is
also
something
that
hits
into
this
space
right.
So
in
terms
of
the
draft,
we've
done
two
revisions
since
the
product
meeting
zero
six
revised
the
introductory
remarks
added
some
discussion
of
the
OEM
related
metadata
in
Section,
six
and
updated
the
conclusions
made
them
a
little
more
focused
the
dasher,
seven
again
revised
the
introductory
remarks.
We
removed
a
bunch
of
duplication,
put
some
of
that
text
into
the
conclusions
actually
made.
The
conclusions.
K
I
think
we'd
a
lot
better
and
actually
conclude
something
new,
something
that
improved
it
and
that
there
are
a
bunch
of
other
details
or
around
the
rest
of
the
drift.
So
hopefully,
we've
now
addressed
all
the
comments.
I
believe
there
are
a
couple
of
minor
editorial
mix.
We
have
outstanding,
which
we
will
get
to
in
pretty
short
order.
N
B
A
B
We
discussed
that
last
meeting
because
it
was
before
the
last
ITF.
We
got
a
real
security
review.
We
worked
through
a
it
was
quite
a
long
one
which
was
really
good.
We
went
through
the
comments
and
responded
to
each
of
them
in
turn,
and
then
we
updated
the
document
we
put
in
text
to
address
nearly
all
the
comments.
But
there
are
a
couple
of
comments.
Were
we
wrote
the
response
on
the
mailing
list?
Why
we
didn't
think
the
extra
text
was
going
to
be
helpful
in
the
document.
So
that's
the
current
state
with
that
review.
K
N
That's
very
good
to
know.
Thank
you,
so
this
document
is
not
entirely
unrelated
to
a
prior
document
that
was
published
this
the
draft
mm
WG,
encrypt
and
I.
Think
it's
there's
like
a
chance
that
some
of
the
language
in
this
document
hits
the
ears
of
people
from
security
and
applications
areas
a
little
bit
differently
than
maybe
people
in
this
room
or
people
who
work
in
operations
and
I.
Guess
we.
K
N
To
the
extent
that
some
of
the
same
concerns
could
be
dealt
with,
all
the
document
is
still
in
the
working
group.
I
think
that
would
that
would
perhaps
make
for
a
smoother
process
than
what
we
went
through
with
the
other
documents.
So
that
might
just
mean
you
know
advertising
widely
when
you're
doing
more
than
trip
last
call,
or
we
can
certainly
socialize
this
in
the
IHG.
If
that
would
help,
but
I
think
it
would
be,
you
know
good
to
get
the
feedback
earlier.
If
there's
gonna
be
feedback
of
similar
nature
at.
O
B
B
K
O
D
The
plan
here
is
that
we're
going
to
is
that
they'll
be
revision
in
the
near
future
and
that
provision
will
go
to
working
group
last
call
since
that
we're
talking
about
August
it
bugs
me
longer
than
the
usual
two
weeks,
and
it
will,
at
the
very
least,
be
crossing
the
cross
cross
nouns
to
sag
sounds
of
also
other
other
cross
announced
at
some.
Listen,
the
ops
area
that.
P
P
So
I'm
a
transport
guy
I
like
to
think
of
my
networks
as
a
collection
of
very
dumb
pipes
and
then
stop
thinking
about
my
network.
But
for
that
to
really
work,
there
should
really
be
a
plumber
somewhere,
who
is
trying
to
find
the
leaks
and
page
them,
and
if
you
are
such
a
plumber,
if
you
operate
a
network
and
somebody
calls
you
and
says
I'm
experiencing
packet
loss,
what
is
the
first
thing
you
wanna?
P
Do
you
want
to
see
if
you
could
observe
the
problem,
and
then
you
want
to
figure
out
is
a
loss
in
my
network,
or
is
it
any
of
my
peers,
whom
do
I
call?
So
what
do
I
do
if
I'm
looking
at
the
TCP
flow
life
is
not
that
bad?
There
is
a
number
of
tools
that
can
absorb
sequence
numbers
F
numbers
can
figure
out
where
the
there
is
loss.
P
P
One
alternative
is
just
look
at
TCP
flows
between
similar
endpoints
use
that,
but
if
that
doesn't
work
what's
next,
you
could
think
of
nuclear
option,
which
is
basically
let
me
just
block
quit
entirely
temporarily
on
that
link
and
forced
TCP,
failover
and
troubleshoot,
then
well
as
crazy
as
it
sounds.
It
might
not
actually
work
either
because
network
may
treat
TCP
and
UDP
quick
flows
very
differently.
So
what's
next
now,
before
I'm
going
to
go
further,
there
is
one
question
that
I'm
asked
often
so
I'm
from
Akamai
and
people
ask
you're,
not
a
typical
network
operator.
P
If
my
package
doesn't
arrive
at
my
desk
at
my
at
my
doorstep,
and
they
get
some
excuse
that
well,
that's
because
some
tracking
company
truck
ran
out
of
gas
I'm,
not
gonna,
be
super
convinced
with
that
I
mean
my
business
relationship.
Is
this
Amazon
I
expect
them
to
deliver
the
package?
So
if
that
was
convincing,
we
have
a
proposal.
It's
basically
using
two
bits:
I'm
not
gonna,
go
into
detail,
read
the
draft,
but
there
is
a
qubit
which
is
stands
for
square
signal
and
it's
an
altered.
It's
a
mark.
P
That's
alternating
every
N,
packets,
zeros
and
ones,
and
there
is
an
L
bit,
which
is
a
lost
signal.
That's
counting
the
number
of
packets
lost
as
determined
by
the
but
protocols
such
as
quick.
So,
for
example,
in
this
picture
we
have
a
number
of
packets
from
sender
to
receiver.
The
red
ones
are
lost,
so
one
RTT
to
one
or
two
or
later
the
protocol
quickly
goes
out
there
lost
and
to
two
future
packets
are
sent
with
l1.
How
can
you
use
the
signal?
Well,
end-to-end
loss
is
just
a
fraction
of
packets.
P
You
observe,
with
l,
equals
1
up
stream.
Loss
is
a
fraction
of
the
packets
in
each
q,
blog
that
are
missing
packets
downstream
loss.
You
can
figure
out
from
the
other
two,
so
you
can
notice,
but
we
don't
specifically
talk
about
where
to
put
those
two
bits.
It's
being
proposed.
Everything
from
IP
header
to
quick
header
and
really
anything
in
between
the
purpose
of
this
draft
is
to
point
out.
P
The
problem
propose
a
solution
framework
using
the
two
bits,
and
once
we
have
consensus
on
that
I'm
sure
we
can
work
and
draft
in
the
appropriate
group
that
will
find
the
home
for
the
bits.
So
this
is
not
a
purely
theoretical
work.
Akamai
that
actually
implemented
this
scheme
in
our
production
servers
and
we've
been
serving
traffic.
Like
that,
a
quick
traffic
for
a
while
to
a
number
of
orange
customers
in
different
countries.
We
have
data
for
this,
and
tomorrow
it
mapper
G
will
be
talking
a
lot
more
about
data
from
different
countries.
P
What
the
data
means
for
those
who
are
curious.
We
used
the
two
most
significant
bits
of
apt
GL
to
help
to
carry
those
bits
it
worked
now.
The
encrypted
protocols
do
what
they
do
for
a
reason.
So
one
of
the
important
reasons
is
and
user
privacy
and
the
proposal
we
have
is
trying
very
hard
to
make
sure
that
nothing
more
is
compress
disclosed
to
the
network.
Then
what
quick
already
discloses
so
separate
counters
for
each
flow
sub
flow
separate
count
fresh,
portable,
separate
counter
for
each
connection,
a
diem.
P
The
other
important
things
that
encrypted
protocols
like
quick
worry
about
is
particle
ossification
resistance
and
because
loss
signaling
is
not
an
integral
part
of
the
protocol.
It's
very
convenient
to
basically
do
what
quit
does
already
with
a
spin
bit
with
a
latency
spin
bit,
which
is
say
that
20%
of
connections
must
use
pseudo-random,
basically
random,
looking
garbage
in
those
bits,
it's
very
easy
for
observer
to
tell
a
real
signal
from
no
signal
and
for
middleboxes
there's
a
incentive
to
not
pacify
on
that.
So
that's
all
I
have
for
today.
P
Q
H
Two
quick
points:
one
is
I
think
this
is
great,
but
I
wonder
what
else
there
is
like
what
other
information
people
are.
Gonna
want
like
what,
if
I
want
to
spike
in
latency,
so
I'm
worried
if
you
get
a
mouse,
a
piece
of
cheese
and
on
the
glass
of
milk
and
all
that
so
I
could
see
this
becoming
the
avalanche
part.
2
of
that
is
protocol
agnostic
mechanisms
much
better
than
protocol
specific.
H
B
R
P
That's
yes,
I
actually
did
think
about
it
and
well,
as
you
see
in
our
current
thing,
we
do
mess
with
IP
header
bit.
It's
not
it's
not
going
to
be
any
different
from
what
people
can
do
right
now.
So,
but
if
it
goes
into
a
quick
header,
it
true,
it
will
be
authenticated
and
it
will
not
be
subject
to
manipulation
by
by
the
pass.
So
there
are
advantages
and
disadvantages
to
any
of
the
proposals.
So
I
can
that's
why
we
don't
directly
dive
into
pics
the
header
right
now.
P
R
P
P
You
can
definitely
do
more,
and
so
this
is
using
just
one
probe
just
kept
looking
at
one
direction
of
traffic
once
you
identify
look,
do
that
and
you
identify
which
direction
the
loss
is.
You
could
move
the
probe
or
have
another
one
already
available,
that's
just
another
way
to
use
in
the
technique.
We.
D
T
B
B
U
U
Now
the
first
version
was
the
identical
version.
The
second
or
one
version,
was
switching
to
xml
with
minor
differences.
The
version
o
two
integrates
all
the
Aurora's
from
the
errata
document.
So
that's
all
that
changes
we
sort
of
agreed
on
an
RC,
eight
five,
four
zero
there's
some
stuff
which
needed
changes
like
updating
references
to
RFC's,
which
have
been
updated
and
some
editorial
stuff,
which
is
in
the
O
3
version.
U
What
is
in
progress
is
the
fourth
version,
and
this
comes
back
to
a
comment
from
Gauri
we
used
and
4960.
A
lot
of
may
must
should
not
in
capital
letter,
and
the
request
was
to
remove
this
stuff
to
either
capital
letter
mast
or
a
different
wordings,
so
that
when
you
read
the
text,
you
are
not
arguing
whether
this
cabot,
wherever
this
must
is
meant
as
a
mandatory
language
or
not.
This
is
right
now
in
the
github
repo.
U
We
need
to
go
once
again
to
the
other
changes
to
make
sure
everything's
fine
and
then
it
will
be
submitted.
What's
left
is
one
issue
brought
up
on
the
github
tracker,
which
is
related
to
setting
up
SATP
associations.
So
if
an
endpoint
knows
multiple
IP
addresses
of
the
peer,
the
current
API
and
4960
only
allows
you
to
provide
one
of
these
addresses
to
the
associate,
primitive
and
then
set
up
the
Association.
U
The
socket
API
allows
you
to
provide
this
list
of
errors
as
to
the
end
point,
and
then
it
already
uses
multiple
addresses
to
doing
them
as
a
session
set
up,
and
this
is
a
feature
which
is
requested
by
operators
and
when
they
try
to
talk
to
vendors
and
vendors,
come
up
and
say
well,
this
is
not
specified
there,
so
we
don't
have
to
do
it,
and
so
we
will
update
the
text
of
the
API
section,
replacing
the
single
IP
address.
We
are
providing
by
a
list
of
IP
address.
U
We
are
providing
making
clear
that
it
is
informational,
only
adding
a
link
to
the
socket
API
stuff
and
add
some
text
to
the
document.
Saying
if
you
know
you
set
up
a
list
of
IP
addresses,
make
you
go,
miss
may
use
of
make
use
of
them.
The
last
thing
is
sort
of
layout
improvements.
The
XML
code
reads
ugly,
just
to
just
that
the
text
version
looks
like
4960
and
that
will
be
cleared
up
at
the
last
step
to
look
okay
in
HTML
and
text,
but
not
yes,
but
not
identical
to
4960.
B
U
C
U
B
Fine,
if
the
working
group
thinks
that
there
are
additions
to
this
document,
these
and
either
come
to
the
Mike
on.
Let
us
know
on
the
mailing
list,
because
this
document
is
meant
to
be
a
stable
document
that
reflects
implementations
and
our
best
understanding
of
this
standard.
So
please
speak
up
at
this
stage.
If
you
think
there's
anything
extra
needs
to
be
added
to
it.
Does
anybody
wish
to
comment
in
the
room
about
something
that
they
think
should
be
added
into
this
revision
of
the
spec.
U
J
U
Then
two
people
read
it
pretty
detailed
and
Gloria
was
one
of
them
and
he
made
a
number
of
editorial
and
clarification
things
and
one
remark
in
particular
basically
split
making
it
clear
for
an
endpoint
developer
or
a
middle
box
developer,
which
sections
apply
to
that
role.
So
we
have
common
text
explaining
these
things.
U
We
have
common
text
giving
examples,
but
where
we
describe
what
needs
to
be
implemented,
it's
made
clear
in
the
headers
of
the
section
or
subsection
whether
this
is
a
consideration
for
endpoint,
implementers
or
middle
box
implementers,
that's
integrated,
so
I
think
I
addressed
everything.
Gauri
reported
thank.
U
M
U
G
V
Okay,
hello,
my
maxim
portion-
and
this
is
the
state
status
update
on
not
the
CTP
work
that
I
presented
basically
in
the
previous
idea,
so
I
will
quickly
go
through
situation
and
proposal
and
mainly
focus
on
updates
and
approved.
So
the
the
problem
that
we
try
to
solve
is
well-known
is
that
if
Yuri
transmit
data
chunk
and
you
get
acknowledgment
back,
you
cannot
distinguish
if
it
acknowledged
its
original
recent
data
or
it
transmitted
to
one,
and
there
are
basically
two
use
cases
when
you
have
real
loss
or
when
you
have
spurious
retransmission
next
slide.
V
So
the
idea
is
quite
straightforward.
We
want
to
use
one
bit
in
data
or
write
data
to
indicate
that
this
is
retransmission
and
acknowledgement
on
retransmission
should
also
include
that
bit
and
we
thought
about
different
ideas.
More
bits
may
be
new
suck.
That
will
be
more
complicated,
but
we
came
to
conclusion
that
this
is
a
simplest
approach
that
addresses
all
our
use
cases
we
need.
So
this
users
of
this
bit
requires
a
negotiation,
and
basically
there
are
two
main
rules:
the
first
row
for
the
under
that
it
should
set.
V
So
since
last,
ITF
I've
submitted
a
new
draft
version
where
I
added
the
description
of
HTTP
improvements
from
this
mechanism.
This
was
main
feedback
that
I
received
there
and
I
will
describe
it
in
next
slide.
I
also
added
some
clarifications
about
the
issue
with
multiple
retransmission
retransmission,
which
is
one
of
the
challenges
for
this
mechanism,
because
when
you
have
multiple
transmissions
and
you
get
acknowledgments
back,
you
cannot
distinguish
one,
but
still
it
brings
improvement
because
you
can
distinguish
a
regional
transmission
and
you
can
still
detect
spurious
retransmissions.
V
Have
some
improvement
and
I
also
made
some
editorial
updates?
We
also
implemented
the
negotiation.
You
can
easily
know
implementation.
Previously
it
was
some
proprietary
mechanism,
but
it's
not
yet
in
the
live
network.
I
think
it
will
be
the
end
of
this
year.
We
started
collection
of
data.
It
was
requested
last
time.
I
think
we
focus
on
signal
traffic
profiles
to
show
the
improvement,
so
I
hope
you'll
present
next
time
and
yeah.
We
continue
to
probability
linux's
TV,
so
this
is
what
can
be
improved
if
we
use
this
retransmit
bit.
V
So
there
are
some
mechanisms
already
in
SCTP
that
will
be
improved
up
to
your
calculation,
powerful
textual,
quick
failover,
where
you
have
issued
this
ambiguous
acknowledgement.
The
other
big
carry
that
can
be
improved.
This
detection
of
spirit
transmissions,
because
when
you
get
when
you
have
sphericity
transmission
and
you
get
sucked
back
without
our
bit,
you
can
already
that
time
understand
that
there
was
a
spirit
retransmission.
V
You
can
react
accordingly,
you
can
at
least
until
fire
application
about
that
or
you
can
adjust
your
settings,
because
one
of
the
common
issue
is
some
kind
of
miss
configuration
of
mini-mario
and
shock
delay
parameters
that
leads
to
spurious
retransmissions
in
network,
or
you
can
even
recover
your
congestion
state,
because
when
you
do
spurious
retransmissions,
you
basically
reduce
congestion
variables
and
when
you
detect
that
there
was
a
spirit
spirit,
a
transmission,
you
can
recover
it.
The
other
big
area
which,
where
we
use
this
mechanism,
is
so-called
population
of
moccasin
mark
delay.
V
It's
also
to
prevent
spurious
retransmissions.
It's
similar
to
how
it's
done
in
quick,
but
I
mean
the
idea
is
that
you,
dynamically
calculate
calculate
maximum
delay
and
if,
but,
if
you
carry
transmissions
in
the
existent
mechanism,
it's
it
brings
some
problems.
You
should
always
be
able
to
distinguish
between
what
stock
actually
acknowledges
like.
W
V
So
implementation
status
is
almost
the
same
as
it
was
before,
so
we
have
it
in
Ericsson,
a
CTP
it
enabled
between
Ericsson
STP
endpoints.
We
have
also
local
path
for
linux,
st
petes,
without
negotiation
mainly
used
for
in
two
previous
tests,
so
improvements
are
implemented
in
ours
to
be
not
in
that
patch
next
slide.
V
My
plan
is
to
close
all
DVDs
in
the
next
version,
I
think
it's
two
or
three
of
them.
We
has
already
mentioned
we
plan
to
share
some
data
of
these
improvements.
There
are
different
use
cases
not
only
be
spurious
retransmissions,
but
also
some
other
use
cases,
and
we
spent
in
into
probability
with
linux
SCTP,
and
if
I
mean
there
is
interest
in
this
work,
we
want
to
adopt
it
in
the
world.
W
D
B
U
V
U
V
B
B
Hi
Gouri
first
as
an
individual
talking
about
DPL
PM
PUD,
wasn't
sure
whether
you
could
have
killed,
slides
or
not.
So
this
idea
have
got
colorful
DPL
PMT
UD
has
changed
significantly
in
that
it's
used
the
new
markup
language
for
RFC
XML,
and
therefore
we
have
some
SVG
diagrams
in
and
thanks
Magnus
fer,
inviting
us
to
join
this
experiment
and
all
the
diagrams
that
are
being
rendered
to
SVG
go.
Look
at
the
HTML
version
and
you'll
see
the
effect
of
using
the
new
format.
B
We
moved
Appendix
A
because
Appendix
A
had
been
introduced
and
was
useful
to
us
going
through,
but
really
was
a
duplication
that
became
less
less
and
less
easy
to
justify
because
it
was
just
a
representation.
The
same
thing:
it's
gone:
it's
no
longer
there
removed
a
section
on
DPL,
PM
tud
with
UDP
options,
and
we
put
it
in
a
separate
draft.
B
We
will
we've
no
taught
to
our
ad
and
we
probably
will
refresh
this
draft
and
keep
this
active
so
that
we
can
capture
what
happens
when
you
use
UDP
options
with
this,
and
we
don't
intend
to
put
that
back
into
this
particular
document.
We'll
keep
it
as
a
separate
item
and
we
shortened
the
description
of
phases
we
introduced.
The
idea
of
phase
did
help
people
understand
an
overview
of
how
the
algorithm
worked.
B
We
really
want
that
to
be
a
discussion
of
issues
concerning
the
whole
way
in
which
this
works
are
not
going
into
the
details
of
the
state
machine.
So
we
will
probably
shorten
this
yet
further
and
I'm
not
aware
of
oh
I
want
you
to
draw
a
picture,
and
this
is
what
it
looked
like
before,
and
this
is
what
it
looks
like
now
see
if
you
think
that
looks
better
before
after
okay,
whatever.
B
Yeah
right
and
you
could
talk
about
the
implication
of
that:
okay,
so
no
serious,
they
want
to
keep
this
shot
and
we
think
the
state
machines,
stable
and
usable.
We
presented
that
last
IETF.
We
haven't
discovered
anything
to
change
our
mind.
We
are
still
gathering
experience
with
paths
and
methods.
There
will
be
research
issues
come
out
of
this
because
we
don't
quite
know
how
the
internet
works,
but
we
believe
the
method
that's
proposed
here
is
finished
as
a
framework.
We
believe
it
is
finished
as
a
set
of
states.
B
We
believe
it's
finished
and
we
will
be
updating
the
draft.
So
we're
not
asking
for
working
group
last
call
next.
This
is,
we
will
be
asking
it
for
it
before
the
next
one.
As
we
finish
the
document,
we
have
some
author
comments
to
still
resolve
we're
still
willing
to
take
feedback.
So
if
you
have
any
questions
or
feedback,
please
tell
us
if
you
have
a
new
implementation,
please
tell
us,
we
know
four
different
implementations
in
different
ways
of
this.
If
you've
got
an
idea
of
implanting
it,
please
talk
to
us.
Please
tell
us:
okay,.
D
Couple
process
notes,
as
Cory
said,
expect
this
to
be
last
call
of
working
with
glass,
quadraphonic
IETF
and,
on
the
first
slide,
the
removal
of
the
UDP
options.
Mature.
A
separate
draft
was
an
executive
decision
by
your
working
group
chairs
to
move
this
draft
along
and
hopefully
get
it
published
and
stable
without
waiting
for
UDP
options
which,
as
you're
about
to
see,
is
going
to
need
some
work
in
mate
and
and
they
and
may
take
a
while.
B
This,
for
there
were
four
there's
four
attempts:
there's
a
freebsd
work,
which
is
on
the
gate,
it's
not
being
up
streamed
because
it
won't
be
until
the
specs
finished.
There
is
UDP
options,
which
is
our
test
implementation,
which
were
keeping
up
to
date,
which
is
again
on
get.
There
has
been
another
implementation
I.
Do
you
want
to
talk
about
yours
and
we
did
it
one
in
most,
quick,
the
hackathon
just
to
prove
it
could
be
done
in
Moss,
quick,
okay,.
H
U
B
O
B
So
jokes
are
able
to
make
this
particular
meeting
Joel's
in
LA
I
believe
it's
sunnier
and
warmer,
but
I'm
going
to
try
and
summarize
your
slides
and
Jose,
and
seeing
rather
a
lot
of
comments
on
the
list
in
the
in
the
last
period
and
particularly
just
prior
to
the
IETF.
And
he
has
a
number
of
pending
updates
and.
B
These
there's
no
wordsmithing
and
various
things
to
be
done
right
and
there's
updates,
particularly
on
the
use
of
the
OCS,
which
is
this
checksum
over
the
options
area.
It
appears
be
a
nice
thing
to
be
able
to
check
the
validity
of
the
options,
but,
as
we
discussed
in
previous
TSV
meetings,
this
is
important
for
traversing
middleboxes,
that
do
strange
things
with
checksums.
And
if
you
don't
do
this,
then
you
don't
get
through
the
middle
box
and
even
more
frightening.
B
D
Think
the
the
primary
issue
is
worked,
I
mean
a
crucial,
but
the
crucial
texture
there
bracelet
and
bond
agreement
on
is
the
EB
checksum
is
nonzero.
Then
you
have
to
use.
Then
you
have
to
use
use
OCS.
We
have
some
corner
cases
in
the
tunnels
area
where
the
UDP
checksum
is
0-2
now
now
lock,
which
will
work,
which
will
will
will
work
out
in
the
list.
Okay,.
B
So
I
think
this
reflects
discussion
on
the
list
and
if
you
disagree
with
what's
written
in
the
site,
then
please
bring
it
up
again
on
the
list
and
Joe
will
produce
a
new
revision
for
the
OCS
work
and
there's
a
request
on
the
list
that
length
of
options
should
be
increased,
so
you
can
declare
options
that
are
longer
than
254
bites.
This
seems
like
an
odd
thing
to
want
to
do,
but
one
of
the
uses
of
UDP
options
is
to
send
fragments
and
possibly
other
data
in
the
options
space.
B
So
this
limit
becomes
a
silly
limit
when
you're
doing
using
this
for
fragmentation.
For
those
of
you
who
don't
recollect
the
story,
we
put
the
fragments
into
the
option
space
and
because
we
don't
want
them
to
be
inadvertently,
delivered
by
a
UDP
receiver
that
doesn't
know
how
options
work.
So
this
protects
them
from
being
delivered
by
accident
and
it
requires
a
longer
option.
Jaw
recently
announced
that
the
length
field
of
255
would
indicate
that
the
length
is
followed
by
a
2-byte
length
field
which
gives
us
up
to
64
kilobytes
of
options.
H
B
D
Ok,
this
is
no
mostly
from
joe
of
stuff
we'll
need
to
get
back
to,
which
is
that,
with
some
of
the
similar
suffering
mucking
with
are
going
to
have
some
impacts
on
options
and
option
processing
to
take
care.
One
of
the
things
you're
gonna,
hear
on
on
use
of
can't
use
of
kind
is
going
an
impact
process.
Just
a
heads
up
that
we're
gonna
have
to
go
look
carefully
at
that
processing
text.
Ok,
so
this
is
Joel's
position.
Yeah!
All
right,
you
want
me,
go
go,
go,
try,
try,
try,
try.
B
The
first
one
since
this
on
which
saying
I'll
first
start
and
the
original
options
filled
Remick
mimic
tcp
options
rather
than
ipv6
options.
So
all
options
were
just
options
in
ipv6
the
the
indicator
allows
you
to
have
a
flag
which
indicates
that
the
option
is
critical
and
that
impacts
the
processing
of
options,
and
the
question
was:
can
we
have
something
a
little
bit
similar
to
this,
and
tom
was
a
part
of
the
discussion?
Other
people
also
on
Joe's
response.
Is
this.
D
So
the
this
is
about,
where
it
says
word
says,
must
support
flag.
So
there's
there's
two
things
going
on
there:
that
we
need
that
we're
going
to
need
need
to
try,
try
to
contrite
ooh
get
a
spectrum.
The
first
one
is
Joe's,
been
quite
adamant
that
you
can't
have
the
crucial
thing
here.
Is
you
get
a
critical
option?
It's
marked,
as
must
be
understood,
and
you
don't
understand
it.
D
B
M
D
No
no,
this
is
this
is
this:
is
your
behaviors?
The
receiver
has
received
a
valid
UDP
packet,
the
payloads
fine
receiver.
So
it's
going
at
the
options
area
and
says
I
understand
this.
We
are
saying
that
what
this
one,
what
nerd
is
this
whoops?
It's
got
a
critical
indication
and
I
don't
understand
it.
The
the
first
thing
we
just
went
through
was
that
if
this
happens,
but
most
you
can
do
is
toss
all
the
options
here
on
the
floor,
you
can't
drop
a
packet
because
you
didn't
understand
some
of
the
options
area
from.
X
D
Y
D
Was
part
one
part
part
two
is
you've
just
I've
already
given
the
game
away.
We've
had
some
discussion
on
the
list
about
whether
to
put
in
a
critical
indication
of
some
sort
authorized.
A
critical
flag,
though
I
think
I
posed
on
the
table,
is
to
take
the
range
of
possible
option
kinds
and
Mark
some
range
as
critical
and
the
rest.
The
range
is
critical,
it
might
be.
Half-And-Half
might
be
quarter
in
three
quarters.
D
H
This,
this
bid
is
based
on
what
ipv6
did
for
how
khop
options
and
destination
options,
and
so
the
two
higher
order
bits
in
an
ipv6
option,
type
and
disposition
of
an
option
that
is
undirected
an
option
type,
that's
unrecognized
by
the
receiver,
one
of
the
these
there's
two
bits,
because
there
is
also
an
ICMP
disposition,
but
we
don't
need
that
here.
So
fundamentally,
ipv6
says
you
do
one
of
two
things.
H
If
you
see
an
option,
you
don't
recognize,
you
either
skip
it
and
continue
processing
options
or
you
drop
the
packet
and
the
reason
you
drop
the
packet
is
because,
if
you
don't
recognize
that
option
and
don't
process
it,
the
processing
of
the
rest
of
the
packet
may
be
fundamentally
incorrect
and
that
that's
that
that
last
part
is
significant,
because
if
you
don't
have
this
fit
and
you
can
ignore
any
option,
that
means
you
can
never
have
options
that
are
interesting.
That
like
modify
the
data,
you.
H
H
H
So
if
we
use
this
bit
approach,
you
should
never
see
that
bit
set
in
any
of
these
travel
options,
because
it's
invalid,
because
those
options
consult
always
be
ignored,
but
in
mode
2,
where
the
UDP
length
is
8,
a
there's,
no
such
thing
as
an
agency
receiver,
the
legacy
receivers,
don't
see
any
payload
or
anything
as
they
essentially
adopt
the
passion
with
the
tie
with
a
caveat.
But
if
it's
a
receiver
that
processes
options,
then
it
can
follow
the
rules
process.
H
The
option
list,
if
I
see
an
option,
I,
don't
understand
and
it's
important
drop
it
and
don't
forget.
In
that
case
you
there
is
no
technical,
UDP
payload
there
is
payload.
Yes,
that's
in
the
surplus
space
we
can
do
whatever
we
want
with
that,
because
that's
not
UDP
payload,
so
we
can
change
it
and
encrypt
it
or
whatever
are.
H
H
H
D
B
W
D
Different
here
is
ipv6
to
find
that
option
behavior
as
part
of
defining
ipv6
we're
retrofitting
here
and
not
disturbing
the
behavior
of
existing
UDP
payload
when
the
payload
is
present
is
definitely
important,
I'm,
not
sure
about
the
about
the
zero
and
zero
links
conventionally
UDP.
Okay,
so
I
am
certainly
dropping
the
packet
when,
when
there's
really
to
be
payload
there,
because
you
have
a
bad
option-
is-
is
a
problem
so.
H
D
D
D
B
H
H
X
B
D
And
I
think
the
the
other
thing
is
I
believe
that
the
the
design
direction
going
forward
for
how
to
put
a
critical
indication
in
the
option
is
the
divide
up
the
option
space.
It
might
be
the
most
significant
bit
of
this
50/50.
It
might
be
the
two
most
visits
if
it's
2575
will
figure
out
on
the
list,
how
divide
up,
but
that's
that
I
believe
the
design
direction
going
forward
and
I
see
nobody
headed
for
the
mic.
So
that's
our
record
that
essentially
the
room
so.
B
B
That
is
a
real
question
to
the
working
group.
Do
we
need
the
light
functionality
independent
of
frag?
The
discussion
that
the
chair
saw
on
the
list
recently
suggested
that
we
might
be
able
to
remove
the
UDP
light.
Partial
coverage
function
from
the
option
trailer,
so
it
so
we
don't
have
an
option
that
says
this
is
UDP
light
equivalent
and
does
anybody
think
that
we
need
the
UDP
light
option?
B
D
The
the
consequence
that
the
discussion
are
about
light
and
wear
lighter
we've
got
connected
into
all
of
this-
was,
if
you're
trying
to
do
DNS
fragmentation
chrisbeek
because
of
DNS
setting
using
UDP
options,
because
OCS
has
to
be
present
in
every
single
one
of
those
UDP
packets.
You've
got
the
individual
checksum.
Do
you
almost
immediately
assembly
checksum
and
if
you
want
an
end
and
we
assembly
checksum
that
shove
it
in
the
application?
Is
so
there's
note
this
there's
no
reason
to
borrow
it
and
if
the
application
is
doing
its
own
reassembly
checksum.
D
H
B
D
X
B
H
It
is
a
grant
it's
a
relatively
minor
point,
but
the
the
difference
here
is:
we
want
to
model
stateful
options
or
stateless
options
and
I.
Think
if
you're
going
with
stateless
option,
which
you
seem
closer
to
I,
would
prefer
the
ideas,
ipv6
method,
implementation
wise.
If
I
have
both
of
these
it's
a
lot
easier,
because
I
can
use
the
same
implementation
for
hop-by-hop
destination
options.
Now
segment,
routing
options,
it's
UDP
option
same
exact
code.
It
would
be
just
conveniens,
quick
cinchy.
It's.
B
Okay,
so
this
is
design
goals
and
Joel's
passionate
about
this,
and
it
doesn't
actually
help
sculpt
the
problem,
so
I
think
it
would
be
worth
people
checking
on
the
list
whether
they
think
the
list
of
design
goals
are
still
valid
and
whether
some
of
them
need
to
be
updated.
It
would
help
just
thinking
about
checking
the
consistency
if
we
check
the
design
goals
section
of
the
draft
and
we're
already
questioning
support
for
partial
checks
and
coverage,
which
was
one
of
those
design
goals.
B
B
There's
basic
rules
in
those
design
calls
that
se,
how
you
DP
options,
work
I
think
it's
good
to
have
a
strong
model
of
how
you
think
they'll
work.
So
if
you're
interested
in
the
UDP
options,
debate
or
you've
talked
on
any
of
these
topics
on
the
list,
please
check
those
and
find
out
whether
the
design
principles
are
still
correct.
That's
right,
I
mean.
B
B
Have
one
question
that
we
didn't
ask
there
was
some
so
on
the
list.
We
talked
about
a
CRC
16
as
an
integrity
check
where,
as
I
thought,
David
that
we
had
previously
discussed
that
remind
me
otherwise
that
we
should
have
been
a
crc32
see
was
used
for
integrity
check
as
per
SCTP
and
I
scuzzy.
Is
that
right?
My
general.
D
Sense
I
think
in
this
discussion
and
from
elsewhere,
is
that
if
we
don't
use
the
typical
internet
16-bit
checksum,
what
is
a
CRC?
The
right
series
t
to
use
is
CRC.
30
is
CR,
see
through
to
see
don't
waste
time
on
CRC
16
and
your
crc32
see
because
it
has
incredibly
good
software
support,
courtesy
of
I,
scuzzy
and
SCTP.
B
I'm
I
think
we
could
have
most
arrested
stuff
and
what
we
really
need
to
see
is
people
check
the
design,
principles
and
Joe
to
revise
the
documents
so
that
we
have
a
consistent
view
of
all
the
comments
that
be
made
on
the
list
recently.
If
you
didn't
look
at
it
and
you're
interested,
please
look
at
the
next
revision
from
Joe,
because
this
is
beginning
to
settle
down,
which
is
good.
Okay,.
D
Now
I'm
gonna
I'm
gonna,
unilaterally
bash
the
agenda.
Jerome
you
here:
okay,
let's
quickly
deal
with
the
announcement
really
different,
let's
quickly
deal
with
the
qci
and
diffserv
draft,
so
Jerome
and
Tim,
who
are
the
folks
who
brought
us
the
very
useful
RFC
on
how
to
map
between
Wi-Fi,
QoS
and
DIF
circ
us
went
to
work
on
qci
for
Chrome
mobile
networks.
You
saw
some
comments
from
the
3G
from
some
3gpp
folks
on
the
list.
Expressing,
let's
see,
I
would
say
profound
reservations.
D
There
was
a
meeting
between
3gpp
and
IETF
leadership
on
Monday,
which
included
this
topic
like
Magnus
Magnus
go
and
I
were
all
there
along
with
I
think
some
other
folks
in
the
room.
The
upshot
of
that
meeting
is
that
we,
the
there
will
not
be
a
normative
stainless
area,
so
this
cannot
be
standards
track.
They
there
appears
to
be
an
opportunity
to
write
an
informational
draft
for
guidance
to
non
experts,
eg
those
setting
up
private
networks,
and
there
will
be
more
details
coming.
D
X
I
Back
on
to
these
topic
good
morning,
Germany
one
of
the
others,
so
Thank
You
mr.
chair
I'm,
looking
forward
to
the
feedback
from
the
summary
of
what
said
and
I
think
if,
as
I
hope,
the
feedback
is
that
they
are
not
opposed
to
an
informative
texts.
One
of
the
first
tests
will
probably
be
to
clarify
the
intent
of
that
draft
in.
C
AA
So
Martin
Dali
18,
TM
herbs
and
18
t
and
the
CT,
as
well
as
sa
three
working
groups.
Okay,
so
the
table
that's
being
referenced
here
on
qci
in
essay.
2
is
an
informative
table
and
the
reason
why
it's
an
informative
table
is
that
just
like
each
of
the
characters
and
their
backbones
used
if
surco
points
differently,
the
qci
and
arc,
which
is
the
priority
marking,
are
also
used
differently
or
can
be
used
differently
between
various
different
carriers.
AA
AA
D
R
B
B
Z
Z
L4
s
link
where
you've
got
differentiation
between
effectively
classic
TCP
in
the
in
the
classic.
Q
versus
next-generation
TCP
is
with
congestion
controllers
that
can
achieve
ultra
low
queuing
delay
in
a
low
latency
queue
identifying
sparse
traffic
that
can
coexist
with
that
l4s
traffic
in
that
little
8zq.
But
in
addition,
there
are
like
the
other
link
types
that
can
make
use
of
this
code
and
provide
similar
support
for
sparse
traffic,
in
particular
pointing
up
links
that
have
the
ability
to
optimize
media
access
or
channel
parameters
for
sparse
traffic.
Z
Z
The
concept
Lola
was
that
an
application
could
make
its
decision
between
whether
it
wants
a
little
latency
or
whether
it
wants
a
little
loss
and
that
concept,
I,
guess
morphed
into
essentially
utilizing
or
proposing
to
utilize
the
same
signaling
as
we
proposed
in
the
nqb
draft
originally
and
with
further
discussion.
We
agreed
that
the
definition
of
nqv
is
like
identifying
sparse
traffic
and
providing
both
low
latency
and
low
loss
was.
It
was
a
better
outcome
in
the
end
and
so
that
work
was
merged
into
the
MQB
draft.
Z
Mention
the
previous
little
approach,
also
referencing
an
RD
mechanism
rate
delay
trade-off
mechanism.
That
was
some
earlier
work
as
well
that
discuss,
and
then
there
was
a
comment
at
the
last
IETF
should
discussed
the
implications
on
the
RFC,
83
25
mapping
of
diffserv
to
802
11,
and
so
we've
got
a
recommendation
there
as
well.
Okay,
the
rest
of
these
slides
are
essentially
a.
D
Z
All
right
becomes
that
I've
seen
them
both
on
the
mailing
list
and
offline,
so
talk
when
adding
five
G
nomenclature
in
the
mobile
section.
So
there's
been
some
discussion
on
that
and
what's
the
appropriate
language,
their
comment
about
you
know
interesting
mobile
networks.
The
the
fact
that
mobile
networks
have
highly
varying
channel
capacity
is
a
aspect
that
maybe
the
original
use
cases
didn't
have
to
consider
for,
for
example,
for
cable
broadband,
and
so
some
interest
in
running
lab
tests
to
understand
the
cue
death
and
queue
protection
implications
for
someone
that
works
and
then
offline.
Z
There's
a
discussion
in
relates
to
the
the
immediately
previous
in
a
previous
discussion
around
QC,
I
and
diffserv
map
mapping.
We
have
a
line
in
the
n
cubed
graph
that
says
for
LTE.
You
must
use
a
low
latency
bear
with
QC
i7,
and
the
suggestion
was:
let's
that's
not
the
normative
on
that,
at
least
on
the
QC
I
piece
of
it
and
say
must
use
a
low
latency
bear
EG
with
QC
i7
and
martin
Dali.
Thank
you
for
your
help.
With
this.
R
C
Actually,
and
also
thanks
birth,
you
know
softening
that
language
must
say,
but
I
actually
read
the
draft
and
I
see
that
for
Wi-Fi
sections
you
had
recommendation
should
but
or
the
LT
section
you
had
must
so.
Is
there
any
Pacific
reason
for
that,
because
I
would
prefer
I
think
that
even
this
should
be
should
not
the
mosque,
because,
as
Martin
said,
that
in
its
evolving
and
not
pacifically
even
giving
the
example
because
I
think
Wi-Fi,
section
I
like
that
section.
So
if
this
section
can
be
mastered,
the
similar
tone
I
think
that
would
be
better.
B
X
Z
The
first
part,
actually
the
suggestion
that
that
be
a
Mazda
support.
Q
protection
was
mentioned
on
the
last
ITF
as
well.
The
reason
that
I
left
that
as
a
should,
is
I
think
that
there
are
some
computers
uplands
that
would
not
need
to
implement
your
protection,
in
particular
an
FQ
system
or
there's
isolation
per
flow,
maybe
without.
C
So
with
the
second
I
think
one
additional
points:
I
read
the
security
consideration,
I
think
it's
a
good
thing,
but
maybe
that's
a
little
bit
elaboration
would
be
good.
Who
is
responsible
for
marking
this
you
mention
about
that
no
integrity,
protections
in
on
path
attacker
can
change
it,
adding
some
what
the
consequences
would
be.
If
someone
does
that,
I
think
that
would
be
a
good
thing
not
to
add
in
that
section
as
well.
Okay,
fair.
B
F
AC
B
B
D
B
Y
B
Chest
will
also
I'm
asked
on
the
list
to
confirm
that
anybody
here
and
it's
an
agreement
with
the
sense
of
the
room
we
had
see.
So
we
see
a
sense
of
the
room
I'm
supporting
this.
Thank
you
for
the
presentation.
We
will
confirm
on
the
list
and
then
we
work
with
our
ad
to
decide
what
to
do.
Yeah.
Okay,
we
would
like
to
provide
some
time
for
a
presentation
weights
being
squeezed
a
little
bit
and
it
probably
has
a
lot
of
slides
so
and
please
use
the
time
after
you
see
fit.
AB
G
AB
AB
This
particular
draft
was
part
of
the
net
one
working
group
and
there
we
realized
that
it
took
a
little
more
analysis
from
the
QA
side,
also
a
little
more
understanding
on
the
Yang's.
So
this
particular
draft
was
moved
into
a
rocking
working
group
from
networking
group
0-7
version
of
the
draft.
We
had
adoption
call
on
this
one,
and
one
of
the
comment
which
came
out
of
that
was
why
not
we
present
the
same
TSP
working
group
take
additional
comment
from
the
community,
as
well
as
for
more
the
qsr
work
in
this
community.
AB
W
AB
So
next
one
so
I
already
explained
that
fun.
Maybe
we
can
go
to
the
next
slide.
Okay,
so
to
come
up
with
a
model
which
is
common
across
vendors
is
very
challenging
task,
the
reason
being
all
the
vendors
are
there,
so
many
qsr
construct
across
industry
that
to
fit
one
particular
construct
for
Albany
is
very,
very
difficult.
So,
but
we
realize
that
there
are
a
lot
of
commonalities.
AB
The
lot
of
commonalities
on
the
qsr
parameter,
as
well
as
the
way
vendor
apply
the
qsr
configuration
on
the
devices,
and
so
what
we
realize
that,
typically,
all
vendors
create
a
qsr
policy
and
apply
on
interfaces
in
ingress
and
egress
direction.
So
by
understanding
that
we
came
up
with
this
model,
where
we
converted
the
model
into
t3
set
of
layers,
one
was
the
base
layer
which
consists
of
classifier
action
policy
and
target,
so
the
classifier
is
nothing
but
a
set
of
filters
and
policies
list
of
classifier
associated
with
the
corresponding
actions.
AB
AB
So
ie,
as
I
already
explained,
there
is
a
class
per
module
which
is
referred
by.
The
name
contains
the
list
of
filters.
There
is
a
policy
module
which
contains
set
of
classifier
with
the
corresponding
actions.
The
classifier
could
be
referred
by
reference
or
it
could
be
a
filter
parameter,
which
is
here
in
line.
AB
AB
C
AB
Okay,
so
doing
policy
will
contain
including
related
parameters,
and
we
can
always
have
four
three,
two,
eight
nine
for
those
parameters.
Scheduling
policy
will
contain
a
queuing
policy
as
well
as
min
rate
next
state.
At
that
time
you
have
means
olive
and
I
have
their
own
set
of
features
which
can
be
easy,
augmenting,
augmented
to
the
model,
and
they
can
enhance
the
model
the
way
they
want.
AB
So,
in
summary,
you
know
we
have
defined
a
base
set
of
modules
and
then
we
have
based
on
those
face
set
of
modules.
We
have
three
actually
derived
set
of
modules.
It
is
pretty
more
adaptable
to
any
vendor
requirements.
It
could
be
augmented
to
any
specific
vendor
specific
parameters,
and
you
know
it
can.
It
is
pretty
very
extensible
next
thing:
yeah,
please
go
through
the
draft
when
you
get
time
and
please
provide
some
comments.
Thank
you.
Can.
B
I
ask
people
to
come
to
the
mic
if
they
have
comments
and
also
to
think
because
I'm
just
about
to
ask
whether
anyone
in
this
room
can
help
in
this
initiative,
because
this
room
has
expertise
in
running
networks
with
QoS
and
has
the
expertise.
And
if
so,
is
there?
Anybody
here
who
is
willing
to
help.
B
AB
D
AB
Yeah,
so
one
thing
I
would
like
to
explain
here
as
part
of
this
presentation
is
that
we
created
a
separate
operational
model.
The
reason
being
config
model
was
too
detailed.
An
operation
model
requires
own
set
of
analysis
on
the
counters
part,
and
so
we
went
through
all
the
different
discussions.
We
thought
is
very:
it's
better
idea
to
have
a
separate
model
for
operation
and
where
we
can
detail
about
the
statistics
for
qsr.
One
other
thing
is
that
you
know
nowadays
this
lot
of
talk
about
network
visibility.
AB
AB
So
essentially,
you
know
these
are
the
basic
element
for
any
Q
s
policy
which
can
be
applied
to
interface.
We
have
class
per
classifier
statistics,
we
have
policy
statistics,
B
metering
and
queuing
statistics.
In
addition
to
that,
we
have
named
statistics,
which
is
very
similar
to
classical
statistics,
except
that
it
has
a
common
name
across
the
classifier.
When
it
does
happen,
that
means
we
aggregate
those
counters.
This
is
very,
very
beneficial
for
low-end
devices,
where
the
resources
for
hardware
is
very
scarce,
so
other
than
that
yeah,
it's
a
usual
stuff.