►
From YouTube: IETF102-TSVWG-20180719-1550
Description
TSVWG meeting session at IETF102
2018/07/19 1550
https://datatracker.ietf.org/meeting/102/proceedings/
A
B
A
C
A
C
C
D
E
A
A
C
A
F
F
Anybody
in
Jabbar
at
all,
okay,
Randy,
be
sorry,
your
name
Craig,
okay,
my
apologies,
Craig,
okay,
Craig
will
be
jabbar
Scott.
Thank
you
very
much.
Please
note
that
th
DWG
is
the
thing
chairs
look
for
when
we're.
When
we're
new
dresses
are
submitted
to
see
whether
with
it,
whether
whether
they
might
they
might
apply
to
us,
okay
doctrine
review
reminder:
dr.
Holly
relies
on
reviews,
please
review
documents
and
your
working
group
at
least
one
of
the
doctor,
another
working
group.
If
you'd
like
documents
that
you
care
about
reviewed,
please
review
other
documents.
F
I
subscribe
to
treasure
the
peoples
back
both
of
those
guys,
yours,
okay,
accomplishments
and
status.
We've
had
no
Marcy's
published
since
the
start
of
London
IETF.
However,
we
had
four
RFC's
published
between
Singapore
London,
demonstrating
the
addition
of
network
traffic
output.
This
working
group
is
bursty.
There
are
two
net
drafts
in
our
editor
queue.
The
tips
of
web
RTC
QoS
trap
has
been
there
for
a
while.
F
It's
in
miss
ref
state
on
a
number
of
our
TC
drafts
is
a
massive
web
RTC
draft
hairball
or
tar
ball
that
will
eventually
pop
out
of
there,
and
this
is
part
of
it.
Dsc
PR
Anna
process
changes
that
is
at
the
RFC
editor
in
the
RFC,
and
there
is
editing
on
that
one.
Okay,
we
had
one
more
ID
that
almost
made
it
SCTP
errata
and
issues.
This
one
is
still
act.
F
F
We
have
two
drafts
room
chairs
and
authors
after
working
group
glass
code.
These
the
two
forward
error
correction,
drafts
there'll,
be
a
slide.
Labels
Decker
will
show
you
what
the
inclusion,
glass,
working-class
last
call
is
concluded
and
I
think
we
need
one
more
set
of
minor
updates
all
before
these
go
to
the
is
G
diffserv
low-effort
pro-hop
behavior
draft
work
that'll
be
later
in
this
session.
The
plan
is
to
conclude
working
group
last
call
later
today
with
the
discussion
on
the
slides
and
that
draft
we're
likely
to
work
with
last
call.
F
These
two
EC
and
tunnel
related
drafts
in
the
variant
in
the
very
near
future,
I
was
hoping
to
working
group
glass
to
call
them
before
this
meeting.
Other
things
happened
while
I
was
busy,
while
I
was
busy
making
plans
to
do
that
last
month,
so
these
will
get
last
called
in
the
very
near
future.
There
are
seven
additional
working
group
IDs
listed
here.
Most
of
them
are
on
our
agenda,
the
one
that
the
one
that
really
isn't
is
childish
and
feedback.
That
draft
is
on
hold,
while
a
use
case
for
it
gets
worked
out.
F
The
use
case
is
over
in
the
service
function,
chaining
working
group
and
as
that
work
moves
forward.
This
draft
will
get
picked
up
and
move
forward
also
related
graphs
on
the
agenda
here:
path:
MTU
detection
via
v6
packet
truncation,
which
is
a
draft
that
was
new,
submitted
six
man.
We
want
to
talk
about
it
here
because
path.
Mtu
is
something
we
care
a
lot
about.
Translator
encryption.
There
are
impacts.
We
talked
about
this
a
few
times.
There
will
be
requests
with
group
adoption
here
in
this
meeting.
F
Tcp
encapsulation
considerations,
which
came
out
of
a
talk
at
TSV
area,
the
develop
our
topic
TSV
area
in
London,
l4
s
and
diffserv,
which
is
part
of
the
l4
s
draft
set
which
will
come
up
in
that
item
and
ipv6
reservation
protocol,
which
is
a
new
draft.
We'll
talk
about
to
add
down
the
end
of
the
next
session,
all
right,
related
drafts
to
more
drafts
or
transfer
related,
but
not
on
the
agenda.
One
is
the
priority,
switching
scheduler,
which
we've
reviewed
here
and
which
we
will
support
publication
of
via
the
independent
submission
under
track.
F
I
need
to
do
a
few
more
things
to
go
dot.
The
I's
cross
city
say
say
this
is
this:
is
this?
Is
a
fine
draft?
Ta
Street
of
G
supports
its
publication,
EC
and
NS
h,
draft
Eastlake,
SF,
c
NS,
HEC
and
support
this
is
the
SS
FC
draft
that
is,
that
has
the
usage
of
telling
Direction
feedback
that
will
be
discussed
over
in
the
SFC
working
group.
F
Then
we
have
a
three
internet
draft
draft
IETF
into
area
tunnels
which
job
touches
we've
been
working
on
over
an
empty
area,
fragmentation
of
fragility,
draft
ronica
in
the
area,
frag
fragile.
That
ron
has
been
been
been
working
on
and
a
draft
on
socks,
protocol
version
6.
Okay.
So
now
we
get
to
start
start
telling
you,
where
you're
on
the
agenda
in
a
little
bit
I'm
gonna,
go
gonna,
show
you
the
agenda
and
we
will
go
go
ahead
and
see
we
meet.
Do
any
bashing
do
more
to
right
now.
Go
through
the
the
milestone
review.
F
We
originally
hoping
to
get
the
two
ecn.
Encapsulation
drafts
done
for
this
meeting,
so
I
call
that's
going
to
be
next.
Meeting
cycles
are
going
to
move
those
two
dates
to
October.
The
next
three
are
in
good
shape.
The
for
our
glass
call
is
done
on
the
two
forward:
error
correction
drafts
and
we're
about
to
finish
off
a
working
group
last
call
on
the
lower
ever
phb
draft
and
in
addition,
the
related
dscp
I
Anna
mechanism
allocation
mechanism.
Change
draft
is
already
at
the
RFC
editor
and
being
edited.
F
So
those
three
in
good
shape
for
reasons
that
we'll
talk
about
more
when
all
4s
comes
up,
the
September
dates
for
l4s
are,
shall
we
say
a
wee
bit
optimistic
we're
going
to
move
those
out
to
July
of
next
year's
Bob
Brisco
here,
yes,
he's
here,
Bob
is
that
going
to
that
is.
Is
that
a
better
approximation
of
reality.
F
Right:
okay,
any
case
well
push
the
dates
out
out
of
July
and
there's
there's
positive
credit
for
getting
it
done
earlier.
Sctp,
not
support
is
Michael
Michael
focusing
back
there
somewhere
is
October,
so
reasonable
date.
I
think
it
is
yes,
okay,
good
transfer
options
are
UDP.
Packet
is
a
taxation
layer
path,
MTU
discovery
for
Datagram
transports.
Those
have
ND
your
milestones
to
look
plausible
telling.
F
That's
the
milestone.
Reviews
click
go
through
the
agenda.
You
are
in
currently
act
item
to
hear
a
gender
bashing.
We're
gonna
do
in
this
session.
The
lower
effort
pH
be
including
Berg
last
call
Datagram
path,
layer
and
Taxation
layer
path,
layer
and
view
discovery,
ipv6
packet
orientation,
a
couple
of
discussions
that
have
come
our
way
out
of
the
quick
working
group.
Jonna
young
guard,
wants
to
talk
about
with
transport
mechanisms
and
Magnus
has
some
quick
and
ECN
details
to
the
guide
us
through.
Hopefully,
we
won't
vote.
F
We
won't
get
lost,
wait
a
minute
interesting
there
you
go
transferred
header
encryption
impacts,
that's
Gouri,
Fairhurst
and
and
Colin
that
we've
talked
about
a
few
sessions,
we're
going
to
talk
about
our
adoption
and
then
TC
encapsulation
considerations
that
gets
us
to
the
break
after
we
trekked
plans
after
the
break
SCTP
drafts
are
the
two
drafts
that
we're
looking
at
that
that
are
in
them
that
are
being
dealt
with
here.
Knapp,
the
nat
support
draft
and
the
errata
draft
lesson
plans
for
the
this
RFC
4960
UTP
options.
F
L4
s
drafters
now
includes
a
fourth
draft
on
this
cert
on
diffserv
and
finally,
a
new
draft
proposing
a
new
idea
for
an
ipv6,
a
reservation
protocol.
So
that's
the
agenda.
Any
comments
going
once
going
twice
considered,
bashed
all
right.
So
Vincent
sent
along
this
slide,
Vincent
Roca
for
the
feck
for
the
two
drafts.
These
are
both
both
about
updating
the
forward
error
correction
framework.
We've
had
a
bunch
of
bunch
of
good,
solid
reviews,
aroun
groove
last
call.
A
number
of
things
happened.
J
Yes,
probably
I
have
a
few
things
to
update,
but
very
menial,
Corrections,
otherwise,
I
said
we
made
a
lot
of
modifications
to
this
document
during
this
previous
period.
We
clarified
what
this
parameter
duration
section
and
we
changed
totally
the
PNG
for
reasons
I
want
detail.
You
know,
I
mentioned
this
on
the
lists
and
I
also
did
a
presentation
during
the
energy
meeting
to
the
morning.
J
F
L
K
M
G
F
F
G
F
G
O
K
So
that's
a
that's
a
correct
one.
Thank
you.
Tim,
sorry
didn't
remember
my
own
RC,
a
number
of
cricket.
Okay,
so
yeah
the
changes.
There
were
some
suggestions
of
also
incorporating
the
scavenger
service
term
into
the
draft
in
order
to
that
people
find
it
by
googling
for
that
or
so
so.
I
added
also
some
more
history
just
putting
out
the
relation
to
that,
and
there
were
some
requests
from
David
I
guess
for
more
references,
edit
them
and
I
had
a
text
to
the
RTC
web.
Walk
us
draft
right.
K
K
What
I
didn't
address
so
far
was
Turlough
Secord's
comments
with
respect
to
multicast,
so
he
just
should
suggested
to
have
a
small
I,
don't
know
paragraph
or
section
about
the
problem
that
you
want
to
probably
avoid
replications
of
lower
F
or
pickets
too
busy
output
ports
so
that
packets,
don't
get
replicated
and
then
dropped
directly
afterwards
and
trellis
also
would
suggested
include.
The
keyboard
is
TCP
and
scavenger
in
the
document
title
I
also
didn't
do
that.
Maybe
there
is
support
for
that
and
I
can
do
anything
and
yeah.
K
We
need
to
need
basically
to
resolve
the
issue
with
the
draft
in
the
MS
roof.
Maybe
just
the
suggestion
for
updating
the
lado
RC
is
okay,
I,
don't
know
because
it's
maybe
too
far
and
in
the
process
right
now
and
so
I
try
to
submit
version
or
six
incorporating
any
open
issues
that
come
up
right
now
or
in
the
next
week.
K
A
Now
coming
to
me,
first
set
of
bullets
and
I
think
in
this
case
the
DHCP
and
scavenger
thing
is
well
worth
bringing
up,
because
we
were
replacing
something
which
is
rather
obscure
in
the
RFC
series.
So
we
really
need
to
be
clear
that
people
find
it
and
they'll
be
got
the
good
chance
of
people
actually
reading
this
rather
than
the
previous
thing,
so
I'll
be
good
right.
A
About
multicasts
I
think
it
would
be
good
to
include
something
of
multicast,
but
the
text
should
be
limited
to
if
you're
doing
multicast.
This
might
also
apply,
and
there
might
be
things
you
need
to
consider
to
prevent
going
wrong
and
I
would
just
leave
it
at
there
at
the
moment.
We
are
not
specifying
multicast
forwarding
here,
but
we
kind
of
a
specified
diffserv.
A
F
F
The
update
text
for
45-45-90
for
I
believe
the
path
forward
on
RTC
web
cross
is:
let's
go
and
write
the
before
and
after
text
that
we
want
to
see,
and
then,
after
the
iesg
approves
this
draft,
we
can
then
figure
out
what
to
do
if
not
an
easy
path
and
likely
path.
That
forward
is
that
our
aid,
our
ad,
asks
the
RFC
editor
to
go.
Make
that
change
please.
Okay,
so.
A
To
conclude-
and
this
draft
is
past
working
group
last
call,
if
you
have
additional
comments,
you
can
always
provide
them
on
the
mailing
list,
because
the
ITF
will
move
it
to
IETF
Lascaux
source
still
possible
to
comment.
Please
read,
but
we've
concluded
the
formal
working
group
last
column
we're
trying
to
finalize
this
document
and
please
prepare
new
rather
yep.
F
F
F
Q
It
works
hello,
I'm,
Tom,
Jones
planning,
our
draft
datagrampacket
ization,
lira
path,
MTU
discovery
which
I
don't
know.
Some
people
see
much
of
a
mouthful
by
seem,
okay
with
it
so
changes
since
zero
one
that
I
presented
London
the
zero
to
Rev
addressed
a
lot
of
the
comments
we
got
from
the
working
group
and
Magna
special
in
a
particular
from
that
we
updated
the
requirements
list
for
the
for
the
algorithm.
Q
We
added
a
figure
relating
packet
sizes
just
to
try
and
explain
what
all
of
these
different
terms
of
reasoning.
Are
we
updated
the
the
big
state
machine?
We
have
ok
so
since
year
one
we've
done
some
terminology
changes.
We
thought
the
term
effective
path.
Mtu
was
too
much
to
say
and
really
the
the
right
conclusion
from
the
the
DPR
PMT
UD
algorithm
is
the
PRP
MTU.
So
the
the
packetization
layers
estimate
of
the
path
MTU-
and
this
is
the
number
we
consistently
went
to
use
and
we
think
we've
called
them
and
we're.
Q
F
A
Author
and
the
terminology
is
messed
up
David
there
are
different
flavors
of
this
and
I
think
I'm
as
an
author.
What
I
would
propose
is
we
choose
a
term
very
clearly
and
we
explain
the
reference
to
the
other
terms
in
the
terminology
bit,
which
is
what
we've
now
tried
to
that.
Would
that
would
be
fine.
F
And
dandy,
I
just
would
like
it
to
be
that
someone
who
reads
this
draft
and
the
anti
area
tunnels
draft
doesn't
doesn't
see
the
same
term
used
to
use
to
refer
to
two
different
things
and
your
proposal
to
explain
what
all
attorneys
are
they
get
used
over.
An
entire
Eternals
is
an
excellent
idea.
We
think
we're
doing
that
now.
So,
okay.
F
S
Ron
Bonica
Juniper
Networks
yeah
in
in
the
int
area.
We
have
the
same
problem
that
we
do
many
drafts
that
talk
about
the
same
things.
Maybe
it'd
be
a
good
idea
to
abstract
the
terminology
and
put
it
in
a
separate
short
document.
Oh
yeah
hide
victim,
tear
myself
to
do
the
work
if
it
needs
to
be
done,
I
mean,
if
you
use
our
terms,
I'm
perfectly
happy.
Q
Q
We
spoke
to
both
these
people,
so
hopefully
we're
all
on
the
same
page
and
then
Timur
Volker
has
done
an
implementation
based
on
a
UDP
application
layer
and
he's
raised
similar
issues
with
terminology.
He
really
doesn't
like
the
past
tense
for
probes,
sighs,
I,
don't
know
this
as
a
German
thing,
and
and
so
we're
going
to
incorporate
these.
He
also
raised
some
issues
with
the
state
machine.
All
three
of
these
Comoros
greatest
issues
of
the
state
machine
and
most
people
do
okay.
So
we
react
into
the
questions
on
ptb.
Q
This
is
this
is
not
captured
in
rev
zero.
Three
but
we're
gonna
do
the
next
Rev
and
this
is
what
we
think
we
should
do
and
we'd
quite
like
feedback
up
if
this
is
actually
the
right
case.
So
if
we
get
a
PT
b
wherever
in
the
done
state,
we
should
reduce
down
to
our
safe
size
and
and
use
the
value
in
the
PTB
to
start
a
search
algorithm,
and
we
think
that's
a
nice
step.
Q
And
if
we
get
a
value
in
between
our
our
search
probe
size
and
our
estimate
of
the
path,
then
we
can
use
this
as
an
input
for
our
search
algorithm,
and
so
this
is.
This
is
what
we
think.
Hopefully,
people
will
come
and
argue
with
us
if
they
think
we're
wrong,
but
I
think
we're
quite
happy
with
this.
Now.
Q
You
know
once
that
thing
up:
okay,
quick
and
so
there's
there's
been
quite
a
lot
of
discussion
on
this
one
on
the
quick
list
and
we
think
quick
is
probably
a
protocol
to
capture
quite
there's
quite
relevant
for
the
draft,
and
so
I
I
did
work
at
the
hackathon
this
past
weekend
and
I
implemented
a
small
subset
of
the
algorithm
without
ICMP
handling
on
top
of
Moz
quick
and
the
conclusion
from
that
was.
This
is
entirely
possible
and
all
of
the
the
mechanisms
are
there
in
the
protocol.
Q
So
we're
happy
with
the
we're
quick
is
now
in
relation
to
our
protocol
to
include
text
and
and
swing
to
Magnus,
and
we
have
sort
of
thon
that
may
be
load.
Balancers
will
need
more
states,
so
they
can
handle
ptb
and,
as
I
understand.
Please
correct
me
if
I'm
wrong,
so
there's
there's
two
directions
for
connection
IDs
in
quick,
there's
a
source
and
a
destination
connection
ID,
and
we
think
any
quick
probes
that
are
going
to
go
to
load
balancers
will
need
to
carry
both
IDs.
Q
Q
Okay,
the
state
machine
we
have
right
now
is
is
very
big.
It
almost
does
not
fit
on
one
page
of
paper
in
an
ASCII
art
diagram
and
we
think
we
need
to
redesign
our
algorithm
around
some
core
components,
and
so
we've
identified
four
pieces
and
the
the
first
two
pieces
of
the
algorithm
are
the
gross
phase
where
we
are
trying
to
grow
and
discover
the
the
actual
PRP
MTU
of
the
path.
Q
You
big
handling-
and
we
think
these
are-
are
the
the
core
pieces
that
we
can
describe
separately
and
then
integrate
together
into
the
fool
algorithm
and
where
we're
gonna
update
the
document,
hopefully
for
a
September,
and
we
will
Rev
the
spec
around
this
and
then
there
are
two
more
states
and-
and
so
there's
this
error
state
that
I
alluded
to
where
that
we're
getting
just
really
strange
stuff
from
the
network
and-
and
we
think
we
know
what
to
do
about
that.
But
it's
probably
gonna
be
quite
contentious.
Q
Text
to
write
I
can
I
can
see
who
I'll
be
arguing
with
and
then.
Finally,
we
have
this
discussion
about
robustness
and
resilience
in
search
and
when
we
deal
with
inconsistent
network
state,
and
so
we
really
need
some
real-world
information
to
feed
into
this
discussion.
So
we
can
do
detection
of
weird
broken
network
paths
and
so
that
we
can
do
the
right
thing
and
we're
gonna
work
towards
this
for
for
a
November
and
okay,
and
that
is
me
and
I
will
take
questions.
T
Iger
Omaha,
so
first
thanks
for
working
with
us
to
improve
this
suggestion
for
error
states.
The
way
I
would
think
about
it
and
your
error
state
that,
typically
due
to
PT
B,
that's
claiming
something
that
shouldn't
be
the
case
in
the
network.
I
would
probably
just
equate
it
to
ICMP
that
comes
and
says
things
like.
Basically,
network
has
broken
the
destination
unreachable
and
asked
to
treat
the
error
state
just
like
what
you
would
do
in
case
of
those
those
packets,
yeah.
T
F
A
Corey
fast,
as
an
author
again
and
one
of
the
arrows
states,
which
is
actually
meaningful,
is
when
your
application,
so
it's
gonna
send
1000
bytes,
that's
the
minimum,
and
then
your
error
state
says
the
only
workable
thing
is
576,
and
you
know
that
ipv4
actually
supports
that
as
a
smaller
number
and
your
application
kind
of
wants
to
go
there
if
it
really
has
to.
But
it
doesn't
want
to
drop
back
unless
it's
explicitly
told
that
the
other
one
doesn't
work.
A
A
A
A
U
Q
V
S
Thank
you,
Ron
Bonica
Juniper
Networks
I'd
like
to
talk
about
this
draft,
that's
going
on
in
the
six
men
working
group
and
also
about
a
recommendation
that
we
got
from
the
TSV
working
group
about
how
to
change
it.
Maybe
talk
about
that
change
a
little
bit
more
and
you
know
if
we
all
agree
on
it.
I'll
make
the
change
in
the
next
grab
of
the
draft.
S
Okay,
ipv6
allows
for
fragmentation
at
the
source.
Only
so
source
source
nodes
have
a
choice.
They
can
either
refrain
from
sending
packets
greater
than
1280
bytes,
which,
incidentally,
is
what
they
all
most
of
them
do
these
days
or
they
make
it
can
maintain
a
running
estimate
of
the
PM
to
you
and
refrain
from
sending
packets
that
are
large
larger
than
that
estimate
and
they've
got
two
tools
to
do
that.
One
is
PM
PM
tud,
the
other
PL
PM
tud,
now
called
DP
LM.
S
Okay,
a
second
to
talk
about
how
PM
PM
tud
works.
The
source
produces
an
initial
estimate
of
the
PM
to
you
and
that
initial
estimate
is
normally
the
MTU
of
the
first
hop
along
the
pass.
That
estimate
may
be
larger
than
the
actual
PM
to
you.
Then
the
source
starts
sending
packets,
the
packets
are
never
larger
than
the
PM
t.
S
You
estimate,
but
they
may
be
larger
than
the
actual
PM
to
you
when
a
packets
larger
than
the
actual
PM
to
you,
the
intermediate
node
that
can't
forward
the
packet
drops
it
and
sends
an
ICMP
PT
b
to
the
source,
and
if
that
message
reaches
the
source,
it
updates
its
PM
t.
You
estimate,
and
everything
is
fine.
That's
if
the
ICMP
PT
b
reaches
the
source.
S
Now
that
we've
talked
about
how
PMT
UD
works,
let's
talk
about
how
it
breaks
well,
sometimes
that
ICMP
ptb
can't
make
it
back
to
the
source,
and
there
are
a
bunch
of
reasons
why
the
most
common
is
a
poorly
implemented.
Firewall
rule
lots
of
consumer
CPE
will
not
allow
the
ICMP
message
in
because
it's
coming
from
an
unknown
source,
a
source,
that's
in
the
middle
of
the
network.
There
are
other
reasons
too,
but
we
don't
need
to
get
into
that
for
the
purpose
of
this
presentation.
S
In
any
event,
when
this
happens,
the
ICMP
PT
UMS
ptb
message
does
not
make
it
to
the
source.
The
source
does
not
update
its
PMT.
You
estimate
and
a
persistent
black
hole
occurs.
So
this
is
how
PMT
UD
breaks.
So
we
need
some
new
procedures
and
let's
talk
about
what
those
new
procedures
are,
an
upper
layer
protocol
is
emitting
a
packet
and
it
marks
that
packet
as
being
truncation
eligible.
S
S
The
destination
node
sends
an
ICMP
message
back
to
the
source,
and
the
assumption
here
is
that
the
ICMP
message
from
the
destination
node
is
more
likely
to
make
it
to
the
source
than
an
ICMP
message
that
originated
somewheres
in
the
middle
of
the
network.
It's
more
likely
to
get
around
that
misconfigured
firewall,
it's
more
likely
to
not
have
the
anycast
problem
that
we
referred
to
in
the
last
slide.
S
So
let's
talk
a
little
bit
about
mechanics.
How
do
we
do
this?
Well
to
mark
a
packet
as
being
truncation
eligible?
We
have
a
new
destination
option,
called
the
truncation
eligible
option
and
to
mark
a
packet
as
having
been
truncated
and
still
be
eligible
for
further
truncation
by
another
downstream
node.
S
Let's
talk
about
what
the
truncation
eligible
packet
looks
like
it
has
right
now.
It
has
two
fields
in
it
and
there's
a
proposal
from
this
working
group
to
add
a
field.
There's
an
option:
type,
that's
TBD
by
iana.
It
indicates
that
it
is
the
truncation
eligible
the
first
two
bits
of
that
packet
indicate
what
a
destination
node
should
do
if
it
receives
the
option-
and
it
does
not
understand
it,
and
in
this
case
it
should
just
skip
over
the
option.
The
packet
was
truncation
eligible.
It
was
not
truncated,
it's
all
irrelevant
just
skip
over
it.
S
S
S
It's
action
is
to
discard
the
packet
and
send
an
ICMP
parameter
problem
message
and
again
the
change
bits
are
irrelevant
because
there's
no
option
data
so
summarizing
quickly,
source
node
procedures,
it
emits
a
packet
with
a
truncation
eligible
option,
destination,
node
procedure,
the
intermediate
node
attempts
to
forward
a
packet
and
encounters
an
MTU
issue.
If
the
packets
eligible
for
truncation,
you
truncate
it
and
mark
it
for
truncation
and
forward
it.
S
If
the
packet
isn't
eligible
for
truncation,
you
do
what
you
do
today:
drop
the
packet
and
send
an
ICMP,
that's
for
backwards,
compatibility
at
the
destination
node.
If
you
receive
a
packet,
that's
truncation
eligible
and
it
hasn't
been
drunk
ated
just
deliver
it
to
the
upper
layer
protocol,
there's
no
special
action
to
take,
but
if
it
receives
a
packet
that
has
been
truncated
and
it
recognizes
the
option,
send
an
ICMP
to
the
source.
Node
and
the
ICMP
MTU
reflects
the
length
of
the
packet
by
default.
S
You
discard
the
packet,
however,
the
upper
layer
protocol
can
register
for
delivery
of
the
truncated
packet.
Now,
one
thing
that
it
can
do
is
take
the
packet
it
realizes
that
the
stream
has
been
corrupted,
because
that
truncated
packet
options
there
and
it
might
just
use
the
metadata
it
might
use
the
metadata
to
say.
Oh
I,
know
now.
I
now
know
the
PM
to
you
between
the
source
and
myself.
Maybe
I'll
use
that
to
signal
at
layer
four,
what
the
MSS
is,
so
it
might
be.
S
The
metadata
might
be
useful
by
the
way
if
the
destination
receives
a
truncated
packet
and
it
doesn't
recognize
the
option,
it's
obliged
to
drop
the
packet
and
send
an
ICMP
program
at
a
problem,
so
you
won't
try
to
keep
truncating
packets
now.
What
are
the
benefits
of
truncation?
It
allows
you
to
use
larger
m
to
use
at
very,
very
least
that
fixes
the
PM
to
you
PMT
you
deep
problem.
It
might
also
provide
some
tools
that
upper
layer
protocols
can
use
to
learn
the
PM
to
you
without
relying
on
ICMP
at
all.
S
S
M
S
S
Now
it
is
very
likely
to
be
truncated,
it's
truncated,
downfield,
so
the
option
type
is
over
overwritten
with
the
truncated
packet
option.
Now
you
get
to
the
destination,
the
destination
looks
at
it
and
says:
oh,
this
was
a
padded
packet
and
it
was
truncated.
You
can
tell
whether
all
of
the
useful
data
made
it
or
not.
S
If
all
the
useful
data
made
it
you've
learned
the
PM
to
you
and
you
have
all
the
useful
data
if
all
the
useful
data
didn't
make
it
well
you've
at
least
learned
the
PM
to
you
and
you
throw
away
the
data
you
have
as
if
the
packet
had
been
picked
up
so
anyhow.
My
questions
for
the
working
group
first
is
the
work
interesting.
Without
that
extra
padding,
tweak
that
has
been
recommended-
and
second
is
the
padding
tweak,
interesting,
hey.
S
S
S
O
T
I
think
well,
if
the
packet,
actually
truncated
packet,
does
get
to
the
destination.
Now
it's
a
big
if
I
think
it's
interesting
because
for
TCP
the
upper
layer
actually
can
use
way
more
than
just
metadata
because
effectively
you
got
maybe
big
n
minus
small
Delta
of
the
actual
data
that
doesn't
need
to
be
retransmitted.
It
can
be
act
so
that
that
is
useful.
T
The
question
is:
there
is
a
premise
that
ICMP
from
the
destination
is
more
likely
to
reach
the
source,
the
source
and
for
any
car
that
seems
plausible,
but
for
other
reasons,
I
think
it's
basically
needs
to
be
tested.
Did
you
do
any
any
sort
of
tests
for
measurements
to
see
if
the
same
kind
of
ICMP
send
by
the
source
is
more
likely
to
reach?
Yes,.
S
We
know
of
a
common
bug:
that's
in
consumer
CPE.
What
they
will
do
is
allow
a
packet
to
come
in
only
if
you've
sent
a
packet
to
the
same
address
out
recently.
Well,
if
you've
sent
a
packet
and
the
ICMP
comes
from
the
destination,
it
will
get
past
that
firewall.
If
it
came
from
an
intermediate
node,
it
won't
now
grant
that
this
is
a
bug
in
the
CPE.
Q
Q
T
Q
S
X
S
U
U
A
A
Q
Need
to
lunch
yeah,
so
the
suggestion
is:
there's
there's
two
lights:
there's
the
the
the
length
of
the
total
IP
diagram
and
there
was
a
length
carried,
which
is
the
original
size
of
the
Datagram
before
any
padding
is
added.
And
so,
when
you,
when
you
get
these
you
can
you
can
strip
away
until
you
have
the
original
IP
Datagram
again,
but.
S
U
So
in
the
case
of
STP,
we
have
petting
chunks
and
we
can
add
that
and
we
can
reconstruct
the
packet
structure
if
we
would
ignore
the
checksum
and
if
I
would
do
this,
for
I
would
only
do
this
for
pro
packets,
where
I
know
oh
I
don't
want
to
date.
It
transfer
data
with
it.
So
I
just
need
to
verify
this
belongs
to
an
association
and
which
number
are
you
so
I
could
live.
For
that
case,
the
wrong
checksum,
okay,.
G
S
Basis
only
when
the
packet
cannot
be
forwarded
because
you've
hit
an
MTU
issue.
Now
there
is
precedent
for
doing
that.
The
precedent
decided
in
the
draft
and
it
happens,
there's
an
option
called
the
encapsulation
max
and
I
forget
the
RFC
that
does
it,
but
there
it
there
is
one
other
RFC
in
which,
on
an
exception
basis,
you
go
all
the
way
to
the
end
of
the
destination
options.
S
G
Okay.
Second
question
second
comment:
you
referred
to
net
based
firewalls
as
walking
doing
its
own
based
defense.
I,
don't
know
very
many
actual
nets
in
the
world.
Most
of
them
are
napped,
and
so
you
find
yourself
looking
into
a
UDP
or
TCP
header.
Looking
for
a
I
I,
never
said
anything
about
NAT
based.
You
said
that
broken
CPE
equipment
looks
for
address
pairs.
Yes,
yeah
address
pairs
are
napped.
I
S
Y
You
start
out
with
truncation
eligible,
which
is
destination
option
and
somewhere
along
the
line.
When
something
bad
happens,
you
get
truncation
happened.
What
happened
to
the
are
not
modified
extension
headers
are
not
modified
or
removed,
or
added
or
deleted.
Obviously
this
is
the
stretch,
so
so
I've
got
post,
iesg,
review,
stress
disorder
and
there's
no
support
meeting
this
time.
S
C
S
The
precedent
we
have
precedent
for
looking
beyond
for,
on
an
exception
basis,
looking
at
the
destination
at
some
place
other
than
the
destination
option,
someplace
other
than
the
destination
precedent
for
overwriting,
an
option
type
well
yeah.
We
do
it,
but
only
on
this
crazy
exception
basis
when
you've
already
gotten
off
the
forwarding
path,
and
it's
a
case
where
you
would
have
dropped
the
packet
anyway.
S
A
H
It
was
just
on
this
incremental
deployment
thing.
It's
got
to
have
some
way
of
people
wanting
to
do
this
without
the
packet
being
likely
to
be
lost,
and
so
you
know
something
like
a
bi
balls
would
help.
But
I
was
just
just
looked
up:
RFC
78
72,
which
is
statistics
on
drop
of
the
distillation
option,
and
it's
between
12
and
17
percent
yeah,
and
even
if
this
Reuter
supported
it
the
first
all
the
route
is
up
to
where
you
wanted
to
deal
with
your
support
of
it
is.
A
S
Things
here
we
actually
talked
about
that
in
the
draft.
The
very
first
thing
you
have
to
do
is
see
if
you're,
on
of
one
of
those
10%
of
the
paths
and
that's
why
there's
another
draft
called
draft
Bonica
unrecognized
destination
option
or
you
have
a
special
destination
option
that
if
it
makes
it
through
we'll
send
you
an
ICMP
message
and
if
it
doesn't
make
it
through
we'll
send
you
silence.
Uh-Huh
thanks,
Ron
I.
A
W
T
B
B
Can
use
this
right?
Wonderful,
so,
very
briefly,
the
premise
of
the
draft
is
this:
quicks,
transport
or
general
transport
machinery
is
different
from
DCPS
in
in
some
in
subtle
ways
and
some
in
glaring
ways,
but
for
instance-
and
this
is
not
an
exhaustive
list,
but
it's
the
list
that
I
could
come
up
with
send
order.
N
quick
is
separable
from
delivery
order
in
quick.
This
is
not
so
in
TCP,
the
sequence
in
sequence,
number
is
used
for
both
send
order
and
for
delivery
order,
and
that
causes
all
kinds
of
hurt
in
pain.
B
In
quick
delivery
order
is
with
streams
and
stream
sequence
numbers,
whereas
end
order
is
uses
a
packet
number
and
we
explicitly
chose
to
call
it
packet
number,
instead
of
sequence,
number
two
avoid
conflating
the
concepts
of
sequence
number
in
TCP,
with
that
of
packet
number
in
quick-quick,
has
moronically
increasing
packet
numbers.
What
this
means
specifically,
is
that,
if
there
is
a,
if
there
is
data
that
is
retransmitted,
the
packet
number
on
the
packet
is
not
the
same
as
what
it
was
earlier.
It's
a
new
packet
number
that
is
still
increasing.
B
This
is
a
pretty
significant
and
a
pretty
big
difference
from
TCP
again
in
terms
of
how
we
think
about
the
mechanisms
there
is
no
retransmission
in
quick.
There
is,
there
is
death,
there
is
no
packet
level
retransmission
in
quick
stream.
Data
can
be
rebuttal
and
sent
again
in
a
new
packet,
but
the
new
packet
just
gets
a
new
packet
number,
and
that
goes
along
just
fine.
That
way.
B
Acknowledgments
use
this
monotonically
increasing
packet
number,
of
course,
and
the
receiver
explicitly
states
actally
instead
of
inferring
how
long
the
receiver
of
sitting
on
an
ACK
before
sending
it.
That's
explicitly
stated
in
the
ACK
and
again
there's
there's
sort
of
a
fiddly
bit,
which
is
that
we
do
not
use
a
cumulative
ACK.
B
We
use
the
largest
technology
which
is
sort
of,
if
you
think
of
it,
it's
sort
of
the
the
right
edge
of
what
you
would
receive
your
receiving
sacks
right
and
not
the
left
edge
of
the
of
what
you
believe
has
been
received
at
the
receiver
and
ECM
signaling
is
quite
different
and
you'll
hear
more
about
that
in
the
next
presentation
that
Magnus
is
doing
so.
Loss,
detection
and
congestion
control
use
all
of
these
signals,
and
these
signals
are
quite
different
in
quick
than
from
TCP.
So
how
does
loss
of
diction
and
condition
control?
B
How
do
they
look?
Well?
They
are
same
but
different.
So
that's,
basically
what
it
is.
We
have
fast
retransmit.
We
have
early
retransmit.
We
have
time-out
that
looks,
look
the
same,
but
they're
just
slightly
different
here
and
there
and
in
some
places
significantly
and
it's
confusing.
When
you
see
it
because
then
you
go,
this
I
thought
this
work
this
way,
but
it
doesn't
in
addition
to
those
differences
in
just
the
mechanisms
themselves.
Because
again,
like
said,
we
have
these
signals
that
are
different.
B
We've
introduced
some
other
elements
like
an
early
retransmit
timer,
which
is
there
in
Linux,
but
not
there
in
the
standard,
not
there
any
any
any
RFC
RNA
draft,
we
used
a
loss
probe,
which
is
an
expired
draft.
Somebody
should
really
pick
it
up
and
run
with
it
for
TCP,
but
we
have
those
things
baked
into
the
loss.
Recovery
draft
in
quick
and
those
are
a
part
of
it
again
because
of
the
difference
in
signaling.
We
have
a
completely
different
spurious
time
out
detection
technique
than
fr2
you.
B
It
covers
previous
time
out
detection,
but
it's
sort
of
hidden
and
those
are
all
things
that
are
in
the
in
the
mechanisms:
congestion
control
we
specified
in
the
draft.
We
specified
nearly
no
in
the
draft
for
quick,
but
we
use
again
larger
signal
acknowledged,
install
the
cumulative
ACK
for
a
recovery
period.
This
in
practice
turns
out
to
be
quite
an
important
difference,
because
TCP
ends
up
staying
and
recovery
for
much
longer
than
quick
does
so
again.
These
are
just
I'm
just
touching
on
things
it's
not
to
get
into
the
details.
B
Here
we
are
doing
a
bunch
of
editorial
work.
We
will
be
adding
a
lot
more
rational
and
clarifying
the
mechanisms
in
the
draft
over
the
next
few
months
and
I
am
hoping
to
present
it
in
much
more
detail
here
or
TCP,
M
or
TCP.
This
V
area,
maybe
probably
Bangkok,
but
I-
want
to
give
a
heads
up
to
this
community.
If
you,
if
you
are
interested,
go,
read
the
draft
and
provide
feedback
I'm
happy
to
discuss,
we
will
like
I
said
we
are
doing
a
bunch
of
work
on
it.
So.
A
Curry
first
I
have
to
accept
the
blame
for
inviting
you
here
and
we
can
have
comments
at
the
mic,
but
we
are
not
going
to
discuss
the
quic
protocol
functions
here
because
that's
the
quick
working
group
so
if
you've
got
protocol
stuff
on
all
this
discussion,
join
the
quick
mailing
list
tell
someone
in
quick
deal
with
it
on
quick,
but
it's
good
to
talk
about
it
here.
So
thanks
John
for
doing
that
Randall.
Would
you
like
Stuart.
Q
U
B
Could
I
mean
in
in
in
theory
so
effectively
quick
loss?
Recovery
is
covers
rack
again,
as
the
mechanisms
are
different,
because
the
protocol
itself
is
different,
but
it
effectively
is
rack.
So
rack
uses
time
based
things
right,
so
when
you're
doing
retransmissions,
for
example,
it
helps
quite
a
bit
because
now
you're
looking
at
time
from
transmission
rather
than
the
actual
packet
number
as
it
turns
out,
because
packet
numbers
are
monotonically
increasing
in
quick.
That
actually
gives
you
time
ordering
directly.
B
So
we
don't
need
to
look
at
time
ordering
outside
of
sequence
numbers,
because
the
packet
number
itself
gives
you
time
ordering.
In
addition,
if
you
want
to
look
at
the
time
from
packet
sent
to
do
the
reordering
thing,
that
rack
does
we
have
that
also?
So,
yes,
it
covers
rock
effectively
it's
on
a
rack
for
quick,
but
it's
covered
in
quick.
N
Just
simple
creation
question
I
think
when
this
is
recovered,
rock
has
initiated
I,
stick
it
in
initial
design.
He
rose
up
is
something
like
you
know.
Using
random.
You
are
now
is
famous
with
deviating
it's
trying
to
how
come
as
a
design
new
congestion
control
based
on
new
Reno,
but
it's
better
than
in
Reno.
Is
that
the
current
the
design
principle
I
would
say
that.
N
B
So
the
so
the
launch
detection
mechanisms
can
be
slightly
different
than
what's
in
the
standards
and
that's
where
rack
comes
in.
So
this
is
more
PC
P
plus
rack
+
PL
PE,
which
is
also
in
rack
+
earlier
transferred
timers,
which
is
not
in
any
other
document.
That's
the
last
detection
part
on
the
condition,
control
side.
We
basically
quit
simple
plain
Yuri,
no,
but
just
modified
it
for
the
protocol.
Things.
B
Can
so
one
thing
I
will
note,
is
that
quick
again
allows
for
a
receiver
to
send
acknowledgments
less
frequently,
then
every
two
packets
and
we
absolutely
intend
to
exercise
that
freedom?
We
are
right
now
we
are
trying
to
figure
out
how
to
how
to
do
this
right
so
that
the
congestion
control
doesn't
suffer.
We've
done
some
experiments
with
this,
but
we
need
to
have
a
good
signaling
mechanism
from
the
receiver
to
the
sender
to
say,
or
the
sender,
to
the
receiver
to
see
how
frequently
this
and
their
needs
the
receiver
to
signal,
send
acts
back.
N
A
Maybe
I
can
help
with
the
question
here.
I've
got
a
question
to
the
people
here,
and
many
of
the
people
here
will
be
familiar
with
transport
protocols
and
their
interaction
with
the
Internet.
If
what
he
heard
from
Janet
sounded
good,
and
you
would
think
you'd
be
valuable
to
find
out
more
of
an
introduction
about
this,
so
you
could
actually
comment
on
the
quick
mechanisms.
Could
you
just
raise
your
hand
if
you
think
that
introduction
would
be
something
useful
for
us
to
try
and
arrange.
A
AA
AA
Okay,
so
let's
start
summary
of
the:
what's
actually
went
into
the
into
quick:
now:
listen,
so
it's
packets,
with
any
type
of
easy
n
marking,
is
acknowledged
in
a
special
act
for
a
key
cm
frame
and
it
has
counters
for
marking
them
for
the
different
parking
types.
If
you
get
an
easy
NC
mark,
you
send
an
immediate
a
Kia
been
increased
counter.
So
that's
how
you
do
send
the
notes
that
you
get
you
can
use
to
mark
in
congestion,
indication
its
per
Direction
verification
of
ECT
capability
of
the
path
and
the
receiving
host
stack.
AA
So
it's
both
p.m.
you'd
verify
both
that
you
can
send
this
here
and
ect
marks,
receive
easy
and
related
markings
on
the
receiver
side
and
report
them
back
so
that
you
shaking
each
all
of
this
functionality,
both
at
starter
connection
and
the
any
connection
migration
happens.
If
you
get
any
if
the
receiver
Allah
C
is
not
easy
T,
it
will
act
back
and
regular
RAC
frame
and
that's
why?
How
you
separate
the
two
types
to
cope
with
any
kind
of
path
changes,
anything
else
that
will
screw
up
the
ECT
capability.
AA
You
actually
do
a
continuous
verification
of
the
balance.
You
see
that
the
number
of
received
and
act
packets
is
correspondent
by
similar
race
in
the
counters,
and
if
it's
something
happening,
then
you
stop
sending
so
do
not
get
for
false
benefit
of.
Is
he
marks
like
when
you're
not
responding
to
them
the
markings
when
it
comes
to
ECM
black
hole
mitigation?
There's
some
description.
AA
What
you
could
do,
for
example,
if
you
get
the
retransmission
time
out
during
connection
establishment,
you
could
retransmits
without
ECT
marks
as
a
way
of
ensuring
that
you
don't
go
into
primary
connection
failure.
But
there
is
quite
a
lot
of
implementation.
Freedom
around
this
black
hole
mitigation.
How
we
would
do
it,
you
could
mark
7%
your
package
or
anything
in
the
stats,
but
it's
up
to
you
as
an
implementer
in
this
case,
so
the
next
slide.
AA
There's
one
about
potentially
optimizing
yak
formats,
that's
might
happen
or
not,
but
it's
at
least
ongoing
discussions
around
that.
The
continuous
verification
and
applause
handling
this
actually
been
addressed
with
one
in
one
way
currently
is
that
issue
has
actually
been
closed,
but
it's
something
that
resulted
in
tax
changes
coming
out
in
the
next
version.
It's
in
merchants
master.
Currently
they
also
need
around
detecting
Lion
receivers
so
and
based
on
these
issues,
and
some
I
have
some
kind
of
high-level
questions
or
issues
that
came
up
around
this,
which
will
go
into
I
know.
AA
We
don't
have
time
to
go
through
all
of
them,
but
we'll
see
how
far
we
get
depending
how
much
feedback
I
get
so
next
slide.
So
one
thing
that
came
up
was
that
there's
this
potential
attack,
which
is
for
if
B,
is
having
a
session
with
C
and
you
have
an
attacker
a
which
is
on
the
side,
but
he
gets
a
copies
of
some
or
all
all
the
packets
that
goes
between
B
and
C.
AA
So,
therefore,
we
only
reports
the
first
packet
of
any
duplicated
packets
that
arrives
at
the
receiver,
so
there's
some
risk
of
missing
in
legit
marking
that
happened,
downs
downstream,
so
to
say
of
the
where
the
packets
get
supplicated
but
and
it
could
result
in
a
slightly
delayed
congestion
response.
But
I
think
this
is
a
trade-off
where
same
straight,
for
for
now
at
the
moment
to
be,
but
people
have
a
penis
it
is.
It's
you're
welcome
to
comment
on
this
etcetera.
AA
You
know
okay,
yeah
next
slide,
so
another
thing
which
this
has
really,
but
this
may
be
looking
at
other
ways
of
doing
the
acknowledgement.
Formant
is
well.
We
see
actually
see
easy
to
zeros
and
easy
to
once
mixed
in
one
packet
flow.
Now
that
we
don't
have
any
kind
of
you
seen
on
style,
use,
etc,
and
also
and
this
access
to
do
with,
can
we
assume
one?
AA
That's
my
understanding
with
the
whole
thing,
and
you
wouldn't
see
alternating,
but
so,
and
if
you
actually
see
alternating,
you
probably
need
to
have
some
dual
controller
states
etc
to
deal
with
the
different
treatments
from
the
net,
which
is
likely
to
arise
from
having
two
different
coupons.
So
David.
F
H
T
H
Doesn't
make
judgments
as
to
what
might
come
in
the
future,
because
you
know
what
Dave
was
talking
about
is
current
experimentation,
but
the
future
is
very
long
time
and
and
however,
there
is
also
the
question
of
how
how
quickly
quick
deployment
is
compared
to
yeah
TCP,
because
in
TCP
we
assume
that
things
take
a
very
long
time
to
change.
And
so
you
want
a
dumb
reflector
at
the
receiver
so
that
senders
can
unilaterally
upgrade
and
just
expect
things
to
be
reflected
back.
But
it
may
be
a
different
question
music.
So.
AA
I
I
mean
even
quickcast,
mostly
the
same
kind
Adam
report
reporting
back
for
the
Seas,
it's
more
sequest.
This
was
mostly
from
a
perspective.
If
you
make
an
assumption
that
you
mostly
you,
expect
to
see
one
of
those,
you
could
actually
optimize
the
report
informant
to
see
that,
and
then
you
have
only
summers
exception
indicators
that
oh
I
see
something.
I
wasn't
expecting,
oh
good.
If
this
is
only
about
optimizing
reporting
format,
just
don't.
H
A
B
Jenna
and
does
there's
a
slight
difference,
though
the
optimization
is
not
it's
not
just
an
optimization.
It's
also.
What
being
able
to
reflect
something
accurately
so
in
in
in
quick,
the
AK
format
itself
is
actually
quite
extensive.
It's
expensive
in
the
sense
that
you
can
have
a
large
number
of
packets,
that
I,
acknowledged
and
large
number
of
gaps
are
acknowledged
and
there's
a
particular
format
that
that
is
currently
being
used.
So
the
question
part
of
the
question.
T
B
B
A
V
Z
V
AA
AA
I
think
we
have,
you
can
go
on
to
the
next
slide.
If
so,
yes,
and
then
this
we're
gonna
be
the
last
one,
so
detecting
heating
receptors
receivers
so
I
mean
this
is
the
only
point
that
a
receiver
here
could
ignore
to
report
a
see
mark
for
the
benefit
of
saying
I
will
grab
a
bit
more
ballast
and
on
the
other,
flow
stats
are
following
and
reporting
correctly
if
they're
sharing
both
liquid,
multiple
suppose,
that's
the
kind
of
assumption
there.
AA
AA
The
question
around
that
was
basically
the
problem
should
be
some
limit
limitations.
There
I
mean
okay.
If
you
send
this
very
infrequently,
it's
it's
definitely
find
its,
but
it
shouldn't
be
sent
to
frequently
because
it
might
hide
true,
see,
marks
but
I
guess
some
common
rule.
If
you
send
it
every
number
of
hundred
packets
you'd-
probably
not
really
hide
it
as
much
so,
but
if
anyone
has
any
more
in
PI
yeah
staying
about
this
go
ahead.
H
AA
AA
H
A
X
A
That
comment,
Mike
Ramiro,
was
the
reason
why
Magnus
is
here,
because
I
looked
at
that
and
I
said
AHA
we're
going
to
do
this
for
quick.
We
should
talk
about
this
for
the
whole
community,
because
it's
a
way
of
using
easier.
So
it
should
come
here
to
have
a
little
bit
of
a
discussion,
at
least,
but
for
everything
for
this
I
think.
T
F
T
F
X
AA
H
H
Actually,
you
could
have
a
time
before
you
apply
with
the
seee
cuz
if
you're
doing
stretch,
acts
there's
no,
not
necessarily
any
need
to
to
respond
to
each
Cee,
because
you
may
be
getting
a
lot
of
them
and,
and
you
only
need
to
wait
a
certain
amount
of
time
and
then
report
how
many
you've
received
you
don't
actually
need
to
go
discuss
this
on
the
mailing
list.
It
will.
V
V
So
the
the
the
point
of
this
draft
right,
we're
beginning
to
see,
transfer
protocols,
of
which
quick
is
the
the
the
prime
example
which
do
end-to-end
encryption
and
the
integrity
protection
of
the
transport
layer
headers.
So
things
like
the
sequence
numbers
and
their
equivalents.
This
obviously
has
some
implications.
It
has
some
implications
for
the
way
we
build
transport
protocols.
It
has
some
implications
for
the
way
people
build
network
monitoring,
equipments,
which
tends
to
look
at
the
sequence
numbers
to
CS.
This
packet
loss
entering
Firth
round-trip
times,
and
things
like
that.
V
V
In
addition,
we've
expanded
all
the
various
introductory
remarks
about
the
ossification
and
the
reasons
for
encrypting
the
transport
layer
headers
as
a
way
of
preventing
ossification
and
added
some
notes
about
the
implications
for
accountability,
network
neutrality
and
the
like,
and
again
we're
trying
to
do
this
in
a
neutral
way
to
avoid
advocating
for
any
particular
side
and
just
just
factually
document.
What's
going
on
next
slide.
V
In
addition,
we've
actually
written
a
sensible
security
consideration
section
for
the
draft.
This
mostly
talks
about
the
implications
on
avoiding
ossification
versus
exposing
information
to
the
network.
The
ability
of
preventing
various
sort
of
data
data
injection
attacks
and
the
like,
primarily
given
the
nature
of
the
draft.
This
is
sort
of
summarizing
and
elaborating
summarizing
on
the
issues
which
we
then
elaborate
on
in
much
more
detail
elsewhere
in
the
draft
next
slide.
V
V
We
think
it's
useful
to
try
and
take
a
step
back
a
little
from
the
actual
ongoing
standardization
of
quick
and
reflects
a
little
about
the
broader
lessons
from
the
development
and
deployment
of
these
protocols
and
try
and
try
and
learn
some
of
the
more
general
lessons
up
about
it
and
think
about
how
they
apply
to
future
protocols
network
operations.
The
way
we
do
things
in
the
ITF
and
that's
the
sort
of
thing
we're
trying
to
get
across
in
this
draft.
V
Accordingly,
we'd
like
to
ask
this
working
group
to
consider
adopting
it
as
a
working
group
draft,
we
can
get
in
pretty
good
shape
and
we
think
topic
is
important.
So
if
there
any
comments,
I'd
be
very
well.
Very
happy
to
receive
them
and,
as
I
say,
I'd
like
to
request
the
group
consider
adopting
this
as
a
work
item.
Ok,
Jenna.
V
B
Of
that,
so
thank
you
for
presenting
this
I
haven't
read
the
draft
in
in
detail,
but
I've
seen
it
in
previous
iterations
and
yeah,
and
definitely
intend
learning
to
read
it.
I
wanted
to
say
that
it's
it's
good.
It's
very
good
to
see
the
ossification
text
show
up
in
the
introduction,
because
that
was
in
big
part.
One
of
the
motivators
for
actually
encrypting
most
of
the
header
was
instruct
the
ossification
that
we
have
seen.
It
might
be
very
useful
to
actually
list
out
some
of
those
things
that
we
are
suffering
right
now.
B
F
B
B
Something
that
quick
has
done.
This
might
be
a
useful
thing
to
do
like
we
have
gone
through.
The
considerations
that
are
in
this
document
it'd
be
useful
to
make
sure
that
the
people
who
are
who
are
proponents,
not
proponents,
but
the
editors
of
the
quick
working
group,
people
who
have
been
talking
about
introducing
network
signalling
into
quick
all
of
them
have
a
look
at
this
and
make
sure
that
their
points
of
view
have
been
represented.
If
all
of
that
can
be
done,
yeah
I
think
it
might
be
useful
thing
to
have.
Thank
you.
L
L
One
question
so
like
there
was
a
very,
very,
very
long
process
that
went
over
sore
the
encrypt
draft,
which
this
one
refers
to,
which
was
sort
of
a
more
general
arrangement.
I
think
the
that
we
learned,
we
learned
some
things
in
that
process
and
I
think
reflected
here.
How
do
you
see
this
draft
sort
of?
How
do
you
see
the
positioning?
This
draft
with
respect
to
the
wire
image
in
past
signals
drafts
that
we
talked
about
in
TSP
area?
L
Do
you
see
is
compliment
or,
like
I
mean
they
talk
about
easily
about
the
same
things,
but
is
it
I
mean?
Is
there
something
we
should
be
doing
together
on
these
or
it's
just
like
hey?
These
are
different
groups
that
have
different
viewpoints
in
different
opinions.
I
mean
it
turns
out
people
into
the
same
thing,
but
it's
suddenly
similar
issue.
V
L
A
I
A
This
document
is
well-written,
it's
going
to
indicate
there
are
giants
over
here.
There
are
giants
over
there.
There
are
good
things
over
here,
good,
but
no
real
guidance,
probably
because
we
don't
yet
have
the
audience
we
we
we
have
experience
from
the
past
about
building
things
that
we
understand
how
they're
used
when.
L
I
I
think
wire
image
is
pretty
close
to
done
personally.
I
hope
that
that
comes
out
for
community
review,
september/october
and
then
yeah.
So
please
have
a
look
at
it
and,
if
there's
feedback
from
your
process
here,
but
it
makes
sense
in
the
scope
of
that
document.
With
the
understanding
thoughts
about
talk
to
me,
you
have
limited
scope.
The
passing
those
draft
was
basic
is
much
older.
Actually,
it's
been
kicking
around
for
a
while,
probably
a
little
bit
more
controversial
leaving
within
the
IAD,
and
that
essentially
says
you
must
think
about
these
things.
L
AB
V
F
V
X
We
could
have
been
so
there's
actually
there's
a
step
between
just
listing
the
use
cases
and
giving
some
recommendation
or
developing
solutions
or
whatever
that
means,
and
the
step
in
between
is
to
kind
of
analyze.
The
use
cases
figure
out
what
the
benefits,
what
the
risks
are
in
getting
some
agreement
in
the
community.
What
we
want
to
support,
what
what's
good,
what's
bad
a
little
bit,
it's
like
that's
the
heart
step,
the
more
you
can,
the
more
you
can
get
in
that
direction,
the
harder
it
will
be
to
proceed
with
a
document
but
more
useful.
V
Y
Well,
Morton
I'm
really
glad
to
see
the
whole
slide
on
neutral
point
of
view.
I
learned
a
lot
about
that
and
I
found
that
there's
a
really
good
tutorial
on
it
in
Wikipedia,
yes,
and
so
I
encourage
other
people
to
find
that
and
take
a
look
at
it.
I
I
support
this
draft
going
forward.
I
also
support
the
reestablishment
of
the
support
group
for
iesg.
Another
review,
a
stress
disorder.
Y
F
I
X
Want
to
give
some
some
piece
of
background
information
on
the
EM
encrypt
craft
and
correct
me
if
I'm
wrong,
and
but
that
was
an
ad
sponsored
individual
draft.
So
there
was
no
working
group
and
it
was
or
it
will
be
finally
published
without
IETF
consensus.
Just
to
make
the
confusion
about
the
IRT
f
series
more
complete.
P
F
Nice,
okay,
so
it's
time
to
go!
Do
this?
Please
raise
your
hand
if
you've
read
the
draft
I
see
a
good.
Does
I
see
a
good,
any
read,
read:
read
any
version
of
this
draft
I
see
well
over
a
dozen
hands.
That's
that's
really
good
for
it.
For
this
group,
okay,
it's
home
time
hung
if
you
think
the
working
group
should
adopt
this
draft
and
work
on
it.
F
AC
Awesome
all
right,
I'm,
Eric,
Kinnear
from
Apple
and
I'm,
not
Tommy,
obviously,
but
at
ATF
101,
a
strategy
for
encapsulating,
Ike
and
ESP
was
presented
in
TSV
area,
and
there
was
some
interest
expressed
in
having
a
document
that
kind
of
codifies
the
problems
with
doing
that
and
the
concerns
around
doing
that
independently
of
Ike
or
ESP.
But
just
as
a
general.
What
happens
when
you
try
to
do
this
kind
of
thing?
AC
It's
meant
to
be
an
informational
reference
for
other
things
that
support
tunneling
any
sort
of
protocol
over
TCP,
and
it
kind
of
covers
some
of
our
experience
with
with
experimenting
with
that.
But
one
of
the
primary
things
we'd
like
to
hear
from
all
of
you
is
like
what
are
the
other
cases
that
you
have
to
do
this
and
what
are
the
other
pitfalls
that
we
haven't
captured
here?
AC
I'm
sure
there
are
more,
it
would
be
great
if
we
could
collectively
enumerate
those
so
that
we
could
write
them
down
and
other
people
could
look
at
them
so
to
get
it
out
of
the
way.
This
document
is
not
intended
to
say,
go
encapsulate
TCP
within
TCP,
and
it's
a
great
thing.
It
says
here
is
all
sorts
of
ways.
It
causes
problems,
it's
deliberately
not
trying
to
modify
TCP
to
add
unreliability
or
anything
like
that.
AC
So
some
of
the
strategies
for
doing
this
involve
making
one
of
the
two
GPS
no
longer
really
TCP
and
just
kind
of
fake
and
that's
out
of
scope
here
and
we're
also
not
trying
to
say
this
is
exactly
the
format
that
you
must
use
on
the
wire
to
encapsulate
things
we'd
like
to
document
multiple
ways
of
doing
that.
If
anybody
has
any
other
ones,
we've
proposed
one,
but
there
are
lots
and
lots
of
ways
to
do
that.
So,
first,
just
kind
of.
Why
do
we
even
want
this,
especially
around
the
VPN
protocols
case?
AC
There's,
networks
that
block
UDP
traffic
and
Nats
that
then
timeout
with
UDP
at
very,
very
different
timeouts
than
they
have
for
TCP.
So
really,
the
reason
you'd
want
to
encapsulate
stuff
in
TCP
is
because
you
want
it
to
get
there
at
all,
not
because
you
wanted
to
get
there
in
the
most
optimal
way
or
the
best
way,
which
is
why
some
of
the
concerns
around
performance
and
other
issues
or
things
that
you
kind
of
put
up
with,
because
you
do
this
when
the
alternative
is
you
aren't
going
there
today.
AC
So
very
briefly,
we've
proposed
a
link
value
format
for
how
to
do
this.
Encapsulation,
if
you
have
other
formats,
we'd
love
to
chat
about
them
and
add
them
in,
but
it's
very
basic.
You
take
what
would
have
been
your
Datagram
payload
and
you
prefix
it
with
the
length
and
you
stick
it
on
the
stream
that
allows
you
to
find
the
delineation
between
them
and
at
the
other
end
you
unpack
them
and
send
them
along.
AC
You
can
also
have
some
sort
of
type
or
D
MUX
value
if
you
want
to
handle
different
types
of
data
grams
and
stuff
like
that,
and
the
nice
part
is
because
this
is
a
way
to
pack
any
sort
of
Datagram
onto
a
in
order.
Byte
stream,
you
can
do
this
over
TLS
or
TCP,
or
anything
else
you
want.
This
is
just
how
to
take
data
grams
and
shove
them
over
streams,
and
what
goes
horribly
horribly
wrong.
If
you
do
that.
AC
Protocols
that
actually
want
to
deploy
this
need
to
allocate
a
port
we're
suggesting
the
parallel
port
from
UDP.
So
the
same
way,
you
have
the
IQ
ports
for
UDP
if
they're
available
it's
great
to
use
those
from
TCP,
so
things
kind
of
line
up
in
people's
minds.
So
the
the
meat
of
the
content
that
we're
trying
to
talk
about
here
is
kind
of
what
can
go
wrong
with
this
and
what
are
the
around?
How
to?
How
do
you
deal
with
it?
AC
AC
There's
two
cases
that
we're
going
to
talk
about
we're
going
to
focus
a
lot
on
the
second
one.
So
the
first
one
is,
if
you
were
previously
sending
UDP
inside
your
datagrams
and
now
you're,
encapsulating
it
in
TCP.
You've
added
unneeded
reliability
because
usually
somebody
on
top
of
that
is
handling
it.
And
so
that's
not
great,
but
it's
not
nearly
as
concerning
for
many
people
as
TCP
within
TCP,
where
now
you've
got
all
sorts
of
other
issues,
because
you're
doing
to
congestion,
controls
and
etc.
So
diving
right
into
those
yes.
X
Mia
kudamon
and
wonder
if
we
want
to
make
an
even
stronger
architectural
recommendation
here
and
say:
even
if
you
have
reliability
on
top,
you
should
not
like
redesign
your
protocol
and
try
to
remove
it
to
save
a
couple
of
bits,
because
that's
even
more
confusing
to
users
I'm,
not
sure
if,
like
I,
think
that
would
be
the
guidance
I
would
give
em
much
of
this
agreement.
Yeah.
AC
The
the
which
one
you're
referring
to
starts
to
become
very
repetitive,
so
I'm
going
to
talk
about
an
outer
tunnel,
an
outer
TCP
and
inner
flows
that
are
going
through
that
outer
tunnel.
So
you
have
an
inner
TCP
and
you
have
an
outer
TCP.
One
of
them
is
tunneling
the
other
traffic
through
and
we're
going
to
cover
just
three
concerns,
which
is
all
that's
in
the
draft
right
now.
AC
So
if
you
have
more
concerns
than
these
we'd
love
to
add
them
and
make
a
four
and
a
five
and
a
six,
but
the
first
one
and
I
think
the
the
main
core
of
a
lot
of
the
other
issues
that
that
happen.
Are
that
because
you're
running
two
different
loss,
recovery
contacts,
the
inner
flows,
experience
loss
on
the
segments
that
are
tunneled
inside
of
the
outer
ones
as
delay,
not
as
loss,
and
so
that
confuses
things?
AC
So
the
big
one
is
like
I
said:
the
inner
flows
are
going
to
see
any
loss
on
the
network
segments
that
are
tunneled
inside
the
tunnel
as
delay.
Well,
the
outer
tunnel
makes
up
for
those
losses
by
retransmitting
and
that
can
confuse
things
because
effectively,
instead
of
going
through
fast
retransmit
and
knocking
your
window
down
and
everybody
backs
off
a
little
bit,
you
think
Oh
everything
is
great,
there's
just
some
buffer
in
the
middle
and,
if
you're,
using
purely
lost
sensitive
conduction
control.
AC
Instead
of
loss
directly
there's
one
kind
of
side
effect
that
we
were
kind
of
surprised
by
when
running
running
tests
about
this
is,
if
you
have
a
very
minor
little
bit
of
loss
that
and
you
and
you
have
a
short
enough
RTT
that
you
can
make
up
for
it
very
quickly.
The
outer
tunnel
is
actually
going
to
hide
some
of
that
loss
from
the
inner
flows
and
they
will,
on
occasion
complete
faster.
Although
I
don't
expect
that
to
hold
true
for
the
Internet
at
large.
AD
Ramping
up
that
kind
of
goes
in
fits
and
starts
in
the
network
coding
research
group
there.
Some
of
the
work
that
we've
done
sort
of
amplifies.
What
you're
saying
here
about
using
delay
based
congestion
control?
That's
an
approach
that
we've
found
effective
in
the
network
coding
context.
Nice
I
believe
some
of
the
stuff
that
discussions
going
on
in
the
research
group
looks
at
another
approach.
They
might
be
experimenting
with
actually
using
ecn
on
the
inner.
AC
AC
Yeah,
it
sounds
like
we
should
talk
a
little
more,
but
yes,
so
ECN
would
be
great.
There
are
other
signals
to
bring
that
in
and
we'd
love
to
add
that
in
here
as
well.
So
if
you
have
and
also
if
there
are
other
use
cases
of
times
where
you'd
want
to
be
tunneling
things
like
that
one,
we
should.
We
should
cover
those
two
and
make
sure
we
get
everything.
How.
AC
Effectively,
two
more
okay.
So
the
last
point
on
this
slide
that
kind
of
makes
a
lot
of
the
other
schemes
that
you
might
try
to
come
up
with
to
be
really
really
sneaky
fall
to
pieces.
Is
that
very
often
after
you
get
outside
of
the
tunnel.
Those
inner
flows
need
to
then
be
out
on
the
wild
wild
internet,
or
at
least
in
a
they
have
multiple
hops
that
they
need
to
go
through
before
they
get
to
their
final
destination,
and
so
they
still
need
to
be
fully
functional
in
all
the
ways
that
that
implies.
AC
AC
So
a
next
piece,
which
is
very
related,
is
now
that
you've
got
all
of
these
guys
who
are
seeing
delay
or
potentially
seeing
packet
loss
beyond
the
tunnel
anytime.
Somebody
retransmits
for
a
loss
when
they
time
out
within
the
tunnel.
That
is
effectively
a
spurious
retransmission
because
the
outer
tunnel
is
going
to
make
up
for
that
loss
eventually,
even
if
it's
taking
it
a
really
long
time.
AC
So
it
may
be
that
3,
4
or
500
milliseconds
later
it
comes
back
and
you
get
your
original
act
for
the
original
segment
and
you've
already
timed
out
and
retransmitted
that
entire
flight,
and
so
now
you've
dumped
a
whole
bunch
of
other
data
into
this
tunnel.
That
and
the
tunnel
doesn't
know
that
this
is
duplicate
data,
that
this
is
a
waste
of
time
and
so
wait
very
happily
delivers
it
and
outside
the
other
end
of
the
tunnel.
Comes
this
huge
dump
of
duplicate
packets.
AC
But
you
still
have
a
point
at
which
you
fall
off
a
cliff
and
the
one
thing
that
does
give
us
a
little
bit
of
hope
here
is
we've
seen
that
you
don't
fall
off
of
this
cliff
until
you
have
fairly
significant
packet
loss
in
the
in
the
high-ish
single-digit
percentage,
which
is
not
too
too
far
off
from
where
tcp
falls
off
a
cliff
all
by
itself,
so
it
you
definitely
fall
off
the
cliff
sooner.
But
it's
not
like
you,
you
suddenly
just
the
floor
drops
out
from
under
you
immediately.
AC
The
other
concern
here
is
you
end
up
with
multiple
layers
of
slow
starts.
So
after
you
fall
off
of
this
cliff
waking,
everybody
back
up
and
saying.
Alright,
let's
get
back
to
a
acceptable.
Sending
rate
means
you
effectively
have
to
push
the
window
open
of
the
outer
tunnel,
while
you're
also
trying
to
push
the
window
open
for
your
inner
flows,
and
so
you,
you
now
are
effectively
doing
twice
as
much
work
to
to
get
the
packets
across
once
you've
fallen
off
a
cliff,
so
your
recovery
is
slower.
AC
That's
it
for
this
slide
and
I
did
not
advance
the
last
one
here
is
out
of
line
blocking
so
now
you've
got
this
in
order,
byte
stream
that
you're
putting
things
that
didn't
really
care
about
being
in
order
on,
and
so
when
you
fall
off
of
this
cliff
and
you
have
a
problem.
Any
kind
of
timeout
like
that
on
the
outer
tunnel
means
that
every
other
flow
is
blocked.
AC
Well,
it
makes
up
that
lost
packet,
and
so
everybody
who
is
trying
to
sneak
their
way
through
here
is
suddenly
blocked
by
the
fact
that
that
one
of
the
packets
got
lost,
and
that
is
part
of
what
contributes
to
that
burstiness
coming
out.
The
other
end
of
the
tunnel
is
all
these
people
who
are
blocked
and
waiting
up
and
just
sitting
there
on
the
other
side,
waiting
to
be
delivered
for
that
last
segment
to
be
filled
in
it
gets
filled
in
and
everything
Donson
goes
out.
AC
So
this
is
the
kind
of
partial
mitigation
here
that
I
mentioned
a
little
bit
earlier
is
effectively.
If
you
can
tune
some
of
your
timeouts,
you
can
make
it
such
that
you
fall
off
the
cliff
a
little
bit
less
often,
but
you
still
in
in
significantly
high
loss
scenarios.
You
still
are
going
to
end
up
falling
off
a
cliff.
Fortunately,
it's
not
too
too
far
away
from
where
TCP
does
all
by
its
lonesome.
A
AC
B
That
you
might,
if
you're
able
to
make
guarantees
on
how
you
packet
is
on
the
sin
side,
you
might
be
able
to
do
pull
packets,
pull
the
inner
TCP
packets
out
of
order
and
jetsam
along
reducing
the
burstiness
and
so
on.
Yes,
so
you
might
be
able
to
do
some
tricks
there.
You
don't
have
to
specify
them,
but
you
might
wanna
lude
to
that
in.
AC
The
that
would
be
good
to
mention
we
did
some
experience,
experiments
with
that
and
at
least
under
not
particularly
real-world
conditions.
It
didn't
give
us
that
much
of
a
win,
but
I
am
I
would
imagine,
as
you
start
varying
all
the
parameters
for
how
a
network
could
behave.
It
would
help
significantly
yeah.
B
It
might
be
useful
to
mention
that
the
other
thing
I
want
to
point
out
is
that
you
don't
want
to
make
assumptions
about
the
condition
controllers.
Yes
on
the
outside.
Specifically,
if
you
are
assuming
that
it's
it's
small
space
or
the
inner
one
is
delay
based
or
not,
then
you
might
have
issues
at
least
just
keep
that
in
mind.
As
that's
a
good
point,
we.
V
V
I
would
a
true
sis
you
might
want
to
list
this
as
updating
RFC,
four,
five,
seven
one,
since
it's
the
same
on
the
wire
format
and
I.
Think
the
people
who
implement
that
in
it
I
believe
it
is
recently
widely
implemented-
would
do
well
to
read
what
you
have
written.
The
initial
list
isn't
updated,
see.
X
F
Simply
comment:
this
is
a
what
definite
one
of
one
encourage
are
the
work
here.
It's
highly
germane,
this
working
group,
if
for
no
other
reason
than
both
gory
and
I,
have
and
now
that
the
scars
in
dealing
with
UD,
UDP,
encapsulation
and
guidance
for
people
who
want
to
do
things
like
encapsulation
with
UDP.