►
From YouTube: IETF103-TSVWG-20181107-1120
Description
TSVWG meeting session at IETF103
2018/11/07 1120
https://datatracker.ietf.org/meeting/103/proceedings/
B
I'm
David
black
on
another
of
your
heart,
heart,
hard-working
working
group,
chairs
and
I.
Guess:
I,
get
quick,
explain!
You
explain
the
agenda,
so
this
is
the
bulk
of
the
agenda
of
UDP
options,
SCTP
drafts,
including
the
latest
on
the
on
the
errata
draft,
which
is
now
approved,
and
at
the
RFC
editor
thank
you,
Thank
You
Spencer,
and
then
we
get
to
do
a
whole
path,
a
whole
bunch
of
path,
MTU
discovery.
B
Now
on
Monday
we
bashed
the
agenda
on
I
want
to
thank-
and
thank
you
for
talking
about
her
draft
on
Monday,
because
what's
going
to
happen
here
is
let's
see
if
I
may
get
this
dudes
right
thing.
We're
gonna
pick
up
the
diffserv
to
QC
I'm
mapping
draft
at
the
end
of
the
agenda
time
permitting
the
items
shown.
This
page
are
all
more
important
than
this
sort
of
QC
I
and
what
we
will
put
the
time
into
these,
that
we
need
to
get
to
to
understand
and
try
to
close
close
open
issues.
All.
C
A
D
B
So,
if
you're
looking
for
an
update
on
what,
so,
if
you
can
put
an
overview
of
what
UDP
options
are,
please
read
the
draft.
This
is
the
latest
update
from
Joe,
as
and
as
an
editor
there's
a
bunch
of
editing
items
on
this.
The
first
two
here,
the
peel
p.m.
2d
and
the
processing
failure
items
are
our
editing,
our
editing,
things
that
are
being
done.
Update
draft
beyond
that
we've
got
a
couple
of
open
issues
and
then
adventure
Glory's
going
to
get
to
first
is
here's
the
here's?
B
What
what
Joe
is
currently
working
on
for
rules
for
new
options
that
abuse
in
the
future?
You
can't
depend
on
the
content
of
the
option
area.
You
can't
depend
on
processing
order,
and
the
only
exception
is
if
for
somehow
we
make
a
new
option
mandatory.
If
options
are
prepped
at
present,
all
this
one
has
to
be
there.
Then
you
get
a
little
more
flexibility.
Otherwise
it's
it's
really
kind
of
rough
out
there
I'll.
Let
you
read
the
bottom
of
of
the
slide,
which
is
Joe's
rationale
for
what
he
wants
to
do.
B
F
B
If,
if
we
were
ever
to
add
mandatory
options,
we
get
to
figure
out
what
a
flag
day
looks
like
I'm,
not
quite
sure
what
that
line
refers
to.
It
might
be
the
case
that
that
refers
to
the
two
to
two
current
mandatory
options
not
once
be
added
in
the
future,
and
it's
all
really
complicated
because,
as
I
think
I
saw
discussed
on
the
list,
if
we're
designing
protocol
from
scratch-
and
if
you
don't
understand
this
game
over
bit,
would
be
a
fine
thing
to
add.
B
However,
because
we're
tacking
options
onto
UDP,
if
you
don't
understand,
then
game
over
is
the
wrong
is
the
wrong
outcome?
It's
if
you
don't
understand,
then
maybe
ignore
the
entire
set
of
options,
but
don't
drop
the
packet,
because
these
off
this
weird,
don't
drop
the
UT
back,
because
this
weird
options
thing
got
tagged
onto
something
went
wrong
with
it.
A
B
G
So
I
don't
want
to
open
a
retinyl
here
right
but
but
I
mean
I
I,
don't
really
see
anybody
jumping
up
and
down
for
actually
needing
UDP
options,
and
if
that's
the
use
case
right
and
given
that
you
know
as
a
chair,
quick
right
and
quickest
konasana
on
GDP
traffic,
I'd
be
willing
to
say
good
luck,
trying
to
get
the
quickest
to
implement
UDP
options
for
path,
MTU
discovery,
I.
Think
you're
gonna
have
a
very
hard
argument
there.
So
this.
B
G
I
Hi
Colin,
Perkins
I,
have
to
say
I
somewhat
agree
with
plus
the
the
RTP
based
applications.
I
I
know
about
that.
You
use
UDP
I
can't
see
what
useless
is
for
us
if
it
doesn't
work
for
RTP
and
it
doesn't
work
for
quick.
Those
are
the
two
main
uses
of
UDP
unless
the
DNS
folks
wants
it,
not
that
we
know
about
and.
A
Something
about
right,
wait,
we're
not
doing
a
chartering
discussion.
We
did
the
chartering
discussion,
we're
not
doing
a
working
group
last
call,
so
we
take
these
as
inputs
and
we
push
back
on
complexity,
because
adding
complexity
is
dangerous
with
those
inputs,
but
we
carry
on
the
discussion.
I
think
is
chess.
Yes,.
F
I'm
Tom
Jones
and
we'll
skip
that
because
David
did,
and
so
we
have
an
implementation,
FreeBSD
and
present
this
in
Montreal
and
in
London
it
has
not
materially
changed
and
we
convinced
Joe
to
accept
options.
We
need
for
PLP
MTD,
and
so
they
will
appear
in
the
draft,
but
they
have
been
implemented
for
a
long
time.
We
have
things
we
have
not
implemented
so
I'll
get
to
that,
and
we
also
have
some
questions
about
where
that
the
ACS
is.
F
The
draft
is
different
than
we
thought
it
was
so
we're
a
bit
confused
and
hopefully
Joe
or
respond
on
the
list.
And
yesterday
a
Mukherjee
I
presented
results
on
early
measurements,
EDP
options
and
we
find
that
unique
options
doesn't
really
work
in
the
internet.
It's
like
a
50%
chance
on
a
path
that
the
path
will
drop.
F
Udp
options
at
this
slide,
which
is
much
harder
to
read,
is
shows,
shows
a
breakdown
of
some
of
the
failure
modes
and
what
works
the
yellow
line
across
is
where
we
are
EDP
options,
and
so
we
get
45
50
percent
depending
on
the
traffic.
We
measure
that
fails
on
the
Internet
and,
if
we
add
the
the
CC
option,
which
we
have
a
draft
for,
we
get
a
huge
improvement
in
the
number
of
paths
we
will
work
on.
F
The
presentation
yesterday
went
into
this,
so
we
have
the
CCO
option
just
ensure
it
has
a
modified
pseudo
header
causes
a
collision
and
the
the
checks
on
space
so
that,
if
you
calculate
the
checksum
correctly
or
incorrectly,
you
get
the
right
checksum
out.
It
can
address
all
the
issues
where
you
DP
options
doesn't
work.
So
there's
boxes
on
the
Allies
zero
in
the
UDP
option,
space
I'm
going
to
do
about
that.
There
are
bosses.
F
We
should
do
a
heart
check
against
the
IP
payload
length,
equaling
the
UDP
length
and
can't
deal
with
that
and
there's
some
really
weird
pseudo
header
calculations
done
where
I
don't
know
where
the
numbers
came
from
and
we
can
really
defeat
that
and
but
we
still
see
a
big
improvement
by
using
CCO.
So.
F
F
F
Yeah,
so
we
have
the
the
CCO
and
we
we've
had
discussion
in
the
past
about
the
the
checks
on
which
covers
the
the
checks
on
Space
Needle
options
and
the
the
OCS
checksum
we
have
right
now
is
a
8-bit
checksum
and
there
there
is
thought
that
that
is
probably
not
a
great
idea.
Considering
the
internet,
checksum
is
twice
the
size
the
for
us.
The
CCO
is
clearly
something
which
is
required
to
use
for
most
traffic,
and
so
we
could
move
to
using
the
CCO.
B
So
David
blacks,
being
an
angel
individual
for
a
floor
from
the
floor,
there's
a
time
for
rough
consensus
and
there
is
a
time
for
running
code
and
after
what
I
saw
on
map
RG,
which
was
an
even
blunter
version
of
the
more
complex
I
was
shown
earlier.
I
think
running
code
wins
this
one
by
wins
this
one
by
a
country
mile
I
would
based
on
what
I've
seen
and
the
fact
that
this
makes
the
UDP
options
go
through
a
heck
lot
more
places
than
than
they
do
without
it.
A
Would
you
okay,
so
so
so
I
think
I
think
that's
good
input
and
I
like
that
and
there's
another
question
is:
do
we
require
this
to
be
present?
I
think
the
the
slide
here
says
that
we
that
the
implementation
will
use
this
by
default
anyway,
because
it's
the
only
way
or
work
in
the
current
internet,
but
Joe's
point
seem
to
be
on
the
mailing
list
that
maybe
this
should
be
optional,
because
the
internet
may
change
completely
and
we
may
no
longer
need
this.
B
F
And
yeah,
and
so
if
we,
if
we
can,
that
that
will
be
the
change
in
our
implementation,
we
will
bend
the
will
be
in
the
OCS
and
replace
it
with
the
CCO
I
still
like
calling
it
a
compensation
option.
I
find
that
very
funny,
and
then
so.
On
the
the
list
this
week,
I
raised
some
other
topics
and
to
do
with
implementation,
and
there
are.
F
There
are
three
options
in
this
draft
that
are
one
difficult
to
understand,
difficult
to
implement
and
have
very
dubious
value
and
sorry
the
first
to
hit
these
requirements,
and
so
there
is
a
light
option
in
the
draft
and
it
involves
a
quite
a
complicated
four
byte
packets.
Well,
we
don't
have
any
motivation
for
this
now
with
the
CCO
and
because
you
need
the
CCO
for
light
for
a
UTP
options
to
work
and
then
your
check
something
your
light
data
and
it
doesn't
seem
to
tie
together
and
there
is
a
fragmentation
option.
F
I
land
on
the
the
site
that
fragments
are
fragile
in
interior
and
I
have
no
interest
in
implementing
lists,
and
then
finally,
there
is
a
a
II
option,
which
is
trying
to
pull
in
TCP
a
o
style,
authentication
and
I
had
think
this
is
a
fine
course
of
action
to
look
into,
but
it's
under
specified
in
this
draft,
and
it
probably
means
some
document,
and
so
we
were
to
continue.
This
I
think
it
should
be
a
separate
piece
of
work.
A
So
I
guess
that
I'm
asking
the
working
group
in
general
is
the
working
group
chair.
Are
people
keying
to
implement
these
three
things
and
if
people
come
running
to
the
mic,
if
people
ask
them
the
mailing
list
to
to
use
this
because
they
think
this
is
useful
or
if
people
volunteer
cord
even
better
than
these
can
appear
in
the
implementation,
we're
working
on
we'd,
happily
add
them
and
check
them.
A
G
So
you
very
much
a
freebie,
a
scheme
limitation.
We.
A
G
F
And,
and
with
huge
and
the
last
conversation
I
had
with
Joe,
is
he
doesn't
want
it
to
be
upstream?
This
or
and
working
group
last
call
because
he
wants
to
fiddle
which
doesn't.
I
I
We
have
experimented
with
as
a
satellite
especial
checksums
right,
so
we've
experimented
with
that
in
RTP
and
Sean
Magnus
can
comment
further,
since
he
did
the
draft.
But
my
understanding
is
that
while
we
did
the
spec,
it
turned
out
not
to
be
desperately
useful
in
practice
and
as
for
authentication
and
encryption
unless
it
ties
in
with
stun
and
ice
and
all
of
that
and
the
security
mechanisms
I
see
that
we
would
have
Easter
it.
I
A
I
E
B
J
B
J
B
J
But
in
practice
looking
at
the
wider
internet,
for
you
know
billions
of
users
and
so
on
fragmentation.
It
doesn't
work
very
well.
So
I
think
Maya
stated
this
in
numerous
emails
we
should
have
you
know.
Networks
must
support
fragmentation,
but
also
that
application
should
probably
try
to
avoid
it.
If,
if
they
don't
know,
if
they're
talking
to
anyone-
and
they
have
no
idea
in
controlled
environments,
you
can
do
whatever
you
want.
But
if
you
wanted
to
work
on
the
Y
during
that
you'd
be
better
off
a
void.
J
F
F
A
A
But
we
had
the
discussion
of
the
mic,
so
the
things
that
haven't
been
implemented
are
currently
in
the
spec.
The
most
input
I'm
asking
for
the
working
group
is,
if
you're
at
all
interested
in
this
space.
Please
look
at
the
list
of
things
that
weren't
implemented,
excluding
ACS,
which
and
OCS
which
tom
says
are
going
to
be
updated,
but
the
other
things
the
light,
the
fragments
and
the
a
oh.
A
Please
comment
on
whether
you
think
these
are
important
or
whether
the
working
group
can
go
forward
without
them
and
please
contribute
Cordura
examples
where
you
want
to
use
these.
If
you
want
these
to
remain
at
the
same
level
in
the
spec,
we
need
to
get
closure
on
this.
We've
had
it
as
open
as
a
work
item
for
a
while.
I,
don't
see,
increasing
activity
I
see
implementation.
A
B
G
I'm
I
mean
so
AI,
really
as
I
said,
where
that
I
don't
see
anybody
really
needing
this,
but
I
and
then
I,
you
know,
apologies
but
I,
don't
see.
Anybody
also
relate
sort
of
super
interesting
implementing
it
like
because
that's
the
other
thing
that
drives
it
drives
it
up
straight.
If
it's
in
a
stack,
somebody
might
use
it
or
it
gets
into
the
sex
piece,
we
do
rely
on
it,
so
I'm,
really
sort
of,
and
then
I
haven't
really
followed
the
map.
G
Our
key
discussion
yesterday
to,
but
it
seems
like
this-
is
making
UDP
more
fragile,
even
even
with
ZCO
right
there's
still,
it
still
increases
you're,
not
at
100%
delivery
rate.
You
don't
get
sent
delivery
right
because
there
are
boxes
out
there
which
police,
which
correct,
and
so,
if
I
mean
we're
to
discussion,
a
quick
where
quick
doesn't
work
over
some
small
fraction
of
paths
right
and
it's
the
same
five
percent
other
one
right.
G
So
so,
if
you
were
an
app
UDP
application
right-
and
you
basically
can
use
this
and
give
up
five
percenter
to
do
three
chances
or
not
use
this
and
and
have
100%
delivery
or
whatever
you
have,
but
so
it
seems,
it
seems
like
the
the
the
incentives
for
actually
using
that
seem
to
be
pretty
yeah
cap
or
even,
if
I
write
even
with,
even
though
it
was
really
bad
without
the
option
and
then
with
the
option
had
it
in
it
was
better,
but
it
was
still
not
at
baseline.
It's
still.
A
G
A
Yeah,
maybe
we
should
move
on
because
I
mean
you
could
probe
to
see
if
you
DP
options
were
supported
and
you
would
get
this
you'll
be
then
know
which,
if
you
don't
use
it,
every
packet
is
a
perfectly
viable
thing
to
do.
We
should
talk
about
this
on
the
list.
This
is
a
good
topic
list,
mirror
your
you
call
yeah.
K
G
If
the
transporte
wants
to
say
you
know,
this
is
a
mechanism
and
we
believe
people
should
be
using
it,
but
then
then
you
should
be.
You
know
telling
us
what
it's
useful
for
and
and
I
I
frankly,
don't
hear
that
right,
and
so,
if
you're
building
a
mechanism-
and
we
don't
know
what
it's
useful
for,
why
are
we
building
it?
I
B
I
C
A
Setp
the
slide
it's
from
Rocco
tux
and
we're
going
to
talk
about
the
network
address
translation
support.
This
work
was
on
hold
until
the
RFC
errata
was
published.
That's
know
with
the
RSC
editor,
so
we
this
wit,
will
start.
There
was
difficult
review
at
the
in
the
last
call
and
sorry
in
preparing
for
the
last
colors
interment,
and
most
of
this
is
to
do
with
taking.
This
document
has
been
around
the
working
group
for
quite
a
while,
which
has
been
edited
in
various
places
but
was
being
prepared
for
working
group.
A
A
There
are
other
comments
received
since
that
document
was
commented
on,
and
the
intention
of
the
authors
is
to
prepare
a
new
version
that
we
can
actually
send
to
the
TSV
WG
list
in
preparation
for
that
working
group.
Last
call
if
you
have
looked
at
this
and
you
feel
that
there
are
opinions
on
not
support
the
SCTP.
Please
be
aware
that
now
is
a
good
time
to
comment
on
this
draft
as
we
head
towards
the
working
group,
moscow.
A
There
should
be
a
drumroll,
we
published
the
errata
document.
The
errata
document
was
subject
to
quite
a
lot
of
debate
by
the
iesg
in
terms
of
process.
The
errata
document
was
a
plan
by
this
working
group
to
follow
the
practice
they've
done
with
the
previous
revision
of
SCTP
and
identify
all
the
things
that
have
changed
in
the
SCTP
spec
from
496.
So
this
document
is
now
with
RSC
editor
and
the
plan
is
now
for
the
working
group
to
open
a
replacement
document
for
496.
A
So
the
first
version
of
the
draft
will
be
a
copy
of
496
all
mangled
by
the
ITF
tools
to
regenerate
a
XML
file
or
an
a
table
file.
So
we
can
actually
start
with
a
0-0
draft
which
reflects
496
or
as
much
as
possible.
Shortly
after
that,
496
or
bits
will
be
rolled
again
to
produce
the
Erawan,
which
will
be
a
committed
set
of
changes
from
all
the
ones
currently
identified
in
the
errata.
No
other
changes
will
be
intended.
A
Then
version
2
will
appear,
which
starts
to
include
the
text,
clarifications
to
the
SCTP
spec
and
going
through
this
process
to
try
and
be
clear,
because
the
intention
of
this
process
is
to
implement
the
errata
document
we
specified
and
the
textual
improvements.
So
this
document
is
a
better
specification
of
the
protocol.
If
people
know
of
other
changes
apart
from
errata,
then
there
should
be
of
course
discussed
here
they
if
the
implementers
know
of
any
other
things
that
need
to
be
changed.
A
Please
discuss
them,
but
the
current
intention
of
the
working
group
in
opening
this
is
to
just
provide
textual
improvements.
We've
done
this
with
other
IETF
documents.
I
worked
with
the
pin
SM
new
spec,
which
was
simply
a
rewrite
of
the
spec
to
make
it
better
and
clearer,
but
didn't
change
the
protocol
on
the
wire
in
any
single
way.
This
may
well
be
the
way
forward
for
this
particular
document,
because
this
is
purely
improving
these
sheds
and
musts
and
the
way
things
of
this
rydym
presented.
A
We
expect,
let's
do
it,
be
very
fast
through
this
working
group,
but
we
shall
see
how
quickly
and
easily
we
can
provide
those
textual
changes.
Spencer
you're
near
the
mic.
There
are
process
things
involved
with
all
this.
Would
you
like
to
comment
on
them
or
anything
else.
L
Mr.
Dawkins
service
possible
outgoing
area
director
I
want
to
thank
you
for
putting
this
slide
up
and
kind
of
explaining
the
multi-step
process
actually
I.
Think
it's
really
good
for
us
to
start
out
with
something
really
close
to
nothing.
Four,
two
zero
zero
draft
about
this
and
I
think
that's
something
that's
be
good
for.
If
we
did
more.
L
F
Diagram
packetization
lair
path,
MTU
discovery,
and
so
in
Montreal
last
time
we
promised
some
pretty
large
changes
just
to
this
this
structure
of
the
draft
and
we
promised
we
would
break
that
into
more
of
the
the
core
components
and
so,
since
Montreal
we
have
done
all
this,
so
we
have
renamed
the
Frick
that
the
phases
dealt
with
transitions
in
the
the
state
machine,
redrawn,
diagrams,
consistently
renamed
terms,
so
they
are
correct.
We
hope
clarified.
F
States
clarified,
suspending
the
algorithm
verified
normal
text,
clarified
terms
throughout
the
draft
and
added
a
security
consideration
section,
and
so
now
the
draft
is
different
than
it
was
before,
and
so
we
now
introduce
the
mechanisms
to
implement
DPL,
PMT,
UD
and
so
the
the
way
the
draft
is
structured.
Now
they
should
be
relatively
easy
to
point
into
the
draft
if
you
need
to
from
somewhere
else.
So
you
can
say
this
is
how
we
should
these.
F
This
is
the
requirements
of
how
we
should
do
probing,
and
this
is
what
black
hole
detection
is
and
how
we
should
address
it
here
are
actually
sensible
rules
for
PTD
handling
and
we
broke
out
the
error
states.
And
now,
when
you
read
through
the
drafting,
consider
the
algorithm
is
broken
down
into
four
major
phases
and
where
we
confirm
the
path
search,
complete
our
search
and
we
end
up
in
an
error
condition
and
so
to
introduce
this.
F
We
have
a
simpler
state
machine
as
in
addition
to
the
overall
giant
machine
which
is
hard
to
get
into
a
single
page
of
ITF,
ASCII
R,
and
so
this
gives
you
enough
pieces
so
that
you
can
look
at
the
algorithm
and
in
isolation,
and
you
can
figure
out
what
what
the
processes
you
need
to
do
to
do.
Dpl,
PM
TD.
F
Condition
of
the
the
path
doesn't
support
the
base
MTU
and
then
the
the
application
that
can
make
a
decision
about
what
it
actually
needs
to
do
so,
the
layer
using
this
algorithm
at
the
point
where
we
cannot
actually
find
him
good
number.
You
can
decide
if
you're,
just
gonna
keep
looking
if
you're
just
gonna
use
the
path
anyway
or
maybe
you
want
to
break
down
and
use
IP
fragmentation.
F
And
we
also
add
a
text
on
resilience
to
inconsistent
paths.
This
is
the
situation
where
maybe
you're
getting
occasional
routing
across
different
paths
and
you
get
different
values,
and
so
we
want
the
algorithm
to
be
able
to
try
and
detect
this
so
that
we
can
try
and
take
a
consistent
state
that
will
work
and
yeah,
and
this
is
still
an
open
area
and
we
still
need
to
do
a
bit
more
work
here
and
implementation.
F
So
we
have
a
new
implementation
at
University
of
Aberdeen
and
we've
been
running
this
in
a
lab
and
never
starting
to
do
real-world
testing
between
ourselves
and
cloud
providers.
We
got
comments
on
the
list
from
Christian
and
on
integration
with
quick
I
haven't
managed
to
speak
to
him
to
find
out
if
he
has
an
implementation,
and
most
of
his
comments
were
nits
and
issues
with
just
pointing
to
the
right
parts
of
quick
in
the
right
frames
and
I.
F
Think
now
that
takes
us
up
to
five
implementations
of
this,
two
of
which
I
didn't
do
and
so
I
think
we're
actually
quite
a
good
place
in
terms
of
implementations.
We'd
love
to
hear
about
other
people
with
implementations
of
this,
and
just
so
that
we
can
be
more
sure
that
the
algorithm
is
sensible
and
that
the
draft
is
readable
and
you
can
pull
the
right
information
over
tom.
F
J
A
Think
that's
kind
of
where
this
swag
leads
to
and
we
will
have
some
people
feel
six-month
here
who
also
do
path,
MTU
discovery
on
think
they
come
and
and
we'll
talk
about
that
in
a
second
just
to
try
and
widen
that
scope
in
the
way
you
suggest
I,
think
greater
number
of
eyes
on
this
now
would
be
really
good.
Yeah.
J
J
M
M
A
F
A
N
N
So
we've
been
doing
PMT
UD
for
30
years,
we're
trying
to
do
it
and
there
has
been
a
few
lately.
A
few
proposals,
for
you
know
at
least
some
thinking
about
you
know
clean
slate.
Could
we
do
PMT
you
the
better
at
internet
layer
there?
So
the
problems
we
have
with
the
current
mechanism,
which
you
know,
is
the
ICMP
based
packets,
a
big
that
we
have
today?
It's
you
know,
dinner
eaters.
So
that's
a
you
know
define
behavior
in
the
RFC,
so
readers
are
supposed
to
truffle
these
messages.
N
It's
filtered
in
firewalls,
ignored
by
hosts
in
v4.
You
didn't
even
get
enough
information
in
the
ICMP
packet
to
match
it
with
the
with
the
flow
you
were
sending
doesn't
work
well
with
load.
Balancers
requires
multiple
round
trips
and
and
detects
destination.
You
know,
/
destination
of
the
flow.
Do.
J
J
J
N
La2
networks
switches
might
silently
draw
large
packets
and
we
have
been
doing
this
for
a
while
right,
I
think
1063
came
out
in
88,
so
we're
you
know
thirty
years
in
here
and
and
what
are
the
options?
What's
the
solution
space
we
want
to
do
just
see
what
are
the
possibilities
here
and
clearly
there
are
work
in
other
areas,
so
the
routing
area
is
doing
this
in
routing
protocol.
Well,
you
can
just
advertise
TM
chief
in
the
routing
protocol
and
be
done
with
it.
That's
being
done
largely,
it
seems
for
a
segment
routing.
N
I
haven't
studied
this
work
very
much.
If
anyone
is
familiar
with
it
and
it's
you
know
good,
let
me
know,
multicast
area
is
doing
stuff
specifically
for
beer
and,
of
course,
we're
here
in
transport
which
is
has
to
do
it.
I
mean
we're
not
saying
that
we
can
do
this
solely
in
the
internet
area
right,
but
it
goes
way
we
have.
Is
you
know
it
has
to
be
robust?
It
has
to
be
deployable,
that's
probably
the
hardest
one.
N
It
would
be
nice
if
we
could
detect
the
path
MTU
in
a
singularity,
and
we
shouldn't
make
the
signaling
traffic
you're
signaling
back
to
the
sender,
an
easy
target
for
filtering
and
also
have
a
unique
set
of
problems
of
trying
to
have
heterogeneous
MTU
on
a
single
single
data
link
which
the
current
methods
don't
support,
and
when
we
talk
about
these
solutions.
Think
about
detecting
the
empty
you
different
from
signaling,
the
MTU
back
to
the
sender,
and
we
could
signal
back
in
in
different
ways.
N
You
know
you
could
using
the
UDP
option,
you
could
use
the
existing
ICMP
package,
a
big
message
which
is
well.
It
doesn't
sound
like
it's
that
more
prone
to
dropping
than
if
you
had
a
UDP
option,
but
that's
not
my
problem.
It's
on
a
different
layer
and
you
could
use
a
new
l3
option
or
you
know,
like
an
extension
header
or
you
could
do
it
in
the
application
so
fun
to
transport.
That's
the
default!
You
guys!
It's
your
problem,
not
mine,
and
that's
essentially,
you
have
the
final
responsibility
for
the
for
the
path
empty.
Alright.
N
So
you
have
to
do
this
anyway,
and
you
have
to
do
it
for
a
long
time,
even
if
we
came
up
with
a
mechanism
in
an
Internet
layer
that
could
guarantee
you
to
find
the
bmq,
it
will
not
be
deployed
in
in
one
day
right
so
so
this
is
really
your
problem,
we're
just
here
to
help
you
know.
So
it's
the
second
way
of
this
we're
just
leaves
me
status
quo
as
it
is.
We
could
do
empower
fragmentation
right.
We
know
that
before
it
was
supposed
to
raise
a
charcoal,
it
did
in
six-man.
N
N
Or
we
could
do
there's
two
new
proposals
in
in
six-man.
One
is
doing
packet
truncation.
The
sender
sends
a
packet
as
large
as
the
outgoing
interface
empty.
You
intermediate
Reuters
truncate
the
packet.
You
know
if
it
hits
an
outgoing
interface
with
a
smaller
empty
you
and
sets
you
know
a
truncated
flag.
The
sender
sets
a
trunk
at
truncation
eligible
flag,
probably
had
to
record
your
regional
payload
empty
you
if
you
were
to
do
this
on
normal
data
packets,
as
opposed
to
probes,
but
you
could
imagine
a
way
you're
doing
in
this,
where
you
could.
N
You
know
Pat
out
a
TCP
soon,
for
example,
get
that
truncated
and
then
you
know
in
the
soon
a
kit
would
do
the
same
thing
and
you
could
discover
the
MTU
on
on
a
single
RTT.
We
require
all
the
sender's
receivers
and
intermediate
nodes
to
be
updated
in
support
is,
of
course,
Cerrone.
Bonica
has
a
proposal
to
this,
and
you
have
some
ways
of
making
this
look
backwards
compatible.
N
So
this
thing,
since
large,
packets,
wouldn't
necessarily
detect
you
know,
l2
switches,
which
would
silently
discard
large
frames,
for
example,
so
that
is
one
solution
proposed.
The
other
one
is
is
parting
to
you,
recording,
which
would
be
that
you
know
you
send
a
small
packet
with
an
arc.
V6
hope,
I,
hope,
header
option
worthy
to
mediate.
Node
would
then
fill
in
the
empty
you.
If
it
was,
you
know
the
outgoing
interface
empty
was
smaller
than
what
was
already
in
the
packet.
L
F
F
It
for
you,
yeah
and
I
think
from
from
the
the
perspective
of
the
transport.
The
service
offered
by
the
network
is,
is
1280,
the
network
can't
offer
a
higher
service,
and
so
maybe
just
leave
it
to
the
transport
to
try
and
use
more
and
actually
let
us
send
packets
lower
than
larger
than
1280
I
mean
if
we,
if
our
operating
system
has
an
MTU
estimate
and
it's
bombed
into
the
root,
we
it
stops
us
sending
packets
and
it
makes
it
impossible
for
us
to
search
without
clearing
that
state.
F
N
F
And
but
the
ICMP
messages
are,
you
know,
they're
very
far
fragile
on
the
network
and
they
don't
give
us
great
information.
They
give
us
a
really
inconsistent
signal.
You
know
our
draft.
We
still
have
to
probe
when
we
get
that
number.
So
it's
not
like
it
solves
a
problem
very
quickly
for
us
yeah.
So.
L
Spencer
Dawkins
said
I'm
doing
this
as
responsible
Area,
Director
40s
DWG
I
wanted
to
thank
you
for
being
here
number
one,
because
I
think
that
a
lot
of
the
work
that
we're
going
to
have
to
be
doing
going
forward
in
general
at
the
IETF
is
going
to
be
like
what
you're
talking.
You
know
the
conversation
you're
having
here
and
in
other
places,
I
wanted
to
thank
you
for
coming
here
and
doing
that
I
wanted
to
unless
somebody
lines
up
a
bunch
of
people
line
up
behind
me
telling
you
no
don't
do
this.
L
N
O
L
To
full
standard
there
was
an
awful
lot
of
heartburn
about
you
know
this
isn't
actually
usable
now
and
that
isn't
going
to
get
any
better
and
the
empty
users
aren't
going
to
get
it
any
smaller.
It
seems
to
me
so
you
know,
for
you
all
to
be
working
on
it,
yes,
and
for
you
all
to
be
working
on
it
with
other
people,
and
you
know
communicating
and
cooperating
the
way.
You're
doing
seems
like
to
me
exactly
the
right
way
for
the
Internet
going
forward
and
I
said.
L
A
P
Hidden
and
this
is
sort
of
back
dispenser,
so
the
you
know
regarding
deprecating
82
a1,
so
the
mechanism
were
proposing
to
use
in
these
new
things
is
also
sending
packet
to
big
messages.
So
what
we're
changing
is
that
the
destination
host
sends
them
instead
of
the
intermediary.
So
it's
not.
You
know
it's.
That's
still.
The
mechanism
that
we
are
currently
using
I
mean
we
could
do
something
new,
perhaps,
but
so
it's
not,
but.
N
L
You
know
we're
gonna,
you
know
what
you
get
is
this
and
if
you
don't
do
this
and
you
don't
have
path
MTU,
just
but
Peka,
Peka
basis,
a
path,
packetization
layer,
I'll
path,
MTU
discovery,
it
just
kind
of
sucks
to
be
you,
you
know,
and
so
we're
having
these
interesting
conversations
which
you
you
know
we're
seen
for
UDP
and
stuff
like
that,
and
it's
like
you
know
it's
a
real
problem.
So,
like
I
said
I,
you
know
my
way,
my
you
know
the
only
people
that
responded.
L
Q
J
Michael
Abramson,
so
I've,
just
yeah
we
moving
packets
will
try
to
do
a
better
job
in
providing
the
single
back.
I
think
that
all
but
I
would
also
like
to
point
out
that
was
not
here
is
that,
what's
probably
even
better
working
in
today's
Internet
is
TCP
MSS
clamping,
that
is
a
network
signal
and
I,
know
a
lot
of
people
hate.
It
just
want
to
point
it
out.
We
have
a
way
of
setting
in
a
packet
for
the
that's.
You
know,
please,
please
don't
use
larger
packets
than
that.
J
J
A
There
is
some
ongoing
discussion
about
this,
and
there
are
some
people
meeting
around
the
IETF
space
on
Friday,
see
the
mailing
list
for
and
a
note
about,
work
people
are
meeting
on
who
to
talk
to.
Please
continue
this
because
if
the
PL
PMT
UD
is
reaching
its
end
here,
we're
in
the
final
stages
of
discussing
all
the
corner
bits
now
is
a
good
time
to
discuss
how
we
use
network
layer,
signals
and.
N
A
Ok,
we
want
to
squeeze
one
last
talking,
because
we
are
the
opportunity
opportunity
to
do
a
heads
up
talk
of
something
that
we
spoken
about
in
the
past
and
that's
the
relationship
between
diffserv
and
the
qci,
and
this
is
an
a
mapping
draft
the
diffserv,
it's
the
first
cut
at
this,
but
it's
an
area
that
probably
requires
a
lot
more
people
to
look
at
it
and
make
comments.
So
please
guide
us
through
quickly
the
highlights
of
your
draft.
Please
Thank.
O
O
At
the
same
time
for
the
same
application
and
that's
you
know
thanks
to
quick
and
P
TCP
and
some
other
mechanisms
or
because
your
U
is
going
to
alternate
between
the
two
connections
or
because
it's
going
to
talk
to
extension,
which
is
in
the
other
domain.
The
LTE
3gpp
people
have
done
a
lot
of
work
over
the
last
few
years
to
increased
number
of
QC
eyes.
They
initially
had
only
four
and
then
they
climbed
up
to
nine.
They
were
at
seventeen
last
year
and
now
they
have
21,
and
this
QC.
O
So
if
we
have
the
scenario
where
that
station
is
going
to
have
to
communicate
over
the
two
mediums,
at
the
same
time,
we've
been
more
and
more
asked
about
a
mechanism
to
translate
the
intent
of
these
QC
eyes
into
the
serve
intents
and
also
at
the
same
time,
if
your
application
is
marketing,
this
serve
a
certain
way
and
you
get
into
a
bigot
way,
which
is
the
interface
into
the
3gpp
domain.
How
would
you
translate
the
deep
serve
intent
into
something
that
makes
sense
into
their
domain?
O
So
this
draft
is
a
first
attempt
to
do
that,
trying
to
create
mechanisms,
and
we
found
unfortunately,
but
that
just
using
RFC,
45,
94
and
few
others
just
didn't
work.
We
have
to
create
new
values
here.
So
this
is
your
first
attempt.
I
would
like
to
encourage
you
to
read
it.
Provide
feedback
write
to
the
mailing
list.
Ask
questions
about
what
these
are.
If
they
are
not
something
you're
familiar
with,
because
they
will
really
be
a
need
for
us
to
create
a
mapping
that
works
in
both
directions,.
R
O
So
in
you
know
in
a
nutshell,
they're
working
inside
their
domain
and
there
is
actually
a
work
done
not
by
the
3gpp,
because
our
concerning
to
the
utrom
idea,
the
3gpp
world,
not
the
outside
world,
but
the
GSMA
has
done
a
mapping
that
was
done
maybe
15
years
ago,
but
that
only
addresses
the
four
cues
that
were
of
h.res
for
them.
So
now
that
5g
is
raising
the
speed
at
which
those
QC
eyes
are
going
to
be
created.
There
will
probably
be
a
work
at
the
GSMA,
but
I
think
it's
more
on.
R
Sounds
a
little
bit,
I
mean
as
this
read
people
define
security
is
an
intention.
They
it's
I,
don't
find
it
unreasonable
that
they
actually
also
say.
Okay,
this
probably
Maps
best
to
these
are
operators,
so
I
just
think.
Maybe
at
least
we
should
at
least
have
the
handshaking
in
the
relevant
50
people
working
group
about
this,
and
maybe
this
MA
also,
but
that's
if
we're
gonna
do
this
I
would
like
to
know
that
they
are
ok
with
it,
rather
than
be
stepping
on
their
toes.
Oh,
you.
A
Think
that's
there's
a
prerequisite
here
that
this
is
a
zero
zero
draft.
Although
it's
go
amount
of
text
behind
it,
it's
the
first
time
it's
been
aired
at
the
iti.
We
are
not
going
to
do
this
work
on
our
own.
It
may
be
a
great
thing
for
the
our
each
you
have
to
do
if
other
people
think
it's
a
great
thing
to
do
as
well.
So
let's
look
let's,
let's
talk
about
this
and
let's
tread
carefully.
Okay,.
S
A
T
A
O
B
Reminds
me
somewhat
of
the
work
we
did
on
Wi-Fi
mapping
and
just
as,
as
was
the
case
for
802
11,
it's
going
to
be
necessary
to
do
to
to
educate
this
community
on
what
QC
eyes
are
and
aren't,
and
what
the
state
of
the
art
is
both
in
spec
and
deployment
as
a
foundation.
To
look
to
to
look
at
how
the
mapping
comes
out.
A
So,
finally,
on
this
topic,
please
discuss
on
the
list
not
necessarily
the
proposal,
but
the
whole
concept
of
what
could
be
done
here.
What
should
be
done
here
and
what
is
being
done
elsewhere
and
hopefully
we'll
be
able
to
progress
on
the
topic
to
know
whether
we
have
insight
and
help
here
use
the
list.
Please
thank
you
for
coming
to
TSP
WG.