►
From YouTube: IETF103-TSVAREA-20181105-1120
Description
TSVAREA meeting session at IETF103
2018/11/05 1120
https://datatracker.ietf.org/meeting/103/proceedings/
A
A
What
did
you
cook
here?
Go
I
know
how
to
do
that,
but
but
yeah
here
we
found
the
Clipper
excellent
so
now
that
now
that
the
area
directors
have
noted
where
the
clicker
is
for
the
advance,
the
slides.
Please
note
the
note.
Well
we're
learning
a
lot
of
things
at
the
ITF
apparently,
and
we
are
not
on.
Oh
that's
right,
I
changed
it
to
morning
session
two
but
forgot
to
change
Tuesday.
So
we're
doing
that.
But
this
is
our
agenda.
Would
anybody
like
to
batch?
They
didn't
know
before
we
get
going
good.
A
Not
seeing
any
rush
towards
the
microphones,
so
this
is
what
we
will
be
doing.
We
have
some
administrivia
to
do
which
we
always
do
we're
talking
again,
and
this
is
for
the
first
time
in
a
while,
but
TST
area
is
often
doing
forward-looking
talks
about
things
that
may
affect
transport
and
the
internet,
not
necessarily
things
that
we're
looking
to
bring
into
the
ITF
at
this
point
or
bringing
in
to
do
they're,
not
looking
at
things
that
we
are
looking
to
bring
into
a
TSP
or
can
group
for
Standardization
at
this
point.
A
So
we
have.
We
have
three
talks
there,
which
are
I
believe
all
more
or
less
related
to
discussions
that
they're
having
in
the
art
area
about.
We
didn't
used
to
think
mumble
years
ago.
That
HTTP
was
a
particularly
good.
Transport
spoke
straight
but
TC,
sorry
that
HTTP
is
not
a
particularly
good
transport
substrate,
but
HTTP
has
changed
a
lot
since
then,
and
now
we
can
now
where
we
read
thinking's
of
things
so
you're,
looking
at
like
BCP
56
bits
as
draft
names
over
there
and
things
like
that
and
I
believe.
A
All
three
of
these
talks
are
kind
of
growing
out
of
that
conversation
that
we
wanted
when
they
talked
about
them
in
the
art
area
of
meetings.
People
asked
transport
questions,
so
we
brought.
We
asked
them
to
come
here
and
we
hope
that
we
will
not
be
having
transport
people
asking
them
art
questions
and
then
we
we
do
have
a.
We
do
hope
to
have
some
time
for
questions
and
answer,
and
we
always
say
it
is
not
too
soon
to
start
going
mean
the
outgoing
area,
director
hi
I'm,
mr.
A
Dawkins
I'm,
the
going
area
director
for
for
the
transport
area,
and
we
wanted
to
recognize
the
review
team
and
actually
welcome
Cory,
who
has
joined
the
review
team
now
and
recognize
the
people
who
have
done
reviews
and
a
bunch
of
people
have
done
reviews,
and
we
appreciate
that,
including
even
one
of
the
triage
team
members
Magnus,
if
we're
still
recruiting
additional
review.
Reviewers
you'll
see
here
that
most
of
the
people
on
this
team
have
done
at
least
one
review
since
the
last
ITF
meeting.
So
you
know
that's,
they
haven't
done
eight.
A
So
you
know
it's
not
a
desperate
problem,
but
it
will
be
good.
It
will
be
good
to
make
sure
we
have
spare
capacity
during.
In
this
honest
review
team,
we
have
our
usual
thing
about
our
working
group
groups
and
what
I'm
actually
talking
about
for
my
groups
is
what
we're
talking
about
at
this
meeting
so
DT
in
Seoul
version
of
the
slides,
let's
good.
Let's,
let's
come
back
to
these,
so
this
is
what
we've
done:
publishing
rfcs
and
getting
things
approved,
and
things
like
that
since
the
last
IETF
know
this,
these
are
real
old
cool.
A
A
B
C
B
E
Right,
hi
everybody
thanks
for
being
here
today,
I'm
going
to
be
talking
about
proxy
and
hopefully
motivating
future
work
for
UDP
proxy
in
particular.
So
this
talk
is
related
to
a
couple
presentations
that
were
given
at
the
last
IETF
in
Montreal
I'm
Ben
Schwartz
gave
a
presentation
on
helium
and
dispatch,
and
Lukas
pardhu
gave
a
presentation
on
hint
NH
Phoebus.
E
E
Basically,
you
want
the
traffic,
that's
proxying
traffic
between
the
client
and
the
proxy
to
not
be
distinguishable
from
normal
Internet
traffic,
and
ideally
this
is
traffic
on
the
link
between
the
client
and
the
proxy
would
look
like
typical
web
browsing
activity.
We
don't
really
care
what
the
traffic
looks
like
between
the
proxy
and
the
destiny,
because
in
our
threat
model,
the
middlemen
that
were
interested
in
are
on
the
link
between
the
client
and
the
proxy.
E
E
E
The
third,
the
proxy
should
attempt
to
maintain
similar
performance
characteristic
for
the
characteristics
for
the
proxy
traffic
as
non
proxy
traffic
would
have
so,
for
instance,
if
a
client
wanted
to
send
traffic
to
a
destination
with
UDP
like
characteristics,
then
both
the
link
from
the
client
to
the
proxy
and
the
link
from
the
proxy
to
the
destination
to
both
have
UDP
like
characteristics.
If
either
those
links
had
TCP
like
characteristics,
then
we
wouldn't
really
be.
You
know,
maintaining
the
the
UDP
light
characteristics
that
the
client
really
wanted.
Okay.
E
Fourth,
the
proxy
should
have
enough
authentication
mechanism.
This
is
pretty
standard,
for
proxies
should
be
willing
to
transport
or
to
proxy
traffic
from
a
client.
If
the
client
hasn't
authenticated
properly
v,
the
proxy
should
be
resistant
to
active
probing.
Attacks.
Active
probing
attacks
are
cases
where
a
third
party
sends
a
manipulated
packet
to
a
piece
of
Internet
infrastructure
to
try
to
gain
more
information
about
it.
E
E
So
there
are
solutions
out
there
that
work
pretty
well
for
our
use
case
for
proxy
TCP
traffic
and
on
the
next
few
slides
I'm,
going
to
try
to
demonstrate
how
you
can
use
an
HTTP
proxy
to
meet
those
five
features
on
the
last
slide.
So
let's
say
that
you
have
a
secure
web
proxy,
meaning
that
the
client
is
going
to
perform
a
TCP
handshake
and
the
TLS
handshake
with
the
proxy
before
it
sends
its
connect
request.
E
I
guess
I
should
note
that
these
slides
are
for
HT
1.1,
but
it's
very
similar
for
HV
2,
because
the
TLS
handshake
occurred,
the
connect
request
will
be
encrypted
and
assuming
that
the
proxy
does
a
successful,
TCP
handshake
with
the
destination,
then
any
data
that
is
sent
later
on
between
the
client
and
the
destination
should
be
encrypted,
at
least
on
the
link
between
the
client
and
the
proxy.
There
could
be
an
additional
layer
of
encryption
between
end
to
end
between
the
client
and
the
destination
if
the
destination
is
using
TCP
a
TLS,
sir.
E
Ok,
so
that's
that's
basically
requirement
number
one
in
securing
proxy
traffic.
Now,
if
we
look
at
the
traffic
between
the
client
and
the
proxy,
what
does
it
really
look
like
to
an
outside
observer?
It
looks
like
TLS
over
TCP
/
IP,
and
this
is
basically
what
web
traffic
looks
like
now.
You
could
get
more
sophisticated
and
perhaps
look
at
things
like
packet,
lengths
or
packet
timing,
and
then
maybe
at
that
point
you
could
realize
that
this
is
proxy
traffic
and
not
normal
web
traffic,
but
at
least
a
some
approximation
and
for
some
reasonable
threat
model.
E
Okay
and
the
last
two
requirements
that
we
need
were
proxy
authentication
and
active
probing
resistance.
So,
typically,
if
you
have
a
proxy
and
the
client
issues
a
request
and
doesn't
either
includes
no
authentication
information
or
includes
the
wrong
authentication
information,
the
pricing
will
typically
respond
with
a
407
error
code
requesting
proxy
authentication,
and
this
obviously
gives
itself
away
as
a
proxy
all
right.
So
you
know
if
you're
trying
to
do
inconspicuous
proxy
in
here,
you
can
not
send
that
process
of
an
error
code
and
you
can
act
like
a
web
server.
E
Instead,
if
you're
wondering
on
the
draft
that
specifies
the
407
uses
a
should,
rather
than
a
must-
and
in
this
case
so
I
think
it
doesn't
actually
conflict
for
the
standard
and
for
the
proxy
to
act
like
a
web
server.
It
should
also
be
able
to
serve
a
web
page
and
responds
to
a
get
request
on
port
4
with
you,
okay,
so
that
was
all
for
TCP
proxy
and
without
getting
too
much
into
the
solution
space.
What
would
a
potential
solution?
Look
like
for
UDP
Rocking?
E
E
E
So
there
are
certainly
solutions
out
there,
some
standardize,
some
not
that
deal
with
UDP,
proxy
and
I
thought
it
might
be
constructive
to
talk
through
some
of
those
and
try
to
explain
why
we
think
they
don't
meet
our
use
case
and
perhaps
also
help
motivate
why
we
want
additional
work
in
this
area.
So
first
up
is
turn
which
has
come
up
a
lot
in
previous
discussions
around
him
and
helium.
So
to
secure
the
traffic
we
would
need
to
use
DTLS
overturn,
and
perhaps
this
would
look
a
little
bit
like
web
RTC
traffic.
E
At
that
point,
there's
a
question,
though,
as
to
whether
the
entirety
of
WebRTC
traffic
provides
enough
collateral
damage
or
enough,
or
is
it
a
sufficient
cover
for
our
use
case?
Certainly,
in
the
long
run,
it
seems
like
a
better
bet
for
us
to
blend
in
with
quick
traffic,
quick
web
browsing
traffic.
E
E
But
this
would
still
be
this
would
not
blend
in
well
with
quick
web
browsing
traffic
at
all,
either
the
traffic
component
or
the
socks
proxy,
but
that
wouldn't
really
resemble
a
web
server
and
I
think
running
both
Sox
and
HTTP
on
the
same
court.
It
would
not
be
a
good
idea.
Okay.
Lastly,
there
are
various
existing
VPN
protocols
that
support
EDP
proxy,
but
these
are
generally
finger
printable,
so
they
wouldn't
the
the
traffic
itself
wouldn't
blend
in
with
web
traffic,
and
the
VPN
would
not
look
like
a
web
server.
E
E
Now
so
this
is
everything
that
I
have
for
today,
so
the
five
feature
that
my
features,
that
I've
kind
of
been
harping
on
kind
of
represent
a
minimum
feature
set
that
we're
interested
in
and
there's
certainly
other
aspects
to
this
problem
that
we
find
interesting
and
if
you've
seen
the
helium
draft,
you
may
have
in
an
understanding
of
what
those
are
already
if
anybody
has
use
cases
that
overlap
with
the
features
that
we've
been
talking
about.
That
would
be
very
interesting
here
as
well.
Thank.
D
You,
yes,
thank
you
very
much.
Just
I
should
have
mentioned
that
before,
so
we
have
two
more
presentations,
short
presentations,
which
will
go
further
into
detail
and
talk
about
more
use
cases.
So
we
can
have
like
a
high-level
discussion
about
the
general
concepts
after
those
three
talks,
and
we
can
have
some
specific
questions
to
this
talk
right
now.
But
if
you
have
like
a
more
general
comment
and
maybe
hold
up
for
after
the
next
presentation,
well,.
F
Yes,
I
mean
you're,
presenting
the
requirements
of
POC
seeing
and
we
did
a
very
similar
exercise
in
the
TRS
working
group
when
studying
the
requirement
for
SNA
encryption,
and
we
have
a
draft
that
is
in
walking
Pascal
right
now
listing
all
the
requirements
for
sni
encryption
and
going
in
great
details
about
ways
to
do.
That
and
I
think
that
it
would
be
very
much
related
to
what
you're
doing.
Ok.
G
E
A
H
Kinnear
Apple
I,
agree.
I
think
this
is
really
interesting.
I
can
think
of
several
use
cases.
That
would
be.
That
would
be
very
helpful
to
be
able
to
proxy
UDP
in
a
similar
way,
as
people
do
TCP,
especially
as
quick
and
and
other
similar
areas
start
to
kind
of
expand
the
usable
amount
of
UDP
in
the
world.
H
It
would
be
worse
that
we
may
talk
more
about
specific
solutions
later
so
I
don't
want
to
get
too
far
ahead,
but
it
would
be
worth
double
checking
on
the
some
of
the
datagrams
stuff
in
quick
that
we're
discussing
about
how
to
send
unreliable,
UDP
ish
traffic
over
quick.
The
other
kind
of
question
that
I
had
is
when
you
talk
about
the
HCP
connect
where
you're
doing
TLS
to
the
proxy
and
then
potentially
even
TLS
through
the
proxy,
and
we
talked
about
that
as
having
similar
performance
character
as
its
characteristics.
H
If
it
looks
like
HTTP,
a
lot
of
HTTP
flows
are
fairly
short-lived,
but
the
set
up
cost
for
that
many
round
trips
to
get
through
that
proxy.
All
the
way
to
the
end
can
be
very
high.
On
the
other
hand,
if
you
want
a
much
longer
lift
connection
now
somebody
who's
fingerprinting,
it
probably
is
not
as
convinced
that
it
looks
like
a
cheapie,
so
it'd
be
interesting
to
look
at
how
that
trade-off
could
be
alleviated
for
other
solutions
that
might
be
able
to
shave
some
of
that
time.
Yeah
yeah.
E
And
that's
certainly
something
that
we
would
need
to
consider
as
being
part
of
the
front
model
or
not
you
know,
do
we
want
to
their
length
of
connections,
timing
between
packets,
length
of
packets?
You
know
all
these
sorts
of
things
could
absolutely
be
used
to
differentiate
between
different
types
of
traffic,
even
given
encryption.
So
you
know
it's
just
a
question
of
how
high
we
want
to
set
that
bar
totally.
D
I
Ahead,
come
on
because
I
am
very
jet-lagged,
so
I
apologize
that
I'm
in
San
Francisco
and
outside
at
protests
related
to
the
unions
and
the
hotels.
So
if
you
can
hear
some
noise,
apologies
for
that
yeah
I
changed
the
title
of
these
slides
slightly
for
what
was
on
the
agenda.
I
didn't
want
to
focus
too
much
on
on
the
tunneling
aspects,
but
more
just
on
some
of
the
they
talked
about
quick,
which
I
had
a
nice
prelude
to
you.
Just
then
in
the
comment.
So
if
you
could
go
onto
the
next
slide,
please.
I
We
have
another
one
there,
and
indeed,
with
with
this
kind
of
nature
of
HTTP
proxy,
you
can
chain
those
proxies
up,
so
you
might
have
in
you
know
a
worst
case
scenario,
quick
within
quick
within
quick
ad
nauseam
and,
and
that
might
be
something
people
want.
It
might
not
be
I,
don't
want
to
focus
too
much
on
it.
But
if
people
are
interested
in
some
of
the
visualizations,
some
of
the
pros
and
cons
just
a
flavor
text
on
that
ID
I
would
encourage
them
to
have
a
look
at
that
presentation.
I
I
did
last
time,
but
if
we're
going
to
move
on
to
the
next
slide,
coming
away
from
that
discussion,
I
wanted
to
kind
of
really
distill
down
the
capability
of
what
my
focus
was
of
the
HTTP
connect
aspect
of
things.
So
what
what
is
it
really?
What's
it
trying
to
do,
and
my
view
is
that
it's
it's
a
signal
that
is
defined
already.
That
allows
us
to
change
the
meaning
of
this
client
to
save
a
hop
from
a
it's.
D
A
I
So
HP
1.1,
we
use
the
connect
method
to
change
the
entirety
of
that
HTTP
connection
in
hate
should
be
to
if
people
aren't
familiar,
it's
the
same
method,
but
it
just
reserves
a
stream
for
a
particular
Association
and
in
HT
to
be
quick.
It's
it's
a
very
similar
mechanism,
but
all
it
can
do
is
reserve
that
stream
for
wrongful
onward
TCP
use.
So
this
is
kind
of
the
the
motivation
for
why
I
wanted
to
look
at
UDP
proxying.
I
So
we
could
have
a
quick
world
that
we
can
have
UDP
all
the
way
through,
okay
and
so,
if
anyone's
familiar,
the
the
HTTP
to
WebSockets
bootstrapping
was
was
fairly
recently
standardized.
So
this
is
our
C
eight
four,
four
one-
and
this
is
a
slight.
You
know,
modification
of
what
Connect
means
in
order
to
enable
that-
and
there
are
few
options
there,
but
you
know
Patrick
McManus,
taking
a
view
of
the
community,
decided
that
this
was
maybe
the
best
way
to
do
things.
I
So
it's
what
it's
trying
to
highlight
is
that's
how
things
are
done
already
and
that's
how
I
went
into
IDF
1ot,
but
but
having
had
some
feedback
and
then
seeing
what
was
naturally
happening
in
this
space.
There's
been
a
few
things:
I've
seen
no
heared.
So
if
you
move
on
to
the
next
slide,
I
just
want
to
give
it
an
overview.
These
are
kind
of
the
the
quick,
specific
addendums
that
have
happened
in
the
meantime.
I
So
some
of
the
feedback
is
that
these
these
new
uses
of
stream,
if
we're
gonna,
reserve
a
http/2
or
HP
quick
stream.
These
are
you
know,
guaranteed
delivery
mechanisms
with
congestion
and
flow
control
and
that
actually
there's
use
cases
VDP
that
that
may
suffer
from
from
those
characteristics
and
that
you
might
not
be
needed
or
impractical
and-
and
certainly
you
know,
I
work
in
in
video
related
things.
So
unreliable
delivery
definitely
has
use
cases
here.
We
don't
want
to
be
losing
that
capability,
just
because
we're
tunneling.
I
Meanwhile,
we've
got
Colin
and
you're
looking
at
say
real-time
media
over
quick
and
what
that
might
need
from
the
quick
transport
itself
again
back
towards
these
kind
of
unreliable
deliveries,
whether
that's
a
Datagram
message
or
unreliable
streams,
really
trying
to
state
some
of
the
needs
here,
not
mandating
the
implementation
of
them.
And
then
a
final
point
without
any
link
here
is:
is
this
idea
of
multiplexing
different
protocols?
I
So
there's
been
work
already
in
this
area
about
how
we
might
be
able
to
multiplex
different
protocols
at
the
UDP
layer,
but
recently
is
a
bit
of
chatter
in
the
quick
space
about
how
you
might
multiplex
different
application
protocols.
So
you
know,
if
you're
doing
something
like
alternative
services.
I
I
just
lurk
on
and
so
there'll
be
a
bit
of
discussion
on
that
in
the
tap
session
later
this
week,
I
can
find
the
agenda
item
exactly
when
I
put
these
slides
together,
but
I'm
sure
somebody
can
comment
there
towards
that
in
the
discussion.
So
for
about
onto
the
next
slide.
Just
to
summarize
everything
the
the
IDS
are
both
Ben
and
I,
presented
at
IETF.
101
haven't
changed
so
if
you
did
read
them
they're
still
relevant.
I
We
there's
probably
a
few
fix
up
from
perspective,
but
yeah
that
there
as
they
are
we're,
learning
more
stuff
and
there's
more
bit
of
momentum
in
this
area,
which
is
a
good
thing
and
I'm
really
keen
to
follow
that
on.
You
know.
There's
some
related
work
going
on,
be
good
to
try
and
answer
the
question.
What
is
the
problem
exactly
here
that
we're
trying
to
solve
the
fall
solutionizing?
I
It
unfortunately
I'm
not
there
in
the
ITF
this
week,
I'm
a
remote
participant,
but
if
people
have
emails,
I'd
love
to
to
follow
that
up
and
the
thing
I'd
like
to
kind
of
leave
with
is
is:
can
we
continue
to
distill
down
things?
Is
there
you
know
Katherine
presented
brilliantly
stuff.
I
would
have
said
already
so
I
try
to
commit
at
this
from
a
different
angle.
No
is
there?
I
Is
there
some
kind
of
features
of
multiplex
flows
within
you
know,
with
an
ability
to
pick
congestion
flow
control
as
needs
must
or
as
desired
within
a
single
connection
context,
that's
always
secure,
and
that
this
is
a
really
simple
and
performant
way
to
initiate
those
flows
with
minimal
overhead?
You
know,
HTTP
connect
was
one
way
to
do
it
that
requires
round
trips.
There
might
be
a
simpler
way.
I
You
know
using
more
of
a
binary
framing
a
native
approach
to
these
things
that
deliver
some
wins
over
the
old
ways
of
doing
things
and
that
having
everything
within
one
connection,
as
opposed
to
distinct,
TCP
or
UDP
connections,
to
call
them
is
there
an
ability
ability
to
clearly
relate
those
things.
Have
them
more?
D
Thank
you
very
much.
Any
questions
on
this
point.
I
actually
go
back
to
like
one
of
your
first
lights
for
a
second.
So
if
you
haven't
heard
or
read
those
two
drafts,
please
do
so
and
provide
transport
feedbacks
to
the
authors.
I
think
that
would
be
really
important.
I,
don't
see
anybody
in
the
queue
so
Lucas.
If
you
want
to
join
the
discussion
later,
you
can
join
the
media.
It's
you
again,
but
thank
you
so
far,
and
we
go
to
the
next
presentation.
J
J
Example,
one
without
loss
or
a
very
variable
latency
or
here
yeah,
if
you
have
highly
asymmetric
links,
for
example,
with
narrow
upstream,
is
the
case
of
satellite.
Then
you
put
one
of
these
boxes
or
two,
sometimes
at
both
end
of
the
of
the
weak
link
and
that
leave
that
it's
splitters
prove
the
TCP
connection
and
perform
a
number
of
tricks
that
include
ACK,
manipulation,
decimation
reconstruction
flow
control,
manipulation,
header
compression
latencies
plate
and
let
it
fix.
The
problem
then
suggest
to
provide
a
concrete
example
of
of
these
boxes.
J
What
did
they
do
in
specific
scenarios
away
I'm
coming
with
a
mobile
example,
but
I
suppose
the
satellite
people
would
have
you
know
hundreds
of
this
example
to
provide
in
the
discussion,
but
but
from
a
mobile
perspective.
What
what
happens
is
that
the
often
they
the
air
interface
phrases
and
then
the
upper
layer
see
it's
complete
freeze
of
the
of
the
channel,
because
the
there's,
a
no
congestive
loss
on
the
on
the
air
and
the
and
the
lower
link
protocols
in
the
3gpp
stack
actively
try
to
retransmit
right.
J
So
they
operate
on
ten
million,
roughly
ten
million
trees
by
one
two.
Three
times
at
10-minute
intervals
and
if
the
specific
configuration
so
say
your
multipath
fading
situation
or
the
obstacles
doesn't
within
that
short
interval.
And
what
happens
is
that
the
the
the
freeze
can
last
longer
than
the
typical
RT
t.
And
so
the
sender,
the
TCP
sender,
on
on
the
other
side
of
the.
J
Have
the
other
layer
trying
to
repair
again
so
completely
waste
wasted
thing,
so
what
these
boxes
do
in
this
context?
Is
they
provide?
So
what
they
do?
Is
they
buffer
data
right
from
the
sender?
They
act
the
sender
and
then,
when
the
link
is
back
to
normal,
they
smooth
the
data
out
to
the
receiver
and
and
with
this,
providing
being
pronounced,
matching
right
at
the
point
where
the
mobile
network
in
the
wire
link
connect.
So
without
the
pad,
the
sender
was
probably
protein.
J
So
so
you
have
a
stolen
the
congestion
winner
or
a
reduction
in
collision,
and
just
in
winners
of
the
throughput
and
in
general,
the
group
would
decrease
decrease,
so
these
boxes
are
middleboxes,
of
course,
so
the
typical
caveat
applies
particularly
optimize.
The
current
application
at
the
expenses
of
the
future
applications
and
their
precise
behavior
is
not
clearly
specified
right.
So
that's
the
problem
boxes
they
can
break
depending
on
how
they
are
designed
and
built
and
operated
and
upgraded.
They
can
break
the
path
badly,
but
even
more,
they
can
break
paths
only
partially.
J
So,
for
example,
if
they,
if
one
of
these
middle
boxes
want
to
optimize
always
what
happens
is
that
it
needs
to
understand
the
end-to-end
semantics
always,
and
so,
if
you
are
negotiating
an
optional
bit
of
semantics
on
top
of
Europe,
there
is
the
speaker,
nation
and
and
and
that
guy
doesn't
understand
that
thing
it
will
probably
eat
it
up,
and
this
is
very
very.
It
is
precluded
the
EDD,
the
information
of
transport
wires
being
one
of
the
major
causes
of
ossification.
J
F
J
That
means
that
the
the
PAP
cannot
do
anything
it
does
normally,
so
it
can
do
the
other,
compression
or
actrix
know
our
window
segments
not
manipulation,
so
the
function
are
completely
inhibited.
So
we
have
this
original
problem
that
the
pep
soles
say
yeah
problem,
one
peps
then
peps
create
another
problem.
Then
encryption
solves
this
problem,
but
doesn't
so
the
other
problem
right
so
that
the
fee,
the
top-level
problem
by
itself.
J
First
of
all,
is
pep
a
valid
approach
still
so
in
terms
of
the
problems
that
it's
all
are
these
problems
still
relevant
and
if
yes,
if
these
problems
are
still
there,
can
we
solve
the
same
problems,
we
other
techniques
and,
if
not
or
if,
yes,
but
partially,
so
if
better,
are
still
needed.
So
how
does
a
modern
pep
look
like
from
the
perspective
of
the
end
points?
J
We
know
that
it
must
be
explained
explicitly
at
this
point
in
time,
because
the
it
must
have
been
a
the
security
Association,
so
it
has
to
be
visible
to
one
or
both
end
points,
and
the
second
point
is
shoot.
The
new
transport
take
that
into
consideration
at
the
same
time
doesn't
seem
to
me
that
quick
did
this
effort
right,
but
in
particular
the
problem
with
quick
is
that
it
collapses.
The
two
security
Association,
the
application
level
security
association
with
the
transport
association
is
association.
J
In
there
congestion
controller,
so
the
condition
controller
from
from
from
the
end
point
to
the
episode,
the
proxy
and
the
any
outer
congested
controller.
Sorry
vice
versa
and
the
other
ND
and
the
one
from
from
the
end
points
to
the
Obsidian
from
the
end
point
from
one
point
to
the
other
end
point
in
particular,
under
diverse
links
and
use
a
mobility
models,
so
this
should
be
characterized
properly
before
we
can
say.
Ok,
this
is
a
valid
set
of
terms
that
we
can
use
in
the
pepper
context.
J
And
third
thing
is
one
thing:
is
it's
nice
in
helium?
Is
this
in
band
control
channel?
That
seems
to
be
an
interesting
bit
be
used
to
exchange
cross
layer
signals,
for
example,
from
3gpp
stack,
dip
down
and
say
in
the
air
interface
to
to
the
transport
that
we
very
nice
bathroom
to
provide
these
things.
Yeah
I
think
this
is
the
discussion
scheme
that
I
wanted
to
provide.
K
Hi
Stuart
Cheshire
from
Apple
I
had
a
minor
point
on
one
of
your
earlier
slides,
I,
don't
know
which
number
it
is.
You
talked
about
typical
round-trip
time.
You
talk
about
spurious
retransmission
there
you
go
I
wanted
to
point
this
out,
because
this
is
a
common
misperception
or
maybe
miss
representational.
K
The
way
a
transport
protocol
like
quick
or
TCP
works
is
it
doesn't
retransmit
when
the
average
round-trip
time
comes,
because
if
you
think
about
it,
the
round-trip
time
distribution
is
like
a
bail
distribution
or
some
shape
of
distribution,
and
if
you
retransmitted
every
time
you
hit
the
average
round-trip
time
on
average
you'd
be
transferee
transmitting
too
early
50
percent
of
the
time.
So
all
of
these
algorithms
take
the
variance
or
the
standard
deviation
into
account.
K
So
so,
if
you
have
a
link
that
is
very
variable
that
ought
to
be
reflected
in
a
larger
standard
deviation
so
that
you
have
a
broader
bell
curve.
You
still
should
be
tuning
your
retransmission
timer
to
be
two
three
standard
deviations
out
so
that
there's
false
tree
transformations
are
rare.
So
now
that's
just
one
comment
that
are
often
often
the
way
the
salesmen
who
sell
these
performance
in
enhancing
properties
sell
them
is
with
this
oversimplification
of
see
how
stupid
TCP
is,
we
can
fix
it
and
the
reality
is
not
that
simple.
K
My
other
observation
is
when
ipv6
started
rolling
out
in
volume.
All
the
measurements
confirmed
that
its
performance
was
measurably
better
than
ipv4,
not
twice
as
good,
but
somewhere
between
10
and
30%,
better
performance,
and
it's
not
it's
hard
to
know
for
sure
why
our
network
is
because
the
Internet,
but
one
of
the
speculations
was
that
it
performs
better
because
none
of
the
performance
in
the
hansung
proxy
support,
ipv6.
A
Mr.
Dawkins,
and
speaking
as
a
speaking
as
the
former
chair
of
the
Pihl
working
group
that
produced
the
RFC
on
peps
the
day
known
that
RC
is
2001.
Most
of
the
work
was
done
significantly
before
I
was
published.
We
could
talk
about
why
and
like
it
seems
like
to
me.
Yeah
I
can
have
opinions
about
this,
but
I
think
what
I
want
to
say
here
is
that
it
seems
like
we
could
look.
We
could
talk
about
whether
it
what
the
right
thing
to
do
was
every
20
years
or
so
whether
we
needed
to
or
not.
L
D
M
So
this
is
Ben
Schwartz
from
jigsaw
at
Google
and
I
wanted
to
agree
and
disagree
with
something
that
Thomas
just
said.
Thomas
said
that
in
a
in
a
post,
PAP
world-
or
you
know,
in
a
vision
of
pet
for
quick-like
protocols,
the
proxy
has
to
be
explicit.
I
agree
with
that,
and
he
also
said
that
it
has
to
be
explicit
because
it
terminates
the
security
Association.
At
least
that's
what
I
heard
and
I
think
I
disagree
with
that.
M
So
I
would
like
to
I
would
like
to
propose
that
there
are
at
least
parts
of
this
solution
space
where
the
security
Association
remains
end-to-end
from
from
client
to
destination,
and
there
is
something
else
going
on
that
wraps
around
the
around
the
encrypted
transport
and
possibly
introduces
a
second
congestion
controller
in
couples
the
to
congestion
controllers
in
the
right
way.
In
a
way
that
allows
us
to
avoid
terminating
any
any
crypto
from
the
from
the
end-to-end
stream
in
the.
J
Been
so
sorry,
yes,
this
one
when
my
mic
boys
get
garbled
I
didn't
want
to
imply
that
the
end-to-end
security
Association
is
the
read
of
the
proxy
on
the
contrary,
but
it's
there's
an
association
that
needs
to
be
a
terminated
at
the
proxy
and
and
then
but
it.
This
doesn't
have
anything
to
do
with
the
end,
to
anything
completely
explicitly
separate
cool.
M
So
then
we
agree
on
I
also
want
to
since
I
have
the
mic.
I
want
to
just
take
this
chance
to
say
a
little
bit
about
this
concept
of
explicit,
because
I
think
there's
you
know
we
treat
client,
often
from
the
network
perspective.
We
treat
the
client
as
a
monolith,
but
clients
also
have
components
within
them.
So
you
can
imagine
that
I
can
imagine
a
world
where
apps,
for
example,
aren't
aware
of
the
presence
of
this
proxy.
N
N
There
we
go
okay,
so
I
think
the
problems
are
still
relevant.
These
links
still
exist.
It
is
possible,
I
mean
there
are
certainly
there's
another
way
to
approach
it,
which
is
developing
a
a
congestion
control
that
is
truly
adaptable
to
all
link
types.
I
think
that's
an
open
question
if
we
have
that
or
not,
but
regarding
the
peps
specifically
and
if
they're
needed,
so
we've
been
quick,
we've
already
we've,
you
know
we
started
with
this
no
middleboxes
approach,
we've
already
bent
the
rules
one
and
a
half
times
well.
N
We've
already
decided
that
that
there
must
be
some
ability
for
stateless
load
balancers
to
do
things
and,
secondly,
work.
There's
talk
now
about
DDoS
anti-ddos
devices
sending
retry
packets,
so
we're
trying
to
preserve
this
notion
of
explicitness
is
a
couple
other
people
have
set,
rather
than
have
it
be
transparent
as
it
is
in
TCP
land.
N
The
other
thing
I'll
say
is:
this
will
not
happen
in
v1,
but
there
is
talk
about
separating
just
chatter
at
this
point
about
separating
the
keys
of
between
the
transport
stuff
and
the
actual
application
traffic.
For
reasons
of
diagnosing
for
a
for
the
fact
you
can
provide
the
the
transport
key
to
whoever
is
going
to
analyze
your
network
problems
without
sacrificing
your
application
security
that
might
be
a
framework
that
would
enable
some
sort
of
explicit
TCP
of
sorry.
A
O
Gory
Fairhurst
thanks
Spencer
I'm,
not
sure
with
the
answer
to
the
question
so
I'll
continue.
I
was
one
of
the
original
authors
of
one
of
the
RFC's
was
put
up
and
john-boy
did
the
other
and
RFC
leader
and
the
PAP
spec
always
said
explicit
was
better
so
when,
when
hilt
madam
talked
about
this,
they
said
experts,
it
was
better
than
implicit,
because
then
you
know
somebody's
fiddling
with
stuff
or
doing
things
doesn't
matter
today.
I
mean
that's
a
good
question.
So
over
the
past
few
months
we've
been
trying
quick
over
satellite
links.
O
Cuz
we
play
with
those
among
other
things,
and
then
ninety
percent
of
the
traffic
runs
slower
with
quick,
currently
just
because
probably
quick
was
never
designed
really
for
satellite
links
with
Bo
D
and
RRM
functions.
Underneath
now,
quick
could
be
designed
better
and
we
could
fix
it
here
if
we
fix
it
here.
Right,
Tom
suggests
what
like
yeah
it'll,
be
good.
If
we
don't
fix
it
here,
then
we
got
a
problem
because
for
some
people
ninety
five
percent
of
the
traffic
will
be
slower,
which
makes
quick
undesirable.
So
how
are
we
gonna
deal
with
this?
A
I
just
like
to
echo
that
what
what
John
said
when
he
was
talking
to
me
back
in
London
was
that
they
were
giving
like
an
order
of
magnitude
slower
throughput
right,
so
testing
them
between
quick
and
TCP.
So
you
know
the
easy
answer:
there
is
just
block
UDP
or
just
like
quick.
You
know
and
that's
an
algorithm
and
we
were
wondering
if
there
might
be
better
algorithms,
okay,.
O
P
Hey
Colin
Perkins,
so
just
to
follow
up
quickly
on
that
previous
discussion.
I
think
we
need
to
be
a
little
careful
drawing
conclusions
about
quick
performance
compared
to
TCP
performance
at
this
stage,
because
we're
comparing
very
new
unoptimized
and
unfinished
quick
implementations
with
TCP
stacks
I've
had
20
or
30
years
of
tuning.
P
So,
yes,
the
quick
performance
will
improve
over
time
on
the
explicitness
issue,
I'd
like
to
draw
people's
attention
to
the
perc
working
group,
which
is
doing
a
multi-level
encryption
scheme
to
allow
middleboxes
to
do
semi
trusted
processing
of
some
things
which
looks
similar
to
someone.
I
mean
it's
addressing
a
different
problem,
but
but
it's
in
a
way
which
seems
very
applicable
to
these
yeah.
The
proposals
to
allow
the
middle
box
is
to
do
head
of
processing
but
not
see
the
content.
The
same
ideas
will
probably
apply
to
these
sort
of
proxies
as
well.
D
Q
That's
right
that
so
I
admit
and
people
are
gonna
start
stuff
at
me
because
it
sounds
really
stupid.
I
submit
that
this
is
not
a
transport
problem.
Okay,
now
this
is
an
IP
layer
problem.
What
we're
trying
to
tell
the
sender
is:
if
you're
curing
packets
to
this
destination,
they
are
gonna,
be
delayed.
This
has
nothing
to
do
with
any
particular
transport
session.
It's
a
queue
management
problem.
Okay,
so
if
you
know
why
is
this
not
done
at
the?
Why
do
you
have
to
break
the
encryption?
Q
Q
I
agree,
but
why,
but
like
we
should
look
at
carefully
why
we
deprecated
it
and
whether
the
reasons
is
still
current
today
now
that
we
know
that
you
know.
Middle
boxes
have
really
really
serious
considerations
for
ossification
and
for
security,
and
also
on
with
that
decision,
may
not
be
the
right
decision
anymore,
and
we
should,
if
the
facts
of
change,
we
should
change
our
minds
right.
A
And
so
that
to
me
you
know
one
of
the
key
things
that
you're
just
pointing
to
there
is
that
this
is
a
conversation
we
need
we
need
to
have
and
we
need
to
not
have
it
while
we're
trying
to
standardize
a
specific
protocol
so
that
you
know
that
was
the
point
in
bringing
this
to
TSP
area.
So
we
could
have
the
broader
conversation
with
people
who
are
not
trying
to
finish
quick
in
mumble
months.
R
Michael
Abraham's,
can
we
go
back
to
the
asking
slight
or
actually
it
might
might
go
here
as
well.
I
just
like
to
point
out
that
some
middle
boxes
today
there
and
why
to
use
set
MSS,
does
MSS
clamping
on
TCP,
for
instance.
This
is
a
signal
from
a
network
device,
saying
I
think
you
should
do
this,
so
this
is.
There
are
a
few
of
these
kind
of
signals.
R
The
lorenzo's
point
here
was
was
another
one
is
sometimes
she
actually
want
devices
on
the
way
to
be
able
to
put
bits
or
stuff
into
the
packet
as
it
goes
by
so
having
in
transport
header
encryption,
where
the
network
knows
nothing
well,
actually,
sometimes
it
might
be
good
if
you
know
something
that
the
never
can
tell
you
something
in
the
packet
as
it
goes
by
so
when
you,
when
you
design
a
transport
protocol,
I
actually
think
there
should,
there
should
be.
Some
knepper
should
be
able
to
influence
something
as
a
fact.
R
C
Hi
Gigi
super
Hughes
I
work
for
a
satellite
operator,
so
I
mean
we
don't
want
to
have
a
MIDI
box
of
path.
I
mean
it
caused
a
money
or
resources,
but
the
problem
is,
as
you
encrypt
a
trophy
header
and
it's
the
performance
degree
significantly
so
with
currently
and
a
satellite
show.
We
show
that
with
the
TCB
path,
the
transfer
ray
can
be
up
to
200
megabit
per
second.
C
If
you
run
quick
with
the
current
congestion
window
or
2000
packet,
you
can
do
the
limited
and
it
turns
out
that
only
20
megabits
per
second,
it's
a
one
order
of
magnitude
slower.
So
I
did
the
solution.
I
mean
we
don't
want
pair
for
MIDI
boxes.
The
solution
should
be
I
mean
Chris
should
be
designed
such
that
it
works
for
all
types
of
link,
including
a
satellite
link.
Satellite
RTT.
C
Even
the
physical
layer
delay
is
600
milliseconds,
but
in
a
busy
hour
it
can
be
a
strong
at
1.
Second
and
there's
two
issues:
one
is
the
congestion
window
and
you
can
fix
with
the
adaptive
congestion
window
you
that
mm
packet
is
not
enough.
The
second
thing
is
a
packet
loss.
It's
too
late,
I
mean
RTG,
so
I'm
the
best
for
us
is
quits,
can
accommodate
a
design.
Such
a
I've
also
worked
for
satellite
link.
Thank
you.
So.
D
A
S
A
T
U
All
right,
Aaron
made
me
get
up
a
lot
of
second,
so
wanna
I
go
back
what
what
Stewart
said
earlier
right,
so
that
nobody's
debating
that
peps
help
in
certain
cases
where
it
is.
There's
ample
evidence.
If
that
nicotine
you
to
help
the
problem,
is
that
many
of
them
get
put
in
and
then
they
rot,
and
so
you
do
not
know
whether
there's
a
pep
that
actually
helps
you
on
this
path
or
where
there
is
a
pep
that
limits
your
performance
on
this
path
right
and
that's
sort
of
the
fundamental
problem
and
and
if.