►
From YouTube: IETF113-TAPS-20220323-1200
Description
TAPS meeting session at IETF113
2022/03/23 1200
https://datatracker.ietf.org/meeting/113/proceedings/
B
Yeah
we
can,
we
can
see
your
slides
and
we
can
see
you
that's
great
and
we're
also
on
the
top
of
the
hour.
So
maybe,
let's
get
started
already.
Hi
everybody
welcome
to
the
transport
services
working
group,
it's
good
to
see
everybody
on
site
or
online.
B
B
Also,
I
don't
see
anybody
sitting
towards
the
back
of
the
room,
but
I
hear
the
acoustics
are
kind
of
better
at
the
front.
If
that's
an
issue
reminder
that
this
meeting
is
being
recorded
and
by
the
way
my
name
is
rhys
engert
I
go
by
theresa
in
the
data
tracker
and
various
systems.
B
My
co-chair
aaron
fogg
is
joining
us
remotely
and
without
further
ado
I
will
pass
it
to
him
for
these
chairs
update.
A
Hello,
everybody.
Can
you
hear
me.
B
C
B
A
I'll
I'll
try
to
speak
more
forcefully
thanks,
okay,
so
hi.
A
I
recognize
some
of
you
in
the
very
tiny
window,
the
president
in
vienna,
glad
you
guys
were
able
to
make
it
no
well.
Anything
that
you
say
here
is
considered
an
itf
contribution.
You've
probably
seen
this
multiple
times,
itf
meeting
tips-
hopefully
you've
seen
this
as
well,
especially
those
folks
who
are
on
site.
Please
use
the
meat,
echo
light
client
to
get
access
to
the
mic
queue
and
turn
off
your
audio
and
video.
A
If
you
are
not
on
site-
and
I
see
I
should
be
using
a
headset
well,
I
couldn't
pair
my
headset
so
I'll
have
to
muddle
through
with
that.
But
it's.
A
And
nothing
too
controversial
here.
I
think
today's
agenda,
so
we
are
almost
halfway
through
the
chairs
update,
so
we're
already
making
progress
on
the
agenda.
Tommy's
going
to
talk
about
the
quick
mapping
document
gorban's
going
to
talk
about
a
new,
quick
implementation,
pan
api,
we
have
some
time
for
open
mic
and
that's
the
plan.
A
So
since
itf
111,
which
was
some
time
ago,
we've
had
six
interim
meetings
we're
trying
to
meet
basically
once
a
month,
two
of
our
three
main
docs,
the
architecture
document
and
the
api
document
have
received
reviews
from
the
art
reviews
and
sector
as
well
as
some
internal
deep
reviews.
A
Working
groups
been
focusing
on
resolving
those
review
comments
which
were
plentiful
and
we're
grateful
for
getting
that
kind
of
external
review
and,
and
we've
been
focusing
naturally
on
getting
the
third
document.
The
implementation
draft
ready
for
working
group
last
call.
A
The
last
item
to
point
out
was
the
these
documents
had
have
many
contributors
and
the
author
list
had
grown
quite
long.
It
violated
the
recommendation
of
five
authors
for
an
rfc.
The
chairs,
and
the
authors
discussed
this
at
length,
some
of
the
contributors,
the
smaller
contributors
elected,
to
remove
their
name
from
the
author
list.
A
A
E
A
A
The
interface
document
in
the
same
state
there's
still
not
all
the
issues
resolved,
but
we're
down
to
only
two
which
is
awesome
and
the
implementation
draft
is,
I
think,
not
quite
there.
A
Yet
there's
still
a
handful
of
open
issues
but
they're
my
assertion,
and
I
I
think
the
current
plan
is
to
take
this
document
to
working
group
last
call
after
the
ietf
we'll
see,
if
there's
any
discussion
in
that
when
I'm
through
with
these
slides
or
and
during
the
the
open
mic
time
at
the
end.
A
A
I
think
we've
found
that
it's
been
useful
for
sort
of
editorial
continuity
and
consistency
with
the
other
documents
and
just
general
quality.
So.
A
It's
fascinating
reading.
I
promise
you
besides,
let's
see,
do
I
have
to
push
something
so
zad
can
talk.
I
think
I
do.
F
Hello,
so,
first
of
two
things:
first
of
all,
thanks
for
resolving
the
author
list
issue
I
mean
we
have.
We
have
really
worked
really
well
together
as
a
as
a
team
to
resolve
that.
So
I
really
appreciate
all
the
authors
and
the
chairs
to
actually
helping
on
that
one.
So,
on
this
this
this
jointly
submit
jointly
together
I
mean
we
can
do
that.
F
Do
we
see
any
any
point
of
those
who
completed
working
last
call
to
go
for
iitf
last
call
write
the
shefford
document
and
eddie
reviews
and
everything
done
separately
and
then
go
for
ige
evolution
together.
Is
there
any
point
of
doing
that?
Just.
A
The
reason
that
we
elected
to
hold
the
first
document
was
that
we
were
on
there's
a
this.
These
documents
have
a
lot
of
abstraction
in
them
and
and
we
wanted
to
get
the
wording
consistent
between
them
and
in
fact,
we've
made
a
bunch
of
sort
of
you
know,
search
and
replace
changes
to
get
the
wording.
A
F
A
You
know
it
takes
you
as
long
to
review
them
as
as
it
takes
reviewing.
I
mean
we've
been
working
on
these
documents
for
like
seven
years,
so,
if
you
know
you
can
spread
out
the
workload
in
whatever
way
makes
sense
to
you.
F
So
it
it
makes
sense
to
me
just
to
if
we
are
completing
the
working
last
call
for
taps
arc
and
interface,
then
let's
put
them
forward
and
then
we
can
also
have
another
part
of
these
issues
when,
in
the
idea
of
law
school,
we
don't
don't
know
what
we're
getting
there,
so
that
might
actually
help
implementation
document
actually
to
align
with
the
terminologies
and
everything
that
anything
we
need
to
change.
So
just
just
a
thought
I
mean
I'm
not
suggesting
I
don't
have
any
extra
opinion
on
that
one
but
think
about
it.
Yeah.
B
All
right,
so
I'm
actually
curious
who
has
read
the
implementation
draft,
so
I'm
gonna
see
what
a
show
of
hands
tool
gives
us
in
a
hybrid
setting.
B
So
I
guess
people
can
also
raise
their
hands
physically,
but
it's
kind
of
interesting.
I
think
the
presenter
laptop
can
also
raise
its
hand,
say,
let's
say
within
the
past
three
versions:.
B
A
I
just
I
think
that
the
just
the
level
said
here
that
the
criteria
for
this
reviewer-
you
don't
need
to
be
an
expert
right,
we're
asking
for
people
who
are
non-authors,
we're
looking
for
readability,
consistency.
You
know,
comprehension,
stuff,
that
people
who
are
really
familiar
with
the
content
are
probably
going
to
miss.
A
So
if
you
have
not
been
deeply
involved
in
the
past,
don't
that
does
not
disqualify.
In
fact,
that
probably
makes
you
a
better
candidate
for
a
reviewer.
A
All
right
seeing
no
volunteers.
I
will
take
this
to
the
mailing
list
to
see
if
we
can
beat
up
some
volunteer
cycles.
H
So
there
is
one
hi
brian
dremel.
There
is
a
question
from
thorben
kruger
in
the
chat
about
when
we
need
this
review
completed,
which
I'm
bringing
to
the
mic,
because
that
might
be
input
to
whether
or
not.
A
Yeah,
thank
you.
I
would
say.
A
Ideally,
four
weeks
after
itf,
probably
roughly
the
time
for
our
next
interim,
but
I
think
if
it
it's,
if
we
have
somebody
who
would
be
willing,
if
they
had
a
little
more
time,
I'd
rather
have
a
volunteer
who
needed
more
time
than
have
to
waste
that
potential
review
time.
Finding
another
volunteer
so.
A
Okay,
well,
let's
move
on
you
don't
need
to.
If
you
think
about
it,
you
can
contact
reese
or
myself.
Okay,
dorban
is
thinking
about
it.
Thank
you,
norman
moving
right
along
okay.
So
a
slightly
revised
schedule
you
can
see.
We
are
here
on
the
left,
the
general
plan
for
the
working
group.
Our
cadence
has
been
to
try
to
have
an
interim.
Every
month
we
usually
meet
for
two
hours
and
go
over
get
issues
and
pull
requests.
A
If
we
can
get
the
review
done
by
april,
we'll
have
a
working
group
last
call
open
then,
and
then
really
the
interims
will
continue
until
we
resolve
the
working
group
last
call
comments,
our
general
cadence.
We
actually,
I
think,
got
a
consensus.
Maybe
it
wasn't
one
of
our
interims
that
meeting
every
itf
didn't
seem
like
it
was
going
to
be
a
great
use
of
our
time.
Most
of
our
working.
A
The
interim
meetings
are
quite
detailed
and
don't
necessarily
lend
themselves
to
sort
of
the
cross-participation,
and
so
we
we
are
just
meaning
because
we
agreed
to
meet
every
other
itf.
So
if
we
continue
on
that,
then
we
would
not
meet
at
itf.
114
continue
on
with
our
interims
and
and
then
meet
at
itf
115.
A
Let
me
just
pause
here.
I
people
have
not
seen
this
before
so
if
anybody
has
any
comments
on
it
or
questions,
we
can
talk
about
that
now.
A
A
And
then
the
final
slide
here
is,
you
know
we
have
talked
about
mappings,
which,
for
those
of
you
who
who
aren't
closely
involved
in
taps,
you
know
taps
is
a
generic
api
for
accessing
services
provided
by
transport
protocols,
and
we
thought
that
it
might
be
useful
to
produce
some
documents
that
showed
how
a
a
protocol
that's
sat
on
top
of
taps,
whether
it's
a
transport
protocol
or
any
other,
would
make
use
of
the
api
and
tommy's
gonna
talk
in
a
few
minutes
about
about
quick
for
that
the
general
feeling
has
been.
A
You
know
you
shouldn't
have
to
have
a
published
mapping
document
to
use
taps,
but
this
is
more
of
a
matter
to
make
it
easier
for
folks
to
us
understand
how
they
would
make
use
of
taps
if
it
was
available
for
them,
and
so
the
proposal
here
is
to
add
a
milestone
for
producing
a
protocol
or
one
or
more
protocol
mapping
documents
to
our
charter.
A
A
Certainly
any
comments
on
the
value
of
the
the
quick
mapping
that
tommy's
going
to
be
talking
about
will
inform
that
discussion
and
also
whether
there
are
other
candidates,
and
I
think
that
you
know
a
candidate
in
my
mind-
would
be
a
protocol
where
it's
not
obvious
how
you
would
use
taps
to
get
what
you
want,
or
maybe
there
are
benefits
from
using
taps.
A
That
would
not
be
obvious
to
the
you
know
the
upper
layer
protocol
and,
and
so
it
would
be
sort
of
a
collaborative
activity
between
somebody
who
has
some
expertise
in
the
upper
layer
protocol
and
folks
in
the
taps
working
group.
Otherwise,
why
do
it
in
the
working
group?
So
let
me
just
pause
here
see
if
there's
any
questions
or
comments
on
this
or
any
objections
to
to
doing
this.
A
There's
a
comment
from
martin
on
the
chat
that
http
is
one
where
the
mapping
is
pretty
unclear.
A
Okay,
so
that's
it
for
me
thanks
everybody,
sorry!
I
can't
be
with
you
and
let
me
hand
the
baton
back
to
reese.
If
I
can
figure
out
how.
B
Thanks
aaron
all
right,
so
I
think
next
up
we
have
our
presentation
on
the
quick
mapping,
so
if
tommy
could
join
and
share
the
preloaded
slides,
please.
J
B
I
So
I'll
be
sharing
a
document
which
I
only
put
out
at
the
beginning
of
this
week.
So
after
the
deadline,
there
was
a
previous
document
from
a
couple
years
ago,
where
we
talked
about
how
you
could
use
taps
as
an
api
for
quick,
and
it
gave
a
couple
different
options
that
was
before
we
had
a
lot
of
the
formal
mapping
concepts
within
tabs
implementation,
and
it
was
also
when
quick
was
very
much
in
flux.
I
So
this
is
a
simpler,
more
direct
document
that
hopefully
will
be
useful,
as
both
an
example
of
how
we
can
do
a
mapping
as
as
well
as
just
showing
how
we
can
use
taps
with
quick.
I
I
There's
a
section
at
the
end
of
the
document,
with
a
bunch
of
mappings
for
the
transport
protocols
that
were
originally
analyzed
within
taps
for
tcp
and
udp
and
sctp,
but
essentially
what
these
are
are
just
definitions
of
what
happens
when
you
use
each
one
of
the
transport
services.
Api
calls
and
a
different
transfer
protocol
is
loaded
underneath.
I
So
it's
very
implementation
focused
as
far
as
you
know,
if
you're
building
this
api,
how
do
you
actually
wire
it
up
into
the
individual
protocol
calls?
And
it
also
tells
you
as
an
api
adopter
what
the
contract
and
guarantees
are
when
you
are
using
the
tabs
interface,
and
this
is
really
focused
on
kind
of
the
establishment,
tear
down
and
data
transfer
properties.
I
I
And
from
the
implementation
document
we
have
an
appendix
in
there,
which
says
here
are
the
things
you
need
to
add
or
need
to
define
in
a
mapping
document
like
this
one,
and
so
it
has
a
template,
and
so
this
is
essentially
the
first
document.
That's
trying
to
follow
this
template
and
show
how
we
can
extend
it
and,
as
part
of
the
exercise
of
doing
this,
I
realized
that
we
needed
to
update
the
template
a
bit.
I
We
have
relatively
recently
added
some
close
group
and
abort
group
functions
to
the
overall
api
to
handle
tearing
down
multiplex
connections
or
groups
of
connections
in
general,
and
when
we
added
that
to
the
api,
it
didn't
make
it
into
the
implementation
document,
and
so
we
actually
already
have
merged
in
a
pr
to
update
that.
And
so
that
was
one
thing.
You
know
that's
good
about.
Actually
using
this
template
and
exercising
the
mapping
is
that
we
learn
any
things
we're
missing.
So
it's
a
good
part
of
the
review
of
the
implementation.
I
It's
very
short.
You
could
read
it
in.
You
know
a
couple
minutes:
it's
mainly
trying
to
copy
the
style
that
we
have
in
the
implementation
document
for
tcp,
udp
and
sctp.
I
The
particular
approach
for
what
the
mapping
is
is
based
on
our
experience
within
the
network
framework
at
apple,
since
that
is
a
taps
like
api,
and
it
supports
quick
and
you
know
originally,
we
had
had
various
different
approaches.
We
were
trying.
This
reflects
this.
This
mapping
reflects
what
we
ended
up
shipping
as
our
quick
api
and
because
it
ended
up
being
the
most
friendly
for
use
on
top
of
a
taps
type
extract
abstraction.
I
There
doesn't
have
to
be
just
one
mapping
for
a
given
transport
protocol.
The
one
here
that
is
defined
in
this
document
currently
is
just
about
quick
streams
and
how
to
use
unidirectional
bi-directional
streams
within
quick.
It
doesn't
currently
address
how
you
use
datagrams
and
it's
possible
that
you
would
essentially
have
a
different
mapping
for
accessing
unreliable
data
on
quick
than
you
would
for
the
reliable
streams
or
you
could
have
it
as
one.
So
there
could
be.
I
I
So
the
first
part
of
a
mapping
is
just
to
define
what
kind
of
what
are
the
objects
at
the
high
level?
What
are
they
mapped
to?
What
is
the
overall
contract
of
this,
and
there
are
a
couple
different
options,
so
first
we
have
to
define
what
is
your
connectedness
of
like?
Is
this
an
unconnected
like
udp?
Is
it
connected
like
tcp,
or
is
it
an
inherently
multiplexing
protocol?
So
quick
is
inherently
a
multiplexing
protocol,
so
it
gets
that
connectedness.
I
The
mapping
also
wants
you
to
find
kind
of.
What's
your
basic
data
unit
offered
by
this
transport,
and
so
in
this
case
it
is
a
byte
stream
and
that's
why
this
mapping
is
specifically
applying
to
using
quick
streams
and
not
quick
datagrams.
That
would
need
a
different
mapping
and
then
the
last
thing
here
is
what
is
the
connection
object,
and
this
is
probably
the
most
interesting
confusing
controversial
choice
here.
I
This
is
like
the
main
thing
to
choose,
and
this
mapping
defines
that
a
taps
connection,
which
is
you
know
the
thing
that
you're
used
to
using
as
a
a
tcp
stream,
like
the
equivalent
of
that
is
a
quick
stream
which
makes
sense
like
when
you're
just
calling
like,
I
need
an
object
in
which
I
can
create
one
and
send
and
receive
a
stream
and
get
to
the
end
of
stream.
I
I
I
So
a
calling
initiate
on
a
connection
will
because
this
is
a
quick
stream.
If
there's
not
already
a
quick
connection
to
the
pier
it
will
have
to
bring
that
up.
But
if
there
already
is
initiate
really
just
is
allocating
a
new
stream
id
on
which
to
send
so
it's
either
bring
up
quick
connection
and
allocate
stream
id
or
just
allocate
a
stream
id
on
an
existing
connection.
I
I
The
listen
and
connection
received
calls
mean
that
you
have
a
new
stream
from
the
pier
for
sending
receiving
it's
quite
straightforward
and
simple.
The
ascending
just
generates
stream
frames
on
the
quick
connection
for
that
stream.
Id
receiving
is
handling
the
inbound
stream
frames
that
you
get
for
your
stream
id
closing.
The
connection
is
equivalent
to
sending
a
fin
on
that
stream,
just
as
it
is
with
tcp
aborting
is
sending
a
reset
stream
closing.
The
group
means
that
you
close
that
stream
and
then
you
close
the
connection.
I
Once
all
streams
have
closed
and
aborting
a
group
means
that
you
immediately
close
the
connection
and
you
just
drop
all
outstanding
streams.
So
that's
what
is
written
in
the
document.
I
think
it's
the
most
straightforward
mapping
too
quick
from
what
we
have
in
the
taps,
concepts,
but
I'd
love
to
hear
your
thoughts
or
reviews
on
that.
I
A
Your
audio
is
gating
a
lot.
I
don't
know
if
there's
me
want
to
turn
off
your
video
or
something
because
it
was
distorting
a
bit
might
be
sorry.
A
Video
yeah
we'll
see
if
that
helps
so
I
was
I
was
looking
for.
I
just
scanned
the
document
for
the
comments
that
you
opened
with
about
sort
of
the
the
sort
of
the
use
cases
for
quick
that
that
this
mapping
addressed
that
might
help
distinguish
it
from
other
use
cases
that
might
go
to
another
mapping,
and
I
didn't
see
that-
and
I
thought
that
maybe
that
would
be
a
good
addition
to
the
document.
A
The
you
know
what
just
even
maybe
sort
of
a
high
level
summary
of
what
is
this
good
for
and
what
is
it
not
good
for
to
help
people
sort
of
understand?
You
know
where
they
are
in
the
zoo.
I
I
Yes,
it
doesn't
have
a
lot
of
descriptive
text,
but
an
option
is
that
we
could
also
add
the
quick
datagram
mapping
into
this
same
document
as
well,
and
then
you
know
essentially
say
here
here
are
two
different
mappings
real,
quick
and
then
have
some
text
to
couch
them
and
like
this
is
when
you
use
one.
This
is
when
you
use
the
other.
B
Thanks
next,
we
have
brian.
H
So
can
we
go
back
actually
to
the
sort
of
the
mapping
bit?
Yes,
so
I
see
sort
of
what
happens
if
there's
like
create
a
new
connection,
if
needed.
So
there's
a
quick
connection
right.
So
I
I
get
the
mapping
between
connections.
H
I
Yes,
it
is
mentioned,
so
this
is
not
exhaustive.
This
is
what
fit
on
the
slide
and
was
interesting.
There
is
an
initiate
with
send
that
essentially
says
this
is
the
same
as
initiate,
except
right.
If
you're
bringing.
I
K
Hello,
sorry,
hello,
lucas,
buddy
cloud
player.
Thanks
for
the
draft
tommy,
I
had
a
quick
read
over
lunch
good.
The
thing
that
struck
me
immediately
was
like
the
lack
of
datagram
here.
I
think,
given
the
progress
that
quick
working
group
is
making
on
datagram,
if
you're
going
to
do
a
mapping,
just
consider
datagrams
and
streams
like
those
are
the
things
that
applications
can
use
to
just
do
it
as
well.
Contrary
to
aaron's
suggestion.
I
it
doesn't
seem
like
we
need
to
say
what
you
would
use
them
for
quick.
K
Doesn't
it
just
says
this
is
what
they.
This
is
the
service
that
those
things
provide
and
lose
it
up
to
other
people
that
decide
how
to
use
them.
We
might
be
documenting
that
elsewhere
and
we
could
just
point
at
that,
but
I
don't
feel
like
taps
needs
to
say
anything
in
particular,
and
then
one
specific
point
on
the
draft.
I
didn't
see
anything
about,
stop
sending
frames
before
like
how
to
cancel
the
one
one
end
of
a
stream.
K
I
don't
know
if
that
was
in
consideration
at
all
or
just
didn't
make
it
into
this
cut.
I
Yep
yeah,
thank
you
so
yeah
on
the
point
of
including
datagram
and
the
reasons.
So,
yes,
I
think
to
be
complete.
This
needs
to
include
datagram,
and
I
agree
with
you
that
we
shouldn't
go
into
too
much
detail
about
the
applications,
but
having
a
bit
of
text
of
you
know
hey
if
you're
using
taps
to
get
a
byte
stream,
then
you
should
use
the
stream
mapping
if
you're
doing
it
to
kind
of
replace
your
udp
usage
use
datagram.
We
could
have
some
high
level
bits
like
that
as
far
as
stop
sending.
I
This
is
something
we
have
talked
about
previously
in
the
group,
and
I
don't
quite
remember,
but
I
believe
the
consensus
was
it's
not
something
that
is
included
in
the
base
api
for
taps,
because
it
is
a
feature
that
pretty
much
no
other
transport
protocol
offers
on
its
stream.
You
know
within
network
framework
itself,
we
don't
have
an
api
to
do
it.
I
When
is
it
needed?
If
we
believe
it's
generic,
because
the
other
option
is
that
you
know
taps
apis
certainly
do
allow.
You
to
add
protocol
specific
extra
functions
if
you
want
to
support
that
in
in
your
implementation.
But
it's
not
something
that
you
can
expect
that
every
byte
stream
protocol
would
be
able
to
support.
K
Okay,
I
don't
know
enough
about
taps.
It
just
seems
like
a
pretty
critical
thing
for
quick
to
be
able
to
do
that,
because
you
can't
stop
things.
Otherwise,
you
can
only
close
your
side.
It's
about.
We
can.
I
K
Okay,
let's
take
it
offline,
but
thanks
for
this
work
cheers.
L
Hello,
jonathan
lennox,
I
guess
my
question.
Having
only
briefly
read
this
document
and
not
thought
about
terribly
hard
is:
is
this
api
sufficient
to
implement
a
fully
fledged
h3
client,
an
h3
server,
or
are
there
things
that,
if
you
were
actually
doing
that,
you
would
need
to,
you
know,
do
something
magic
and
maybe
a
network
framework.
You've
actually
done
this.
You
know
concretely
or
maybe
you
can
just
think
about
it.
But
I
guess
my
question
is:
is
this
because
I
think
that's
the
where
the
rubber
meets
the
road
for?
I
On
top
of
this,
there
are,
I
think,
the
one
thing
that
is
used
there-
that's
not
explicitly
part
of
this
mapping
is
what
perhaps
would
consider
like
a
protocol
specific
metadata
to
access
the
stream
id
numbers
etc
from
within
the
transport,
but
so
maybe
that
is
something
that
would
be
good
to
add
to
the
document
of
saying,
hey,
and
you
also
probably
want
to
expose
a
quick,
specific
getter
for
your
stream
id,
but
beyond
that,
this
mapping,
for
actually
just
using
center,
receive
create
and
close
all
work.
Fine
for
h3.
M
Martin,
duke
google,
thanks
for
this,
I've
been
waiting
for
it
and
I
support
adoption
not
that
we're
asking
for
adoption
yet.
But
let
me
preemptively
do
that.
Just
a
couple
of
nits,
like
I
mean
on
on
the
abort
call,
it
should
be
like
reset
stream
and
or
stop
sending,
depending
on
the
direction
directionality
of
the
stream
and
like
on
the
listen
thing.
It
seems
to
like,
say
well,
open
a
socket,
but
in
fact
listen
is
being
used
for
receptiveness
to
new
streams
as
well.
Correct.
H
Hi
brian
trammell,
google
I'll
be
brief,
because
I
think
we're
getting
ready
to
go
down
a
rabbit
hole
here.
I
would
point
out
on
the
quick
datagram
thing:
datagram
looks
kind
of
like
sockseek
packet,
which
does
exist
in
another
protocol,
so
I
think
that
we
can
sort
of,
like
you
know,
take
some
of
how
we've
thought
about
sctp
into
that,
and
I
think
it
is
probably
important
to
do
right
like
so.
H
We
said
we're
going
to
do
the
quick
base
protocol,
but
datagram
is
rapidly
progressing
through
quick,
but
I
think
these
are
things
that
we
can
do
once
it
is.
You
know,
a
working
group
item
look
forward
to
working
on
it
since
we're
not
talking
about
supporting
adoption.
Yet
I
support
adoption.
I
D
M
D
Yes,
okay,
good,
so
I
I
guess,
I'm
gonna
take
something
similar
to
what
brian
started
out
with.
I
can
see
how
this
can
be
a
replacement
for
a
bunch
of
tcp
connections
very
easily.
D
I
can
also
see
how
we
can
define
this
in
a
way
that
acts
as
a
replacement
for
udp
and
provides
security,
and
all
that
on
top
of
it,
are
we
flexible
enough
in
the
way
we've
defined
taps
that
we
can
ask
for
a
connection
which
allows
you
to
do
both
reliable
and
unreliable
data
on
the
same
connection,
so
you
can
have
basic
streams.
I
Right,
I
think
that's
where
kind
of
what
the
mapping
of
connection
objects
turns
into
under
in
quick
is
very
important.
B
Thanks
and
we
have
michael
and
after
that,
he
was
closed.
E
Michael
herzl,
I
wonder
if
these
two
things
that
were
brought
up
regarding
the
interface
and
quick,
if
they
I
mean,
I
don't
want
to
make
things
harder
for
the
interface
document
now
for
sure,
but
if
they
maybe
should
should
be
included
there,
because
I
think
the
stop
sending
frame
is
probably
safe
enough
to
ignore
for
transports
that
that
don't
support
that
and
the
stream
id.
I
You
know
get
me
the
protocol,
specific
information
for
this,
because
you
know
the
specific
type
of
a
stream
id
or
one
of
these
things
could
vary
between
different
protocols.
So
there
should
just
be
a
way
to
say
like
for
quick,
get
me
this
property,
and
then
you
say:
oh
the
I
want
you
know,
quick
property
stream
id
and
then
it
returns
me
an
object
which
happens
to
be
variant
in
this
case.
Yeah.
F
Transport
eddie
hat
off.
I
have
one
comment,
so
we
we
used
to
have
like
those
are
ourses.
Now
we
have
to
survey
document
and
the
feature
document
right:
the
documentary
service
couple
of
transport
protocols
and
also
the
transport
features
and
recorded
them.
So
I
think
it
would
be
good
to
have
this.
This
kind
of
mapping
document
also
to
actually
have
some
sort
of
like
background
information
and
a
surveys
around
it,
not
just
like
direct
mapping.
I
didn't
find
it
this
time.
F
It
would
be
good
because
some
of
the
topics
that
I
think
lucas
was
mentioning
would
could
come
up
here
and
we
could
have
a
resolution
in
this
kind
of
mapping
document
how
to
deal
with
those
instead
of
like
filling
around
already
like
long
big
documents.
So
that's
one
comment
I
have
think
about
it
and
that's
the
solution.
F
With
my
eddie
hat
on,
I
don't
find
this
as
a
related
document
in
the
data
tracker.
So
something
went
wrong,
so
maybe
we
should
we
need
to
fix
that
yeah
you.
I
think
I
think
the
naming
of
the
draft
didn't
allow
it
to
record
as
a
related
document
in
the
data
tracker,
so
maybe
resubmit
it
with
drafts.
Tommy,
probably
taps
something.
B
Yeah,
that's
the
truth.
Okay,
I'll
look
into
that.
Thank
you,
zahid
and
at
this
point
I'm
curious
to
just
get
a
sense
of
the
room
for
the
first
question
on
tommy's
slide,
which
is
support
for
adopting
this
mapping
document.
B
Okay,
we
have
21
raised
hands
in
medical
25,
oh
wow,
and
no
physical
raised
hands.
I
guess
midair
coins.
Okay,
that's
not
bad!
Thank
you!
So
tommy
is
there?
Oh
yeah.
Should
we
start?
Others
is
actually
the
second
question
on
this
slide.
We
we
kind
of
have
two
minutes,
and
then
we
have
another
presentation
with
15
minutes
allocated.
M
F
So
cheers
eddie
interruption
again
I
mean
two
things
one:
if,
if
there
is
anybody
in
this
room
who
has
not
really
used
this
online
site
tool
or
some
way
to
log
into
this
session,
they
will
be
not
part
of
the
blue
sheet.
So
please
do
that
and
also
like.
I
will
not
pro
and
use
your
hand
raise
of
hand
virtually
this
time.
I
think
that's
the
that's
the
what
we
want
not
really
raised
in
hand
room.
B
N
Great
all
right,
thanks
for
having
invited
me,
I
guess
I'm
going
to
talk
about
our
panapi
system,
which
is
a
taps
like
transport
system
that
we
are
developing
and
there's
already
been
some
discussion
about
this
on
the
mailing
list
and
yeah
and
reece
was
so
kind
to
invite
me
to
give
a
talk,
and
here
I
am
we
quick,
although
this
is
not
exactly
visible.
This
talk
is
split
into
two
parts.
N
I'm
going
to
talk
a
bit
about
the
system
that
we
are
building
and
then
I
also
have
some
feedback
that
might
be
valuable
or
might
not
be,
I'm
not
sure.
So,
who
are
we?
I'm
a
phd
student
at
the
nexus
lab
network
and
distributed
resistance
lab
at
the
ottawa
university
in
magdeburg,
germany
and
our
research
group
is
mainly
focusing
on
zion
as
a
promising
future
internet
architecture.
I
think
many,
if
not
most
people
here
have
at
least
heard
about
this,
but
just
in
case
there's.
N
Here's
the
really
quick
repack
recap:
simon,
is
a
proposed
new
dead
architecture
designed
to
eventually
replace
bgp.
It
exposes
path,
awareness
and
multiple
features
to
each
end
host,
and
it
has
already
seen
a
pretty
wide
deployment,
at
least
among
certain
industries.
So
the
financial
industry
in
switzerland
seems
pretty
keen
on
it,
but
they
are
internationally.
There
are
more
deployments,
and
the
project
is
spearheaded
by
the
network.
Security
group
of
etheric
cyan
has
some
interesting
implications,
and
so
we
asked
ourselves
what
benefit
can
pathways
actually
have
on
the
end
host?
N
N
As
networking
nerds
we
most
likely
are
the
only
ones
who
care
and
we
would
probably
be
the
first
to
point
out
that
interesting
new
networking
features
should
not
complicate
the
lives
for
users,
because
networking
should
be
a
commodity
like
tap
water
right,
so
it
should
just
work.
N
N
In
the
back
end,
we
have
some
highly
scriptable
environment
that
allows
us
to
experiment
with
the
interesting
networking
details
and
to
to
that
allows
us
to
try
out
certain
things
like
different
capacity
profile
based
path,
selection,
behaviors
and
so
on.
N
We
managed
to
get
ngi
pointer
funding
for
our
system
and
we
decided
to
call
it
panel,
api
or
panapi
for
a
pathway,
networking
api
in
case
our
lack
of
creativity,
wasn't
already
obvious
yeah.
The
system
is
written
in,
go
with
a
web-based
scripting
back
a
backend
that
supports
lower
scripts.
N
Spec,
although
tabs
is
very
internet
specific,
we
do
not
use
an
event
system
because
a
goal
already
comes
with
different
native
ways
to
do
concurrency
properly,
we
try
to
have
an
event
system,
but
this
turned
out
to
be
highly
unintuitive
and
since
we
are
in
a
sense
developing
an
api
that
is
meant
to
be
used
for
the
by
the
average
goal
programmer
that
doesn't
want
to
worry
too
much
about
networking.
N
We
decided
to
not
like
force
an
event
based
system
on
them
and
simply
allow
them
to
use
idiomatic
go
as
it's
called,
so
we
avoid
the
the
old
system
of
trying
and
failing
by
having
all
calls
block
and
until
they
can
either
return
success
or
an
error.
N
If
we
need
asynchronicity,
we
can
simply
dispatch
these
walls
in
the
background,
as
required.
The
go
primitives
are
really
well
suited
for
this,
and
we
have
already
had
some
discussions
about
the
details
of
this
and
whether
this
is
in
the
spirit
of
taps
or
not
on
the
mailing
list.
I
forgot
to
link
this
here,
but
yeah.
The
the
discussion
is
on
record.
N
N
N
N
Then
briefly,
we
also
have
a
back
end.
That
is
right
now,
a
science-specific
back-end
daemon,
so
meaning
that
for
regular
non-scion
communication,
the
ap
api
works
just
fine
as
a
standalone
library,
and
in
case
there
is
a
demon
present
and
we
are
communicating
via
scion.
There
are
rpc
calls
happening
between
the
api
library
and
the
demon.
N
We
have
support
for
path,
quality,
estimation
and
scriptable
path,
choice
and
optionally.
Our
backend
can
also
perform
active
latency
measurements
over
certain
paths
and
we
found
that
most
tabs
concepts
map
map
pretty
directly
to
scion,
at
least
in
in
our
opinion,
so
we're
quite
confident
that
we
are
not
under
mining
top
semantics
in
any
way.
So
in
the
in
the
scion
world.
Different
capacity
profiles,
for
instance,
can
be
satisfied
by
selecting
suitable
paths
after
considering
cached
path,
performance
information,
similar
to
what
the
standard
semantics
are.
N
There
is
at
least
one
thing
that
we
sometimes
use
in
the
site
in
scion.
That
does
not
appear
to
have
a
taps
equivalent,
which
is
active.
Probing,
namely
something
where
we
perform
active
pings
over
alternative
paths
to
a
destination
and
to
just
keep
track
of
which,
which
are
available
or
promised
to
offer
better
latency
than
the
currently
chosen
path,
and
I
would
be
interested
if
this
is
something
that
could
conceivably
be
added
or
if
this
is
something
that
should
stay
very
much
sign
central.
N
N
Maybe
we
can
also
talk
about
maybe
having
a
scion
mapping
as
rn
proposed,
but
I
would
propose
to
shift
the
actual
discussion
into
this
to
a
later
point.
Since
I
have
some
feedback
of
my
own.
N
N
There's
I
I
previously
mentioned
that
we
have
had
some
pain
with
with
supporting
the
different
property
types
in
a
statically
typed
way
and
so
and
with
their
scope
and
their
validity.
So
on
the
left,
you
see
a
quote
from
the
api
draft,
and
here
the
properties
are
meant
as
configurable
parameters
for
protocol
selection
connections
and
messages,
and
it's
all
sort
of
semi
lumped
together,
but
not
quite
and
sort
of
they're
they're
distinguished
there's.
There
are
certain
boundaries
which
are,
which
could
be
more
explicit.
N
Let's
say,
and
on
the
other
hand,
on
the
right
hand,
side,
you
there's
a
quote
where
it
says
that
properties
sometimes
or
at
some
point
have
sort
of
converged
and
can
be
queried,
so
they
have
converged
from
a
preference
to
a
boolean.
So
from
from
an
enumerated
preference
to
a
boolean,
and
the
documents
do
not
disappear
to
distinguish
between
these
two
stages
that
the
property
can
be
in.
N
It
can
still
be
a
setting
that
can
be
modified,
and
this
is
currently
still
not
not
has
not
converged,
and
it
can
be
a
converged
property
that
that
actually
reflects
the
result
of
a
selection
process,
and
we
found
that
this
is
that
when,
when
trying
to
implement
this
properly,
we
sort
of
need
to
have
this
clear
distinction
between
the
two
stages.
N
I
think
right
now
the
drafts
are
mentioning
that
the
preference
can
first
be
in
this
sort
of
preference
state
or
probably
in
the
preference
stage,
and
then
at
a
later
point.
It
congeals,
let's
say
to
a
truth
value-
and
this
is
a
very
very
let's
say,
dynamic
way
of
looking
at
this.
So
in
dynamically
type
programming
languages,
this
is
easy,
but
in
statically
typed
programming
languages.
This
is
really
hard,
and
maybe
it's
worth
thinking
about
how
to
maybe
conceptually
distinguish
these.
N
The
second
piece
of
feedback
is
a
small
nitpick.
So
if
you're
remembering
the
the
discussion
from
the
mating
list,
I
try
to
justify
why
we
didn't
use
an
event-based
system,
and
people
were
quick
to
point
out
that
it's
somewhere
in
an
appendix
it
said
that
it's
valid
to
implement
this
in
a
different
way.
Also,
and
it
would
have
been
really
nice
if
this
had
been
clarified
way
earlier.
And
this
went
more
visibly.
N
But
in
conclusion,
it
has
been
a
pleasure
to
work
with
taps
and
the
work
that
you
guys
have
been
doing
here,
and
I
hope
that
you
guys
have
interesting
comments
to
what
we
have
done
so
far.
And
thanks
for
listening.
E
Hello,
michael
westley,
again
we
have
been
around
that
block
of
selection
properties
morphing
into
booleans.
E
N
I
I
don't
I
I
don't
disagree
that
properties
at
some
point
become
immutable.
It
would
just
be
nice
if
this
was
actually
sort
of
being
if
it
was
a
clear
distinction
between
properties
that
are
still
mutable
and
those
that
aren't.
A
E
N
J
N
Yeah,
so
this
is
a
cyan
address.
This
is
the
format
of
a
sign
address.
The
19
is
the
isolation
domain.
The
thing
that
looks
a
bit
like
mac
address
is
the
the
and
the
as
address,
and
the
last
part
is
the
as
internal
ip
address
and
the
very
last
part
is
support.
H
Yeah
so
thurman,
you
asked
a
question
earlier:
does
this
make
sense?
Is
it
in
the
tap
spirit?
Yes,
yes,
this
stuff
is
awesome
totally
okay
to
not
do
it
event
base
totally
okay
to
do
things.
Go
like
we've
actually
seen
another
go
implementation
of
this.
That
was
I'm
just
going
to
throw
away
the
all
of
the
naming
because
it
should
be
called
dial
because
it's
go
right
like
so
this
is
I
really
like
how
you
did
this
here.
Michael
addressed
your
first
bit
of
feedback.
H
Your
second
bit
of
feedback
has
now
been
filed
as
issue
1009,
and
I
hope
to
have
a
pr
for
that
by
the
end
of
the
break,
so
yeah
you're
right,
we'll
fix
it.
I'm
sorry,
we
wasted
your
time.
N
Yeah
I
hesitated,
I
hesitated
to
open
an
issue
because
it
seems
like
this.
This
draft
is
pretty
much
mature
now,
and
so
I
wanted
to
discuss
it
first.
B
Okay
thanks,
so
we
are
out
of
time.
Aaron
did
you
have
any
last
words.
A
Last
word
is
think
about
whether
what
other
tapping
mapping
documents
might
be
useful
and
send
suggestions
to
the
list.
So
thanks
everybody
for
coming
great
discussion
today,.