►
From YouTube: IETF109-QUIC-20201118-0500
Description
QUIC meeting session at IETF109
2020/11/18 0500
https://datatracker.ietf.org/meeting/109/proceedings/
A
We
have
a
pretty
full
agenda
and
I
think
we
want
to
have
some
discussion
on
a
bunch
of
topics,
so
I'm
going
to
get
started
with
the
usual
overview.
This
is
the
quick
working
group
at
itf
109.
If
you
participate
here,
there's
a
note
well,
the
highlights
here
are
mine.
The
text
is
the
standard
boilerplate.
A
So
there's
a
patent
policy
and
the
contributors
agreement
that
you
are,
you
know
obliged
to
comply
to
when
you
participate
in
the
itf
and
please
read
the
pcp79
for
what
it
means
to
participate
specifically
sending
email
to
a
list
or
speaking
during
one
of
these
meetings
is
counted
as
participation
and
then
you're
obliged
to
fulfill
certain
requirements
with
regards
to
disclosing
ipr
and
so
forth.
You
also
agree
to
work
respectfully
with
other
participants.
I
hope
I
don't
have
to
remind
you
of
that.
A
A
We
have
scribes
lucas
mentioned
that
I
think
dmitry
and
robin
volunteered
we're
using
the
kodi
md
tool
for
that,
as
I
said
before,
if
you
want
to
help
them
out
by
keeping
an
eye
on
the
minutes
and
correcting
things
as
you
see
them,
please
do
so
blue
sheets.
I
guess
mitecho
does
this
for
us
lucas
not
having
done.
A
Yes,
the
ad
says
yes,
okay,
that's
all
I
want
to
know
and
and
chat.
We
have
the
meet
echo
chat,
which
is,
I
think,
also
the
jabber
chat
room,
and
it's
also
now
relayed
with
m-nut's
funky
proxy
to
our
slack
channel
called
jabber.
So
you
can
follow
in
in
many
different
ways,
so
we're
using
that
we're
specifically
also
using
that
to
monitor
the
microphone
queue
so
lucas.
How
do
you
want
to
do
this?
With
the
q
plus
q
minus.
B
The
me
echo
tool
to
put
themselves
in
the
queue
so
there's
a
symbol
that
looks
like
a
hand,
so
they
can
join
the
queue
and
from
the
participant
list
we
can
see
people
in
the
order.
There's
no
there's
no
except
participant
like
last
time.
It's
like
different.
So
if
you're
in
the
queue-
and
we
we
signal
you
to
to
speak,
then
you
can
just
use
the
the
send
video
and
or
send
audio
buttons
along
the
top
to
to
begin
speaking.
A
Thank
you
yeah.
That's
why
I'm
confused,
because
the
queue
stuff
we
do
with
webex
or
zoom
or
whatever,
but
here
we
have
custom
tooling
right.
The
agenda
is
here:
I'm
gonna,
I
didn't
manage
to
make
a
slide
out
of
it,
but
I'm
gonna
try
and
share
my
other
browser
view.
Let's
see
if
that
works,
and
then
you
guys
can
follow
along.
A
Looks
great,
okay
right,
so
this
is
our
agenda.
I
I
saw
that
there
was
a
desire
to
bash
the
agenda
by
moving
the
quick
multipath
discussion
down.
I
did
that
since
a
bunch
of
people
spoke
up
in
favor
and
nobody
was
really
arguing
against.
If
people
want
to
re-bash
that
we
can
do
that,
I
hope
we
don't
have
to.
A
Going
once
going
twice
doesn't
seem
to
be
like
it
due
to
work
day,
job
and
personal
stuff.
Last
week
I
wasn't
actually
able
to
join
the
virtual
intro
interrupt
that
we
had
during
the
hackathon
I've
seen
what's
happening
on
the
slack
and
and
the
google
sheet
is
being
filled
out.
So
I
don't
think
there's
anything
special
to
report
other
than
the
the
interrupt
is
continuing.
A
Also,
the
interrupt
runner
that
martin,
seaman
and
janna
have
set
up
is
obviously
continuously
testing
the
implementation
against
each
other,
so
that's
ongoing
and
will
keep
on
going
for
the
foreseeable
future.
So
I
would
move
on
to
a
discussion
of
the
base
drafts
and
I
think
janna
sent
me
slides
for
this.
A
I
should
say:
oh
yeah,
congratulations.
We
are
a
past
working
group.
No,
we
passed
itf
last
call
as
of
yesterday.
I
think
we
got
a
whole
bunch
of
directorate
reviews.
I'm
not!
I
can't
remember
if
there
were
any
individual
issues
that
were
raised,
that
didn't
come
from
working
group
participants,
but
there
were
certainly
a
bunch
of
those.
So
the
the
project
board
at
the
moment
with
our
issues,
looks
rather
full.
C
A
D
D
D
I
don't
know
it
seems
like
my
voice
isn't
coming
through
very
clearly.
I
hope
it
is.
If
not
please
say
something
on
the
java
chat.
I'll
speak
even
louder
see
so
so
we
had
129
issues
filed
during
last
call,
and
most
of
them
were
from
area
reviews.
There
were
just
a
few
from
from
working
group
participants.
D
We
closed
74
of
them
as
they
were
minor
editorial
or
very
clearly
no
action
issues.
We
have
left
55
issues
open
now.
That
seems
like
a
daunting
number,
but
a
lot
of
them
are
very,
very
trivial
issues.
26
of
them
are
proposed
already
now.
These
are
ones
that
have
had
a
lot
of
discussion
on
the
on
the
issue
itself
and
have
proposals
either
of
closing
with
no
action
or
actually
have
prs
attached
to
them
and
they've
been
marked
as
proposal
ready
for
a
little
while
now.
D
So
those
are
the
issues
that
we
have
dealt
with
now.
In
the
past
two
days,
we've
had
a
bunch
of
issues
filed
specifically
25
issues.
These
are
not
proposed
ready
because
they've,
not
all
they've,
not
they've,
been
they're
still
going
through
discussion,
we'll
get
through
them
over
the
next
few
days.
I
I
expect-
and
there
are
four
that
are
not
yet
proposal
ready
that
are
older
than
two
days
next
slide.
D
I'm
not
going
to
go
into
the
details
of
these
issues.
The
numbers
are
there,
you
can
go,
look
them
up,
but
we've
had
discussion
on
both
of
these
and
those
are
ready
to
go
and,
as
I
said,
there
are
25
issues
that
were
filed
over
the
past
two
days.
These
are
mostly
area
reviews
and
iona
review
filed
a
bunch
of
issues,
the
mostly
straightforward.
There
are
probably
some
discussion
that
will
happen,
but
I
suspect
this
is
something
that
we
can
get
through
soon
as
well.
Next.
D
Finally,
there
are
these
four
issues,
which
is
actually
three
issues
now,
because
43
47
got
closed.
These
were
so.
There
are
exactly
three
issues
left
that
are
older
than
three
days
and
not
yet
marked.
I
don't
have
a
a
proposal,
that's
completely
done
yet,
and
that's
that's
where
we
are.
I
don't
know
that
we
need
to
discuss
these
issues
here.
There
is
active
discussion
on
github,
so
I
think
that
we
will
get
towards
closure
on
these.
Unless
somebody
wants
to
say
something
here,
but
that's
all
I've
got.
A
E
A
Yeah,
I
think
we
can
so
I
mean
the
summary
of
the
issue
is
that
it
was
raised
by
stuart
in
his
general
review
that
there's
for
for
the
version
numbers
there's.
Actually
no,
there
wasn't
any
registry
defined
and
it's
certainly
easy
to
define
one.
The
question
is,
or
one
question
is:
which
document
should
they
be
defined?
Then,
logically,
you
would
expect
them
to
be
in
the
invariance
document,
because
version
numbers
are,
you
know
in
very
invariant
and
have
meaning
across
versions.
A
However,
there's
a
whole
bunch
of
text
around
how
what
policies
we
define
for
our
registries
and
that
text
at
the
moment
is
in
the
transport
draft.
So
there's
some
discussion
on
whether
we
should
move
that
or
replicate
it,
and
I
think
that
was
what
I
remember
the
discussion
being,
but
it's
probably
progressed
since.
D
I
don't
think
the
discussion
has
moved
too
far
past
that
point.
I'd
say
that
I
didn't
necessarily
want
to
bring
this
up
here,
because
I
feel
like
this
is
a
discussion
between
the
80s
and
the
chairs.
With
some
maybe
input
I
don't
and
enlarge.
You
can
tell
me
if
I'm
off
on
this,
but
it
seems
to
me
that
that's
not
a
discussion
we
need
to
have
with
the
entire
working
group.
Is
it.
E
So
the
reason
why
I
mean
this
is
the
registration
rules,
you
as
people
specifying
future
extension,
etc
is
gonna
live
with,
and
I
think
it's
actually
is
relevant.
It's
not
just
for
the
80s.
It's
it's
very
much
up
to
you.
It's
going
to
affect
your
working
in
the
future
and
and
and
what
you
and
what
you
can't
do.
So
I
think
you
should
pay.
I
mean
I
think
you
should
pay
attention
to
this.
Quite
a
lot
and
not
just
say
no.
E
E
F
If
you
think
of
the
transport
dock
as
defining
version
one
and
the
invariant
stock
as
being
a
special
bonus
that
doesn't
have
any
real
bearing
on
what
people
implement
right
now
then
moving
something
to
invariance
with
you
know,
let's
say
adding
an
extra
two
or
three
pages
to
that
document.
Isn't
going
to
to
help
those
people
have
to
implement
the
transport
they
have
to
go
into
two
docs,
then
to
find
everything
that
they
need.
They
already
have
three.
So
I
guess
it's
not
not
that
much
that
that.
E
F
So
I
saw
a
number
of
comments
there.
None
of
them
were
particularly
troubling.
From
my
perspective,
there
was
a
question
of
what
notes
to
put
in
things
my
preference
would
be
to
do
nothing
and
what
were
the
other
ones.
I
I
did
have
a
small
change
that
I
that
relates
to
the
rules
around
the
first
value.
F
A
F
F
So
I
know
it
asked
well
what
are
the
rules
here
and
I
think
we're
a
little
bit
unclear
on
this
one
and
magnus
suggested
that
the
way
to
think
about
this
is
the
two
ways
you
can
approach,
adding
a
new
value.
You
could
either
go
for
provisional
assignment
or
you
could
request
early
allocation
and
I
think
early
allocation
applies
only
to
those
documents
that
I
have
standards,
action
or
one
of
the
the
heavier
rule
sets
and
7120
would
apply
in
that
case.
F
So
I've
got
a
pull
request
there
that
that
basically
says
the
first
value
in
any
space
follows
the
standards
action
rule.
If
you
want
it,
but
you
can
then
go
and
follow
the
rules
in
rfc
7120.
If
you
want
it
before,
you
publish
your
document
and
that's
all
that
really
says.
I
think
that
should
address
that,
but
I
suspect
people
are
going
to
have
to
review
the
text
to
satisfy
themselves
that
that's
the
case.
D
A
So
I
think
I
want
to
sort
of
encourage
people
that
have
an
interest
in
this
to
take
a
look
at
the
issue
and
and
state
opinions
there.
It's
not
it's
not
a
technically
hard
issue,
it's
just
a
sort
of
what
what
do
we
do
in
terms
of
that
make
sense
issue,
and
you
know
we're
going
to
settle
it
one
way
or
the
other,
and
I
think
we
can
basically
do
do
a
bunch
of
different
things,
and
none
of
them
would
be
terrible.
A
D
I
think
in
the
transfer
document,
rather
than
in
variance
and
and
the
other
reason
that
you
didn't
mention
is
that
invariance
is
largely
focused
on
on
on
protocol
specific
things.
To
the
extent
that
we're
talking
about
the
process
of
assigning
versions.
I
think
that
doesn't
belong
in
the
invariance
document,
but
go
on.
F
Yes,
I
was
going
to
say
I
as
part
of
the
thing
I've
done,
a
review
of
all
of
the
open
issues
and,
aside
from
those
that
are
on
http
or
qpac,
I'm
satisfied
now
that
we
have
reasonable
coverage
in
terms
of
answers.
Most
of
the
questions
that
we
got,
I
think,
can
be
answered
via
email,
but
I've
got
pull
requests,
I'm
up
against
a
bunch
of
them
magnus
open
one.
There
was
that
one
and
the
issues
that
china
had
in
his
presentation
all
have
pull
requests
aside
from
one
which
is
also
http.
A
A
B
B
G
A
A
A
So
but,
but
hopefully
you
know
in
the
new
year
very
soon,
we
can
then
basically
have
the
draft
in
the
rfc
editor
queue
and
then
they're
being
edited
by
somebody
else
for
once
towards
production
later
later
in
the
spring,
I
hope
or
later
in
quarter
one
since
I
don't
want
to
be
hemispherists
here,
I
got
asked
by
implementations
that
would
like
to
ship
a
version.
That's
called
quick
version,
one
what
they
should
do,
and
this
is
obviously
what
each
implementation
has
to
decide
for
themselves.
A
My
take
is
that,
once
the
drafts
are
in
the
rfc,
editor
queue,
meaning
after
isg
approval
has
happened
then
after
we,
you
know,
have
the
version
that
got
approved
by
the
isg
and
they're.
With
the
rfc
editor,
I
would
consider
it
safe
to
and
you're
implementing
that
version.
I
would
consider
it
safe
to
call
yourself
v1,
because,
by
definition,
only
editorial
changes
are
supposed
to
happen
as
the
rfc
editor
edits
and-
and
it
would
something
you
know
really.
A
Unusual
would
need
to
happen
for
there
to
be
any
design
changes
between
isg
approval
and
rfc,
so
that
I
think,
would
be
a
safe
thing
to
do.
For
an
implementation,
but
it's
it's
your
call
as
an
implementation.
What
you
want
to
do
if
you
want
to
wait
until
the
rfc
is
out,
for
example,
and
there's
three
people
in
the
queue
yeah
david,
say
david.
H
Yeah,
no
just
a
fundamentally,
I
think
we
need
bacon
time
here.
We
need
to
deploy
this
and
we
need
to
know
that
it
works.
When
we
did
this
for
tls
1.3,
we
found
out
that
the
standard
was
broken,
so
luckily
work
was
done,
it
was
diagnosed
and
the
standard
was
fixed
before
it
shipped
and
we
really
don't
want
to
ship
something
that
doesn't
work
that
doesn't
work
on
today's
internet
and
all
that.
And
similarly,
I
think,
like
that.
You
know
the
while
that
we
this
can
happen.
H
While
the
document
is
in
the
rfc
editor
few
to
some
extent,
because
if
we
do
find
something
wrong,
it
won't
probably
be
a
big
change,
but
it
might
still
be
a
change.
So
I
would
strongly
advise
against
anyone
deploying
the
v1
identifier
until
we
have
it
actually
published,
because
that
would
cause
a
lot
of
these
interrupt
problems.
So
I
would
really
prefer
that
we
don't
like
rush
here.
Our
goal
is
to
make
a
good
standard.
Our
goal
is
not
to
be
have
it
published
as
soon
as
possible.
H
A
Ship,
it
fair
point,
so
I
don't
remember
the
timeline
for
tls.
I
don't
know
if
that
issue
was
identified
during
rfc,
editor,
processing
or
or
earlier
or
later.
I
think
we
have
people
in
the
queue
that
can
speak
to
that.
One
thing
I
want
to
point
out
so
this
is
this:
came
from
an
implementation
that
has
certain
windows
for
making
it
into
releases.
A
Right
and-
and
one
of
those
windows
is
apparently
first
quarter
next
year
and
and
the
question
for
them
is
you
know,
can
they
make
that
window
with
version
one
or
do
they
have
to?
You
know,
wait
for
another
window
to
come
around
if,
if
you
have
an
implementation
that
has
sort
of
these
timing
constraints,
the
question
is:
what
do
you
do
and
I
gave
that
opinion,
but
if
you
don't
have
that,
you
know
limitation
if
you
can
roll
out
whenever
I
think
what
you
said
makes
perfect
sense.
Martin
thompson.
F
So
I
was
going
to
say
something
else,
but
now
I
have
two
things
to
say.
First
thing
is,
I
think,
david's
being
a
little
bit
too
cautious
here.
If
it
turns
out
that
we
have
to
burn
the
version,
the
code
point
one,
then
we
can
use
another
code
point
to
identify
the
version
that
we
publish
in
an
rfc.
That's
that's
totally
fine.
I
know
some
people
have
even
raised
that
as
a
possibility
for
version,
one
anyways
picking
a
number
like
some
some
random
number
out
of
the
32-bit
space.
F
F
I
had
hoped
to
do
that
pretty
late
in
the
process.
I
I
will
do
that
if
the
isg
has
changes
to
make
so
that
the
version
that
goes
into
the
queue
has
up
final
sucks.
But
if
that
doesn't
happen,
then
the
isg
thinks
this
is
fantastic
and
approves
it
without
any
changes
involved.
That
might
have
to
happen
in
all
48,
but
we
can
probably
just
rev
another
version
before
it
goes
into
the
queue
anyway,
just
to
make
sure
that
the
final
numbers
are
in
place
for
those
people
who
care
about
that.
J
Yeah,
so
oh
hang
on
so
yeah,
so
first
I
think
you're
asking
the
question
one
that
deep,
when
the
one
three
interrupt
problems
were
found,
they're,
probably
they're,
found
prior
to
to
issue
review,
but
but
I
think
so
I
I
think
I
I
I
got
a
position
somewhere
in
between
martin
and
and
david.
It's
true
that
there's
nothing
special
about
the
but
the
the
code
point
one.
J
However,
the
problem
is
that
if,
if
we
that
we
do
not
have
perfect
knowledge
of
when
people
are
deploying
when
people
are
playing
with
code
point
one,
and
so
what
happens
is-
is
that
some
substantial
fraction
of
people
deploy
with
code
point
one,
but
it's
cryptic.
So
we
don't
know,
and
then
we
have
to
make
a
change
in
in
the
last
call
sorry
in
our
in
the
38
that
we
think
is
nominal
and
we
and
then
so.
We
make
the
change.
We
continue.
J
We
could
point
one
because
we
don't
know
those
people
with
the
point
point
one
now
we
have
a
a
cryptic
interrupt
problem
that
we
find
later
and
so
people.
I
think
people
should
be
just
only
discouraged
using
2.1
until
until
the
rc's
actually
shipped
there's
like
there's
no
particular
reason
why
they
can't.
You
continue
to
use
the
29
go
point
and
I
imagine
people
will
have
support
for
that
for
a
second
century
time.
It's
like
it's
a
big
change
like
change
that
code
point
later.
J
B
K
F
We
can
revit
revise
matt
you're,
creating
a
little
bit
of
noise
there.
Sorry
thanks
so
echo
interpreter
that
is
saying
we
can
just
revise
the
the
document
to
fix
the
problem.
My
suggestion
was
yes,
we
can
revise
the
document.
We
would
also
give
it
a
new
version
number.
So
I
was
a
little
confused
about
what
becca
said.
J
Oh
yeah,
so
I
think
what
I
was
saying
was
that
so
right
now,
so
if
people,
if
people
deploy
so
so
yes,
if
we're
prepared
to
commit
right
now
that
any
any
assumption
of
change
will
not
use
version
number
one
anything
change,
meaning
after
the
test
time.
The
light
is
verse
number
one
and
this
works,
but
if
okay-
but
that's
not
that
that's
not
a
commitment
we
ever
made
and
it's
on
normal
commitment
so
so
like
yeah,
I
I
so
so
I
I
suppose
one
could
do
that.
J
D
D
I
don't
understand
why
version
1
needs
to
be
treated
any
more
specially
than
anything
else.
We've
done
we're
going
to
have
a
change
in
salt,
we're
going
to
have
something
go
on
here.
I
agree
with.
I
still
agree
with
what
lars
said
early
on.
There
are
people
who
are
shipping
version,
one
now
and
nick.
D
There
are
there's
also
signaling
where
we
are
when
I'm
talking
to
customers,
for
example,
and
they're,
asking
if
version
one
is
ready.
I
it
doesn't
make
sense
to
wait
for
three
months
of
rfc
editor
fixing
the
the
the
columns
and
the
semicolons
in
in
the
text
before
we
call
version
one
down,
but
there's
just
is
no
reason
to
wait
for
that.
J
Just
calls
the
semicolons,
like
we
made
a
lot
of
a
lot
of
non-trivial
changes
to
one
three
and
all
48,
because
we
actually
read
the
document
again
with
fresh
eyes
and
and
the
rsa
had
questions
and
none
of
those
actually
required.
I
don't
think
like
code
changes,
but
it's
not
like,
like
I'm
sorry,
but
if
you
go
through,
you
have
a
300
page
document
set
you're
not
going
to
you're
going
to
have
you're
going
to
have
non-trivial
changes
in
all
48.
You
just
are
okay,.
L
A
A
G
Ray
I
thought
there
were
people
in
line
they
had
to
be
in
front
of
me
in
the
cube.
We
we've
actually
had
the
conversation
about
not
having
a
quick
v2
anytime
in
the
foreseeable
future,
but
basically
just
using
the
extension
mechanism
a
lot
and
not
and
not
rolling
new
version
numbers.
So
it
seems
like
it
seems,
like
that's
going
to
be
an
important
part
of
this
answer.
Also,
I
agree
that
we've
always
talked
about.
You
know
the
version
number
shouldn't
be
special.
A
A
C
So
there's
I
I
presented
actually
a
very
similar
slide
deck
at
108.
I
got
some
feedback
on
some
useful
things
there,
so
we
did
get
rid
of
one
of
the
four
algorithms,
which
was
actually
quite
gratifying
to
delete
and
there's
been
some
other
rework
in
terms
of
contribution.
So
there's
five
open
issues
right
now:
martin
thompson
and
christian.
Thank
you.
C
You've
actually
provided
a
lot
of
great
feedback
on
the
draft
and
and
we
fixed
up
a
lot
of
things-
also
I've
gotten
some
some
comments
on
github
from
from
some
people,
ant,
financial
and
they've
they've
had
some
interesting
discussions
and
we've
cleaned
up
some
editorial
issues.
The
other
thing
that
has
happened
is,
I
was
able
to
open
source
implementations,
there's
a
library
that
will
encode
and
decode
cids
for
you,
that's
the
first
item
there
and
then
I've
hacked
nginx
to
be
a
load
balancer
in
the
quick
ob
sense
and
that's
the
other
github.
C
Yes,
I
know
it's
weird,
there's
two
different
projects,
it's
legal
stuff,
my
company,
so
that's
available,
I'm
I'm
actually
waiting
on
a
server
implementation
exists
out
there
and
then,
when,
when
someone
has
one
we
can
we
can
interrupt.
So
please,
let
me
know
on
slack
when,
when
you
have
that
next
slide.
C
C
I
thought
that
was
out
of
scope
for,
for
this
particular
draft,
it's
more
of
a
nat
thing,
in
my
view,
and-
and
in
fact
it's
in
that
direct
draft
later
in
the
in
the
agenda.
But
if,
if
people
really
want
to
see
that,
then
then
please
say
something:
I
went
to
the
ops
area
to
try
to
get
some
views
and
they
didn't
really
claim
to
have
the
right
people
to
provide
feedback
on
this.
So
we're
still
actually
not
doing
particularly
well
on
getting
feedback
from
layer
for
load.
C
Balancer
operators,
particularly
the
big
cloud
providers-
azure's-
may
be
an
exception,
but
even
then
they've
been
really
reluctant
to
engage
in
anything
beyond
the
plain
text
algorithm
and
today,
there's
still
five
open
issues.
Several
of
them
have
pr's
and
there
hasn't
been
a
lot
of
feedback
on
some
of
them
and
I'm
kind
of
getting
to
the
point
where
I'm
just
gonna
make
a
decision.
But
I'm
gonna
make
one
last
appeal
for
for
some
guidance
here
next
slide.
C
Okay,
so
the
first
two
bits
of
every
connection
id
are
what
we
call
config
rotation,
so
one
of
them
is
left
for
for
tuple
routing,
which
is
a
different
thing,
but
essentially,
if
you're
rolling
out
a
new
say,
you're
you're
rotating
your
keys,
then
it'll
take
a
while
for
all
your
servers
to
get
those
keys
and
and
switch
from
one
form
cid
to
the
other.
So
for
a
while,
you
can
switch
based
off
these
configuration
bits
to
be
operating
to
algorithms
or
configurations
at
once.
C
There
is
a
proposal
to
make
it
three
and
the
reason
for
that
is
actually,
if
you
have
s-
and
I
switching
next
slide-
and
this
maybe
explains
the
problem
a
little
better.
So
I
presented
this
slide
last
time
too,
but
like
a
really
dumb
thing
to
do,
if
you
were
mega
cloud
corp
who
was
operating
these
these
load
balancers
have
a
single
global
config.
Where
everybody
had.
You
know,
just
there's
one
giant
server
mapping
for
everybody,
because
then
all
the
customers
create
each
other
server.
C
Now,
if
you
have
low
balance
instances,
ips
and
ports,
then
there's
no
problem
here.
You
can
have
different
configs
running
on
those
different
discriminators,
but
if
it's
something
that's
in
the
client,
hello
and
you're,
operating
and
and
you're
trying
not
to
route
off
the
fourth
couple,
because
the
whole
point
of
this
is
to
be
robust
to
migration,
then
you're
you're
gonna
need
something
that
is
that's
in
every
packet
and
they're.
C
Basically
just
two
options:
one
is
to
have
multiple
configs
separated
by
these
configuration
bits,
which
is
which
does
solve
the
problem
of
of
having
the
the
mutually
mutually
mistrustful
customers
being
able
to
reach
other
servers
mappings.
However,
it
also
means
that
that
sni
is
essentially
globally
visible
right.
You
can
connect
to
the
you
can
get
to
the
service
you,
you
could
connect
with
certain
sni,
see
what
the
config
rotation
bits
and
then
understand
those
correspond
which
circumvents
things
like
echo.
C
The
alternatives
just
make
them
share
a
config,
and
then,
if
you
happen
to
be
cohabited
with
with
this
other
customer,
then
then
there's
some
limited
exposure
there,
where
they
can
read
your
server
mapping,
but
it'd
probably
be
hard
for
an
attacker
to
deliberately
position
themselves
it
there.
So
there's
a
trade-off
there,
I'm
kind
of
leaning
towards
the
second
one
actually
I'll,
say
I'll
strongly
lean
towards
the
second
one.
For
some
of
the
reasons
I
just
described.
C
L
I
just
had
a
really
quick
comment,
which
is
that
you
know
anytime,
you
have
like
one
domain
name
mapped
to
one
like
ip.
You
have
immediate
linkability,
so,
like
there's
an
extreme
in
which
you're
just
not
gonna,
obtain
like
the
the
characters
we
would
actually
like.
So
I
don't
know
what
to
do
about
that,
but
I
just
want
to
call
that
out
and
say,
like
the
world
is
not
perfect.
C
Yeah,
absolutely
I
mean
I
think
one
lesson
from
thinking
about
this
quick
obese
stuff
for
a
long
time
is
that
there's
there's
no
guarantees
in
this
space
but,
on
the
other
hand,
like
echo,
exists
for
a
reason
and
largely
it's
consistency
of
the
sni.
So
clearly
there
are
use
cases
and
it
would
be
a
shame
to
kind
of
break
those
with
something
like
this.
C
F
Yeah,
so
there's
there's
two
things
here:
there's
there's
the
this
is
the
same
server
that
we're
talking
to
which
I
think
to
to
ian's
point.
If
the
server
only
has
one,
if
there's
only
one
server
at
this
ip
address,
then
you
know
it's
this
server.
But
the
text
here
is
specific
to
connections
and
I
don't
think
you're
violating
that
requirement
so
directly.
It's
just
that
you're
you're,
creating
smaller
anonymity
sets
for
those
those
customers.
F
C
L
A
C
C
C
There's
nothing
there's
like
a
there's,
a
list
of
the
things
that
you
need
to
configure
to
make
this
work,
but
there's
no
configuration
mechanism
and
I've
really
not
been
able
to
get
any
feedback
from
anyone
on
like
what
would
be
a
useful
thing
to
do.
If
anyone
has
any
ideas
here
like,
I
would
very
much
appreciate
a
pr.
I
think
we
can.
We
can
move
forward
without
it,
but
it
would
make
the
draft
better.
That
was
my
last
request
and
that's
it.
I
think
I
really
am
done
now
eric.
N
We
we,
we
were
chatting
with
some
of
our
cdn
folks
and
some
of
the
other
people
who
do
some
of
our
core
network
operations
and
stuff
about.
You
know:
hey,
there's
this
quick
thing
and
could
we
maybe
like
make
that
work?
Please
and
we
they'd
been
involved
in
some
of
the
very
early
renditions
of
some
of
the
lb
stuff,
and
we
said
hey,
can
you
can
you
take
another
look
and
and
see
and
they
were
very
much
happier
with
with
some
of
the
later
things.
N
C
C
A
O
Good
morning
afternoon
evening,
so
yeah,
actually,
if
you
just
go
to
the
issues
tab,
that's
mainly
what
I
want
to
show
here
is.
We
have
three
issues,
one
of
which
I
was
able
to
do
a
pr
for
during
the
where
we
use
version,
one
is
version,
one
discussion,
one
of
which
I
think
does
require
a
little
bit
of
discussion,
so
whether
we
want
to
have
normative
language
or
not,
and
one
of
which
has
a
little
bit
of
text
to
add.
O
We've
had
some
discussion
on
this
document
sort
of
in
hallways
we've
had
some
discussion
on
the
mailing
list.
We've
had
somewhat
more
discussion
in
the
the
issues.
We
are
getting
more
participation
from
people
who
were
in
the
working
group
this
time
last
year.
Thank
you
very
much.
That's
good!
Basically,
I'm
here
to
say
the
train
is
leaving
the
station.
O
O
O
Yeah,
so
we'll
we'll,
you
know,
I'm
in
the
background
here
sort
of
clearing
these
issues
up,
so
it
could
even
be
by
the
end
of
this
week.
We
have
documents
that
we
think
are
ready
to
rev,
we'll
just
submit
new
versions,
and
then
we
can
discuss
on
the
list
whether
we
want
to
go
to
work
last
call
on
them.
A
Yeah,
I
think
that
makes
sense,
so
we
we
certainly
want
to
like
have
people
take
a
broader
look
at
these,
and
I
think,
going
to
work.
Group
last
call
is
an
excellent
way
to
make
that
happen
and
they've
been
hanging
around
for
a
long
time
and
not
given
that
the
bass
drafts
are
now
stable.
These
ones
can
certainly
stabilize
too,
and
then
we
can
hopefully
ship
them
soon.
So
I
would
agree
with
that
right.
So.
O
If
you
look
at
like,
if
you
look
at
like
issue
100,
one
of
the
reasons
you've
been
have
been
sitting
around
for
a
long
time
is
we're
waiting
for
the
bass
drafts
to
stabilize,
because
we're
actually
sort
of
like
doing
editorial
things
into
those
into
those
drafts.
Right,
like
just
like
making
sure
the
section
numbers
line
up
and
stuff
like
that
was
one
that
we
were
that
we
were
holding
on
to
but
yeah.
O
O
A
So
if
you
switch
to
that
tab
because
I
would
like
to
know
sort
of
who
read
a
version
of
these
drafts
like
during
this
year,
so
so,
if
you
could
sort
of
raise
your
hand
or
not
raise
your
hand
actively,
that
would
at
least
give
a
sort
of
an
initial
feeling
of
you
know
how
much
review
have
these
recently
gotten
in
in
the
working
group
and
that
might
inform
you
know
how
how
long
the
work
and
grab
group
last
call
should
be,
and
so
on.
Plus.
O
A
A
Right
so
I'm
going
to
end
the
session
in
about
three
seconds
and
then
we'll
see
where
we
are
going
once
and
we're
done
so
we
have
16
people
who
said
they
read
a
version
out
of
128
participants,
which
is
not
great
and
and
28
actively
said
they
didn't.
So
I
I
guess
that
that
argues
for
a
longer
working
group.
Last
call
maybe
do
two
or
three
weeks
or
something
like
that
to
really
get
people
to
take.
Take
another
look,
a
pro
tip.
You
don't
have
to
wait
for
that.
A
P
So
I
think,
like
we've,
been
reading
the
other
documents
and
we're
trying
to
flag
anything
that
needs
to
be
mentioned
in
those
drafts
but
like
if
people
have
more
stuff,
that's
something
to
look
for.
It's
not
only
like
reading
the
drafts
and
figuring
out.
If
you
agree
or
disagree
with
anything
that's
in
there,
but
also
figuring
out.
If
there's
anything
that
need
to
be
added.
O
And
I
would
say
there
might
also
be
things
that
that
might
need
to
be
taken
away.
We've
tried
to
take
like
so
things
that
were
initially
mentioned
us,
I
think,
especially
in
the
applicability
draft
that
have
now
made
it
into
the
the
bass
drafts
right,
like
so
things
that
we
originally
didn't
think
were
going
to
make
it
into
the
bass.
A
A
C
C
There's
a
a
version
number,
an
initial
token
extension,
which
is,
which
is
something
that's
just
tacked
on
to
the
to
the
token
and
then
there's
a
salt
and
there's
a
packet
length
offset,
which
is
an
integer
that's
applied
to
packet
links
later
on,
and
so
the
the
salt
and
the
the
offset
are
actually
computed
via
some
some
secure
hash
from
the
version
number
and
ite.
And
so
the
idea
is
that
next
slide.
C
So
this
obviously
greases
a
bunch
of
stuff.
So
so
currently
we
variable
values
for
most
of
the
fields.
The
initial,
but
a
lot
of
them
are
not
unreadable
and
we've
covered.
If
we
covered
a
lot
of
things
that
aren't
so
so,
this
draft
basically
makes
almost
everything
else
unreadable
that
is
supposed
to
be
increases.
C
So
I'm
going
to
make
a
lot
of
claims
about
this
design.
I'm
not
gonna,
read
them
all,
but
sort
of
the
highlights.
So
among
good
things,
I
I'll
contend
that
the
initial
pack
is
entirely
private
immune
from
ossification.
You
can't
ossify
tls
stuff.
If
it's
running
over
quick,
so
we
could
even
use
the
version
field
again
it
greases
things
that
haven't
been
greased
before
it.
You
know,
deals
with
a
lot
of
initial
gesture
injection
attacks,
etc.
C
However,
it
does
not
cover
the
first
connection,
which
is
a
serious
problem.
It
does
depend
on
the
version
negotiation
draft,
which
I
think
is
going
to
move
forward
and
most
of
all
like
this
is
something
that
I
think
a
lot
of
people
incentive
to
drop
and
if,
if
no
like,
economically
important,
browsers
and
websites
are
interested
in
this,
then
it's
really
not
worth
moving
forward
on
in
terms
of
moving
forward.
Q
I
wonder
that
if
we
do
want
to
make
the
connection
more
robust,
whether
we
should
actually
change
the
encryption
or
add
an
additional
checksum
to
verify
that
the
things
are
not
missed
in
transit,
I
mean
there
is
a.
There
is
a
big
step
in
robustness
between
preventing
third
party
to
mess
with
the
packets
and
making
the
packet
not
observable
by
anybody,
because
make
not
observed
by
anybody
may
well
be
a
bridge
too.
Q
C
Yes,
I
I
know
you
have
something
in
this
space
christian,
there's
a
separate
draft
that
you
and
kazuo
did,
which
was
an
influence.
So
thanks
for
that
all
right
yeah.
So
I
think
I'm
I'm
trying
to
dial
this
up
to
really
this
sort
of
a
maximum
result.
I
think
some
people
in
the
in
the
in
the
chat
are
saying
well.
C
This
is
really
about
the
greasing
not
about
the
security
and
the
privacy,
and
if
that's
the
attitude,
I
think
you
know
we
can
go
something
closer
to
martin
seaman's
original
proposal,
which
is
just
that
for
a
for
a
server
to
to
have
two
or
three
versions
that
and
different
salts
that
it
just
gives
to
everybody.
That's
a
direction.
We
could
take
this
if
people
are
interested
in
implementing
that.
C
A
It
would
be
interesting
to
hear
some
comments
on
on
what
direction
people
think
work
in
this
space
should
take.
If
any
right
should
it
go
towards
greasing,
should
it
go
towards
what
christian
outlined
should
it
you
know,
should
we
not
do
anything
in
this
space,
so
maybe
some
quick
feedback
would
be
useful.
I
guess
for
martin
to
to
determine
if
he
wants
to
spend
more
time
on
this
david.
H
Cool,
I
I
think
this
is
great.
I
think
this
is
useful
and
it's
gonna
help.
You
know,
make
a
slight
dent
in
optification
risk
and
also
has
slight
privacy
improvements.
I
think
you're,
maybe
overselling
the
properties
we
get,
but
that
doesn't
mean
we
shouldn't
do
this.
That
just
means
that
we
need
to
actually
do
the
security
analysis,
so
I'm
supportive
of
the
working
group
spending
time
on
this.
Maybe
you
know
after
we
you
know
time
permitting.
H
H
A
J
J
That,
obviously
is
the
same
problem
you
have
here,
which
is
that
if
you
like
lose
state,
then
you
gotta
have
a
way
to
recover,
and
so
the
way
you
recover
is
basically
by
being
like.
Oh,
I
detected
that
like,
if
you
I
mean,
if
you're
in
the
state
you
recover
with
like
a
vn
and
then
you
start
and
then
you
leave
in
the
elite,
the
state
and
the
wire
and
an
ech
on
the
union
mechanism.
We
don't
need
to
save
the
wire.
J
C
C
J
Well,
no,
I
I
I
I,
I
think
the
po,
I
think
the
point
would
be.
I
think
the
idea
would
be.
You
would
hoist
that
you
would,
I
think
so,
if
I
remember
call
correctly,
kazuho
and
grisham's
proposal
basically
had
the
ech,
but
also
hoisted
some
of
that
information
into
quick.
So
you
could
encrypt
you
can
send
for
the
initial
as
well
as
just
suffering
as
well
as
decide
for
the
tls
payloads.
So
the
question
be,
can
you
do
that
right?
J
N
Yeah,
I
would
I
would
second
david's
comment
in
the
sense
that
I
would
be
very
interested
in
greasing
a
bunch
of
this
stuff,
and
I
think
it's
worth
spending
some
time
to
see
if
we
can
get
some
meaningful
security
and
privacy
wins,
but
at
the
very
least,
let's,
let's
grease
it,
so
that
if
we
even
if
it
takes
us
a
whole
nother
version
to
deliver
some
security
and
privacy
wins
it'd,
be
real
cool.
If
we
could,
actually,
you
know,
use
that
version.
Q
C
Okay,
well
thanks
for
everyone,
so
I'm
getting
the
cautious
enthusiasm
I
was
hoping
for.
So
I
will
continue
to
progress
this
draft
as
best
I
can.
Please
read
it
comment
on
the
github,
etc.
Okay,
so
the
other
draft
I
have
is
is
somewhat
less
exciting.
This
came
out
of
a
conversation
in
tsvwg
about
nats
and
quick
next
slide
yeah,
and
this
is
what
it's
saying
like
a
nat
designer
might
look
at
the
the
the
connection
say.
C
So
this
is
one
example
like
you
could
try
to
multiplex
on
on
a
port
by
distinguishing
from
from
the
cids,
but
of
course,
at
the
mobility
event,
that's
that's
going
to
create
a
black
hole
which
is
worse
than
rejecting
the
the
connection
in
the
first
place
next
slide
and
then
on
the
upper
side.
On
the
other
side
on
a
server
net,
you
can
attempt
to
conceal,
address
changes
to
allow
a
routing
infrastructure
to
afford
temple-based
routing
structure
infrastructure
to
to
work
without
modification.
C
But
then
you
essentially
erase
the
signal
that
of
the
of
the
mobility
event,
that
is,
that
triggers
all
the
path,
verification
stuff
so
you've
basically
broken
the
security
model,
quick.
So
basically,
just
it's
just
a
very
short
draft
that
says:
don't
do
that
stuff
next
slide
and
as
I
mentioned
in
my
other
talk
like
somebody
asked
about
proxy
protocol,
I
know
that
I
saw
that
cloudflare
done
something
in
this
area
and
written
something
down.
It
would
seem
to
fit
in
in
that
type
draft.
C
So
I
honestly
don't
care
how
we
triage
this
information.
It's
currently
individual
draft.
Obviously
we
could
toss
it
into
the
ops
draft.
We
could
just
have
a
reference
to
this
expired
draft
in
the
ops
draft
and
not
have
all
this
verbage
polluted
we'd
want
to
pollute
the
off
strap
with
all
this
verbage.
It
could
be
an
info
rfc.
I
could
do
it
here.
I
could
do
it
in
his
uwg
or
we
could
just
drop
it
all
together.
People
think
this
is
stupid
and
pointless.
A
Input
on
that,
thanks,
please
get
in
the
queue.
I
would
say
that
if
we
decide
that
text
along
the
lines,
these
lines
is
needed.
I
I
would
have
a
preference
for
seeing
it
in
the
op
graph
simply
because
this
seems
like
something
that
that
is
a
good
target
for,
but
it's
a
question
of
how
much
are
we
talking
about,
and
you
know
that's
a
different
comment
from
the
group.
A
R
When
we
talked
about
it
in
tsvwg,
one
of
the
good
things
about
having
a
separate
draft
might
be
that
somebody
who's
looking
to
implement
a
nat
found
it
with
the
other
rfcs
about
how
to
do
nat,
and
then
they
read
ready,
and
then
they
thought-
let's
not
do
this,
so
that
was
the
only
thing
that
was
discussed
in
tsvwg,
which
said
this
might
be
worth
publishing,
something
to
think
about
yeah.
I
don't
have
a
strong
preference
myself.
A
P
P
I
mean
I
think
we
can
easily
have
a
shorter
word
in
the
body
and
then
add
some
more
text
in
the
panic.
So
whatever
I
didn't
look
at
in
detail,
but
I
think
we
can
also
merge
the
whole
thing
into
ops,
because
if
that's
you
know
where
people
look
for
it,
then
that's
fine,
like
yeah
or
separate
rc
is
also
for
me.
I
don't
know.
G
A
C
A
B
I
J
I
I
I
I
We
have
evaluated
it
over
the
different
quick
for
that
scenarios.
Here
I
showed
just
quickly
some
results
on
the
case
where
we
have
50
megabits,
download,
10,
megabits,
upload
and
rtt
of
more
than
600
milliseconds.
We
use
cubic
as
a
condition
control
and
how
the
conjunction
control
reacts
to
the
zero
rtt
pdp
information
it
just
jumped
to
the
previously
measured
capacity.
This
is
really
not
what
we
comment.
I
I
I
C
A
S
That
the
server
informs
a
client,
you
know
about
its
current
bandwidth
estimate
and,
like
other
network
characteristics
and
the
way
that
we're
doing
this
is
with
with
a
quick
frame
and
there's
a
lot
of
similarities
for
our
infrastructure.
It
makes
more
sense
for
the
server
to
kind
of
actively
keep
track
of
this
stuff
and
remember
it,
but
so
it
would
be
nice
if,
like
we
could
do
something
like
this
with
the
same
sort
of
frame.
So
like
the
I
I
think
it's
compatible.
S
You
know
if
we
have
a
frame
that
can
convey
this
sort
of
commonly
useful
information,
and
you
send
that
as
part
of
zero
rtt,
then
it
can
go
in
the
other
direction
too.
So
you
could
have
a
client
that
remembers.
You
know
this
sort
of
thing
and
sends
it
and
then
the
server
consumes
it
rather
than
the
other
way
around.
Q
Obviously
they
can
also
use
the
same
kind
of
stuff.
We
do
with
tokens
to
remember
that
and
if
they
do
that
with
token,
they
probably
want
to
do
that
not
with
the
tls
token,
but
rather
with
the
new
token,
because
the
new
token
is
much
a
better
fit
in
the
sense
that
it
can
be
sent
at
any
time.
In
the
connection,
without
messing
with
the
theoristic
machine.
Q
A
Q
L
So
yeah,
I
actually
think
this
is
potentially
fairly
dangerous
because,
like
you're
sending
something
the
client,
the
client
is
going
to
send
back
without
any
authentication
and
potentially
open
a
much
larger
quotation
window
or
other
information,
I
think
doing
it
in
the
new
token
frame
is
relatively
safe.
I
mean
relatively
there's
some
guide
buns.
I
think
that's
a
tsv
area
sort
of
like
gig
to
figure
out
what
the
guidelines
are,
but
I
don't
see
why
we
need
to
do
anything
in
quick
for
this.
L
D
D
My
question
my
question
is:
is
there
a
reason
to
make
this
visible
to
the
client
in
the
sense
that
the
server
is
the
one
that's
exporting
this
value
and
then
is
going
to
receive
it
back?
You
could
keep
this
completely
opaque,
that's
what
you
get
for,
putting
it
in
the
in
the
new
token,
the
new
token
a
server
can
do
that
already.
I
A
I
T
For
those
who
don't
know
q
log,
it's
it's
a
way
for
endpoints
themselves
to
structured
standardized
way
to
lock
whatever
protocol
events
are
happening.
This
is
useful
for
debugging
and
analysis.
You
might
want
to
use
things
like
packet
captures
for
that,
but
this
approach
has
some
benefits
over
that.
Firstly,
you
can
log
things
that
are
not
reflected
on
the
wire
like
congestion
windows,
it's
also
more
interesting
for
privacy,
because
you
don't
need
to
decrypt
the
entire
packet
capture.
You
can
only
log
the
things
that
you
actually
care.
B
T
T
T
T
This
is
still
just
a
personal
draft
for
me
and
we
have
relatively
few
people
dealing
with
the
day-to-day
work
on
these
things,
and
we've
just
released
a
draft
o2
of
this.
With
most
of
the
things
we
could
reach
consensus
on
our
own,
but
we
think
it's
time
for
some
additional
discussion
to
see
how
to
how
to
progress
keylog
in
the
future.
T
T
T
T
A
That
seems
to
work
well
enough,
but
for
quick
it
certainly
fills
the
need,
as
as
can
be
seen
by
the
adoption
and
by
partially
by
the
deployment
that
it's
seen
right.
So
I
think
for
personally,
I
I
think
it's
shooting
too
far.
I
I
would
think
three
is
is
reasonable
if
we
see
enough
interest
from
within
the
quick
group-
and
it
doesn't
preclude
doing
four
at
some
future
point,
but
I
think
at
the
moment
the
sweet
spot
seems
to
be
what
what
qlik
does
for
quick.
C
This,
I
I
I
think.
Well,
of
course
you
have
two
drafts.
I
I
definitely.
I
would
definitely
like
to
see
the
quick
q
log
draft
adopted
in
this
working
group.
I
would
I
would
strongly
support
that,
because
I
think
it's
it's
it's
ubiquitous
enough
in
these
implementations
that-
and
you
know
it's
like
it
is
the
default.
B
N
So
I
would,
I
I
think
qlog
is-
is
great.
We've
we've
adopted
it.
I
think,
there's
a
really
nice
privacy
win
to
not
having
to
export
the
keys
for
all
of
the
content
that
you're
sending
in
a
way
that
for
a
connection
going
over
tls,
we
can
just
drop
the
headers
in
a
pcap
and
be
done,
I
think,
being
able
to
visualize
more
than
what
you
just
get
from
a
bunch
of
tcp.
N
Headers
is
actually
really
nice,
especially
as
we
can
expand
that
into
h3
and
looking
at
some
of
the
prioritization
schemes
and
that
sort
of
thing
I
think,
that's
been
both
useful
in
debugging
problems,
but
also
useful
in
helping
people
conceptualize
the
impacts
of
the
changes
we're
making
in
the
specs.
So
I
think
it's
both
useful
for
the
working
group
doing
the
working
group
and
for
the
implementations
actually
deploying
things
so
I'd
love
to
see
more
of
those.
I
think
I'd
actually
slightly
disagree
with
lars.
N
In
that
I
would
be
interested
in
bringing
some
of
this
to
tcp.
I
think
yes,
there
are
tools.
I
think
what
we've
got
right
now
in
q-log
is
almost
as
good
as
most
of
those
tools,
and
so,
if
we
can
put
all
those
in
one
place,
we
currently,
you
know,
have
the
ability
to
dump
a
bunch
of
packets
for
tcp
stuff
being
able
to
dump
a
bunch
of
q
log
for
quick.
It's
very
quickly
becoming
apparent
that
you,
you
look
at
the
quick
stuff
and
you're
like
wow.
T
Yeah,
if
I
can
just
interject
a
little
bit
it's
it's,
not
it's
not
so
much
expanding
into
tcp,
although
that's
definitely
something
we've
been
doing,
but
it's
more
also
new
application
layer
protocols
right
like
dns
over
tls
with
dns
real
quick
that
kind
of
stuff.
I
think,
there's
there's
a
lot
of
potential
there.
I
know
that,
for
example,
some
others
have
been
trying
to
use
this
for
pgp
and
that
kind
of
ian
go
ahead.
L
D
Yeah,
thank
you
for
this.
Thank
you
for
this
work,
robin
that
you've
been
doing
on
this
for
all
this.
While
I
q
log
is
quickly
becoming
a
d
factor
standard,
and
I
think
that
it's
given
the
number
of
implementations
that
are
supporting
it
and
plan
to
continue
supporting
it.
It's
it.
It
makes
a
lot
of
sense
for
us
to
to
include
it
in
a
part
of
the
working
group
of
the
quick
working
group
we've.
D
We
need
to
have
tooling,
and
this
is
one
of
the
one
of
the
ways
that
we've
managed
to
get
some
seriously
good,
tooling
and
and
that's
important
now.
That
said,
I
want
to
draw
a
line
between
the
q
like
format,
and
the
tooling
that
goes
with
it
like
cube,
is,
is
the
thing
that
people
love
q?
Log
is
a
thing
that
people
manage
to
somehow
rule
and
somehow
follow.
D
So
those
are
two
different
things
right,
so
so
so
I
think
that
when
you're
talking
about
adopting
something
here,
we
are
going
to
be
adopting
q
log.
The
format
not
q
is
the
tool
and,
to
the
extent
that
we
are
talking
about
q
log,
I
would
like
to
make
sure
that
we
don't
try
to
expand
the
scope
of
that
within
this
working
group
to
include
tcp.
D
I
would
love
for
tcp
to
have
all
of
this.
I
would
love
for
tcp
to
have
the
same
sort
of
you
know,
multi-dimensional
capabilities
that
cubist
provides
for
quick
and
http
3,
but
in
trying
to
solve
both
of
those
problems,
we
might
end
up
casting
to
widen
it.
I
would
rather
see
qlot
be
specific
to
quick
and
something
similar
or
parallel
to
it
can
evolve
for
tcp.
If
there's
adequate
interest
in
tcpm,
I
would
love
to
see
qrak
be
here
and
and
and
limited
to
quick.
A
Yeah
quickly
in
the
check-
and
so
I've
heard
from
people
who
are
not
on
the
call
also
that
there's
this
distinction
that
I
mentioned
between
q,
log
and
q,
which
is
interesting
and
and
one
discussion
that
isn't
really
in
scope
for
the
working
group.
But
it's
very
important
to
have
is
sort
of.
What's
the
you
know,
model
forward
for
jointly
developing
qvis
or
similar
tools,
because
there's
obviously
pretty
strong
dependency
between
the
log
format
and
the
tools
and
can't
really,
you
know,
evolve
one
forward
without
thinking
about
the
other.
E
A
B
For
this
thing,
hopefully
people
can
contribute.
We
can
get
a
bit
more
governance
over
over
the
spec
in
order
to
help
it
thrive
rather
than
kind
of
get
a
bit
stuck.
Looking
for
answers
from
people
who
are,
I
don't
know,
maybe
not
so
focused
on
delivering
something.
So,
there's
probably
a
roundabout
way
of
saying
as
an
individual.
I
would
support
adopting
this
somewhere,
rather
than
requiring
it
to
remain
an
individual
draft.
A
A
I
think
I
don't
want
to
say,
require,
but
really
encourage
people,
especially
people
that
are
running
qlok
in
production
in
some
way
to
like
chip
in
and
and
throw
some
effort
at
helping
out
here
to
develop
this
forward,
both
on
writing
the
specification
and
developing
it,
but
also
possibly
on
on
the
the
visualization
tools
right,
which
are
this.
This
other
thing
that
everybody
benefits,
if
th
those
tools
get
better
and
and
that
there
should
be
a
joint
interest
in
making
making
those
better.
A
I
think
we're
going
to
continue
this
discussion
on
the
list.
I
sort
of
what
I
heard
was
mostly
leaning
towards
three
and
four
on
your
list
that
I
cunningly
took
away
already
on
your
last
slide.
So
I
think
we're
gonna
we're
gonna
have
a
discussion
about
whether
we
take
this
on
and
where
it's
also
a
discussion
we
need
to
have
with
the
ads.
In
case
we
gravitate
towards
four,
rather
than
three
and
even
three
going
quickly
into
the
planning
and
wrap
up.
A
So
I
talked
we
already
talked
about
what
we're
planning
for
the
base
drafts
and
we
talked
a
little
bit
that
we're
gonna
see
that
we
can
progress.
The
already
adopted
other
work
items
like
ops
and
various
extensions
forward
and
we're
gonna
see
what
what
else
we
can
adopt.
Multipath
is
another
thing
that
we're
going
to
talk
the
rest
of
the
20
minutes.
A
There's
a
question
mark
how
much
the
charter
should
restrict
us
in
terms
of
topical
scope,
for
extensions,
for
example,
that
we're
going
to
take
on
so
that
that
will
happen
and
you'll
see
draft
versions
of
the
chartered,
and
you
can
comment
on
them.
I
guess
over
the
next
few
weeks,
sometime
future
meetings,
I
don't
think
we're
planning
anything
before
the
next
itf
unless
the
multipath
discussion
seems
to
develop
in
a
two
direction
where
another
interim
might
be
useful.
A
At
the
moment
I
don't
see
any
other
topic
sort
of
requiring
an
interim
of
some
sort,
and
with
that
I
think
I
want
to
open
the
floor.
We
have
20
minutes
for
the
multipath,
this
continuing
of
the
multipath
discussion,
and
maybe
I
want
to
first
sort
of
so
so
there's
a
there's.
It's
been
free-flowing
quite
a
bit
on
the
working
group,
but
there's
been
some
sort
of
directions
that
have
become
a
little
bit
clearer
right.
So
there's
this.
A
Some
people
seem
to
believe
that
the
what
we
currently
have
in
the
base
drafts
is
effectively
support
of
some
parts
of
what
a
full
quote-unquote
multi-part
solution
would
offer
and
therefore
we
already
have,
if
you
want
to
look
at
it,
that
way
delivered
on
our
charter
promise
to
ship
multipath,
we
haven't
shipped
multipath,
that's
compatible
and
features
with
multipath
tcp,
for
example,
but
we
have
some
support
for
multiple
paths
and
some
people
have
said
that.
That's
enough
to
address
the
charter
item,
we
had
there's
other
people.
That
say
you
know.
A
The
charter
item
was
written
specifically
to
enable
use
of
multiple
paths
concurrently
and-
and
that
is
not
something
that
is
maybe
easily
enabled
by
what
we
have
and
I
would
like
to
sort
of
try
and
see
if
we
can
come
to
an
agreement
on
whether
some
of
those
use
cases
that
we've
seen
presented
during
the
interim
are
supported
by
what
we
currently
have
and
if
there's
enough
support
for
doing
something
else.
That
would
support.
Maybe
some
more
use
cases
that
we've
seen
presented
and
I've
talked
enough.
I
think
so
so
please
get
into
the
cube.
A
U
At
this
point,
that
said,
my
personal
take
is
what
people
have
described
as
use
cases
and
the
ones
I
personally
care
about.
Don't
work
in
quick
now
without
multiple
connections,
and
you
can
always
have
multiple
connections,
so
you
can
get
multi-path
at
the
application
layer
by
using
multiple
connections
and
the
failover
characteristics
that
are
there
now.
U
And
if
we
are
going
to
do
multi-path
with
quick,
whether
it's
going
to
be
a
baseline
version
of
quick
or
an
extension
or
a
version
that
runs
parallel
to
the
kind
of
current
failover
version
that
we
have
now.
So
I
I
think
my
personal
take
is
that
all
of
those
are
kind
of
still
on
the
table,
given
what
we've
seen.
But
I
would
prefer
to
see
a
concurrent
multi-path
as
a
version
of
quick,
possibly
not
the
same
version
as
the
failover
version
of
multipath,
and
I've
talked
too
long.
Thanks
very
much.
L
L
Real
quick
is
sensible
because
we
have
tons
of
versions
and
it's
not
really
a
very
large
post,
not
sure,
really
sure
what
else
to
say,
but
except
to
say
that,
like
we're
at
the
factory
like
we've,
been
deploying
quick
for
six
years
or
something
g,
quick
put
that
in
iedf
standard
and
that's
clear
indication
that
you
can
wipe
to
deploy
something
without
an
idea
of
scenarios
and
then
come
back
with
information
to
inform
the
working
group.
Do
you
create
a
good
term?
G
I
want
to
just
mention
a
couple
of
things.
One
is
that
I
think
that
one
of
the
one
of
the
questions
I
wanted
to
ask
was,
you
know
we're
talking
about
like
having
quick,
quick,
do
all
the
scheduling
for
multiple
paths
or
having
applications
do
that
there's
been
at
least
a
couple
of
people
that
have
mentioned
on
the
mailing
list,
the
possibility
of
coming
up
with
some
kind
of
common
layer
on
top
of
quick
that
would
handle
multiple
con
connections.
G
I'm
curious
how
many
people
have
thought
of
that.
Besides
the
three
people
who
said
it
on
the
mailing
list,
none
of
which
were
me.
Second,
I
really
want
to.
I
really
want
to
agree
with
the
point
about
doing
experiments
and-
and
I
really
want
to
thank
the
working
group
for
being
willing
to
talk
about
multi-path
on
this
mailing
list
and
to
consider
multiple
experi.
You
know
multiple
experiments
to
see
what
we
really
need,
and
I
I
am
trying
to
do
some
analysis
in
the
draft.
G
N
Yeah,
I
would
be
somewhat
interested
in
seeing
folks
maybe
write
up
or
use
one
of
the
existing
multi-path
extensions,
slash,
call
it
a
new
version,
whatever
you
want
to
do
and
actually
deploy
it
and
get
some
experience
to
echo
some
of
ian's
comments
and
others.
I
think
that's
something
that
we
do
for
a
lot
of
other
protocols.
I
don't
think
you
need
to
have
the
rfc
to
get
that
experience.
N
So
I
like,
if,
if
we
said,
wow
look
and
here's
an
actual
real
world,
end
user
benefit
where
it
does
this
awesome
stuff
like
cool.
I
like
that,
but
I
think
we're
seeing
a
lot
of
people
who
are
very
hesitant
to
put
time
and
energy
in,
and
I
think
that's
also
a
completely
reasonable
response
until
we've
actually
been
able
to
demonstrate
some
actual
benefit.
D
Thank
you,
so
just
a
few
quick
points
at
a
high
level,
I
I
I
tend
to
think
that
multipath
should
be
in
the
transport.
This
is
something
that's
going
to
be
useful
in
the
long
term.
However,
I
want
to
be
clear
that
I'm
talking
about
what
I
believe
where
I
believe
multipath
ought
to
be
in
the
long
term.
As
far
as
now
is
concerned,
I
I
we've
spent
a
lot
of
time,
building
up
connection
migration
and
all
the
things
that
we
needed
to
make
that
work.
D
D
If
people
want
to
experiment,
I
would
recommend
one
strong
thing
and
a
strong
encourage
people
experimenting.
I
don't
need
to,
but
as
ian
is
pointing
out,
people
are
free
to
go
experiment
on
their
own,
but
I
would
I
would.
I
would
ask
that
people
consider
the
mechanisms
that
are
already
in
place.
We
spent
a
fair
amount
of
time
trying
to
figure
that
out
simply.
D
D
The
fact
that
multipath
can
be
used
with
quick
is
something
that
that
that
needs
experimentation
and
folks
who
can
do
this,
can
do
this
and
bring
the
bring
results
to
the
table
or
bring
the
experiences
to
the
working
group.
But
the
design
of
the
protocol
itself
can
be
something
that
whatever
you
choose
to
use
is
perfectly
fine.
We
can
design
protocols
as
a
working
group
later
and
make
it
better.
What
I
would
want
to
see
is
how
it
gets
used
and
what
the
value
of
it
is
in
actual
deployments.
Q
M
B
B
Is
that
we're
still
trying
to
to
to
take
this
transport
layer
and
map
hp
3
on
the
top
as
a
fully
formed
complex
application
protocol,
that's
multi-streaming
and
will
be
used
in
ways
that
exercise
quick
for
its
intended
goal
in
the
first
place
to
mitigate
head
of
line
blocking
and
some
other
things?
Yes,
quick
can
be
used
for
lots
of
stuff,
but
this
is
going
to
be
a
good
test
of
implementations
and
how
they
do
things
like
tuning
of
congestion,
control
and
flow
control
of
streaming
data.
B
So
I
think
too
much
focus
on
using
multipath
to
solve
perceived
performance
problems
of
quick
implementations
right
now,
risks
kind
of
throwing
bandwidth
a
problem
that
could
be
solved
through
continued
deployment
experience
just
with
quick
version,
one
and
or
extensions
that
can
be
more
easily
designed
deployed
and
tested,
such
as
delayed,
ack
or
other
things
that
people
have
on
the
table
that
they
might
like
to
try.
So
that's
that's.
N
I
would
actually
agree
with
that
a
lot
I
like
the
idea
of
of
not
just
throwing
multipath
at
the
problem.
I
think
we've
deployed
a
bunch
of
multi-path
stuff
and
even
there
the
problem
is
not
technical.
The
problem
is
policy
and
the
problem
is
cost,
and
so
I
think
if
we
were
to
see
a
industry
change-
and
I
know
some
people
have
have
promised
that
that
might
be
a
thing,
but
I
I
don't
know
if
we've
seen
that
yet
if
we
were
to
see
a
difference.
M
N
Cost
structure
or
non-standards
incentive
structure.
I
think
we
might
see
a
lot
more
people
being
way
more
interested
in
deploying
multi-path
things
so
that
that's
I,
a
lot
of
people
have
been
talking
about
a
lot
of
use
cases
that
are
like
well.
This
would
be
super
cool.
If
something
else
happened,
I'm
not
saying
we
shouldn't
solve
the
problems
that
we
will
need
to
solve
when
that
day
arrives,
but
if
we're
advocating
that
we
think
that's
that's
not
going
to
be
a
big
policy
problem.
D
I
I
completely
agree
with
what
eric
just
said.
I
wanted
to
re-emphasize
something
that
lucas
pointed
out.
One
of
the
things
that
made
mpdcb
slightly
easier
grant
that
mpdcp
had
its
own
troubles
was
that
it
was
operating
under
a
single
byte
stream,
so
the
constraints
on
it
were
pretty
clear
in
terms
of
what
the
receiver
needed
to
do.
It
needed
to
re-realign
the
byte
stream
and
reorder
the
byte
stream
and
and
deliver
data
back
up
back
up
in
order.
Quick
introduces
several
degrees
of
freedom
in
this
particular
one.
D
It
introduces
a
degree
of
freedom
of
having
multiple
streams
and
then
there's
priorities
potentially,
and
that
is
a
significant
difference
in
that.
In
that
it
it
it
takes.
Your
scheduling.
Problem
of
multiple
paths,
multiplies
it
with
the
scheduling
problem
of
multiple
streams,
on
multiple
paths,
and
now
you
have
a
much
harder
problem.
This
is
not
just
a
priority
problem.
This
is
actually
a
performance
issue.
D
G
I
think
at
least
one
separate
ietf
meeting
I'd
say
that
there's
a
fascinating
conversation
happening
in
the
jabra
room.
That
would
be
good
to
take
note
of
at
some
point,
but
beyond
that,
the
one
important
point
that
came
up
in
slack
when
it
was
not
being
relayed
to
the
jabber
room
during
the
virtual
interim
was
recognizing.
G
P
P
Now,
it's
like
congestion
control
like
optimizing
it
for
like
the
best
case
or
whatever
it's
really
complex,
because
there
are
a
lot
of
factors
and
that's
not
what
we're
looking
for
we're
looking
for
is
like
some
simple
scheduling,
basic
schemes
that
support
a
lot
of
the
base,
use
cases
to
start
with,
and
then
what
we're.
Also
looking
for,
especially
in
a
quick
working
group,
is
to
get
the
signaling
into
the
protocol
and
get
that
specified.
So
people
can
actually
start
experimenting
with
scheduling,
but
like
we
don't
need
to
experiment
with
the
fingerling.
P
P
A
No,
I
think
that's
that
was
somewhat
useful.
I
thought
so
so
I
think
I
actually
saw
enough
people
talking
about
the
desire
to
see
more
experimentation
for
multipath,
which
is
something
that
I
think
so
nobody's
spoken
against.
That
right.
I
think
there's
still
a
question
mark
in
my
mind
as
to
what,
if
the
working
group
needs
to
do
anything
here
to
enable
that
experimentation,
because
it
you
know
you
can
do
a
private
version,
there's
several
of
them,
and
you
can.
A
You
know,
experiment
with
multipath
that
has
happened,
and
we've
seen
some
reports
from
alibaba
and
others
that
have
done
that,
but
it
so
so
that,
at
least
in
my
mind,
I
don't
see
a
need
for
the
working
group
to
do
work
on
something
that
is
multipath
related
to
further
enable
anything
here
it.
So
it's
very
clear
that
we're
not
going
to
change
v1
to
to
do
anything
here
right.
A
So
if,
if
people
either
in
the
in
the
minute,
we
have
intended
in
the
queue
could
could
say
what
what
the
working
group,
if
what
they
see
in
the
working
group,
to
do
what
what
need
they
see.
I
think
that
might
be
helpful
for
lucas
and
me
to
figure
out
as
we
go
into
the
rechartering,
what
text
we
should
write.
There's
two
people
in
the
queue
be
very
quick.
Thank
you.
Three
people.
U
Have
people
comment
on
it,
share
their
experiences
and
compare
the
implementations
among
those
people
who
are
heading
down
one
or
more
of
these
multi-paths
sorry,
and
I
don't
think
that
the
support
necessarily
needs
to
be
more
than
that
at
the
beginning,
but
I'll
point
out
that
in
his
case
he
came
to
the
point
where
he
said.
Look
there's
this
thing
in
the
transport
draft
that
I'm
going
to
have
to
relax
for
one
of
my
things
to
work.
Is
that
going
to
be
okay,
and
the
discussion
then
has
to
happen
in
this
working
group?
U
A
A
P
A
P
D
Yeah
I'm
with
lars
on
this
one.
I
I
just
two
very
quick
points,
because
your
past
time,
anyways
first,
I
think
that
this
is
a
100,
a
question
of
experimentation,
single
in
in
multiple
design
packet
number
spaces.
Having
built
this
with
single
packet
number
space,
I
can
say
that
it
is
all
about
performance.
If
it's
not
about
performance,
then
that
design
question
basically
doesn't
matter
at
all.
D
So
in
this
particular
case
I
would
say
that
people
can
experiment
and
if
people-
and
we
can't
specify
and
expect,
I
don't
think
that,
just
because
we
specify
people
will
show
up
and
start
experimenting,
it
has
to
be
the
other
way.
If
people
are
experimenting,
then
there's
a
point
in
trying
to
specify
something.
So
if,
if
we
want
to
encourage
experimentation,
then
we
can
encourage
that
by
allowing
what
ted
said
basically
allow
people
to
present
their
results,
I'll
I'll
echo
what
david
sinaji
said
on
chat.