►
From YouTube: IETF109-TSVAREA-20201120-0730
Description
TSVAREA meeting session at IETF109
2020/11/20 0730
https://datatracker.ietf.org/meeting/109/proceedings/
A
My
terrible
bone
conducting
headphone
micro
mic
there,
I'm
like
okay,
I'm
gonna,
go
actually
go
ahead
and
invest
it.
B
C
I
think
so,
quite
soon,
what's
up
yeah
I
mean
I
was
keeping
shutting
a
bit
here
so
that
everyone
yawnings
actually
have
something
to
listen
to.
So
they
know
the
things
are
working.
So
that's
my
primary
thing
of
actually
keeping
me
busy
here,
but
I
will
very
soon
start
as
soon
as
martin
has
rejoined
so.
C
I
can
start
so
welcome
everyone
to
tsb
area
the
meeting,
so
I'm
minus
westland
and
my
co-id
martin
he's
on
picture
two
so,
and
I
asked
him
to
so.
The
note
well
applies
also
to
this
meeting,
and
so,
if
you
don't
know
it
read
up
on
this,
the
bcps
etc
about
code
of
conduct
and
the
rest
procedures,
copyright
patents,
all
these
things
and
the
our
standardization
process,
so
this
meeting
will
be
fairly
straightforward.
C
C
C
B
Yeah,
so
we
have
a
new
chair,
chin
wu-
I
don't
know
if
he's
in
in
the
room
today,
but
he
he
he's
chaired
a
number
of
other
groups
before
he's
been
involved
in
out
there
for
a
number
of
years
and
he's
taking
over
the
the
existing
two
existing
chairs
are
going
to
step
down
and
over
the
next
few
months
as
they
complete
their
milestones.
B
We're
almost
done
with
the
milestones
and
we're
going
to
recharge
her
soon,
and
most
of
this
week's
meeting
was
about
that
rechartering
and
there's
a
bunch
of
great
ideas.
We
just
have
to
narrow
them
down.
I
guess
I'll.
Just
talk
through
all
my
stuff
see
anything
else
of
note
really
here
you
can
kind
of
see
what
it
says
and
yeah
I
mean
alto
is
actually
probably
the
one.
That's
had
the
the
most
interesting
transition
of
really
all
the
working
groups
that
I
that
I
oversee
so
off
to
you
magnus.
C
Yes,
so,
first
of
all
in
d10
we
have
a
new
working
group
sharing
bahrain.
I
really
want
to
thank
mark
blanchett
has
been
since
the
working
group
was
shortage
and
I'm
very
much
a
large
applause
for
him
for
doing
this
work,
for
they
are
finishing
up
the
core
documents:
we're
really
trying
to
get
through
this
dvd
first
at
the
court
documents,
and
then
I
hope,
we'll
see
more
continued.
C
So,
and
in
nfsv4
is
not
meeting
this
week,
they're
planning
an
interview
meeting
in
a
few
weeks
and
they
have
restarted
to
include
rdma
maintenance.
Since
last
meeting,
quick,
that's
been
big
news.
The
base
process
ended,
like
they've
lost
call
earlier
this
week
they
had
a
military
on
multi-paths
and
that's
discussion.
It's
kind
of
ongoing,
but
there's
a
direction
here
for
enabling
experimentation
discussion,
but
we'll
see
how
that
we'll
see
it
as
continue.
C
So
in
the
working
group,
perhaps
series
of
injury
meetings
and
they're
very
close
to
having
an
interface
document.
That's
why
we're
having
the
reminding
people
here
and
maybe
take
a
look
at
this
as
they
finishing
up
their
first
set
of
interface,
space,
api
specifications
or
not
api,
but
what
the
interface
looks
like,
I
hope
will
stram
will
be
done
sometimes,
but
it's
not
making
lots
of
progress,
but
otherwise
it's
it's
one
final
documents
before
that
working
you
can
close.
B
Oh
yeah,
so
lars
on
jabber
asked
what
alto
was
recharging
for.
There
were
actually
five
different
themes
that
came
up
in
the
discussion,
and
I
told
them
to
try
to
reach
consensus
on
the
subset
of
those.
There
was
actually
quite
it's
not
a
large
group
by
any
means,
but
there
was
quite
a
lot
of
energy
around
a
lot
of
these
ideas.
If
people
were
interested,
the
agenda
materials
have
like
a
lot
more
information
about
these.
These
concepts
and
lars
is
in
the
queue.
E
Yeah,
hey
sorry,
I
don't
want
to
drag
this
out.
I
was
a
little
bit
surprised
because
so
has
alto.
I
have
not
followed
it
in
a
while.
Has
it
gotten
deployment
now?
E
B
B
Okay,
so
we
had
a
very
fruitful,
or
at
least
the
rc
editor
had
a
very
fruitful
four
months
of
processing
our
documents
and
a
whole
bunch
of
the
the
editor
key
has
gotten
a
lot
smaller
and,
as
you
can
see,
we
got
four
things
out
of
the
isg
in
this
this
cycle.
You
can
see
them
and
then
there's
some
other
stuff
that's
sitting
around,
but
cluster
238
is
winding
its
way
towards
conclusion,
so
I
think
a
lot
of
that
old,
rm
cat
stuff
is
gonna.
C
Yep,
that's
good,
and
in
general
I
mean
to
for
general
information
the
the
fact
that
cluster
238
is
why
running
down
which
actually
reduce
the
times
that
it
takes
for
the
rcd
to
process
document,
that's
going
to
the
cube
because
they
they're
actually
draining
their
cube,
which
was
grown
by,
for
example,
casters
238,
but
also
the
transition
to
the
person.
3D
format
so-
and
I
have
to
thank
you
one
alone.
C
This
is
that
actually
the
path
packet
stationary
profit,
you
discover
rfc,
it's
actually
one
it's
using
some
of
these
features
for
v3,
and
it's
one
of
these
early
spearheads
that
actually
used
the
format
for
some
of
the
new
things
like
svd,
graphics,
and
things
like
that.
So
it
was
interesting
to
see
that
go
through
so
and
actually
you
should
consider
adopting
some
of
the
v3
features
for
getting
better
documents.
C
That's
uses
this
so
so
the
tsb
air
review
team
has
continued
to
review
documents
that
the
triage
thinks
is
suitable
to
be
needing
transport
reviews,
and
we
will
thank
you
all
other
viewers
that
done
something
you
will
see
those
that
has
reviewed
one
or
more
documents
here,
as
as
noted,
how
many
did
it
done?
It's
still
not
a
high
load
to
be
in
this
review
team,
so
anything
that
martin.
B
Yeah
or
just
as
always,
I
think
that
these
statistics
show
that
this
is
not
a
particularly
honoris
thing
to
volunteer
for,
and
I
think
it
really
expands
your
horizons
at
itf.
But
I
really
encourage
people
to
to
to
consider
joining
the
art.
C
C
C
So
but
yes,
it's
davis,
genesee
said
soccer
and
ken
kao,
which
is
the
candidates,
so
please
provide
the
input.
Yes,
it's
you
have
the
hall
of
friday
and
I
think
the
if
you
were
in
the
plenary
barbara's
said
they
were
going
to
be
open
probably
weekend
out
before
they
closed
it.
So
but.
B
B
C
C
C
Yeah
and
help
denom
com
make
a
good
choice
so,
but
we're
grateful
see
that
we
have
three
candidates
and
that's
very
good
so,
and
I
think
that
was
the
last
slide
from
us
and
therefore
we
will
switch
if
switch
to
brian
and
then
we'll
come
back
with
open
mic
afterwards.
So
yeah.
B
So
so,
if
I
could
introduce
this,
so
I
I
am
a
recent
arrival
at
the
taps.
Working
group-
and
I
am
now
super
duper
interested
as
a
as
an
individual
contributor.
I
think
it's
very
interesting
work
that
has
a
lot
of
applications
at
my
job
and
and
just
as
a
transport
guy.
It
is
also
kind
of
inaccessible.
Their
meetings
are
kind
of
github
operations
for
the
most
part
and
they
generally
don't
meet
at
big
itfs,
they're,
all
interims,
so
yeah.
B
I
I
invited
brian
to
give
this
talk
just
so
people
can
get
in
touch
with
it
and
hopefully
get
some
people
interested
to
go,
read
the
drafts
and
start
participating,
because
I
think
it's
really
interesting
work.
So
brian
go
ahead.
A
Thank
you,
martin.
I
hope
I
can
make
this
more
accessible.
That's
actually
kind
of
a
that's
a
tall
order,
but
we'll
see
we'll
see
if
this
unconfuses
things
a
little
bit
so
hi.
Actually,
we
can
just
sort
of
skip
this
light.
This
is
bangkok
where
we
are
not,
but
martin
did
a
good
introduction,
so
I'll
just
go
straight
into
the
the
content.
So
it's
really
kind
of
hard
to
understand
how
we
got
to
be
the
working
group.
A
We
are
without
understanding
sort
of
the
initial
case
for
taps
and
there
are
sort
of
three
observations
here.
One
of
them
is
that
there's
a
hard
binding
between
transport,
behaviors
and
concrete
protocols
right
like
so
the
sockets
api
basically
works
pretty
well
for
stock
stream
and
sock
d
gram.
Sock
seek
packet
was
sort
of
back
ported
onto
it,
but
in
order
to
actually
use
scpp,
for
example,
you
need
to
use
the
sctp
api.
A
So
you
know
if
all
you
have
is
sockets
all
you're
ever
going
to
be
able
to
deploy,
is,
is
udp
and
tcp.
Just
because
you
know
you
have
no
api
to
actually
select.
It
there's
also
the
problem
that
deployment
of
newer
protocols-
and
you
know
we're
harping
a
lot
on
sctp
here,
because
that
was
sort
of
the
the
the
big
sort
of
deployment
pain
that
we
remembered
when
we
we
started
this
work
in
taps.
A
You
might
have
network
conditions
right,
you
might
be
behind
an
app
that
doesn't
know
what
sctp
is
or
or
how
to
to
deal
with
it.
So
you
might
want
to
be
able
to
have
the
the
endpoint
do
some
network
sensing
and
and
figure
out,
okay.
Well,
I
seem
to
be
working
or
not,
or
will
this
transport
work
here
or
not?
So
a
lot
of
this
work
was
put
together
by
the
the
neat
project,
a
fb,
seven
or
eight
twenty
twenty.
A
I
think
it
was
already
a
2020
by
then
an
eu
funded
research
project
and
it
really
focused
on
this
dynamic
transport
selection
problem
right
like
so.
How
can
we
use
information
about
what
the
os
supports
and
what
the
you
know
what
the
network
can
support
and
use
that
to
dynamically
select
the
protocol,
so
that
was
really
the
focus
of
the
neat
project
and
as
we
started
working
on
this,
we
realized
that
dynamic
selection
is
only
half
the
battle
right
like
so.
A
If
I
have
an
application
that
is
expecting,
you
know
sequential
streams
in
a
single,
sequential
stream
for
a
connection
object,
and
then
my
os
tells
me
oh,
but
you
can
use
sctp
cool,
I'm
just
going
to
use
sctp
to
give
me
tcp
like
service.
A
So
unless
we
have
an
abstraction
that
sits
on
top
of
sort
of
the
union
of
all
supported
transport
behavior
and
allows
us
to
select,
you
know
what
we
need
and
to
emulate
what
we
can't
get
from
the
operating
system
in
the
network.
Then
we're
going
to
be
constrained
to
the
least
common
denominator.
So
there's
work
in
a
research
project
that
I
was
involved
in
post,
sockets
and
also
work
and
network
that
framework
from
apple.
That
sort
of
you
know
tries
to
break
this
up.
A
So
the
story
so
far
next
slide.
A
So
in
2014
we
were
chartered
specifically
for
the
dynamic
transport
selection
problem
and
only
the
dynamic
transport
selection
problem
and
we
went
off
and
did
the
homework
of
looking
at
the
various
transport
layer,
behaviors
that
were
available
from
ietf
protocols
in
order
to
understand
the
basis
of
dynamic
selection
like
so.
What
are
all
of
the
various
different
things
you
might
want
to
choose
based
on
or
that
you
might
want
to
give
an
application,
and
this
is
when
it
became
clear
that
we
needed
an
abstract
api,
as
we
were
getting
into
this.
A
It's
like
okay,
great,
but
these
behaviors
are
different
enough,
that
just
putting
them
into
the
sockets
model
and
and
hiding
all
of
the
goodness
behind
sock
ops
is
not
going
to
lead
to
application
adoption
of
of
this.
A
So
a
couple
of
years
later,
we
started
working
on
the
groundwork
for
the
abstract
api.
So
this
is
the
the
min
set
work
and
and
looking
at
sort
of
how
various
transports
and
how
udp
can
be
split
up
into
the
categories
that
8095
looked
into
and
then
once
we
had
that
groundwork.
I
mean
you'll
notice
that,
like
there's
an
8303
and
8304
in
an
23,
it
took
us
a
while
to
finally
get
mindset
published,
but
but
that
is
is
out
since
the
last
meeting.
A
A
There's
the
architecture
document
which
sets
out
the
assumptions
that
we
make
about
the
problem
we're
trying
to
solve
right
like
so
it
says.
There's
this,
you
know
we
assume
that
there's
this
thing
called
a
a
transport
services
implementation.
A
This
transport
services
implementation,
provides
an
api
up
to
the
application
and
has
some
machinery
for
doing
the
dynamic
selection
and
for
dynamic
up
so
candidate
racing,
so,
like
think
about
happy
eyeballs,
but
happy
eyeballs
across
all
of
the
different
dimensions
that
you
might
care
about.
With
respect
to
that,
you
might
care
about
with
respect
to
the.
A
Like
which
protocols
are
going
to
use
you,
and
then
we
have
the
interface
on
top
of
that,
so
there's
the
architecture.
This
is
what
the
transport
services
is.
The
interface
is,
what
is
the
interface
that
the
application
uses
to
use
the
transport
layer
when
using
a
transport
services
system?
The
interface
document
is
where
we
actually
describe
the
details
of
this
abstract
api,
and
this
has
several
sort
of
concepts.
A
There's
a
concept
of
a
connection,
there's
a
concept
of
a
pre-connection
which
is
all
of
the
information
that
you
need
in
order
to
create
a
connection.
It
supports
the
concept
of
of
rendezvous.
So,
like
the
ability
not
just
to
say,
you
know,
I'm
gonna
listen
initiate
but
have
two
endpoints
find
each
other,
so
this
would
be
sort
of
in
a
an
ice
lake
environment,
and
then
it
supports
sort
of
message-oriented
and
stream-oriented
interactions.
A
It
supports
message
framing
we'll
get
into
the
details
of
that
in
a
minute,
and
then
the
implementation
document
is
where
we
get
into
the
nitty
gritty
details
of
here
are
things
that
we
here
are
things
that,
as
we
have
gained
implementation
experience
with
building
systems
and
taps
that
you
as
an
implementer
of
tap,
should
probably
look
out
for
right,
like
so
it's
kind
of
an
implementation
notes
and
guidelines
document.
A
So
to
the
are
there
implementations
question
we'll
answer
this
later,
but
like
around
the
same
time
that
we
started
the
work
on
the
architecture,
interface
and
implementation
documents
networked
up
frameworks,
so
apple's
formerly
internal,
now
published
api.
That
is
extremely
taps
like
was
announced
at
wwdc.
A
So
on
the
next
slide,
the
next
two
slides
we're
gonna
like
look
at
the
at
the
sort
of
the
different
architecture,
the
basic
you
know,
difference
between
sockets
and
taps.
So
next
slide.
This
is
a
picture
of
how
interactions
work
between
the
application,
the
network
in
the
sockets
api
right.
We
have
a
stream
api
and
a
datagram
api.
A
They
use
mainly
the
same
calls
like
you
have,
like
you
know,
write
versus,
send
and
send
message,
but
for
the
most
part,
using
mainly
the
same
calls,
but
they
behave
differently
based
on
what
the
what
the
struck
sock.
It's
been
oil
since
I've
used
sockets
this.
A
The
structure
underneath
like
basically
is
a
union
structure
that
gives
you
markedly
different
behavior,
based
on
which
you,
which
you
select
the
stream
api
generally
binds
to
tcp
protocol
stack
the
datagram
api
minestro
udp
protocol
stack,
I
could
have
put
like
the
the
seekpack
at
api
and
have
it
applied
to
an
sctp
protocol
stack
but
like
there's
a
different
api
and
a
different
application
interaction
model
for
each
of
these
things
there's
also
another
part
of
the
sockets
interface,
which
is
extremely
important
for
establishing
conventions
in
rendezvous,
and
that's
the
stub
resolver
and
the
stuff.
A
If
I
have
a
name-
and
I
want
to
turn
it
into
an
address
that
I
can
actually
use
to
bind
or
connect
to
something,
I
need
to
do
the
resolution
myself
and
this
has
sort
of
the
upside
if
the
application
has
complete
control
over
when
resolution
happens,
which
is
you
know,
good
in
certain
cases
when
you
might
not
want
to
leak
information,
if
you
don't
know
that
you're
on
a
network
q,
a
minimization,
but
it
also
means
that
the
operating
system
or
the
platform
that
is
providing
the
transport
services
doesn't
have
enough
information
to
be
able
to
do
sort
of
like
good
racing
right
like
so,
you
can't
say:
okay,
I'm
going
to
defer
the
lookup
of
the
thing
that
I
don't
need
or,
more
importantly,
if
the
transports,
the
transport
service
implementations,
thinks
it
might
need
information
in
the
future,
it
can
actually
go
ahead
and
start
queuing
up
these
resolutions
in
order
to
to
parallelize
things.
A
Let's
go
to
the
next
slide,
which
is
somewhat
more
complicated,
and
I
think
this
is
the
diagram
that
that
might
have
scared
martin
off
when
he
first
started
when
he
first
landed
in
taps.
This
is
the
transport
service
architecture
up
at
the
top.
We
still
have
the
application,
and
it's
essentially
talking
to
the
transport
services
interface.
This
is
the
thing
that's
defined
in
the
api
document.
A
There
are
sort
of
four
different
phases
of
this
life
cycle
which
we'll
get
to
later
in
the
talk.
There's
this
pre-establishment
phase,
where
the
application
gives
information
about
its
requirements
and
expectations
to
the
transport
service
interface,
and
this
is
where
the
transport
service
interface
gets
the
information
it
needs
in
order
to
be
able
to
select
a
path
and
a
protocol
stack
then
from
a
pre-connection,
you
can
go
off
and
create
a
connection.
The
connection
is
the
object
over
which
all
of
the
data
transfer
happens.
A
The
the
data
transfer
is
event
driven.
So
basically,
you
can
say
to
the
connection
hi
I'm
willing
to
receive
this
many
messages
with
this
many
bytes
and
it
will
send
those
back
up
to
you
asynchronously,
so
you're,
not
necessarily
polling.
The
transfer
service
interface
interface
itself
also
throws
off
these
asynchronous
events.
As
things
about
the
available
stacks,
for
example,
your
connectivity
may
have
changed
now,
you're
on
an
ipv6
network.
Now
you
have
ipv6
stacks
as
these
things
change.
Those
events
can
come
back
up
to
the
application
as
well.
A
Inside
the
transport
system
implementation.
There
are
a
few
sort
of
like
long-lived
things,
there's
policy
which
allows
the
tweaking
of
the
selection
of
of
protocol
stacks.
Like
you
know,
saying
hey
I
prefer
ipv6,
so
I'm
going
to
actually
do
happy
eyeballs
and
I'm
going
to
give
it
a
20
millisecond
head
start,
for
example,
or
you
know,
on
this
network,
udp
is
disallowed
unless
it
goes
through
this
process.
These
sorts
of
things
are
in
the
policy.
A
These
are
mainly
implementation
specific,
but
we
we
allow,
for
it,
there's
also
a
state
cache,
so
the
transport
system
can
learn
which
bits
of
the
you
know,
which
networks
or
which
connections
or
which
paths
might
support
or
not
support
certain
things
and
can
use
that
to
adjust
the
racing
and
then
underneath
that
all
of
that
there
are
sort
of
the
concrete
implementations
of
the
protocol
stacks
you'll
notice.
In
this
diagram
we
did
not
draw
sort
of
like
the
kernel
user
space
boundary
and
the
previous
diagram.
A
The
kernel
user
space
boundary
is
usually
sort
of
like
right
there
between
the
application.
Application
has
a
little
bit
of
a
library,
but
it
basically
all
turns
it
to
syscalls.
The
taps.
Interface
could
be
implemented.
You
know
that
that
kernel
user
space
boundary
could
be
sort
of
above
the
transport
service
interface.
It
could
be
between
the
transport
service
interface
and
the
implementation.
So
you
have
the
interface
which
does
some
of
this.
The
state
management
runs
in
user
space,
but
is
actually
using
racing
in
the
kernel
or
it
could
all
be
in
user
space.
A
On
top
of
I
mean
you
could
implement
this
on
top
of
on
top
of
any
fiscal
interface,
there
are
sort
of
multiple
different
ways
to
do
that
and
we're
explicitly
agnostic
about
it.
Next
slide.
A
So
just
like
sort
of
the
this
is
the
sales
slide.
These
are
the
features
of
the
abstract
interface.
I
think
I've
I've
gone
through
most
of
these,
so
it's
designed
specifically
to
allow
for
optimization
parallelization
right
this
idea
of
having
a
pre-connection
phase,
followed
by
a
connection
phase.
I
mean
so
once
the
pre-connection's
set
up
the
transfer
services.
Implementation
can
actually
go
and
do
whatever
measurements
it
needs
to.
In
order
to
figure
out.
You
know
what
it's
going
to
do
when
a
connection
finally
happens
explicitly
here
resolution.
A
So
this
you
know,
the
thing
that
happens
is
stubborn,
solver
and
connection
are
not
explicitly
separate.
You
can
pass
an
endpoint
into
this
api
at
whatever
layer
of
abstraction
you
have
a
resolver
for,
and
it
can
go
off
and
resolve
that
for
you
in
the
background,
there
is
also
control
over.
You
can
tell
the
systems
in
the
api
explicitly.
A
Please
defer
any
resolution
until
as
late
as
possible,
just
to
minimize
information
that
might
radiate
out
of
the
resolution
process.
Obviously,
if
you
put
this
on
on
top
of
something
like
dot
or
do
this,
is
it's
less
important
for
the
application
or
the
other
policy
to
be
able
to
control
this,
but
we
wanted
to
have
the
knob
sending
and
receiving
are
both
asynchronous
and
event
driven.
The
connection
interface
is
also.
A
Designed
to
abstract
away
multi-streaming
and
multi-path
protocols
right
like
so,
you
can
have
if
you
end
up
with
a
multi-streaming
protocol
like
quick
or
sctp,
underneath,
like
in
your
transport,
as
your
transport
stack
that
gets
selected,
then
there's
the
idea
of
basically
taking
a
connection
and
cloning
it
it's
kind
of
like
fork
in
unix
and
if
you
clone
a
multi-streamed
protocol,
you
actually
end
up
now
with
two
streams
inside
the
same
protocol,
but
this
also
allows
you
to
do
to
have
applications
that
do
this
cloning
that
says
hey.
A
I
want
a
connection
to
the
same
endpoint
to
the
same
application.
Please
make
that
happen
and
if
you
end
up
selecting
a
protocol,
that's
not
multi-streaming
it'll
just
create
multiple
flows,
one
in
terms
of
the
amount
of
time
we've
spent
on
it
I'd,
say
possibly
the
trickiest
and
most
important,
oh
and
I'll
say
trickiest:
it's
not
the
most
important
feature.
A
We
really
wanted
to
make
sure
that,
like
taps
would
be
usable
in
a
world
where
only
one
endpoint
is
using
taps
because
otherwise,
like
requiring
coordinated
deployment
of
some
system,
is
basically
you're
talking
about
not
building
a
protocol
selection
engine,
but
a
new
protocol.
We
didn't
want
to
do
that.
We
wanted
the
protocol
selection
engine.
A
So
specifically,
if
we
end
up
in
a
situation
where
you
have
one
side
that
is
trying
to
provide
a
message-oriented
service
to
the
application,
the
other
side
is
just
straight
tcp
and
it's
going
to
do
its
own
deframing
inside
the
application.
A
We
provide
for
the
ability
to
push
a
framer,
which
is
basically
the
thing
that
turns
a
stream
of
messages
into
a
stream
of
bytes
and
a
d
framer,
which
is
a
thing
that
turns
a
stream
of
bytes
back
into
a
stream
of
messages
which
can
asynchronously
pop
up
to
the
application.
We
can
push
that
from
the
application
down
into
the
the
transport
service,
so
the
application
basically
gets
this
message-oriented
thing.
Even
if
it's
not
running
on
top
of
a
message.
Boundary
preserving
protocol
stack
next
slide.
A
So
like
the
way
that
to
make
this
a
little
bit
more
concrete,
let's
say
that
you're
on
a
multiply
connected
device
that
has
these
five
possible
candidate
protocol
stacks,
we
can
either
run
udp
over
v4
over
ethernet
or
tcp
or
v6
over
ethernet
or
scp
or
dtls
over
udp
over
v6
over
ethernet
or
quick
overv6
over
cellular
or
tcp
over
v4
over
lte.
A
The
selection
properties
up
at
the
top
are
things
that
the
the
application
could
then
say
that
it
wants
to
prefer
or
require
or
avoid
or
prohibit
and
based
on
the
the
set
of
things,
the
constraints
that
the
application
passes
down.
It'll
eliminate
some
of
these
candidate
protocol
stacks
from
from
a
possible
connection
right,
so
yeah.
A
If
I'm
looking
for
fixed
interfaces
right,
I
don't
want
to
run
on
lte,
because
you
know
I'm
assuming
that
that's
going
to
cost
me
more
well,
then
I'm
going
to
eliminate
all
the
lte
the
stacks
with
lte
at
layer
2..
If
I
need
a
protocol,
that's
explicitly
multi-streaming
because
for
performance
reasons,
I'm
going
to
clone
a
whole
bunch
of
connections-
and
I
know
I
don't
want
to
have
flow
explosion.
Well,
that'll
only
allow
me
to
select
ctp
and
quick
and
so
on.
A
There
is
a
gigantic
list
of
these
in
the
document.
That's
actually
another
one
of
the
things
it's
a
little
can
be
a
little
intimidating
at
the
beginning,
but
these
are
basically
just
you
know
they
all
fit
into
this
framework
of
I
have
some
connection
dimensions
and
I'd
like
to
use
those
to
prune
the
set
of
possible
candidate
protocol
stacks
next
slide.
I
think
there's
one
more
pretty
picture
yeah,
so
to
get
into
a
little
bit
more
detail
on
how
we
create
connections.
A
So
there
are,
these
sort
of
these
three
phases
are
pre-established
established
and
terminated.
I
take
you,
know
information
about
the
local
endpoint,
which
is
not
just
you
know
which
addresses
I
want
to
possibly
use
as
on
my
local
addresses,
but
also
information
about
my
endpoint
identity.
A
If
I'm
using
a
protocol
that
might
require
identity
information,
the
remote
endpoint,
which
is
who
I
want
to
connect
to
the
transport
properties,
which
is
this
sort
of
set
of
things
that
allow
me
to
select
the
candidate
protocol
stack
and
my
security
parameters,
which
are
information
that
just
gets
passed
into
the
the
security
layer
protocols
that
would
be
selected.
A
This
is
the
security
parameters,
are
special
in
taps
because
it
turns
out
there
are
very,
very
very
few
times
that
you
might
want
to
race
based
on
a
security
protocol,
because
you
don't
want
to
end
up
in
a
situation
where
you
actually
downgrade
attack
yourself
right,
like
so.
A
lot
of
transport
protocols
provide
equivalent
services
or
services
that
can
be
emulated
by
the
system
over
equivalent
stacks.
This
is
not
the
case
with
security
protocols.
A
Right,
like
tls
1.3,
has
has
different
properties
than
tls
1.1,
for
example,
so
the
security
parameters
are
kind
of
special
in.
We
have
a
whole
document
about
this.
It
was
one
of
the
ones
that
was
just
published.
If
I
recall
correctly,
so
you
can
either
take
a
pre-connection
and
initiate
it,
in
which
case
it's
like
an
active
open
or
you
can
listen
it,
in
which
case
it's
a
passive
open
and
the
the
transport
properties
then
turn
into
the
set
of
bound
well
bound,
listening,
sockets
down
underneath
the
system.
A
When
you
initiate
you
get
a
callback
when
the
the
connection
is
ready,
it's
connection
ready
event
and
when
you're
listening,
you
get
a
call
back
or
an
event
when
the
connection
is
received,
and
then
you
get
a
connection
that
you
can
transfer
data
on
and
then
there's
basically
two
ways
to
to
end
up
terminated,
there's
either
close,
which
is
an
orderly
shutdown
of
the
connection
or
there's
an
abort
which
is
throw
my
hands
up
and
stop
right
like
so.
These
are
like
pin
versus
reset
in
in
tcp
land.
A
Next
slide,
so
why
like?
If
you
look
at
the
document,
you'll
see
you
know
a
lot
of
stuff
that
looks
kind
of
like
pseudocode
or
the
interface
document.
You'll
see
a
lot
of
stuff
that
looks
kind
of
like
pseudocode.
You
know
why
is
this
an
abstract
interface?
A
Why
isn't
this
something
more
like
the
sap
api,
which
is
actually
defined
in
terms
of
posix
and
there's
a
couple
of
reasons
for
this,
but
but
mainly
it's
because
swift
versus
haskell
versus
russ,
rust
versus
whatnot
is
not
much
fun
to
discuss
in
my
client,
I
did
see
lucas
ask
a
question
about
crust,
which
we
can
talk
about
when
I'm
done
here,
but
we're
not
in
the
business
in
the
ietf
of
trying
to
change
programming,
language
idioms,
and
if
we
want
to
see
something
like
this
adopted,
we
want
to
have
the
general
shape
of
the
api
be
the
same,
but
we
want
to
fit
it
into
the
programming
language
idioms
like
we
had
a
a
student
at
eth
back
when
I
was
at
eph
who
implemented
a
tap
system
for
multi
architecture,
switching
between
the
internet
and
scion.
A
So
this
future
internet
architecture,
based
on
taps
and
the
implementation
that
they
come
came
up
with,
was
explicitly
didn't,
have
a
lot
of
the
names
as
we
have
in
the
taps,
api
and
I'm
like.
Well,
why
is
it
like?
A
Well,
I
wrote
it
in
go
and
I
want
go
programmers
to
be
able
to
use
it,
so
everything
has
to
be
called
dial
right
like
so
we
don't
want
to
be
in
the
business
of
changing
the
the
idioms,
but
we
do
want
to
incentivize
application
development
to
be
less
synchronous,
less
imperative
about
how
it
uses
the
transport
layer
in
order
to
free
up
our
ability
to
deploy
new
transport
protocols,
and
if
we
have
something
that
is
shaped
like
this,
but
with
slightly
different
names
one.
A
It
means
that
we
have
this
evolution
ability
on
more
platforms
too.
It
also
means
that,
as
as
developers
use
apis,
that
are
very
much
shaped
like
this.
It
becomes
easier
to
sort
of
port
applications
between
them
or
to
build
frameworks
on
top
of
different
platforms.
That
sort
of
can
then
run
on
top
of
tabs.
A
The
mike
you're
now
required
to
write
taps
implementation
in
fourth.
I'm
sorry,
I
don't
make
the
rules
cool
next
slide.
A
Sorry
just
looked
at
jabber,
so
why
do
we?
You
know
you
know?
Why
do
we
need
this
right
like
so?
Why
do
we
actually
need
to
have
transport
layer
agility?
Right,
like
I
thought
this
was
the
quick
area.
So
if
you
look
at
all
of
the
all
of
the
transport
protocol
features
that
we
have
in
taps,
the
one
that
has
or
the
two
that
have
not
yet
been
pulled
into
quick,
but
there's
a
lot
of
discussion
about
talking
about
them
is
multipath.
A
Sorry,
john,
I
said
multipath,
quick
and
partial
reliability,
even
though
there
are
certainly
very
easy
hacks
for
doing
partial
reliability
in
in
quick.
So
why
do
we
need
transport
protocol
agility?
If
everything's
going
to
be
quick,
I'd
say
there
are?
There
are
a
few
reasons
for
this.
One,
like
I
tend
to
believe
that,
like
sort
of
the
future,
at
least
of
the
wire
image
of
the
transport
layer
is
going
to
be
increasingly
quick.
The
quick
working
group
has
a
slightly
different
philosophy
about
this
than
the
taps.
A
Working
group,
to
put
it
mildly,
quick,
explicitly,
doesn't
have
a
proper
interface
there's
a
focus
on
the
web.
The
implementations
are
tied
to
h3
the
implementation.
The
interface
between
the
application
and
transport
is
kind
of
blurry
kind
of
internal,
like
there
are
requirements
for
what
that
interface
has
to
do.
But
if
you
look
at
the
implementations
of
quick,
these
things
are
bound
pretty
tightly
to
each
other
and
that's
actually
done
for
sort
of
like
performance
reasons.
A
This
is
seen
as
a
feature
we
believe
there's
still
quite
a
lot
of
of
value
of
having
this
abstract
api
and,
of
course,
quick,
could
be
one
of
the
the
candidate
stacks
that
lives
on
underneath
this
you
could
also
have
you
know
you
know
websockets
or
web
transport
over
h3
over
quick
as
one
of
the
candidates
tax
on
this
right
like
so
it
it
subsumes
all
of
these
things
so
next
slide,
which
I
think
is
my
last
slide.
A
So
we're
we're
almost
done
the
you
know
the
drafts
are
there
in
github.com
ietf
taps
api
drafts
architecture
has
been
close
to
completion
for
quite
a
while
we've
basically
been
holding
it,
making
sure
that
we
don't
find
anything
in
the
interface
that
invalidates
some
part
of
the
architecture.
A
Interface
has,
I
think,
two
open
issues
on
it
that
are
ready
for
text.
We
just
need
to
get
people
out
of
you
know
this
working
group
meeting,
so
they
can
go
write
text
implementation
is
following
close
behind
two
implementations
that
people
in
the
working
group
have
quite
a
bit
of
experience
with
our
apple's
network.framework
and
the
there's
one.
A
That's
looking
at
the
taps
on
top
of
python
async
io
as
a
users
based
environment
from
so
max
and
teresa,
and
a
couple
of
other
people
from
fdinet
the
I
I
think
I've
seen
there
was
a
a
few
research
grades,
implementations
one
and
go
I've,
seen
some
work
and
rust.
Someone
actually
trying
to
put
this
on
top
of
russ
async.
I
think
colin
had
a
student
that
was
doing
that,
but
these
are
the
two
big
ones
that
we
know
about.
So
you
know
please
come
have
a
look.
A
The
architecture
and
interface
will
be
going
through
last
call
and
moving
up
soon.
So
this
is
kind
of
a
speak
now
or
you
know,
enjoy
the
results,
but
please
do
come
by,
and
I
hope
that
this
makes
taps
less
scary.
For
those
of
you
who
have
not
been
paying
attention
to
it,
so
that
I
think
we
have
a
little
bit
of
time
for
questions.
B
Oh
yes,
certainly
brian
thanks
for
being
funny
yeah,
so
the
the
taps
crew
has
been
pretty
good
about
running
a
q,
a
and
jabber.
But
yes,
we've
plenty
of
time
for
comments.
So
pete,
okay,
cool.
D
And
look
at
those
so
hopefully
an
easy
question.
The
last
time
I
coded
on
a
mac
was
way
before
network
framework.
Do
we
know
what
the
uptake
for
either
network
done
framework
or
python
the
python
implementation?
Are
people
actually
using
it?
Calling
tommy
pauly
to
the
microphone.
F
Hello
yeah.
So,
as
brian
mentioned,
we
released
it
initially
in
2018,
so
we've
essentially
had
two
years
of
people
adopting
you
know
for
the
first
year.
You
know
people
generally
don't
kind
of
jump
on
board
initially,
but
I
would
say
like
in
the
past
year,
just
based
on
the
number
of
like
developer
forums
bugs
and
stuff
and
app
developers
we're
working
with
we're,
seeing
a
pretty
good
uptake
on
it.
F
Largely
a
lot
of
developers
had
been
using
some
third-party
libraries
there's
like
things
called
cocoa,
async
io
that
we're
really
just
trying
to
offer
better
like
asynchronous
semantics,
but
with
a
socket
abstraction
and
not
necessarily
giving
you
all
of
these
kind
of
transport
properties,
and
I
think
we
are
definitely
seeing
a
shift
away
from
that,
and
you
know
caveat
on
that
that
you
know
most
apps
are
still
using
like
web
loading
type
apis
for
a
lot
of
people,
but
what
you
are
doing
kind
of
low
level
networking
a
lot
of
our
like.
F
You
know:
vpn
apps,
streaming
apps.
They
are
using
this,
and
actually
there
are
places
certain
platforms
like
a
watch
app
as
well
as
we
have
like
new,
like
app
clip
apps
that
are
only
allowed
to
use
this
api
that
they
can't
actually
access
the
sockets
anymore.
So
we're
kind
of
and.
F
Yeah,
absolutely
this
is
the
layer
that
is
below
all
of
the
http
apis
and
webkit
stuff
that
we
expose,
including
what
all
of
our
connections,
so
the
vast
majority
of
connections
on
ios
and
mac
os
devices
are
using
this
as
their
way
to
decide
how
to
bring
up
the
transport.
F
One
kind
of
detail-
I'll
note
is
the
the
api
for
the
connection.
Is,
you
know,
really
closely
aligned
with
what
we
had
in
2018
in
taps?
There
are
definitely
you
know
additional
properties
and
tweaks
that
have
gone
on
in
the
document.
Since
then,
I
expect
that
you
can
once
we
have
like
rfc
version.
F
There
will
be
some
work
to
spruce
up
some
of
the
apis
to
align
them
more
and
make
sure
that
there's
a
group
gonna
be
like
a
more
accessible
cross-platform
common
approach.
We
can
do
cool
cool.
G
Yeah
I
just
wanted
to
thank
martin
for
putting
this
on.
I
have
not
been
able
to
follow
taps
as
closely
as
I
would
like,
since
stepping
down
some
a.d
and
I'm
really
glad
to
see
the
progress
has
continued.
G
I
know
that
when
we
were
talking
about
a
couple
topics
in
the
quick
working
group,
I
invoked
the
word
taps
and,
and
everybody
kind
of
with
taps,
so
I
think
I
think
that
you
did
exactly
the
right
thing
at
exactly
the
right
time.
Thank
you.
B
Thanks
spencer,
so
I'm
in
the
queue
just
to
say,
like
one
thing
that
I
am
excited
about
with
this
in
particular,
is
I
think
it's
just
coming
at
a
super
opportune
time
with
quick.
We
are
already
essentially
going
to
ask
application
developers
to
to
crack
open
their
code
and,
like
rework
their
api.
You
know:
rework
the
api
that
they're
exercising
and
move
from
sockets
to
something
with
quick
and
what,
if
they're,
already
doing
that?
B
What
a
great
time
to
say,
here's
something
you
can
use
that
is
going
to
be,
in
theory,
portable
lots
of
platforms.
So
I
think
it's
sort
of
like
two.
It's
kind
of
a
chance
to
get
two
wins
here,
so
bring
in
quick
and
bring
in
abstraction
simultaneously.
A
So
so
that's
actually
one
of
the
you
know
one
of
the
things
that
is
driving
us
to
get
this
done.
We
had
a
we
were
like
we
thought
we
were
about
80
done
about
about
two
years
ago,
and
then
we
had
a
bit
of
a
lull
in
the
working
group,
because
almost
everyone
who
was
working
on
this
either
ran
out
of
funding
or
changed
jobs
or
both
so
like
there
was
like
a
a
nine
months
kind
of
you
can
actually
see
it
in
the
github.
A
There's
this
right
and
then
you
know
that's
one
of
the
things
that
energized
us
to
to
sort
of
you
know
get
this
thing
done.
I
will
say
that
one
of
the
the
questions
that
we
ask
ourselves
often
sort
of
like
a
litmus
test
for
a
change
this
api
is.
We
want
to
make
sure
one
that
it
would
be
a
good
api
to
put
on
top
of
quick
now
pointedly
8095.
A
The
original
study
that
we
did
did
not
consider
quick,
because
at
the
time
the
charter
guidance
was
we're
only
going
to
consider
published
ietf
protocols
and
quick
hit
just
chartered
right.
A
So
there's
a
little
bit
of
a
race
condition
there,
but
one
of
the
litmus
tests
we
use
when
we're
when
we're
evaluating
the
api,
as
we
make
a
change
to
it
is,
does
it
make
sense
as
an
api
between
h3
and
quick
and
does
it
make
sense
as
an
api
for
some
sort
of
stream
like
mask
on
top
of
h3
on
top
of
quick
right
like
and
it
has
to
be
able
to
work
as
both
right
like
you
have
to
either
you
know,
have
the
interface
be
you
you,
you
want
to
be
able
to
implement
a
taps
on
top
of
the
taps
right
like
so
that
might
not
be
in
terms
of
like
code
size,
the
best
thing
to
do,
but
as
an
abstraction,
if
the
if
the
abstract
api
doesn't
support
that,
then
that's
a
pretty
good
test
that
we
need
to
think
harder
about
the
abstract
api.
B
H
Ryan,
I
I
basically
want
to
ask
two
questions.
One
of
them
is:
do
we
have
evidence
of
other
folks
between
apple
and
then
I'm
saying,
besides
apple,
because
I
know
that
tommy
and
the
apple
folks
have
been
involved
in
the
progression
of
the
taps,
working
group
and
the
document
itself.
H
H
But
have
you
had
success
with
others
adopting
the
api
besides
apple
and
the
second
part
of
this
is
it's
it
with
relation
to
quick
at
least
one
of
the
things
that
I've
found
is
that
people
have
people
are
building.
These
libraries
have
a
particular
api
philosophy
and
a
particular
api
model,
and
with
h2o
I
can
say
that,
for
example,
h2
has
a
particular
model
and
quickly
sort
of
fits
into
that
model.
H
That
each
tool
has
it's
it's
it's
it's
it's
separable
from
the
http
3
implementation,
but
it
definitely
has
the
flavor
of
the
api
that
h2o
itself
has.
So
I
think
that
the
same
sort
of
thing
applies
to
a
lot
of
other
libraries
which
I
see
actually
as
a
feature
right
and
that's
a
concrete
api,
not
an
abstract
one.
But
so
do
you
see
the
value
in
in
keeping
the
abstract
api
simply
functional,
rather
than
trying
to
have
make
it
aspirational
for
quick
implementations
to
try
and
and
build
themselves
to
that
api.
F
A
Am
I
am
aware
of,
like
I'm
aware
of
groups
that
are
working
on
future
apis
that
are
watching
taps
with
great
interest?
I
can't
talk
very
much
about
them.
I
am
also
aware
of
groups
that
are
maintaining
existing
apis,
who
have
looked
at
taps
and
said.
This
is
not
for
me
mainly
because
if
you
have
an
enormous
installed
base
of
people
who
are
all
writing
to
that
api
and
that
api
shape
is
fundamentally
different
than
taps,
then
there
is
no
reason
to
migrate
them.
A
Like
the
you
know,
the
impedance
matching
between
the
current
concrete
apis
for
something
like
quick
and
the
abstract
api
in
tabs,
and
I
would
say
that
the
first,
the
first
aim
of
this
work
is
making
sure
that
you
have
that
we
move
toward
the
rough
shape
of
taps
and
the
rough
shape
of
taps
is
more
asynchronous,
which
I
think
a
lot
of
these
h2
apis
are
because
you
have
the
multi-streaming
and
less
imperative
which
a
lot
of
the
h2
apis
have,
because
it's
like
go
connect
to
this
web
page
and
go
do
the
right
like
so.
A
If
we
can
get
to
the
point
where
the
application
is
less
involved
in
the
details
of
the
life
cycle
of
the
connection,
that's
a
win,
no
matter
what
that's
sort
of
like
you
know,
that's
taps
level.
Zero
of
you
know
at
least
moving
the
shape
so
that
you
can
start
to
build
applications
that
have
that
interaction
model
with
respect
to
sort
of
like
h2
and
h3
over
taps.
A
We
have
a
lot
of
discussion
about
the
priority
model
in
taps
and
sort
of
like
how
priorities
later
in
taps,
and
we
tried
a
little
bit
to
to
to
keep
that
up
with
the
developments
in
h3,
but
then
we
kind
of
gave
up
right,
like
so
the
deeper
you
get
into
the
concrete
choices
we
made
in
taps
the
farther
you're
going
to
diverge
from
from
like
sort
of
fall
parody.
I
see
martin.
B
Great
so
one
I
just
comment
on
this
space,
so
the
the
wasm
community.
This
is
web
assembly
platform,
independent
platform,
a
platform,
independent
programming
language.
You
could
say:
that's
not
a
good
term,
but
anyway,.
F
B
Wizard
community,
as
we
speak,
is
flailing
around
for
a
networking
interface
that
is
platform
independent
for
them
to
use,
and
I
have
I
dabble
there.
I
would
not
say
I
understand
it
very
well,
but
I've
kind
of
said,
hey
taps,
but
I've
done
a
very
poor
job
because
I'm
still
attached
to
newbie.
If,
if
there
are
any
taps
evangelists
out
there,
you
might
be
able
to
kind
of
shove
something
fairly
important
in
that
direction.
B
B
I
David
hi
again
david
schnazzy,
so
I
maintain
chronet,
which
is
a
the
chrome,
oaking
library
packaged
as
a
library.
So
I'd
say
it's
one
of
the
most
widely
deployed
networking
libraries
out
there,
so
it's
responsible
for
let's
say
the
youtube:
app
google
search,
app
and
stuff
like
this.
So
a
good
chunk
of
the
internet
traffic
at
large
and
we
haven't
really
been
like
looking
at
taps
per
se.
I
mean
just
in
part
because
this
was
like
library
was
created
like
before
taps.
I
But
let's
say
that
hypothetically
we've
had
an
effort
to
rebuild
set
api.
My
main
question
ryan
is
like
taps
is
nice
that
it
kind
of
unified
the
terminology
and
so
having
you
know,
worked
on
network
framework
at
apple
and
now
on
chronet
at
google.
It's
been
interesting
to
see
how
like
there
are
many
different
ways
of
doing
the
same
thing
and
so
having
kind
of
a
bit
more
consistent
naming
is
useful,
but
I'm
still
trying
to
figure
out
why?
I
Why
should
I
get
more
involved
in
taps
like
what
does
it
get
me
because,
like
you
said
you
know,
the
atf
doesn't
want
to
be
prescriptive
about
programming
languages,
but-
and
I
totally
agree
with
that,
but
when
you
look
at
kind
of
into
the
details
of
any
networking
api,
you
really
get
caught
into
the
details
of
your
programming
language.
I
Your
threading
model
is
a
huge
one
that
I've
seen
be
problems
like
if
you
try
to
something
I've
tried
to
do
several
times
is
like
interfacing,
two
different
networking
stacks
together
and
if
they
have
different
models,
it's
just
a
nightmare,
and
so
like
none
of
these
are
answered
here.
So
what
is
the
point
of
having
a
unified
concept?
I
If,
and
I
see
tommy
coming
behind
me
in
the
queue?
What
is
the
point
of
having
a
unified
concept
if
you're
never
going
to
be
able
to
align
all
these
things.
A
So,
okay,
so
tommy
and
I
are
going
to
tag
team.
You
now
so
I'll
point
back
to
my
answer.
So,
first
of
all
I'll
point
back
to
my
answer
to
janna
it's
more
important
for
me
personally
that
these
things
have
congruent
shapes
as
it
put
like
versus
congruent
shapes
right
like
so.
It's
asynchronous
we're
not
doing
this
thing
where
we,
where
we
like,
send
udp
packets
directly
to
a
dns
server,
because
we
need
to
know
the
naming
it
is.
You
know
it.
A
It
is
event
driven
according
to
the
prescriptions
of
the
threading
model
that
you're
working
with.
I
will
say
that,
like
post,
sockets
specifically
tried
to
define
a
threading
model
to
unify
all
threading
models,
which
was
a
great
research
project
that
we
threw
on
the
floor
because
it
was
like
right
like
we
can't
even
get
this
to
work
in
different
versions
of
go.
So
the
the
second
thing
would
be
like,
if
is
a
little
bit
of
terminology,
unification
goes
a
long
way.
A
What
I
would
like
to
to
have
like
the
the
the
advantage
for
for
cronet
here
great
name
by
the
way,
would
be
a
lot
of
sort
of
the
mobile
app
development
space.
Right
now
is
people
writing
to
sort
of
multi-platform
frameworks,
and
those
multi-platform
frameworks
need
to
support
the
lowest
common
denominator,
so
they
can
implement
on
top
of
everything,
if
chronet
has
an
api
shape.
That
looks
a
lot
like
apple's
network
that
framework
api
shape.
A
Then
these,
like
sort
of
like
libraries,
can
become
relatively
thin
layers
and
you
get
maximum
performance
on
both
on
both
platforms
right.
There
are
fewer
arguments
to
make
in
this
in
this
case,
sort
of
on
the
server
side
of
things,
because
there
you
actually
do
want
to
be
able
to
reach
further
down,
and
we
have
facilities
in
in
taps
to
say
you
know
what
I
actually
know
what
the
hell.
I'm
doing.
A
I
want
to
reach
all
the
way
through
the
abstraction
and
tweak
that
parameter
right
there
I
think
you've
identified
the
threading
model
thing
is
the
is
the
scariest
one
and
the
main
reason
not
to
do
this
in
a
platform
and
programming
language
independent
way
like
it
would
be
interesting
if
we
could,
if
we
had
the
energy
to
evangelize
that
out
in
the
programming
language,
standardization
committees,
but
I
don't
think
that
that's
gonna
return
on
investment
in
the
next
decade,
yeah.
I
A
I
I
The
problem
is
those
two
have
very
different
threading
models,
and
so
then
you're
stuck
with
a
fork
that
cannot
possibly
be
efficient
because
it's
bridging
between
them
and
I've
had
the
same
problem
on
the
bottom,
where
tommy
keeps
asking
me
to
implement
chronet
over
network.framework,
and
so
the
idea
would
be
to
have
like
the
chrome,
quick
stack
and
the
network
framework
udp
stack,
but
again,
that's
not
possible
because
of
the
threading
model.
Mismatch.
So
for
me,
that's
really
the
deal
breaker
yeah.
A
B
A
B
G
Open
mike,
if,
if
tommy
is
following
up
on
that,
please
go
ahead.
G
See?
Okay,
I
just
wanted
to
mention
this
to
the
to
the
to
the
transport
community
at
large.
We
had
talked
about
in
whatever
the
last
ietf.
We
were
in
singapore
during
tsv
area
ted
hardy
and
a
couple
people,
I'm
thinking
at
least
a
couple
of
other
people,
and
me
were
talking
about
a
quick
dispatch
function.
I
know
I've
talked
to
the
ads
about
that
fairly
recently,
just
to
see
if
that
seemed
like
a
good
idea.
I
just
wanted
to
let
people
know.
G
G
I
think
that
there's
gonna
be
more
need
for
that
to
make
sure
that
things
aren't
wandering
off
to
end
area
and
stuff,
like
that,
that
you
know
that,
basically,
that
people
can
get
feedback
from
the
community
on
things
they're
proposing
in
a
reasonable
way,
and
if
that
could
happen
without
distracting
the
quick
working
group,
that
would
be
awesome
thanks.
F
All
right,
thank
you.
I
actually
had
been
in
queue
earlier
to
respond
to
janna
and
then
my
wi-fi
died
and
I
had
to
jump
back
on
weed
echo.
Sorry,
I
lost
my
people.
First
john.
I
had
kind
of
asked
about
other
efforts.
One
other
place
that
this
has
at
least
been
discussed
in.
That,
I
think,
is
a
interesting
application
of
taps
is
in
the
c
plus
standard
library
discussions.
F
F
There
was
essentially
just
do
a
socket
with
some
c
plus
wrappers
on
top,
and
there
has
been
a
lot
of
discussion
about
kind
of
using
a
more
taps
like
interface
there
and
that's
a
case
where
kind
of
having
this
generic
interface,
because
it's
going
to
definitely
be
cross-platform
and
plan
to
live
kind
of
longer
than
our
actual
trends
and
transport
protocols
have
lived.
It
makes
it
valuable
to
do
taps
to
david's
point.
F
It's
one
of
the
other
points
I
want
to
bring
up
is
that
we
are
through
taps
trying
to
avoid.
You
know
ossification
of
the
stack
through
what
the
apps
are
doing
either,
because
they
can't
adopt
a
new
protocol
or
because
they're
not
able
to
have
the
system.
Do
you
know
cool
new
features
underneath
their
apis?
F
I
mean
you
know
this,
such
as
like
proxying
over
mask
and
actually
you
know,
you're
a
mask
enthusiast
and
we're
about
to
have
the
mass
meeting
and
it's
actually
a
really
interesting
case,
because
that's
a
case
in
which
someone
is
writing
what
they
think.
F
If
you
just
want
to
say,
hey,
let's
put
everything
over
mask,
so
I
think
that's
one
of
the
angles
where
it's
not
just
about
like
how
do
we
enable
sctp?
There
are
going
to
be
other
things
in
which
we're
changing
the
first
hop
transports,
because
we're
doing
things
like.
B
B
Okay,
I
believe
that
concludes
this
meeting.
The
queue
is
empty,
so
thank
you
all
for
joining
brian.
That
was
wonderful.
I
like
the
discussion
and
I
think
we
may
have
generated
enthusiasm,
which
was
the
point
yeah
you
know
pushed
me
to
do
it,
so
it
was
delightful,
so
we
will
see
you
all
and
if
you
have
anything
else
magnus
before
I
I.
C
Would
like
to
give
a
short
response
to,
I
think
it's
spencer,
about
quick
dispatch.
I
think
that's
something
we
gonna
continue
to
consider
how
we
do
that
dispatching
function,
etc.
I
mean,
I
think,
part
of
why
we
haven't
done
so
much
or
actually
got
it
in
place
was
that
we
haven't
seen
super
much
activity
etc.
C
But
it's
as
you
say
it
might
be
more
relevant
when
we
take
the
next
steps
and
quit
goes
into
maintenance,
a
bit
more
maintenance
mode
and
and
considering
extensions,
etc
and
and
then
we
will
have
this
aspect
and
then
we
also
see
maybe
some
more
pickup
of
saying
people
doing
mapping
specifications
that
reducing
quick.