►
From YouTube: IETF99-QUIC-20170720-1550
Description
QUIC meeting session at IETF99
2017/07/20 1550
https://datatracker.ietf.org/meeting/99/proceedings/
B
D
E
F
A
A
This
is
the
ever
famous
IETF
note
well
slide,
which
describes
the
intellectual
property
terms
which
we're
participating
under
this
is
important.
It's
one
of
the
reasons
why
we
do
standards.
Does
it
get
intellectual
property
covered?
So
if
you're
not
familiar
with
us,
please
familiarize
yourself.
You
can
do
that
most
easily
by
putting
IETF
note
well
into
your
favorite
search
engine
and.
A
Likewise,
we
want
to
keep
a
professional
atmosphere
here.
This
isn't
a
professional
environment,
so
if
you
witness
or
you
feel
you
are
being
harassed,
please
tell
someone,
so
we
can
try
and
correct
it.
We
have
a
team
of
people,
the
Ombuds
team
which
have
an
email
address,
or
you
can
contact
them
directly
and
and
help
to
resolve
the
issue
and,
of
course,
Lars
and
I
are
also
people.
You
can
talk
to
if
you're
comfortable
doing
that.
A
A
Do
we
have
someone
to
relay
comments
from
the
jabber
channel?
Is
anyone
willing
to
do
that?
You
can
do
it.
Finn
you've
got
it
okay
that
will
be
Lars
and
before
I
get
to
the
agenda
Bash
one
other
bit
of
administrative
stuff.
We
have
an
interim
up
coming
in
October
in
Seattle,
hosted
very
kindly
by
f5,
if
you
haven't
registered,
for
that,
please
do
so
soon.
There
is
a
dead
one
which
we
do
intend
to
enforce.
A
A
So
we
have
two
sessions
one
today
and
one
tomorrow,
and
we
have
a
fairly
modest
agenda.
We're
going
to
spend
the
bulk
of
that
time
discussing
open
issues.
We
have
a
number
of
presentations
by
folks
to
get
those
discussions
going.
The
editors
got
together
and
identified
the
issues
that
they
believe
are
most
blocking
our
forward
progress.
Hopefully
most
of
you
were
here
for
our
session,
that
was
joint
with
the
HTTP
working
group.
Yesterday,
we
made
some
really
good
progress,
I
think
on
the
on
the
HTTP
issue.
A
So
hopefully
we
can
continue
that
and
get
things
moving
forward,
so
we're
the
agenda
and
that
we
published
is
a
little
more
than
what
I
have
up
here.
We're
going
to
talk
about
the
outcome
of
the
hackathon
on
the
weekend,
which
was
for
Interop,
we'll
talk
about
the
first
implementation
draft
and
the
upcoming
second
implementation
draft
and
make
sure
we
understand
that
will
go
into
the
issues,
and
then
we
have
a
couple
of
presentations.
I
think
the
issues
will
take
the
bulk
of
the
time,
both
today
and
tomorrow,
then
we'll
go.
A
A
We
had
a
hackathon
on
the
weekend
where
we
had
I,
believe
five
implementations
show
up.
I
would
say
the
outcome
was
pretty
good.
Did
the
folks
who
participated
in
that
want
to
give
a
short
summary
of
what
happened
and
I'll
get
the
spreadsheet
up
for
people
to
look
at?
Do
I
have
to
nominate
someone
Patrick,
since
you
ran
the
thing,
that's
probably
most
appropriate.
G
Yeah
I
think
you
counted
that
what
do
we
got?
One
two,
three,
four,
five
yeah
five
implementation
showed
up
we're
gonna
get
closer
because
it's
hard
to
hear
you
guys.
Five
implementation
showed
up.
You
know
none
of
them
had
achieved
Interop
of
the
o5
graphs
before
that's.
The
first
thing
we
did
is
agreed:
we're
gonna,
throw
out
the
Oh
four
and
just
be
labeled
something
Oh
five
and
with
that
the
biggest
issues
were
really
settling
on
all
the
right
versions.
G
So,
whether
that
be
the
LP
inversion,
the
TLS
version,
the
you
know
the
transport
graphs
etc
going
forward.
But
you
see
we
managed
to
get
in
that
graph
that
just
disappeared
there
we
go
when
you
get
to
green
and
you
see
blocks
that
have
C
in
them.
That
means
you
got
interrupt
all
the
way
through
encrypted
data,
which
is
really
really
terrific,
so
protected
packets
in
the
whole
bit.
So
you
know
no
fundamental
problems
found.
G
We
reported
a
couple
issues
that
are,
a
number
of
things
were
just
purely
editorial
sort
of
you
know,
knits
of
things,
the
worse
syntactically
wrong
on
the
drafts
and
a
couple
to
open
for
consideration,
but
nothing
like
baking,
structural,
so
I
think
you
know
what
the
working
group
meant
to
write
down
for
those
drafts
is
mostly
as
people
understood
it.
So
that's
a
that's
a
good
time
for
the
editors
right,
Thank.
G
I
and
I
would
add
that
there
was.
You
know,
informal
discussion,
that
this
is
a
good
thing
to
do
in
right
before
each
meeting,
because
it
makes
all
the
issues
fresh
and
everyone's
behind.
So,
whether
that's
you
know
the
hackathon,
it
IHF
plenaries
or
our
interims
to
set
aside
a
little
bit
of
time.
It
seemed
to
be
a
very
useful
thing
to
have
in
our
frequent
cadence
right.
A
A
H
A
I
A
A
The
first
implementation
draft,
as
Patrick
mentioned
was,
was
pretty
basic.
We
only
discussed
the
initial
handshake
and
using
one
stream
and
doing
a
close
if
some
basic
encrypted
data
transfer
and
as
you
can
see,
we
we
did
pretty
well
at
that,
although
it
was,
it
was
rough
going
at
first,
they
got
most
of
that
done.
There's
still
some
work
to
do.
There,
I
think
we've
also
defined
or
started
to
talk
about.
J
D
K
A
L
A
What
can
we
take
forward
into
the
second
implementation
draft?
Are
people
still
happy
with
the
scope
that
is
starting
to
be
documented
here?
I
wouldn't
call
this
done,
but
I
think
we
need
to
start
getting
more
serious
about
it.
If
we're
going
to
have
a
give
people
a
chance
to
implement
before
the
October
meeting.
N
Okay,
well,
hello,
everybody
I
I
want
to
first
clarify
what
the
second
draft
isn't
what
it
does
not.
This
is
a
feature
set
that
we
are
seeking
implement
after
this
set
that
we
are
implementing
today.
If
this
initial
set
of
features
requires
multiple
IETF
giraffes,
then
that's
somewhat
orthogonal
to
what
we're
addressing
here.
N
What
they
will
not
include
I
think
this
is
down
at
the
bottom
of
the
document,
if
you're
scrolling,
Lars
or
mark
there
we're
not
we're
not
gonna
address,
we
think
of
reach
consensus,
at
least
on
mailing
list,
that
that
there's
not
a
lot
of
interest
in
gaining
key
updates,
post,
handshake
connection,
ID
changes,
and
you
know
IP
migration
and
in
PMT
you
discovery
into
the
second
draft.
So
that
really
leaves
everything
in
between
and
they're.
Essentially,
three
concepts
forget
about.
N
The
word
recommended
that
was
I
should
probably
deleted
that,
but
that's
where
I
originally
thought
we
were
going.
The
the
first
strategy
is
basically
to
settle
the
wire
image.
There's
some
fear
that
middle
boxes
are
already
starting
to
ossify
on
the
existing
visible
fields
in
the
public
header
and
the
initial
unencrypted
packets,
and
so
this
strategy
really
focused
on
nailing
down
for
good
a
lot
of
the.
N
What?
What
you
can
see
in
that
in
that
image,
which
is
a
lot
of
the
the
public
packets,
the
the
header
format,
there
are
some
issues
open
on
how
to
on
how
we
can
possibly
encrypt
packet
numbers
and
otherwise
toy
with
the
public.
Header
really
just
knew
all
that
stuff
down
and
then,
if
anyone
is
gonna
try
to
deploy
this
at
scale,
you
would
also
have
to
include
loss,
recovery
and
congestion
control.
N
Basically,
implementing
all
the
features
that
are
going
to
have
an
impact
on
how
quickly
quick
delivers
data,
so
this
is
gonna
require
really
implementing
the
HTTP
2
mapping
and
putting
in
a
lot
of
the
performance
relevant
features
like
loss
recovery
could
just
ctrl,
0,
RT,
T
and
probably
resumption
and
I.
Think
that
is
it's
pretty
straightforward.
Why
we
would
do
those
those
things
and
then
the
third
strategy
is
maybe
sort
of
a
mix
of
the
two
and
and
I've
decided
to
call
this
one
deployable
at
scale.
N
This
is
the
in
sweats
suggestion,
so
this
is
one
that
actually
that
doesn't
really
push
the
wire
image
too
much,
but
uh-oh
there's
a
typo
here:
oh
no,
ok,
yeah!
So
I
think
this
has
been
duplicated
in
a
weird
way,
but
right
so
so,
but
but
basically
do
the
HP
2
application,
some
of
the
other
performance
issues
and
then
loss
recovery
and
congestion
control.
So
you
can
actually
put
stuff
out
on
the
field
and
get
experience
with
it.
That
way
so.
N
G
G
Jonathan
talking
to
my
ear
they're,
making
me
ponder
other
scenarios.
I
would
like
to
have
us
focus
on
particular
the
handshake
items
which
I
think
it's
been
successful
so
far
to
get
to
the
really
core
features
of
what
we're
trying
to
you
know
achieve
here.
So
0
RTT
and
the
things
that
enable
zero
RTT
are
a
very
big
deal
for
me.
So
HRR
was
called
out
in
one
of
these
scenarios.
I
think
that's
a
big
deal.
G
I
think
Transport
parameters
is
the
big
deal
and
zero
RTT
and
I
think
there
are
going
to
be
interruption
just
getting
there.
So
what
we
saw
this
last
weekend
was
that
we
were
butting
up
against
the
edge
of
TLS
one
three
deployments.
What
was
the
interesting
of
that
graph?
You
are
the
the
inner
upgrade
you
put
up
earlier
was
those
were
the
quick
implementations,
but
the
variety
of
TLS
implementations
in
use
was
almost
as
broad,
so
picot
TLS
was
used,
open,
SSL
was
used,
boring
SSL
was
used
in
NSS
was
used
and
mint
was
used.
G
I
guess
that
actually
is
as
broad.
That's
five,
some
of
them
for
more
than
one
implementation
and
we
were
able
to
like
sometimes
go
to
18
and
sometimes
to
20
and
sometimes
to
21
right.
But
as
we
get
into
these
things
of
needing
the
API
is
for
the
zero
RTT
features
and
the
transport
features,
and
all
of
that
we're
gonna
start
bumping
into
that,
which
I
think
is:
okay.
I
almost
think
it's
a
forcing
function
on
the
TLS
things,
and
maybe
we
want
to
put
that
down
now
and
not
discover.
O
Martin
Thompson,
one
of
the
things
we
discovered
in
HTTP
2,
was
that
our
our
single,
simple
dependency
on
TLS
was
was
a
Rico
Burton
and,
to
that
end,
I
think
including
the
transport
parameter
exchange
and
the
stateless
retry
is
actually
critical
to
all
of
this
I.
Don't
think
we
want
to
take
on
zero
ICT
in
this
in
this
next
next,
one
I'm,
sorry
to
say
that,
but
I
think
we
need
to.
We
need
to
be
a
little
more
incremental
in
this.
That's
a
that's!
O
A
big
ask
and
I
understand
that
this
is
it's
also
kind
of
important
that
we
get
to
the
bottom
of
all.
The
issues
that
that's
kind
of
raised,
because
my
experience
with
implementing
zero,
RCT
and
TLS
was
that
Debbie
Debbie
dragons
it's
really
complicated
and
the
way
that
the
zero
RTT
will
interact
with
handshake
is
frightening
ly
difficult.
But
that's
the
same
reason.
O
Why
I
think
we
should
try
to
keep
the
increments
relatively
small,
so
I
think
this
first
one
is
probably
the
best
for
what
we
have
and
yeah
I
think
we
can
probably
scale
back
the
loss,
recovery
and
gesture
and
controllers
Martin
suggested,
but
I
think
I
think
just
having
them
there
and
saying
that
you
got
to
do
that
is
necessary.
Now
it
might
be
that
it's
not
the
full-blown
thing,
but
I
don't
want
to
see.
Someone
did
send
every
single
packet
that
they
ever
want
to
send
all
at
once.
That
would
be
setting
that.
K
They're
wrong
so
I
agree
that
it
would
be
good
to
get
their
primp
all
the
things
that
required
these
sort
of
external
interfacing,
the
cellist
at
Yelp
down
soon.
Is
it
good
I'm
less
sanguine
about
this?
Is
locking
down
the
unencrypted
wire
image
part
and
the
reason
is
you
still
have
a
number
of
questions
about
what
that
should
actually
look
like,
ranging
from
ranging
from
you
know,
truven
sequence
numbers
to
these
data
structures
where
we
start
with
like
control
bits
and
then
emphasize
where
it's
all
in.
K
That
we
have
to
get
into
so
I,
don't
think
it's
plausible
think
we're
gonna,
you
know
lock
down
into
wire
image
and
I
mean
unless
we're
gonna,
almost
we're,
basically
just
like
Reese,
like
basically
sure,
throw
away
everything
in
the
meeting
and
the
meeting
and
and
argue
about
whether
secret
sequence
numbers
or
whether
we
have
variable
integer
encoding.
K
Can
lock
the
lock
wire
image
without
prematurely
deciding
this
issues
so
I'm
I'm,
sort
of
ambivalent?
On
these
questions
of
the
of
loss,
recovering
congestion,
control,
the
I'm
not
sure
I
care
with
them,
obviously
important,
but
this
seems
sort
of
ol
I
know
that,
like
you
know
that
I
don't
think
it
does
anybody
do
act
I'm
properly
yet
so
it
seems
like
we're
actually
a
little
far
away
from
like
having
even
plausible
collation
is
the
base
of
things
I,
don't
think
I
think
neither
larger
I
properly
handle
Zack
ranges
either.
K
So
I
think
you
know
where
I.
So
you
know
these
are
still
pretty
unbaked
in
that
environment.
You
know
a
good
target
here
might
be,
like
you
know,
having
your
implementations
actually
converging
or
recent
period
of
time
one
state
has
been
sent
out.
You
know
things
are
like
you
know
that
the
target
of
like
here
is
that
once
you
and
then
which
I
know
we've
seen
number
of
times
so
I
think
you
know,
you
know
what
maybe
instead
of
phrasing.
K
This
this
way,
you'd,
say
like
the
implementations,
must
be
stable
under
various
losses,
so
that
you
know-
and
we
talked
about
simulating
that
like
it-
should
be
the
case
that
you
should
be
able
to
turn
on
some
data
and
then
have
a
bunch
of
a
bunch
of
packet
loss
and
haven't
like
not
freak
out.
It
would
be
like
a
good
start,
so
yeah
that
would
be
I
think
this
is
I,
think
I,
guess
what
the
mental
target
I
have
in
my
head
is
like
good
enough
to
build
like
a
plausible.
P
Q
Ian
sweat,
Google,
I,
largely
agree
with
with
Eckert
or
all
the
things
I
think
he
said,
except
instead
of
a
simple
single
streamed
application.
I
would
very
much
like
to
do
HTTP
with
the
static
HVAC,
and
one
of
the
reasons
is.
There
is
no
point,
in
my
opinion,
in
doing
flow
control
and
stream
level
flow
control
unless
we
actually
run
something
over
it.
Q
R
S
R
K
So
actually,
one
thing
that
I've
been
thinking
about
is
that
you
know
for
the
perspective.
Obviously
we
are
focusing
HTTP
first,
but
obviously
for
KH
to
be
first,
but
this
is
a
generic
system
and
although
it's
a
diversion
from
our
you
know
from
where
we're
trying
to
go,
I,
don't
think
being
able
to
run
h1
over.
This
might
be
a
reasonable
thing
to
do,
because
you
know,
then
we
don't
they.
You
know
that
actually,
the
HTTP
flows
with
embarrassing
Jen.
R
Ayah,
just
chiming
in
on
the
on
the
same
discussion,
I
think
HDB
to
over
a
single
stream
would
basically
be
diagramming
HTTP
over
TCP,
so
you
got
an
unmodified
HTTP
to
over
a
single
stream
with
quake,
and
that
would
work
just
as
well
so
I
I
personally
I
I
I
think
that
we
should
have.
We
should
specify
what
application
we
are
talking
about,
not
just
say
a
single
stream.
The
application
and
I
would
propose,
as
I
just
said,
HDB
to
running
on
top
of
a
single
stream
separately.
R
I,
don't
understand
what
the
deployed
scale
needs
to
do.
I,
don't
think
anybody's
going
to
be
deploying
at
scale,
but
but
I
think
that
having
lost
recovery,
that's
documented
in
there
is
quite
useful
implementing
loss
recovery.
At
this
point.
If
we
have
it
all
written
down,
it
ought
to
be
possible
to
implement
that
and
do
that
to
occurs
earlier
point
about
nailing
down
the
wire
format.
I
agree
that
the
wire
format
is
not
completely
hundred-percent
done,
and
we
know
that
for
a
fact.
R
We
know
that
it's
going
to
take
a
long
time,
but
it
doesn't
it
also
shouldn't
mean
that
we
are
not
going
to
call
the
wire
format
done
for
two
years,
I'd
like
for
us
to
have
some
that
we
consider
reasonably
stable
and
we
will
have.
We
might
have
some
changes
going
forward,
but
if
that
allows
us
to
start
thinking
about
actual
deployment,
I
think
it's
useful.
Just
this
morning,
I
was
presenting
in
mapache,
and
one
of
the
things
that
pointed
out
was
that
the
Google,
quick
wire
format
is
already
a
bit
ossified.
R
A
O
Is
definitely
ahead
of
me.
I
heard
someone
raised
the
point
of
flow
control
and
all
of
that
I
would
actually
I
would
actually
say
that,
because
we
know
that
flow
control
is
a
little
bit
tricky.
I
would
take
it
out
of
this
and
say
that
not
to
the
point
that
I
would
say,
we
put
it
in
very
carefully
and
say
that
you're
expected
to
respect
flow
control,
but
not
actually
manage
it,
and
that
is
to
say
that
you,
you
start
out
the
connection
and
you
may
and
probably
should
send
stream
limits
that
are
basically
ridiculous.
O
H
G
T
Q
Hi
Brian
Trammell
actually
yeah
pretty
much
what
Becker,
John
and
Martin
said
sort
of
in
that
row
and
in
that
row,
let's
not
start
a
g1
without
walking
down
the
wire
image,
looks
pretty
good
to
me
the
thing
that
I'm
afraid
of
when
we
start
talking
about
a
second
implementation
draft
that
starts
looking
like
a
an
application
that
somebody's
going
to
go,
implement
and
then
say:
okay.
Well,
this
is
quick
and
then
not
update
right.
We
want
to.
We
want
to
be
careful
about
getting
stuck
at
second
implementation
with
people
outside
this
room.
Q
So
as
long
as
we
don't
have,
the
mechanisms
that
are
fully
baked
like
so
flow
control
is
scary.
For
example,
zero
RTT
is
super
scary.
Then
we
should.
We
should
probably
hold
off
from
saying
okay
well,
this
is
gonna,
be
we're.
Gonna
actually
run
like
full-blown
h2
over
this
or
something
that
looks
like
full-blown
h2
over
this
cuz
people.
Then
just
do
it
so
I'm
a
little
scared
of
that,
but
I
like
where
we
are
with
the
strategy,
one
without
the
hard
lockdown.
T
S
S
A
K
On
two
points,
one
I
do
think
it's
important
that
we
try
to
get
the
wire
image
nailed
down
relatively
soon.
I
think
that
means
we
should
be
prioritizing.
We
should
be
between
now
and
the
interim.
We
should
be
collecting
questions
which
we
think
impact
the
unencrypted
wire
image,
and
then
we
should
be
are
prioritizing
those
at
the
interim
for
debate
and
I
know
that
I
am
the
owner
of
several
of
those,
and
I
will
work
to
do
that.
The
that
I
do
understand.
Christians
point
I
have
that
I
was
thinking
about
this.
K
Actually,
as
I
was
sitting
down,
I
think
this
is
one
of
the
situations
where
your
light.
Your
language
equation,
really
impacts
your
behavior,
namely
that
and
go
it's
like
super
easy
for
me
to.
Like
a
lengthy,
you
know
the
go
H
to
H,
to
stack
on
top
of
my
thing
and
so
I
don't
really
care
about
it
being
about
it,
but
I
can
understand
now
for
I
thought.
K
It
may
pretend
to
be
much
more
miserable,
I
think
what
you
want
to
make
sure
is
that
is
that
people
do
build
implementations
that
are
like
truly
generic
implementations
and
not
just
like
integrated
top
to
bottom.
You
know
muck,
and
so
that's
part
of
why
I
was
resisting
the
quick
HTTP
hu
q,
as
the
easiest
for
this
question,
I,
don't
know
I'm
not
sure
how
to
how
best
to
square
that
circle,
maybe
like
maybe
one
way
to
think
about
this-
would
be
that
doing.
K
K
U
D
R
Good
Jan,
Iyengar,
I
I
agree
with
I
could
on
the
wire
image.
I
think
we
we
should
absolutely
prioritize,
and
that
was
part
of
my
goal
and
in
raising
that
issue
early
on
the
meaningless
is
that
I
think
we
really
should
be
discussing
all
the
issues
related
to
the
the
wire
image
and
try
to
nail
them
down
as
quickly
as
we
can
prioritizing
them,
for
the
interim
makes
complete
sense
so
separately.
I
agree
that
with
flow
control,
what
Martin
modeled
out
that
not
requiring
just
advertising
a
large
window
makes
sense.
R
If
we
put
all
of
that
in
the
same,
interrupt
on
the
application
itself,
I
figured
I
had
assumed
that
people
would
be
able
to
simply
take
an
issue
implementation
and
and
run
this
on
top
of
a
single
or
a
stream.
But
if
that's
difficult
to
do,
I
I'd
be
fine
with
having
something
simpler.
People
who
are
able
to
do
h2,
but
that's
I
mean
each
one.
You
would
have
the
same
issue
unless
you're
implementing
it
again
in
a
simple
way,
in
which
case
I
don't
get
what
you
implemented.
R
I
mean
you
could
implement
your
own
little.
We
could
implement
a
very
simple
as
a
coset
just
adjust
the
gate
and
the
response,
and
one
single
application
file
transfer
an
amplification
service.
Exactly
you
could
implement
an
amplification
service
there.
We
go
a
glorified
echo,
yes,
so
that
so
these
are
all
the
suggestions
coming
off
the
floor.
So
I
think
those
are
all
fine.
Q
Yes,
well
I
wouldn't
say
that
though
I
recommended
the
idea
of
doing
the
HTTP
2
mapping
without
with
static
HVAC
I'm
happy
with
anything
that
I
think
will
exercise
enough
of
the
other
flow
control
and
stream
flow
kind
of
flow
control.
Machinery
to
be
like
moderately
realistic,
like
I,
don't
really
care
what
the
actual
application
is.
I,
just
don't
want
us
to
implement
a
bunch
of
flow
control
stuff
and
then
not
like
actually
use
it.
Like
is,
if
we're
gonna
do
that
we
should
just
like
get
rid
of
like
we
could
just
not
do
it.
Q
U
V
L
The
I
think,
if
we
do
the
lock
down
the
wire
image,
we
may
need
to
address
a
number
of
the
issues
listed
here
on,
as
the
do
not
address
list
first
and
particular
example:
path.
Mtu
discovery
we
very
like
very
likely
may
want
to
look
at
whether
we
want
things
in
the
wire
image
to
do
the
unencrypted
I'm
a
handshake
to
do
that.
To
do
some
of
the
MTU
negotiation
as
well
as,
if
you
want
to
let
middleboxes,
do
MSS
clamping
and
the
for
the
changing
connection,
IDs,
post
handshake.
N
So
I,
if
I,
can
try
to
capture
the
consensus
in
the
room
it
feels
like
people
are
mostly
interested
in
a
densely
modified
version
of
strategy,
one
the
term
lockdown
was
probably
ill-judged
in
the
first
place
and
and
if
people
fight
lee
pushback
against
it,
you
know.
Obviously
nothing
is
fine
until
its
final,
but
I
think
the
intent
is
to
converge
on.
N
A
T
A
W
Q
A
Q
H
Q
Can
you
hear
me
now
Oh,
almost
all
of
quick
is
encrypted,
including
ass.
As
you
probably
know,
if
you
hear
network
monitoring
and
aqm
systems
use
our
t
te
fairly
extensively
from
what
I've
gathered.
Certainly
internally
I
found
that
the
people
seem
to
want
this
and
seems
to
be
the
most
requested
feature
for
network
monitoring
and
passive
monitoring
of
quick.
Currently,
only
the
handshake
RT
is
visible,
but
correlating
the
packet
types,
and
this
is
no
thanks.
Q
Yes,
RT
t
and
based
on
variation
from
artis,
widely
used
for
trouble
detection
network
management.
All
that
good
stuff.
You
can
figure
out
kind
of
the
minimum
Network
latency
from
menara
TT.
You
can
figure
out
buffer
bloat
from
deviation
and
growth
and
RT
t.
There
are
a
bunch
of
ways
in
TCP
to
do
this.
Most
of
them
are
actually
not
super
exact,
which
is
a
whole
different
problem.
Q
So
weirdly
enough,
you
know
if
we
gave
the
network
and
explicit
signal
we
might
be
in
a
better
place
in
terms
of
the
quality
of
our
TT
measurements
in
quick
and
our
T's
are
also
used
on
top
fairly
often
apparently
for
aqm
systems
for
down
stream
buffer
tuning.
So
and
yes,
quick,
currently,
doesn't
expose
anything.
Q
Q
That's
useful,
although
if
you
see
a
bunch
of
quiescence
and
you
see
a
request,
go
by
and
then
a
response,
it's
probably
about
equally
correlated
well
I,
doesn't
seem
like
a
major
issue
but
figure
to
call
it
out
and
then
minnow
TC
does
actually
expose
an
upper
bound
on
the
physical
distance
between
two
points.
Whatever
that's
worth
I.
The
other
concern
is
basically
people
muck
this
up
that
certainly
never
been
done
before
so
I.
Don't
see
why
it
would
be
done
in
the
future
but
yeah
and
then
they'll
start
managing
their
network
earlier.
Q
Do
you
pour
about
14
in
home
next?
So
we
should
make
this
easy,
because
I
don't
want
them
to
mess
it
up.
Okay,
option,
one!
We
can
do
nothing!
It's
the
status
quo.
That's
no
complexity!
It's
super
easy!
No
privacy
concerns
the
negative.
Is
you
know,
networks
maybe
have
a
harder
time
managing
their
own
infrastructure.
Q
Q
Q
Thank
you,
okay,
yes,
so
innovative
middleboxes
will
attempt
to
infer
RT
t
if
we
do
not
give
them
this
to
them,
and
goodness
knows
what
they
will
do,
but
it
probably
will
ossify
the
wire
format
more
than
we
would
like.
So
it
actually
may
cause
negative
consequences
for
quite
conservative
ossification.
Q
Option
number
two
is
one:
we've
been
talking
about
for
a
while:
a
packet
number
echo.
Essentially
quick
has
packet
numbers,
you
can
see
them
as
they
go
by
in
one
direction
and
you
can
echo
it
in
some
specified
portion
of
the
packet
in
the
packet
header
an
encrypted
portion,
but
the
attend
ocation
ported
portion
on.
Q
You
know,
I
see
three
go
this
way.
Three
comes
back
the
other
way,
and
you
know
you
can
you
can
correlate
the
packet
and
get
an
RTT
measurement
becomes
a
little
bit
more
tricky
if
we
encrypt
packet
numbers,
but
it
still
is
a
viable
option.
So
you
know,
say
you
say
four
bytes
of
gobbledygook
go
in
this
direction.
You
can
match
it
with
the
same
four
bytes
of
gobbly.
Go
in
the
other
direction.
Q
The
idea
would
be
that
if
the
packet
number
is
encrypted,
that
still
that
value
that
was
on
the
wire,
the
the
value
that
the
middle
box
sees
would
still
be
in
like
reflected
in
the
other
direction,
and
so
you
still
have
the
same
token
essentially
to
correlate
the
two
numbers
yeah,
instead
of
becoming
a
packet
number,
becomes
a
random
token
yeah.
So
someone.
O
Q
Yeah
Oh
some
some
negatives
include
the
fact
that
it
does
consume
a
few
bytes
on
the
wire
which
is
not
the
end
of
the
world.
The
the
more
annoying
part
for
implementation
perspective
is
it
changes
your
payload
length,
which
is
a
little
bit
just
tedious
to
deal
with
it
based
on
actually
writing
code
that
changes,
payload
length
and
measurement
may
be
fairly
memory.
O
Length
sure
you
know
so
on
Thompson.
The
other
comment
you
didn't
mention,
which
again
was
kind
of
trivial
and
probably
not
even
worth
mentioning-
is
that
it
does
allow
packets
lighted
part
of
the
point
of
encryption
encrypting.
Your
packet
numbers
would
be
to
prevent
correlation,
but
this
explicitly
reenable
x'.
That.
A
K
Q
R
Q
B
You
could
have
been
adding
to.
It
is,
first
of
all,
the
complexity
of
the
measurement
really
depends
on
how
much
your
effect
right
say.
If
you
would
just
reflect
over
every
packet,
it
would
be
a
super,
simple
and
also
I
think
the
the
ability
to
be
able
to
decide
not
to
reflect
as
rather
something
that
we
should
have,
but
there
could
also
be
case
regicide
taking
every
packet
because
you
just
tap
the
space
or
whatever.
B
Not
a
clarification
is
a
clarification
point,
because
there's
a
list
of
cross
and
content,
we're
discussing
and
I'm
editing
to
it
because,
like
that
moves
actually
from
the
cons,
maybe
and
what
I
want
to
enter
the
pros
is
like
it
also
is.
It
can
be
used
as
a
confirmation
signal
because
it
Carly
so
packets,
write
very
clearly,
and
we
need
to
sometimes
and
yeah
might
be
pro
that.
Q
Is
a
good
point:
I
it.
It
is
a
confirmation
signal
which
has
a
lot
more
entropy
than
the
other
case,
the
one
bits
of
average
side.
Okay,
now
we
get
to
the
fun
part,
animations
all
right,
so
option.
Number
three
is
one
spin
bit
set
per
RTT,
so
essentially
you
can
see.
There's
one
packet
number
with
the
little
one
set
there
there
and
all
the
others
are
0
and,
as
you
use
page
through
the
slides,
it
will
gradually
move
around
to
the
server
and
then
come
back
to
the
client
and
they're
great.
Q
Okay,
great
so
one
spit
bit
for
priority
T
provides
you
downstream
RTT
provides
you
total
RTT,
and
it
also
provides
you
approximate
congestion
window.
Since
you
know
about
how
many
packets,
when
do
I
between
the
time
you
you
see
the
bit
like
flip
each
time,
so
that's
very
nice
for
like
bandwidth
measurement
as
well
as
RTT
measurement.
The
con
is
that
it
must
be
restarted
once
it's
lost.
Q
X
R
Q
Q
Q
Q
Be
restarted.
What's
lost,
I
mean
that
when
the
packet
that
has
the
bits
set
is
lost,
then
suddenly
you
have
a
bunch
of
like
zeros
going
around,
and
one
of
the
peers
must
like
know
when
to
like
start
marking
again,
so
they
can
start
their
like
packing
unpacking.
When
we
understand
how
to
do
that,
we
I
mean
we
have
some
text.
Okay,
Charlie
I
wrote
it
is
possible,
it's,
but
it
may
take
time
to
do
right.
Q
Basically,
you,
the
typical
algorithm,
is
like
only
one
of
you
starts
it
like
only
the
client
can
start
it
and
the
client
starts
it
when
it
realizes
that,
like
the
signal
has
been
lost
based
on
lost
detection
or
some
combination
of
it
not
being
repeated.
That
path
appear,
it's
it's
not
interactively
hard,
but
it's
not
trivial.
Ivan.
H
Q
Q
D
Z
Q
Option
3a
has
the
identical
bit
value
for
an
entire
RTT
of
packets,
the
connection
initiator.
The
client
sends
packets
with
this
VIN
values.
A
of
up
the
pure
reflects
this
pin
in
response.
So
that's
the
same
value
and
then
the
initiator
flips
it
every
time.
It's
it.
So,
as
you
well
flip
through
slides
ones,
will
go
around
and
yeah
there
we
go.
Q
Q
It
does
require
the
endpoints
to
kind
of
fix.
The
signal
up
upon
reordering,
otherwise
reordering
can
sort
of
degrade
into
essentially
noise
in
the
worst
case
situation,
because
the
river
just
sort
of
like
matches
up
this,
this
zero
bits
cream
into
binary,
gobbly
and
the
middle
point
may
have
to
do
some
filtering
to
kind
of
get
it
correct.
Arts
d
estimate,
because
in
the
case
of
reordering
you
may
say,
c:
0
0,
0,
1,
0,
1,
1,
1,
1
1,
so.
O
Q
Q
F
AA
AA
That's
chrissteele
hunterson
just
understand
this
when
you
say
that
fills
it
out
to
account
for
reordered
bits
dooming,
you
can
always
tell
that
you've
got
an
incorrect
results
and
there
you
can
throw
those
away
or
whatever
my
main
concern
would
be
mismatches
which
give
me
a
false
reading
humans.
So
the
what.
Q
Would
actually
happen
is
kind
of
what
I
verbally
gave
them
as
an
example,
which
is,
you
would
have
a
string
of
zeros
that
would
be
about
to
change
to
a
string
of
ones,
but
one
of
the
ones
would
get
reordered
in
front
of
one
of
the
0.
So
you
it
would
go.
0
0,
0,
1,
0,
1,
1,
1,
1,
1,
1
1,
and
so
that's
what
I
was
saying
you
may
have
to
apply
a
smoothing
filter.
Q
Actually,
unless
you,
however,
if
you
still
have
a
packet
number
exposed
it's
easy
to
throw
away
bad
results,
you
can
just
discard
reorders
as
martin
method.
So
if
as
long
as
packet
number
is
exposed,
I
I
guess
I
would
say
from
a
technical
perspective,
it's
pretty
clear
to
me
that
3a
is
strictly
superior
to
3
in
terms
of
robustness,
Jenna.
R
And
God
I
think
3
is
superior.
Even
it
says
the
fact
that
it's
resilient,
the
loss,
makes
it
makes
it
much
much
better
than
option
three
I
like
option:
three.
Eighth,
if
this
is
something
that
we
want
to
do,
the
on
the
in
the
condom,
art
guesstimate
being
filtered
for
the
ordering,
that's
something
that
middle
boxes
have
to
do:
anyways
for
TCP,
it's
not
new
for
quick.
As
you
said,
if
packet
number
is
visible,
then
it's
basically
the
same
thing
that
they
do
for
TCP
anyways.
Even
today.
R
AB
AB
Spectral
methods
for
finding
RT
T's
of
self
clocked
window
congestion
control
protocols
that
require
no
two
labeling
on
the
packets
whatsoever.
They
even
work
when
it's
inside
an
ESP
tunnel
and
you
only
have
one
half
of
the
connection.
So
you
can't
hide
this
information,
even
if
you're
trying
to
hide
it.
H
R
Safe
clocking
is
not
a
requirement
of
the
protocol,
although
I
think
your
point
is
that
you
can
measure
RTD
using
some
of
the
techniques
I
think
you
mentioned
this
earlier
right
that
that
middleboxes
will
end
up
doing
something
to
find
this,
because
it's
a
signal
they
care
about,
and
the
question
is
whether
we
should
expose
something
so
that
the
endpoints
are
free
to
do
whatever
else
they
want
to
go.
They
may
not
do
self
clocked
constants.
Q
AC
Q
AC
G
Think
I
mean
I.
Think
I
really
appreciate
the
presentation
D
and
gave
him
the
initial
slides
I
think
it
described
the
trade-offs
well
and
I
think
essentially
exposing
any
information
to
the
to
the
path
here
is
not
commensurate
with
the
potential
long-term
loss
of
what
we
don't
understand
about
traffic
analysis
and
that
kind
of
thing
I,
don't
they.
The
wind
here
is
nearly
big
enough
to
start
going
down
that
path.
AA
Chrissteele
I
think
broadly
for
me3
a
is
a
big
step
forward.
I
do
work
for
an
operator
and
we
do
with
TCP
you
sequence,
ACK
measurements,
Network
wide
to
find
cue
delays
and
find
hotspots
in
our
network
and
therefore
do
network
planning
fix,
and
actually
it's
turned
out
to
be
a
much
earlier
warning
sign
of
network
problems
than
traditional
methods.
The
other
thing
I'd
say
is
discussion
earlier
about,
even
if
the
packet
header
is
encrypted
into
copy
2,
googly
I
think
you
said
that
it
would
still
be
the
same.
R
M
AA
D
Q
J
Sorry
very
fast,
three
and
three
a
are
like
processed
data,
and
that
may
be
okay,
but
I
mean
the
real-time
I
want
to
see
these
numbers
that
when
things
are
going
wrong,
when
we've
got
packet
loss
when
got
varying
RTT
and
I,
don't
quite
figure
out
how
3a
and
3b
work
but
I'm
trying
to
measure
jitter
and
variation
of
RTT
I
mean
I
know:
that's
not
what
the
transports
trying
to
do,
but
I'm
trying
to
use
to
debug
the
aqm
or
later.
So
that's.
Q
Think
it's
up
to
the
working
group
to
decide
if
this
is
must
should,
in
my
opinion,
I
have
opinions,
but
that's
not
really
the
point
and
then,
in
terms
of
middle
bosses
being
able
to
tell
whether
an
endpoint
is
doing
it.
You
know
we
can
specify
something
like
you
must
do
this
on.
You
know
the
first
or
you
you
know
you
must
start
with
some
value
on
the
first
flight
or
something
and
you
know
presumably
fairly
quickly,
you
could.
You
could
tell
it
what's
going
on
I,
don't
know,
but
it's
a
good
question.
T
X
X
Who
would
want
to
do
something
with
this
if
it
was
exposed,
doesn't
like
I'm,
not
sure
whether
that
was
an
intent,
a
poll
intended
to
indicate
that
we
should
do
something
because
more
people
do
it
or
because
people
won't
I'm
frankly
concerned,
given
what
the
network
operators
have
done
with
other
information
that
we've
exposed
in
the
past
like
port
numbers,
and
we
saw
how
that
worked
out.
So
the
idea
that
we're
going
to
deliberately
expose
something
to
the
network
operators
because
they
want
to
do
something
with
it,
doesn't
strike
me
as
an
argument
for
adoption.
X
D
The
tussle
you
said
repeatedly:
sort
of
requests
that
there's
information,
that's
useful
or
may
be
useful
for
traffic
management
and
and
part
of
the
paradigm
which
we
try
to
find
the
smallest
amount
of
information
that
that
could
be
leaked,
which
is,
in
this
case
the
one
bit
scheme
that
would
give
the
operator
some
information
that
they
claim
they
need
to
manage
their
networks
while
at
the
same
time,
not
exposing
anything
internally
too
quick.
But
it
still
might
be
two
months
right.
But
this
is
what
we're
trying
to
find
is.
X
The
effort
to
minimize
it
and
to
scope
it,
but
like
port
numbers,
are
an
example
of
that,
though,
of
here's
a
limited
set
of
how
you
can
do
multiplexing,
and
we
know
that
network
operators
have
not
only
damaged
the
port
space
but
they've
gone
into
much
deeper
packet
inspection
beyond
the
port
space.
So
it's
not
like
if
we
give
them
a
little
thing
than
that.
That's
going
to
be
enough.
It's
not
going
to
stop
people
from
the
con
of
the
option.
X
D
God
that'd
be
brief:
I
just.
P
AD
AD
Other
minor
comments
is
in
the
same
way
that
there's
no
assumption
about
self
locking
I'm,
not
sure
there
should
be
assumption
about
the
reverse
path
that
the
packets
follow,
because
you
might
as
a
middle
box,
and
we
see
part
of
the
reverse
path
and
packets
might
be
flowing
through
the
they're
like
another
path
that
is
invisible
to
you
in
the
network
and
depending
on
that,
whether
you,
like
you,
take
into
consideration
that
might
affect
different
options
differently.
I.
R
I'm
Jen,
eyeing
or
I
I
think
it's
valuable
to
have
a
noir
discussion
right
now,
but
we
do
have
an
existence,
proof
of
something
that
might
work
but
I.
Don't
think.
That's
necessarily
means
that
this
is
something
we
will
do
so
knowing
what
folks
think
or
about
whether
we
should
do
this
or
not,
is
still
a
very
useful
thing
and
I.
AA
Color
Parkins,
so
I
guess
there's
two
points.
Firstly,
if
this
is
likely
to
be
problematic,
we
should
have
heard
that
the
technique
is
problematic
because
TCP
has
been
doing
it
for
many
years
has
been
exposing
this
information.
So
if
there
are
problems
in
exposing
this
information,
they
should
have
surfaced
by
now.
AA
Well
so,
but
if
there
are
problems
then
rather
than
saying
you
know,
here
are
the
vague.
We
don't
know
what
the
problems
are,
but
they
might
surface
in
the
future
comments
which
have
come
out.
Then
we
should
list
the
problems
in
exposing
this,
this
ITT
information
and
have
that
discussion,
because
I've
heard
several
people
say
we
don't
know
what
the
problems
are,
but
something
might
might
surface
if
we
expose
this.
H
AA
There
are
hypothetical
problems,
the
the
the
main
reason
I
stood
up.
This
is
obviously
providing
information
once
per
round
tripping
and
you
can
get
one
round-trip
sample
round-trip
time.
A
lot
of
the
uses
for
round-trip
time,
sampling
and
measuring
the
round-trip
time
are
to
identify
dynamic
problems.
Looking
at
how
the
the
delay
changes
during
a
round-trip
time,
for
example,
and
that's
not
possible
using
this
mechanism
now,
you
may
or
may
not
consider
that
a
problem,
but
it
is
a
difference
from
what's
possible
using
the
analysis
in
TCP,
for
example,
and
yeah.
W
It's
at
all
ready
before
I
begin
to
the
chairs.
Brian
was
actually
behind
me
in
line.
If
ok
I
was
just
gonna
say
if
you're
gonna
just
have
one
more
person,
please
let
it
be
Brian
because
he
certainly
knows
more
about
measurement
and
I.
Do
I
got
up
on
Wendy
kg
was
making
his
point,
and
although
I
certainly
agree
that
there
are
forms
of
traffic
analysis
that
this
would
allow
I
think
those
forms
of
traffic
analysis
are
also
the
forms
of
traffic
analysis
that
are
basic
to
network
measurement
for
network
planning.
W
Having
done
network
planning
on
a
bunch
of
different
networks
being
able
to
see
when
the
round-trip
time
is
changing
when
you're
looking
at
a
link
that
crosses
more
than
one
here
is
a
pretty
basic
form
of
analysis
that
you
use
both
in
traffic
engineering
to
see
whether
or
not
you're
going
to
use
that
particular
link
in
the
future.
To
talk
to
that
peer
or
other
things
so
well,
I
I
certainly
understand
the
concern.
D
So
yeah
I
want
to
be
actually
so
want
to
reopen
the
queues
since
this.
Actually,
you
you
guys,
are
very
good
and
drained
it
fast,
because
I
think
faster
transport.
K
Eres
Cola
tell
me
I
must
say
I'm
baffled
by
your
argument.
We
know
TCPS
horrific
privacy
problems
and
the
reason
that
we
don't
have
probably
grounds
for
this
particular
bit
is
because
the
privacy
problems
it
has
are
so
terrible
that,
like
no
one
buys
right
papers
on
how
the
visit
visit
doesn't
expose.
Our
bad
like,
like
I,
can
show
you
ten
people,
I
can
show
you
any
number
of
papers
about
about
mm
a
packet.
The
information
leaks
from
packet.
K
You're
saying
is
some
years
that
what
you
sneezing
is
this
time,
is
it
you
don't
worry
we
should
we
love
juice
information
expert?
Could
you
please
slow
down
just
a
bit
sure
you
seem
to
be
saying
that
we
should.
We
should
have
to
reduce
specific
attacks
from
the
specific
information
leak,
but
there's
plenty
of
interaction,
evasion,
Expedia
we
already
have
and
nobody
bothers
with
weaker
leaks,
but
we
have
stronger
leaks.
AA
:
Perkins
what
I
was
actually
saying.
There
was
a
previous
comments
at
the
microphone
that
we
should
not
expose
this
information
because
there
may,
because
there
may
be
future
unknown
privacy
risks
from
from
doing
it,
which
would
be
new
because
of
quick.
Well,
you
know
this
information
has
been
exposed
for
a
long
time.
So
it's
not
new
because
of
quick.
We
may
we
may
want
to
not
expose
this
information
because
we
are
aware
of
privacy
risks
of
it,
and
that's
fine.
AA
AA
D
AB
D
AB
And
this
particular
my
it's
a
very
small,
hot
zone:
okay
I
should
clarify
what
I
was
saying
before
about
the
spectral
methods.
They
don't
actually
require
the
self
clock,
but
of
course
you
are
have
transactional
things
happening
inside
the
protocol
and
the
mere
fact
that
a
response
comes
after
the
query
is
enough
to
key
off
that
method.
Similarly,
the
reflect
that
retransmission
comes
after
the
loss
is
enough
to
key
that
off.
So
unless
you're
prepared
to
put
a
randomized
and
relatively
long
delay
inside
the
in
system,
you
can't
hide
the
RTT
from
a
passive
observer.
AB
AB
The
fact
that
when
you
retransmit
there's
a
hole
and
then
there's
another
packet
at
some
at
some
time
that
is
correlated
by
the
ITT
and
that's
all
it's
detecting
yeah
right.
So
it
doesn't
me
to
be
able
to
tell
anything
about
any
of
the
packets,
except
that
they
belong
to
a
flow
right
and
it
can
even
do
get
you
the
RTT
spectrum
of
an
aggregate
which
actually
from
a
traffic
management
point
of
view,
is
awesome
because
that's
exactly
what
you
want
to
know
and
you
don't
care
about
any
of
the
individual
connections
right.
AE
Tommy
Paulie,
just
in
general,
yes,
I,
like
three,
a
better
of
all
the
flavors
but
kind
of
just
falling
on
on
what
dkg
was
saying
and
trying
to
kind
of
ask
a
question
back
to
that.
He
brought
up
the
point
of
the
account
comparison
to
the
privacy,
problematic
points
of
ports,
which
is
a
small
piece
of
information.
AE
So,
ideally
I.
Imagine
it
wouldn't
be
giving
me
any
more
information
about
the
content
of
what
they're
doing,
because
I
could
already
infer
that
they
are
doing
quick
because
they're
doing
something
over
UDP
that
looks
encrypted.
How
much
I'd
like
to
understand
more
other
people
have
comments
on
why
this
would
be
potentially
more
equivalent
to
something
like
port
privacy.
Q
Hi
burn
criminal.
What
but
I
haven't
said
yet
is
that
I
do
think
that
this
is
an
important
thing
to
be
measurable
and
easily
measurable,
in
a
way
that
you
don't
screw
it
up
very
much,
because
if
it's,
if
it's
like
input
to
an
ATM
again
my
headset,
if
it's
an
input
to
an
ATM
and
you
get
a
crap
signal
as
the
implicit
ei
QM
that
might
turn
into
Oh
quick
is
bad.
We
should
turn
it
off
and
we've.
Q
Given
we
have
a
big
read
off
switch
for
quick
right,
I
mean
block
UDP,
4,
4
3,
and
it
goes
away
and
I
want
to
give
as
few
people
as
few
reasons
as
possible
to
do
that
with
respect
to
I'll
actually
occurs
in
line
behind
me.
I'd
love
him
to
give
a
citation
on
a
traffic
analysis
paper
that
looks
into
the
round
trip
time,
secrecy
of
a
path.
Q
Ok,
so
I've
read
a
lot
of
traffic
analysis
papers
and
a
lot
of
stuff
on
timing
right,
there's
a
lot
of
stuff
that
you
can
figure
out
about
the
implementation
by
looking
at
timestamps.
This
is
the
timestamp
right.
This
is
as
close
as
we
can
get
to
a
pure
Network
RTT
signal
that
we
can
give
to
the
path
with
no
access
to
any
of
the
semantics,
the
underlying
application
layer,
logic,
no
access
to
any
of
the
semantics
of
the
underlying
transport
layer,
logic,
there's!
No!
Q
You
can
implement
this
in
a
completely
separate
piece
of
you
can
implement
this
in
hardware.
You
can
Hardware
accelerate
this
rate.
It
doesn't
even
need
to
touch
so
it
doesn't
even
need
to
be
correct.
Technically
it
doesn't
even
need
to
be
quick
technically,
you
could
give
it
another
name,
but
I'm
not
going
to
suggest
one,
because
that
will
derail
and
I'd
like
to
get
its
the
minimal
UDP
substrate.
It's
called
and.
Z
Q
Figured
if
we
shrink
lost
upon
bit,
people
might
not
hate
it
as
much
I'm
really
interested
in.
In
concrete
examples
of
why
this
is
risky,
because
if
there's
a
risk
here,
then
we
should
look
into
the
risk
utility
trade-off.
But
to
me
the
utility
looks
quite
high.
The
risk
looks
rather
low,
as
Andrew
says:
a
RT,
a
network,
RT
t
hiding
transport
is
a
very
hard
thing
to
build
unless
you
just
go
to
like
slot
reservation
systems
like
a
lahar
or
something
like
that.
So.
D
Pkg
is
behind
you,
yeah
and
I
I
would
sort
of
volunteer
him
a
bit
more
time
than
the
average
queue
speaker,
because
he
seems
to
video.
Leon
is
very
much
and
me
I
was
shaking
her
head.
I'm
gonna!
Do
it
anyway,
because
you
know
he
he
seems
to
be
the
only
one
in
the
room
who
wants
to
argue
the
opposite
side
and
people
are
asked.
You
know
why
is
this
risky
and
I
want
to
give
them
some
time
to
explain
right.
AD
X
This
is
dkj,
so
so
I
want
to
make
a
couple
of
observations
here.
I
believe
that
Andrew
McGregor's
point
about
traffic
measurement.
That
can
be
done
without
any
mechanism
like
this
is
about
a
domain
and
a
network.
That's
under
one
set
of
administrative
control.
No
okay,
sorry
I,
haven't
read
that
paper.
X
The.
If
I
can
see
the
response
time.
I
can
geolocate
to
some
degree
of
some
some
set
of
approximations,
but
I
can't
otherwise
do
so.
If
anybody
doesn't
think
that
location
is
an
issue
that
has
some
privacy
risks,
then
come
talk
to
me
to
point
you
towards
people
whose
location
is
potentially
problematic.
X
It
gives
you
timing
information
about
the
the
endpoint
and
how
it
processes,
packets
and
how
it
responds
to
packets.
It
gives
you
some
information
about
what
protocol
is
being
run.
Not
every
protocol
requires
an
immediate
response
to
every
packet,
so
you
might
send
me
a
packet
and
the
protocol
that
we
happen
to
be
speaking
might
be
extreme.
Might
med
have
a
long
delay
because
something
else
is
happening.
It
might
give
you
information
about
battery
life
on
the
device,
because
your
device
might
decide
to
not
send
information.
X
But
let's
try
to
do
as
well
as
we
can
I
don't
want
to
have
to
do
quick
v2
when
we
find
out
later
that
people
are
getting
I,
don't
know
getting
busted
for
stuff
or
you
know,
network
operators
are
colluding
to
keep
people
off
the
network
because
of
the
round-trip
time.
So
I
agree
that
this
is
a
small
point,
I'm
part
of
a
bigger
picture,
but
we
should
be
minimizing
what
we
exposed
to
the
networks.
X
Q
Q
Up
point
and
I'm
not
sure
if
this
actually
mitigates
your
concern
at
all
and
I
now
regret
not
sending
my
slides
to
you
beforehand,
because
I
think
the
concern
slide
would
have
been
much
more
compelling.
Had
you
written
it
and
I'm
sorry
about
that.
But
this
mechanism,
3a
in
particular,
is
simple
enough
that
if
we
wanted
to
turn
off,
everyone
could
now
the
question
of
whether
that's
a
practical
thing
to
do
ten
years
from
now,
maybe
not
but
in
the
next
few
years.
Q
Certainly
if
we
thought
that
that
there
was
a
privacy
risk
that
had
like
we
could
enumerate,
you
know
it
would
be
possible
to
turn
it
off,
but
we
would
have
to
coordinate
and
turning
it
off.
Otherwise
other
you
would
be
like
identifiable,
but
I
mean
it's
a
mistake.
We're
at
now
we're
like
years
from
the
point
where,
like
I,
think
you
could
probably
get
it
turned
off
and,
like
you
know,
pretty
much
globally,
probably
in
the
next
two
or
three
years
fairly
quickly.
No
well,
we
can
turn
it
off
quickly.
B
I
couldn't
say
on
a
high
level:
I
might
even
agree
with
dkg,
because
you
know
sure
we
should
do
all
this
but
like
if
I
look
at
quick,
then
all
the
examples
he
just
gave
you
can
get
this
information
anyway.
So
I
think
we
should
really
talk
about.
You
know:
what's
the
concrete
case
here,
what
do
we
do
right
now?
If
the
request
is
to
consider
privacy
in
the
decisions
we
make,
I
think
I,
fully
agree
and
I
think
we're
doing
this.
B
Maybe
it's
useful
to
look
at
what
we
learned
so
far,
so
TCP
was
designed
not
was
having
in
mind
to
expose
explicitly
information
to
the
network,
so
everything
was
exposed.
Everything
was
modifiable.
There
was
like
no
integrity
protection,
it's
something
we
learned,
so
we
learned
that
if
we
expose
information,
it
should
not
be
connected
to
any
internal
semantics.
It
should
only
expose
the
information
that
we
want
to
expose
and
we
should
protect
this
information.
D
B
A
H
K
I
guess
I
want
to
make
several
points,
but
if
I
made
them
brief,
first
I
wanna
remember
the
priority
of
constituencies
here
and
our
loyalty
here
is
to
the
end
users
and
so
on
this,
and
so
so,
if
this
is
like,
we
must
inconvenience
the
operators,
and
usually
it's
better,
like
that's-
that's
I-
think
the
appropriate
decisions
to
make.
Now
if
we
make
that
usable
as
different
story,
but
that's
not
what
I'm
hearing.
K
The
second
point
is
the
one
reached
by
deg,
namely
that
our
we
were
trying
to
do
is
make
a
protocol
which
has
superior
security
and
privacy
properties,
the
tcp,
and
so
that
should
be
so.
We
should
be
in
your
rooms
and
watch
signal
as
you
possibly
can,
and
so
I,
don't
I,
don't
think
the
printer
crews
and
people
wanted
with
a
signal
to
demonstrate
that
signals
eventually
meaningful.
The
whole
reason
why
you
want
the
signal
is
because
the
same
those
meaningful
and
so
yeah.
K
So
the
very
fact
that
lease
information
means
it
has
privacy
implications.
So
sorry,
I
think
that
especially
that
requires
a
concrete
attack
that
just
tries
a
privacy
problem.
I
think
is
quite
baffling.
I,
don't
have
one
specifically
I'm
around
truth
is
been
published,
but
I
do
have
one
I'm
going
to
suggest
to
you
right
now,
which
is
on
that
which
is
basically
timing,
a
packet
decryption.
K
So
imagine
you
have
a
situation
in
which
is
a
in
which
you
can
maple
8
from
the
wire
without
decrypt,
without
recording
the
packets,
the
on
Pakistan
such
a
way
that
the
receiver
will
immediately
respond
with
something
with
some
sort
of
error.
There'll
be
encrypted,
so,
for
instance,
on
the
case,
when
TCP
often
uses
what
you
have
out
of
order,
packets
cause
immediate
acts
right
sure.
K
So
so
imagine
you
have
a
situation
where,
by
manipulating
packets
without
decrypting
them,
you
can
cause
the
receiving
implementation
to
immediately
generate
a
response.
Now.
What
you
have
is
a
way
to.
If
now
you
have
via
this
mechanism
is
a
way
to
immediately
detect
which
packets
respond
to
which
other
packets
and
therefore
you
have
an
ability
to
measure
precisely
that
the
packet
timing,
processing
timing.
So
if
you
have
a
non-constant
time
to
christian
implementation
now
you
have
a
potential
way
to
extract
your
corruption.
Key.
This
can't
be
done.
I.
K
Q
K
But
you
know
you
know
you
don't
you
know
with
some
confidence,
but
not
full
confidence.
That
packet
was
an
organically
generated
and
if
you
have
a
situation
in
which
this
package
packets
are
flowing
aggressively
on
like
for
a
security
area
in
chopping
traffic
on
for
for
traffic
analysis
differentiation
and
does
become
quite
difficult,
so
I
didn't
say
this
best
attack
in
the
world.
I
said
you're
leaking
information
now,
but
a
private
piece
of
state
about
the
recipient.
So
as
I
say
I,
don't
there
a
lot
of
papers
written
about
this?
K
Merely
because
we
have
not
yet
I
mean
the
way
security
papers
work
right
is
you
start
planning
down
all
the
signal
and
when
one
single
still
there,
you
don't
plane
down
war
signals,
and
so
we've
plane
down
this
signal.
We
will
then
find
attacks
on
the
signals
that
remain,
and
so
the
demand
that
we
have
an
attack
on
a
similar,
a
very
weak
signal
when
they're
already
attacks
less
strong
signals,
it's
just
not
reasonable.
In
terms
of
house
security,
research
works.
AF
Then
return
I
think
what
brought
us
to
this
discussion
is
a
set
of
requirements
that,
for
the
first
time
since
we've
been
talking
and
quick,
was
we're
very
clear
what
I
think
what
we
want,
what
what
is
needed.
So
if
the
argument
that
the
requirements
are
not
that
I'd
like
to
understand
if
people
are
arguing
about
what
is
needed
in
the
context
of
RTT
/
/
link
for
you
know
on
on
the
path
you
know
and
and
and
I
think
the
solutions
that
are
being
presented,
we
need
a
solution
period,
it
doesn't
matter.
AF
You
know
the
one
three
three
a
seems
to
be
a
good
balance
between
privacy
and
and
manageability,
but
I
think
we
need
to.
We
need
to
acknowledge
the
fact
that
there
are
clear
requirements
and
if
the
requirements
are
not
clear,
we
need
to
understand
why
they're
not
first
of
all,
not
clear
and
second,
why
are
not
there
and
accepted,
but
in
general
I
think
I
think
it
would
be
a
good
thing
to
do
this
and
it's
necessary
for
network
management
not
just
for
operators,
but
also
for
enterprises.
D
Think
the
requirements
are
clear.
The
question
for
the
working
group
is
are
we
do
we
want
to
address
them
right,
which
is
option?
One
was
no.
We
won't
and
options
2,
3
and
3a,
and
there
might
be
others
our
proposals
for
how
they
could
be
addressed,
but
I
think
the
requirements
are
clear.
That's
what
we
spend
a
lot
of
time
in
Paris
on.
R
Gen
Iyengar
yeah,
it
was
I'm
gonna
echo
one
of
the
Katy's
points,
which
I
think
is
what
I
going
again,
that
the
burden
of
proof
for
privacy
bug
is
not
on
I,
don't
think
we
should
wait
for
for
a
problem
before
we
try
to
address
this
because
by
the
time
we
address
by
find
a
problem,
it's
gonna
be
too
late
to
address.
It.If
quick
actually
has
if
there
is
a
privacy
issue
with
this
particular
bit,
and
we
find
out
three
years
from
now.
R
This
is
going
to
be
ossified
and
we
will
not
be
able
to
take
a
bit
back.
So
it's
it's
important
that
we
consider
this
question
now
and
not
wait
for
something
to
go
wrong
before
we
say
no,
we
shouldn't
have
this
bit.
I
also
want
to
add
that
one
of
the
one
of
the
contending
things
with
a
QM
has
always
been
and
continues
to
remain.
Endpoint
condition,
control
and
we
know
that
condition.
Controllers
like
PVR
are
actually
also
working
on
minimizing
queues
in
the
network.
R
This
is
something
that
that
works
towards
the
same
end
as
eqm
does,
and
it's
something
that
we
see,
for
instance,
deploying
DVR
in
for
TCP
traffic
at
Google
and
for
quick
traffic
at
Google
has
shown
substantial
reduction
in
roundup
times
observed
in
the
network,
so
it
does
actually
reduce
buffer
bloat
and
it
addresses
the
same
problem
that
aqm
tries
to
address.
So
that
is
another
thing
to
bear
in
mind
as
well
that
this
is
not
the
only
way
to
handle
bloated
buffers
in
the
network.
R
My
personal
opinion
is
that
a
CEM
is
is
has
been
trying
to
get
deployed
for
a
long
time
and
it
might
yet
get
deployed
in
corners,
but
at
the
same
time
the
endpoints
have
to
do
something
anyways,
because
they
can't
rely
on
ATM
getting
deployed
throughout
the
network.
So
endpoints
are
going
to
try
and
address
the
city
care
about
the
problem,
ultimately,
buffer
bloat
effects,
endpoints
and
if
they
care
about
it,
they
are
going
to
try
and
do
something
with
congestion
controllers
to
address
this
problem.
So
it
may
not
be
an
issue.
R
I,
don't
know
that
will
resolve
this
today.
The
the
conflict
between
endpoint
condition,
control
versus
aqm,
but
that's
definitely
the
direction
in
which
we
could
go,
and
this
becomes
an
on
problem
at
that
point.
The
requirements
change
at
that
point
and
so
I'm
not
convinced
that
the
requirements
are
written
in
stone
either.
Q
AD
AD
This
would
probably
fall
back
to
TCP
because
they
want
to
inspect
other
stuff
other
than
just
the
RTT.
So
it
does
feel
like
a
niche
use
case.
Obviously
someone
said
enterprise
networks
is.
This
is
really
important,
but
there
are
probably
other
ways
than
just
expanding
the
scope
of
what
quic
is
it's
not
this
isn't
even
on
the
right
layer
right,
we're
just
piggybacking
on
quick
because
it's
getting
specified,
but
it's
not
obvious
that
this
should
be
specific
to
quick.
So
that's.
Q
AD
AD
The
minute
you
try,
the
minute,
you
say
that
the
network
ties
this
information
to
a
QM.
Now,
as
a
sender,
I
have
an
incentive
to
manipulate
this,
to
get
performance
benefit
right
and,
like
the
whole
spectrum
of
the
things
changes.
But
we're
saying
this
is
you
know
coolest
thing,
and
this
is
needed,
but
it's
not
needed
and
it
doesn't
have
much
requirements.
AD
Q
AD
AG
So
I'm
still
very
much
in
faith.
Sorry
Phillip,
Diesel
I'm
still
very
much
in
favor
with
3-8
because
of
a
few
things.
First,
I
fear!
If
you
don't
give
this
information,
it
might
start
a
race
of
arms
for
present
measurements.
Purses,
determination
of
the
Arditi
and
the
machinery
needed
for
this
can
be
easily
used
for
other
stuff.
We
much
less
warmth
than
measuring
our
GT.
D
Before
gory,
quick
interject
from
the
chairs
on,
we
have
about
25
minutes
and
we've
been
discussing
whether
it's
worthwhile
to
do
like
either
we
keep
on
this
and
we
basically
burn
until
the
end
today,
which
is
one
option
or
we
try
to
squeeze
in
something
else.
I
don't
really
have
a
preference.
Can
I
can
I
get
a
show
of
hands
who
thinks
we
should
actually
keep
discussing
this
until
the
session
ends?
Are
we
still
making
progress?
In
other
words,
hands
not
mounts
hands.
M
V
V
V
V
D
V
One
might
not
be
surprised
to
discover
that
the
at
the
so
the
idea
is
G
have
a
joint
retreat
every
year
and
these
days
and
on
the
on
the
one
day
that
the
two
retreats
overlap,
the
IB
and
is
G.
He
talked
about
this,
then
the
eye
edema,
I'm,
sorry,
the
ASG
met
and
the
ihd
talked
about
it
on
Thursday,
then
the
IHG
met
and
the
IHG
talked
about
it.
On
Friday.
V
This
is
a
big
deal.
This
is
a
lot
bigger
deal
than
quick.
It
feels
like
to
me
is
won
by
the
way
that
there
are
a
lot
of
you
know
there,
probably
a
lot
of
other
people
in
the
ITF.
That
should
be
at
least
as
worried
as
the
quick
working
group
is
about
some
things.
So
that's
so
that's
number
one
number
two
one
of
the
things
that
happened
there
was
that
occur,
gave
an
excellent
presentation.
V
Helping
the
rest
of
the
isg
understand
the
concerns
better
and
I
mean
he
had
like
a
half
an
hour
with
slides.
It
wasn't
like
standing
at
the
microphone
interacting
and
I
found
that
to
be
extremely
extremely
helpful,
and
it
seems
like
to
me
if
that
kind
of
broader
audience
it
would
be,
it
would
be
helpful.
V
Ordinarily,
it's
not
okay,
it's
never
the
job
of
ITF
participants
to
educate
other
ITF
participants,
though
it
seems
like
to
me
that
it
might
be
helpful
to
make
progress
if
we
had
a
better
understanding
of
what
we're
talking
about
here,
I
in
the
job
you
know
in
the
jabiru,
you
know
it's
like.
Are
there
well-known
citations
to
things
that
would
help
the
people
who
raised
their
hand
the
second
time
I
understand
better
because
I
moved?
This
is
gonna,
go
one
of
two
ways
right.
D
V
About
with
you,
talk
about
with
your
document
right
and
but
the
I
think
the
related
thing
on
that
is
Singapore
is
not.
If
that's
not,
if
that
doesn't
have
something
like
that
doesn't
happen.
Singapore
is
not
too
late
and
Singapore
is
not
tomorrow,
sure,
okay,
and
that
might
even
give
a
very
talented
and
busy
member
of
the
community
an
opportunity
to
involve
other
people
and
and
launch
them
to
do
the
work.
You
know,
which
is
that's
something
an
area
director
would
love.
If,
if
there's
anything
like
I
am
right
now.
A
I'll
go
away,
thank
you
very
much
Spencer,
so
just
not
to
preempt
the
folks
who
are
in
queue,
but
I
mean
we.
It's
already
pretty
apparent
to
us.
I
think
we're
not
gonna,
be
able
to
make
a
decision
about
this
today
and
I
doubt
we'll
even
be
able
to
take
any
homes
about
it
today.
I
think
Spencer
is
absolutely
correct,
that
we
need
a
lot
more
information
and
a
lot
more
thought
about
this,
but
part
of
that
is
discussing
it
in
the
room.
So,
let's,
let's
continue
I,
think
sorry
in.
Q
J
J
Q
--N,
I
I
asked
if
whether
we,
though
we
could
not
have
clarification
on
whether
we
wanted
to
move
forward
with
any
of
these
proposals,
whether
we
could
agree
if
we
were
going
to
move
forward
with
something
we
would
pick
one
partially
just
for
the
sake
of
like
that's
not
going
through.
This
whole
talk
all
over
again
so,
and
we
have
a
here
for
one
of
them
as
well,
which
is
recognizing
that's
now.
J
I
argue
that
and
I'm
not
going
to
mention
any
options
right
and
all
transport
protocols
to
date
appear
to
have
had
sequence
numbers
in
and
the
aim
there
was
not
necessarily
to
annoy
operators,
transport
and
operators
have
worked
together.
So
let's
keep
the
conversation
about
how
what
protocols
work
and
how
we
interact
with
networks.
Networks
are
constantly
changing.
The
transport
area
is
probably
one
of
the
few
areas
where
we
do
a
lot
of
research
to
support
this
one
of
the
nice
things
about
exposing
some
of
this
is.
J
It
gives
researchers
and
other
people
a
body
of
work,
to
bring
here
to
check
whether
these
congestion
control
mechanisms
in
track,
Goodley
or
battling
the
aqm
thing
is
only
a
straw
man.
There
are
plenty
of
other
magazines
out
there
in
the
network,
which
will
impact
transport
performance.
So
if
you
want
to
move
forward,
we
want
to
evolve.
We
want
to
live
with
the
network,
that's
changing,
I
suggest
we
keep
something
in
here
that
can
be
correlated
in
that
data
sack.
AA
Colin
Perkins,
so
Gauri
and
Maria
said
a
lot
of
what
I
wanted
to
say,
probably
in
a
better
way
than
I.
Can
the
other
point
sorry,
Gauri
and
Maria
said
a
lot
of
what
I
want
to
say,
probably
in
a
better
way
than
I.
Can
the
other
point
I
wanted
to
bring
up
I.
Think
I
mean
you
can't
you
raised
a
lot
of
important.
You
know
privacy
issues
and
so
on.
AA
I
tend
to
believe
that
those
are
not
solvable
unless
you
run
tour
or
unless
you
take
active
countermeasures
to
stop
them,
I
think
any
transport
protocol.
You
can
do
the
analysis
to
to
get
RTT
to
that
level
of
accuracy.
Whether
or
not
there's
anything
built
into
the
transport
to
help
you
do
it.
Unless
you
actively
try
to
obscure
the
rtt
the
mechanisms
you
know,
even
if
we
do
nothing,
I
think
those
rivers,
those
risks,
exist
and
I
think
we
need
to
consider
whether
we
are
trying
to
solve
a
problem.
W
Ted
Hardy
had
got
up
to
reply
to
a
couple
of
points
made
by
Spencer
and
to
volunteer
or
something
related
to
the
comments
made
by
Spencer.
The
first
was
that
Spencer
made
a
parallel
between
this
proposal
and
plus
I
think
that
parallel
was
Ultron
plus
he's
considerably
different
in
scope
than
this
proposal.
I
believe
is
as
drawn
as
minimally
as
the
the
type
mind
of
Christian
Wedemeyer
could
make
it
and
I
admire
it
for
that
capability.
W
The
end
points
turn
it
on
in
order
to
tell
the
network
something
when
they
want
the
network
to
know
it
and
being
able
to
turn
it
on
and
off
for
that
purpose,
as
I
believe.
A
critical
part
of
the
functioning
of
any
signal
of
this
type,
that's
going
to
meet
the
privacy
concerns
that
people
do
have
I'm,
certainly
willing
to
be
educated
more
on
privacy
concerns.
The
traffic
analysis
topic
is
also
one
that
we're
working
on
actively
inside
the
prusik
program
and
more
information
is
always
good,
as
I
said
before.
W
I
don't
want
to
prejudge
the
outcome
of
the
discussion.
Balancing
these
two
things,
but
I
think
we
need
to
be
as
open-minded
to
the
importance
of
having
this
information
for
network
planning,
as
we
are
to
the
information
of
the
importance
of
suppressing
this
information
for
privacy.
I
agree
with
with
ekor.
We
may
have
our
thumb
on
the
scales,
but
we
have
to
actually
fill
the
scales
to
do
our
job
properly.
R
It's
because
these
we
didn't
know
better
and
network
operators
used
whatever
was
available
to
them.
As
I
said
earlier,
we
know
that
Google
quick
has
already
been
ossified.
It's
not
because
we
wanted
to
share
their
information.
It's
because
the
one
byte
of
information
that
we
shared
with
the
network
was
taken
on
by
a
firewall
that
decided
to
use
it
to
identify,
quick
and
then
allow
us
to
change
the
flags
bite.
This
is
a
real
queen.
It's
it's!
It's
not
that
we
are
playing
nicely
with
metal
boxes
with
TCP.
R
We
are
trying
to
change
TCP
and
we
can't
do
because
metal
boxes
have
ossified
it.
I,
don't
think
it's
fair
at
all
to
say
that
we
are
having
a
good
thing
going
on
there.
I
think.
That's
a
myth.
That's
a
that's!
A
completeness,
characterization
separately,
III
I,
think
that,
on
the
question
of
unsolvable
privacy
concerns
it's
a
very
broad
statement.
I,
don't
I
am
I,
don't
think
we
are
in
a
position
to
say
what
privacy
concerns
are
solvable
and
what
aren't.
R
But
what
we
are
in
a
position
to
say
is
what
information
we
expose
and
what
we
do
not
and
to
that
I.
Think
I
I
agree
with
what
Ted
was
pointing
out,
that
there
is
there's
a
that
there
are
questions
on
both
sides
for
us
to
consider
on
them
on
the
management
of
networks.
Question
I
have
spoken
over
the
past
year,
not
just
me.
Ian
and
I.
R
Both
have
been
talking
to
operators
over
the
past
couple
of
years
and
we've
been
trying
to
clean
whatever
we
can
out
of
them
in
terms
of
trying
to
understand
what
information
they
might
need,
what
information
they
could
use
and
so
on
and
so
forth,
and
the
answers
have
been
generally
I,
think
varying
from
lukewarm
to
to
sort
of
yes,
we'd
like
it,
but
if
you
didn't
have
it
we'd
still
live,
it's
not
been.
Yes,
we
need
it,
or
else
we
are
going
to
shut
the
network
down.
R
We
are
going
to
shut
down
quick,
which
is
important,
which
is
really
important,
because
one
of
the
questions
about
whether
this
can
be
optional
or
not
I,
don't
know
that
in
practice
it's
ever
going
to
end
up
being
optional,
because
if
an
operator
really
cares
about
it,
they
are
going
to
end
up
saying
I'm
not
going
to
allow
quite
traffic
through
that.
Doesn't
actually
negotiate
this
option
so
either
it's
really
important.
Let
me
make
it
mandatory
or
it's
not
I
have
not
gotten
any
signal
that
it's
really
important.
AH
Hi
I'm
Dakota,
so
I
and
I
think
many
here
in
this
room
agree
that
so
the
knowledge
about
RTT
is
useful
for
network
planning
and
performance
management,
but
I
think
we
are
actually
mixing
up
fertility
and
requirements
yeah
right.
So
so,
what's
the
potential?
What
we
see
I
think
already
visible
privacy
risks
here,
I
think
I,
don't
think
we
can
decide
on
that
without
having
actually
seen
real
evidence
that
there
is
a
problem
in
to
do
something
like
this.
U
Sanjay
Mishra
verison
just
couple
of
observations,
so
I
think
when
we
had
the
Charter
discussion.
Quite
a
bit
of
time
was
spent
about
network
monitoring
and
network
management.
I
should
say
so
at
the
end
of
those
discussions
and
then
what
was
clear
was
that
there
certainly
is
a
need
for
network
management
in
order
to
make
sure
that
there's
some
level
of
accountability
in
terms
of
how
quick
is
performing
and
some
other
things
think
you're
already
agreed
upon
so
now.
Here
we
are
discussing
a
solution
that
might
be
fitting
that
charter
requirement.
U
So
if
you
go
back
and
now
when
the
solution
is
presented
and
then
question
what
was
already
agreed
in
the
Charter
is
then
I
think
in
ways
we're
taking
steps
back
so
certainly
fine
to
discuss
this.
That
maybe
we
should
you
know,
add
this
back
to
the
Charter
and
go
back
and
make
sure
that
you
know
we're
all
clear
with
the
Charter
and
what
you
know
quick
is
going
to
be
delivering.
So
it
moves
upon
us
to.
You
know,
go
back
and
you
know
relook
at
the
Charter.
U
U
D
U
What
we're
doing
right
and
and
yeah
and
then
just
wanted
to
also
make
sure
that
when
other
things
that
Ian
in
your
presentation
at
the
very
upfront
I
think
maybe
a
second
sentence
of
the
second
word
in
the
in
the
presentation.
It
says
that
almost
all
the
data
is
encrypted,
so
I
think
so
you
know,
let's
just
be
careful
about.
You
know
the
concerns
that
you
know
that
might
be
there
with
exposing
the
information
in
the
RTT.
But
you
know,
as
you
said
it's
you
know,
much
of
the
data
is
encrypted.
C
B
Whenever
we
share
information
was
the
network,
it
should
be
explicitly
even
before
the
network
and
it
should
not
have
any
dependencies
on
the
internals
of
the
protocol
so
that
we
still
be
able
to
evolve
the
protocol
even
if
there's
no
certification
or
whatever.
So
that
has
to
be
separated
and
I.
Think
that's
a
lesson
learned
from
the
past
and
the
other
point
I
wanted
to
come
back
on
your
own
last
question.
You
had
towards
like.
B
What's
the
difference
and
I
said
complexity
and
actually
difference
between
like
what
you
can
do
today
and
giving
the
signal
and
complexity
is
one
point
accuracy
at
one
point.
So,
to
go
a
little
more
into
detail,
you
can
look
at
like
trafficker,
hysterics
and
behavior,
and
you
see
the
flow
and
you
see
the
user
or
whatever
and
at
some
point
you
can
get
around
to
time
measurement
and
then
you
know
the
round
time
of
that
flow.
But
like
what
this
mechanism
you
get
like
round
document
measurements
all
the
time,
so
you
get
more
information.
B
You
can
actually
use
it
for
your
network
management.
You
can
figure
out
what's
happening
right
now,
so
while
you,
you
still
have
the
security
risk,
if
you
don't
do
it
because
round
of
time
can
be
into
or
can
be
seen
based
on
your
traffic
characters,
you
don't
get
any
of
the
advantage
by
doing
it,
it
also
it
doesn't
scale.
So
while
you
know
you
can
probably
do
this
search
effort
detection
for
like
most
of
the
flows,
maybe
you
cannot
do
it
for
everything.
D
D
Z
B
B
AB
AB
I,
do
we
have
to
deliver
an
Jake
computation
and
you
have
to
do
something
to
screw
up
the
autocorrelation
structure
in
traffic
which
you
can
do,
but
it
is
point
that
this
is
introducing
edges
through
the
hash
function
and
therefore
leaking
part
of
the
session
key.
That
is
a
very
important
thing,
because,
on
top
of
that,
the
network
operator
can
play
with
your
RTT
by
actively
inducing
delays
to
explore
to
to
expand
their
search
space
on
that
key
right.
AB
Yeah:
okay,
in
any
case
that
that
expands
the
attack
surf,
is
the
protocol.
Someone,
on
the
other
hand,
there's
a
network
operator.
What
am
I
interested
in
I'm
interested
in
the
statistical
characteristics
of
the
traffic
through
my
network
and
I?
Don't
care
usually
about
any
particular
flow
I
can
get
that
anyway,
right
I
can
get
that
with
reasonably
high,
reasonably
high
temporal
resolution.
If
I'm
prepared
to
do
some
fancy,
statistics
and
those
are
quite
computationally
cheap
for
me,
so
I'm
leaning
towards
let's
not
do
this,
because
it
potentially
leaks
crypto
information.
AB
Q
A
Q
A
A
So,
let's
try
and
cut
down
the
search
space.
Just
a
tiny
bit.
Does
anyone
show
of
hands?
Are
they
interested
in
keeping
option
two
or
option
three
on
the
table
or
we're
really
just
talking
about
option
1
option,
3a
or
something
else
which
hasn't
been
discussed,
any
interest
in
option,
2,
2
or
3,
and.
Q
A
D
F
A
Think
the
Ender
just
sum
that
up
really
well
that
this
information
can't
be
got
through
other
means.
So
we
have
partial
information
on
both
sides
and
I'm
wondering
if
we
can
think
about
the
priorities
between
them.
You
know
we
think
about
security
and
privacy
in
this
organization,
that,
from
what
I've
seen
in
a
pretty
fundamentally
different
way
than
lots
of
other
things,
and
so
these
are
the
questions
that
I
was
scribbling
on
to
figure.
If
it
would
help
us
think
about
those
priorities.
A
D
O
A
O
W
W
Given
that
we're
not
gonna
be
trying
to
do
this
for
the
next
implementation
draft,
and
we
had
a
lot
of
discussion
where
we
already
know
that
people
want
to
share
information,
including
Andrews
draft,
the
thing
I'm,
gonna
sense
and
some
papers
that
dkg
also
wants
to
share.
I.
Think
that
the
that
we
have
already
established
through
discussion
that
the
information
that
the
working
group
currently
has
is
less
than
at
once
so
I.
Believe.
D
So
we
were
TLS
one
yesterday
and
then
and
quite
quite
impressed
with
the
know.
One
thing
we
could
do
right
is
we
could
find,
let's,
let's
call
them
champions
for
each
of
the
two
approaches.
Right
aging
option
option
one
and
option
some
3a
or
whatever
it
looks
like
that,
exposes
information
and
get
them
to
do
a
pitch
like
legs.
Even
feral
yesterday
did
very
unfashionably,
for
example,
on
the
other
side
that
as
well
in
TLS
about
the
trade
offs,
and
maybe
that
might
enlighten
the
the
discussion
here.
I
would
like
those.
A
D
D
A
Let's
not
open
the
ques,
the
room
ice
is
emptying
because
we're
out
of
time.
So
we
have
a
session
tomorrow
morning
that
we're
not
really.
A
D
A
Not
going
to
talk
about
this
anymore,
but
we
have
a
list.
Why
don't
we
do
this?
Why
don't
we
close
the
meeting
for
now
and
folks
who
are
interested
in
kicking
this
can
down
the
road
come
on
to
the
front
of
the
room
and
we'll
have
a
chat
about
how
we
can
have
a
more
productive
discussion
in
Singapore,
bring
beer
and
bring
their
cocktails
all
right.
Thank
you.
All
we'll
see
you
tomorrow,
where
do
blue
sheets?
Oh,
yes,
blue
sheets,
please,
on
our
Tahoe.