►
From YouTube: IETF104-TSVWG-20190326-1120
Description
TSVWG meeting session at IETF104
2019/03/26 1120
https://datatracker.ietf.org/meeting/104/proceedings/
A
A
A
Star
agenda
you've
already
seen
the
not
well
they're
not
well,
is
in
the
slide
that
remember.
Everything
in
this
meeting
is
colored
by
the
not
well
read
it
if
you
haven't
done
so.
Our
agenda
has
two
slots
fiscally
working
group
drafts
where
we
have
three
drafts
scheduled
for
today
and
then
a
couple
of
individual
drafts.
A
The
individual
drafts
are
looking
at
two
topics
and
where
does
HTTP
to
as
a
transport
fit
into
the
IT
a
very
big
question
it
could
be
here
or
it
may
not
be.
But
surely
we
should
talk
about
this
draft
and
we'd
love
to
get
feedback
on
that,
and
today
an
sctp
retransmit
bit
is
one
more
bit
the
SCTP
hugger
and
that
we
presented
as
the
final
presentation
for
this
session.
So
we
start
with
a
CTP
and
end
with
SCTP
Michael.
C
Okay,
this
is
about
our
revision
of
RFC
4960
piece
ever
seen,
I've
seen
a
4960
which
is
the
base
bag
of
SCTP,
so
RC
4960
was
way
back.
Written
in
XML
went
to
the
RFC.
Editor
was
converted
to
end
off
and
published.
So
in
doing
a
base
document.
We
wanted
to
submit
the
RFC
almost
as
is
as
an
internet
draft,
and
then
you
can
follow
whether
diffa
to
all
the
changes.
So
this
was
happened.
C
Then
the
stuff
was
rewritten
completely
in
XML
to
match
the
formatting,
which
were
ok
ish,
except
for
one
section
which
is
dealing
with
the
abstract
API,
and
it
had
a
strange
formatting
which
I
couldn't
teach
XML
to
do
so.
But
that
section
is
not
that
critical,
because
it's
an
informational
only
so
the
text
should
be
there
and
different
formatting
and
the
rest.
You
can
check
with
a
with
a
div
to
what's
in
working.
C
C
We
can
think
about
layout
improvements
are
not
so
taking
tweaks
out
of
the
XML
stuff,
which
made
it
look
like
ROC,
4960
or
not,
but
basically
that's
it.
So
the
plan
is
to
do
the
discussion
on
the
Matheson
shirts.
This
week
are
some
of
the
stuff
amen.
It
can
stay
around
for
a
while
for
people
reading
it
and
catching
minor
issues.
We
are
not
aware
of
any
technical
changes,
so
that
should
right
now
work
out
any
questions
regarding
that.
A
Sorry
about
the
floor
and
just
a
chat
question
and
to
be
clear:
the
the
next
Rev
will
the
next
Rev
will
be
Oh
yeah,
which
is
the
with
their
artist
correctly.
Yes,
and
so
that
should
be
a
fairly
boring
thing,
because
it's
the
same
document
we
have
it
set.
It
just
merges
two
of
them
together
effectively
yeah.
A
A
There
is,
of
course,
this
is,
of
course,
a
new
working
group
document,
so
if
we
do
find
things
which
are
important
to
fix,
then
it
is
still
open
for
people
to
send
those
pictures
in
and
contribute
to.
This
document
is
not
just
an
editorial
path.
So
when
we
get
to
stage
3
on
expecting
more
people
in
the
working
group
to
add
comments
and
start
discussing
this,
exactly
Mira
Mia.
D
A
F
G
We're
having
too
much
fun
with
with
with
process
your
honor
RFC
status.
So
what
should
happen?
Is
that
I
mean
and
as
Randy
suggests,
if
we
can
get
it
done
fast
enough,
this
will
be
8960,
which
would
which
would
be
a
very
nice
number
that
will
become
the
new
standards
track
reference
for
SCTP.
So
as
part
of
that,
it's
pretty
clearly
got
an
obsolete
4960.
What
we
do
with
the
errata
RFC
I
think
is
up
to
us.
G
C
C
A
G
C
C
Sorry,
as
so
we
said,
we
are
done,
Gauri
looked
at
it
and
did
a
review
and
provided
substantial
suggestions
for
editorial
changes
like
moving
things
around,
but
it's
this
editorial
of
me
and
Maxine
provided
editorial
things,
but
also
technical
comments
based
on
in
the
Linux
implementation.
I
think,
and
this
has
to
be
integrated,
some
of
the
editorial
stuff
as
well
hoopha
texts
around.
We
need
to
figure
out
how
to
do
this.
C
E
H
E
C
C
G
A
A
The
author's
have
been
working
on
the
draft
and
we
improved
the
description
of
ICMP
and
ICMP
issues
are
more
clearly
defined.
This
is
a
tricky
thing
to
get
right
and
I.
Think
the
test
is
now
more
or
less
there.
Please
read
it
if
you're
concerned,
and
we
also
then
describe
the
path
to
big
processing.
Part
of
the
algorithm
and
I
think
that's
kind
of
ready
as
well.
So
what's
the
main
contribution?
Are
you
ready?
A
It's
a
simpler
diagram.
It's
the
same
state
machine
so
I
said.
Was
a
boring
talk,
I'm,
sorry,
it
is.
But
it's
the
diagram
is
much
much
simpler
because
Michael
with
redrew
it
for
us
with
help
from
our
a
new
co-author.
So
you
might
just
spotted
the
awfulest
has
increased
the
editor
list,
and
this
is
the
state
diagram.
You
can
even
ignore
the
RS
state.
A
There's
lots
of
gotchas
in
this
space
about
how
to
deal
with
loss
reordering
how
to
deal
with
Roc
things
on
the
path
that
might
send
you
something
to
ignore
you,
etc.
And
so
these
are
things
that
we
want
to
get
right
and
we
will
provide
as
much
but
as
we
can
for
the
next
ITF,
where
we
may
be
ready
for
a
working
group
last
call
which
would
be
cool
because
I
think
quick
would
like
to
reference
this
and
that's
their
time.
Skill
as
well.
A
I
Martin
Duke
from
f5
has
anyone
implemented
that.
K
K
G
K
L
A
Recommendation
so
h2
PL,
P
and
T
beauty
and
the
kwiktext
also
says
he
can
do
PMT
UT
if
you
can
how
to
do
that
for
UDP,
which
could
be
challenging.
But
that's
what
the
current
text
says.
We
work
with
the
quick
contribution
Texas,
so
it
does
align
with
what
we
say
here
which
doesn't
mandate
all
this
stuff,
because
this
does
not
kind
of
published
as
an
hour
I've
seen.
Maybe
in
the
next
version
equipped,
we
can
be
stronger
and
we
have
more
experience.
B
Tomorrow,
yeah
I
think
the
big
difference
in
quick
versus
you're
UDP
is
that
quick
is
authenticated
and
to
add,
and
so
that
makes
the
security
consideration
easier
to
resolve
because
I
mean
it.
If
your
peer
says,
I
did
receive
this
packet
that
contained
only
35
bytes.
Then
you
know
that
that's
true
and
that
that
creates
a
difference
in
them.
A
A
feedback
mechanism
which
is
actually
a
stronger
feedback
mechanisms
and
the
other
feedback
mechanisms
we
have
the
algorithm
can
be
more
or
less
than
saying
it
doesn't
matter
what
you're
sending
as
long
as
the
transport
can
target.
As
long
as
the
transport
understands
that
it's
not
real
data,
the
algorithm
can
be
the
same
with
quick,
but
the
feedback
is
encrypted,
which
makes
the
feedback
authenticated,
which
is
which
is
definitely
good.
B
There,
the
one
thing
that
would
be
very,
very
useful
is
that
when
you
do
an
end-to-end,
basically
implementation,
you're
doing
a
search,
yes
and
when
you
are
doing
a
search,
it's
nice
to
have
some
kind
of
Bayesian
logic
based
on
what
you
know
about
the
network.
Yes,
and
so
what
would
be
very
helpful
for
those
implementation?
Is
open
statistics
about
what
are
the
commonly
found
empty
use.
I
agree.
A
A
Also,
perhaps,
information
about
paths,
because
we
don't
know
whether
we
have
previous
status,
it's
whether
they
will
apply
again.
There
are
a
few
things
in
this
face
which
would
be
really
good
to
get
grant
rate
on
before
we
get
an
algorithm.
That's
the
main
reason
why
the
current
draft
doesn't
have
an
algorithm
in,
because
I
think
this
is
currently
a
good
area
of
research,
but
I
think
can
get
there
quickly.
A
A
Me
officially,
it's
July
I
can
talk
to
you
afterwards,
having
taught
to
the
quick
chairs,
but
there
are
a
lotta
wear
of
this
dependency
and
I
think
we
are
aware
of
their
requirements.
Okay,.
G
A
G
B
A
So
in
the
next
presentation,
I
shall
attempt
to
represent
the
document
editor
for
the
UDP
options.
Drugged
I
will
do
my
best
to
do
what
job
was
asked
to
present
to
the
working
group
and
job
coaches,
the
editor
of
the
UDP
options
draft
this
has
been
around
for
some
time.
It
changes
each
IETF
and
there's
been
a
lot
of
discussion
on
the
list
prior
to
this
ITF
and
just
made
an
update.
That
includes
some
of
the
responses
to
this,
but
not
all
recent
changes
he
has,
he
believes,
incorporated
the
CCO
work.
A
If
the
LCS
fails
but
still
deliver
the
body
and
the
receiver
decides
whether
to
require
any
option,
and
there
was
discussion
on
the
mailing
list
about
whether
we
should
always
require
CCL
John's
position.
Is
that
and
the
receiver
decides
whether
the
CC
option
is
required
to
be
present
and
current
internet
operability
probably
means
you
want
that.
A
In
general
and
Joe
puts
forward
that
any
option
and
is
decided
by
the
sender,
they
decide
what
to
include
the
receivers,
decide
what
to
require
and
here's
the
possibility
of
having
a
soft
state
to
this,
so
that
you
can
tell
the
receiver
that
once
it's
got
an
option,
it
would
always
need
that
option
to
carry
on
and
there's
issues
with
that
with
somebody
injects
a
packet
with
the
option.
So
that
needs
to
be
thought
about
at
the
overriding
design
of
the
UDP.
Our
space
is
a
design
which
will
be
consistent
with
legacy
applications.
A
Joe
wanted
to
include
a
slide
to
say
that
these
are
UDP
options.
It's
not
an
encapsulation
method
is
not
designed
as
a
way
in
itself
of
providing
transport
of
other
things
other
than
the
UDP
payload.
So
there
are,
things
are
added
to
the
body
and
options
themselves
should
be
discrete
items.
They
don't
depend
on
one
another
and,
except
perhaps
for
the
OCS,
which
is
required
to
validate
the
whole
packet.
A
Joe
says
you
cannot
declare
the
order
of
the
options
occur,
except
when
they
are
fundamental
to
the
processing
of
the
option.
Then
we
have
the
more
detailed
slide
about
the
more
detailed
problems
or
questions
or
debates.
This
slide
refers
to
use
of
fragmentation,
more
UD
with
the
light
option
of
UDP
options,
and
this
is
an
area
that's
been
discussed
on
the
list
and
there's
various
views
about
how
we
should
do
fragmentation
and
light
and
job
puts
forward.
A
A
Don't
know
really
what
else
to
say
the
if
you're
really
following
this,
please
read
the
slide
in
detail.
The
test
is
too
small
to
Pewter,
perhaps
read
here,
but
please
read
this
just
not
present.
So
we
saw
the
feedback
method.
Mechanism
to
jaw
is
comments
on
the
slides
comments
on
the
presentation
all
on
the
list
and
your
promises
to
respond
actively
to
anybody
who
brings
this
up
on
the
list
to
continue
the
debate
he
just
physically
can't
be
here.
A
The
was
discuss
of
what
we
should
include
to
require
or
ignore
flight
in
options
and
such
that
we
have
at
the
IP
layer.
So
when
we
negotiate
extension,
headers
and
things
in
network
layer
protocols,
we
have
to
know
whether
we
require
or
don't
require
these
options
because
they
have
processed
entirely
with
the
packet
without
any
transport
context.
And
Joe's
argument
is
that
we
don't
need
this
because
the
what
these
are
simply
options
to
the
transport.
A
So
we
don't
need
these
flags
and
a
receiver
is
built
to
expect
options
or
is
built
to
ignore
options,
and
these
are
the
only
possibilities
and
Joe
was
asked
about
surplus
area.
After
the
end
of
the
UDP
options,
the
way
UDP
options
work
is
it
uses
the
the
length
of
the
packet
after
the
payload
to
insert
the
options.
Could
you
have
a
space
after
the
options
which
is
yet
more
space
which
could
be
used
for
something
else
and.
A
Does
the
option
have
to
fill
rest,
the
packet
or
not
I,
guess
probably
I
agree
with
John.
We
haven't
said
they
have
to
fill
all
the
rest,
so
there
could
be
something
else
afterwards
in
future
and
how
that
works.
Well,
all
bets
are
off
as
to
how
you
know
what
is
in
there
and
given
the
previous
presentation,
you
probably
need
another
check,
some
compensation
option
insert
than
that
use
of
the
surplus
area
as
well.
That's
for
another
IETF
I
believe
it's
for
another
document.
A
A
There's
other
possibilities
here,
there's
there's
many
ways
in
which
we
can
design
this.
This
is
partly
a
design
activity,
as
well
as
a
protocol
development,
so
we
could
have
a
fixed
header
and
we
could
require
different
things
and
at
some
stage
the
working
group
has
to
decide
and
John's
draft
represents
what
he
thinks
is
the
right
way
forward
and
of
course,
please
discuss
unless
this
changes,
because
in
the
effort
to
make
this
available
for
the
site,
you
have
a
few.
Things
still
remain
on
the
pending
list.
A
So
there's
anti
polls
in
various
places,
there's
a
list
of
current
titles
and
they'll,
be
fixed
in
you
ref
soon
and
the
middle
box.
Traversal
section
needs
to
be
updated
now
to
reflect
that
the
OCS
work
works
and
how
that
doesn't
work.
If
you
in
future,
decide
to
put
something
in
this
surplus
surplus
area
and
as
ever
light
and
fragmentation
remains
a
point
of
discussion.
A
Should
we
have
a
kooky
option?
Potentially
this
is
an
option
if
we
understood
the
need
for
it,
and
somebody
wanted
to
come
forward
with
a
proposal.
I
guess
this
could
be
included.
It
could
be
a
separate
draft.
It
could
be
incorporated
in
this
draft
if
the
reason
for
it
was
clear
and
clearly
as
possible
to
send
you
a
cookie
as
an
option.
M
A
A
kooky
option
if
I
remember
right
myself
is
the
idea
of
just
sending
a
or
pic
value
as
an
option
and
getting
it
reflected
from
the
other
end,
so
that
you
can
then
do.
You
can
then
verify
that
this
packet
hasn't
been
inserted
by
an
off
path,
attacker
or
whatever.
You
want
to
do,
or
even
set
up
some
soft
state.
G
You
take
off
your
virtual
Joe
had
put
put
your
chair
hat
back
on,
let's,
let's
quickly
talk
about
timing
of
this
draft.
My
sense
from
the
state
of
this
discussion
and
the
number
of
topics
on
the
slides
is:
we
need
another
IETF
cycle
of
soaked
time
before
we
before
we
working
to
blast
callers,
so
I
just
heard
Gauri
say
yes,
I'm
proposing
to
move
the
milestone
for
this,
but
from
a
deceptive
from
from
from
May
to
September.
This.
A
G
A
Just
bringing
this
up
as
in
some
time
we're
gonna
have
to
development
on
this.
If
we're
going
to
have
it
as
a
mechanism
that
there
are
ways
out
of
this
as
well,
because
the
the
things
we
need
in
DP,
LPM
tud
could
be
exported
to
this
draft,
and
we
could
simply
refer
to
it
as
another
way
of
doing
it.
We
will.
G
M
M
I
cannot
find
any
reference
to
the
surplus
area
in
any
RFC,
so
I
do
not
believe
IETF
ever
reserved
that
area,
which
means
it
may
be
in
use
by
somebody
else
or
it
may
have
garbage,
but
I
I
can
not
deploy
this
on
the
internet
without
a
way
to
disambiguate.
Those
other
uses
from
this
use
so
I
think
that's
a
pretty
pretty
clear
requirement.
The
other
thing
I
didn't
mention
this
on
the
ok.
A
M
M
E
M
M
M
L
M
Is
referenced
in
the
draft
and
there's
a
concept
of
soft
state?
This
is
just
a
big
question
mark
for
me.
I,
don't
know
what
this
is.
If
I
was
implementing,
this
I
would
have
no
idea
how
to
do
a
robust
option,
negotiation,
nor
how
to
make
it
interoperable
so
either.
This
needs
to
be
fully
qualified
and
normative
language
or
to
somehow
be
taken
out.
But
if
it's
taken
out,
then
some
of
the
assumptions
like
what
to
do
with
unknown
options
really
really
should
be
changing.
M
So
this
is
trying
to
trying
to
straddle
the
world
between
stateless
options
like
we
have
an
ipv6
that
are
our
kind
of
item,
potent
versus
TCP
options
which
are
completely
negotiated.
So
somehow
it's
like
there's
an
in-between
here,
but
I'm
not
clear
what
that
in-between
is
or
if
it's,
even
if
it's
possible,
to
have
something.
That's
robust
in
between
those
two.
A
I
think,
let
me
not
ants
this
is
presentable.
Answer
this
as
a
chair
I
think
we
should
be
clear
on
what
that
means.
I
have
ideas
about
what
Tom
means
in
this
space
and
I
have
ideas
of
what
Joe
said
in
the
space,
but
the
draft
text
needs
to
reflect
that
in
a
way
that
other
people
understand
less.
B
A
B
A
B
A
G
A
I
think
you
could
have
a
third
controller
actually,
because
if
you
use
UDP
options
with
quick
and
path,
MTU
discovery
with
DF
underneath
you'd
have
three
ways
of
doing
them.
You
discover
at
the
same
time,
which
is
never
good
and
probably
isn't
good
for
security.
I'm.
Certainly
good,
isn't
good
for
performance.
B
B
G
G
A
E
D
First
of
all,
it's
both
under
control
at
the
endpoint
say,
if
you
should
hear
it
sudden,
the
foot,
it's
like
your
control
and
then
I
think
it
doesn't
matter.
It's
not
a
concern
for
this
document.
This
is
like
an
extension
to
UDP.
If
you
don't
want
to
use,
UDP
option
is
quick.
That's
a
recommendation.
You
should
give
in
the
quick
document.
A
G
N
All
right,
I'm,
Eric
near
Tommy
and
I
have
a
draft
out
for
using
http/2
as
a
transport
which
we've
discussed
a
little
bit
previously
in
HTTP
biz,
but
we
wanted
to
bring
here
as
well,
because
a
lot
of
it
is
using
HTTP
too,
but
as
a
transport
and
so
a
lot
of
the
kind
of
transport
properties
of
that
come
into
play.
So
I'm
going
to
kind
of
bump
briefly
through
the
how
we
do
it
and
what
we're
doing
so
that
we
can
talk
a
little
bit
more
at
the
end.
N
I've
got
some
questions
of
you
know
how
much
do
we
address
different
topics
and
different
potential
issues
and
kind
of
how
do
those
apply
so
in
terms
of
motivation,
we're
looking
to
have
a
generic
transport
for
secure,
arbitrary
byte
streams,
and
we
want
to
do
that
over
multiplex
streams
on
a
single
underlying
transport
connection.
There's
a
number
of
ways
to
do
that:
quicks
going
to
be
one
of
the
future
ways
to
do
that.
N
Some
of
the
benefits
we
get
from
that
are
the
low
set-up
cost
for
new
streams.
We
want
to
have
a
single
congestion
and
recovery
context,
so
if
we
know
that
we're
sending
multiple
streams
worth
of
data
to
the
same
peer,
if
we
can
share
a
congestion
context,
then
we
are
effectively.
You
know
using
that
link
to
its
its
best
ability
and
can
use
all
the
information
about
that
data
actually
getting
there.
N
We
also
want
to
be
able
to
use
this
for
peer
to
peer
communication,
and
this
is
where
we
start
to
do
things
that
aren't
as
traditional
in
HTTP
Lent,
where
we
want
the
server
to
be
able
to
open
a
stream
back
to
the
clients.
So
once
I've
got
this
tunnel
established,
I
want
to
be
able
to
make
a
new
bi-directional
byte
stream
in
either
direction
and
have
either
side
initiate
that
and
then
send
my
data
across
it.
N
So
this
is
kind
of
a
nice
to
have,
but
it
is
nice
to
have
a
situation
where
you
already
have
an
h2
connection
to
some
server,
because
you've
made
a
request
to
it
or
something
like
that
and
you're,
sending
normal
HTTP
to
streams
with
requests
and
responses
and,
at
the
same
time,
I'd
like
a
white
stream
to
that
server
to
send
other
data
with
its
own
framing
or
its
own
protocol.
I'd
like
to
have
that
share
the
same
underlying
transport
connection,
a
little
bit
on.
N
Why
we're
trying
to
do
this
within
HTTP
to
effectively
hb2
gives
us
a
really
nice
framing
layer
that
has
a
lot
of
transport
features
that
we're
looking
for.
We
have
a
configuration
exchange,
which
leads
us
to
a
very
nice
extension
mechanism,
which
is
how
we're
doing
this.
In
the
first
place,
it
gives
us
the
stream
multiplexing
it
gives
us
the
stream
state
machine
that
mirrors
other
byte
stream,
like
TCP
state
machines
fairly.
Well,
it's
pretty
easy
to
map
that
one
on
top
of
the
other.
We
get
that
shared
congestion
control.
N
We
get
that
shared
recovery
state.
We
get
flow
control,
so
we
can
have
per
stream
back
pressure.
We
get
stream
relationships
and
priorities,
which
is
something
that
you
don't
actually
get
if
you
just
open
up
a
bunch
of
TCP
connections
or
TLS
connections,
and
it's
also
kind
of
nice
because
it
traverses
the
internet
pretty
darn
well.
At
this
point,
a
lot
of
the
properties
that
we're
getting
here
in
terms
of
the
shared
congestion
control
and
the
shared
recovery
state
are
actually
coming
from
the
fact
that
h2
is
going
over
TLS
and
TCP.
N
N
Very
briefly,
just
the
mechanism
by
which
we
do
this,
which
is
not
necessarily
the
thing
we're
looking
to
discuss
the
most
right
now
and
there's
been
several
proposals
on
how
to
do
this.
Many
of
them
are
equally
good
right.
Now,
there's
a
connect
method
in
HTTP
that
lets
you
establish
a
new
connection
from
the
server
to
somewhere
else
and
tunnel.
N
N
What
you're
going
to
be
talking
on
it
and
and
to
make
sure
that
everybody's
coordinating
properly-
and
it
also
can
coexist,
really
nicely
with
existing
HTTP
request
and
response
streams,
so
you
can
be
making
requests
and
reuse
that
same
connection
that
you've
already
got
there.
You've
already
opened
up
the
congestion
window,
you're
already
having
a
very
nice
effective
conversation
with
somebody,
let's
reuse,
that
without
having
to
handshake
all
over
again
it's
for
somebody
new.
In
order
to
do
this.
N
The
actual
wire
format
of
the
framing
is
not
yet
in
the
draft
and
that's
come
up
on
the
list
as
well,
so
we
can
bike
shed
the
precise
format
that
gets
used
there
at
some
other
day,
but
effectively.
This
allows
you
to
say,
hey
on,
send
any
messages
that
I'd
like
to
come
out.
Delineate
it
on
the
other
side
or
I'm,
sending
you
a
stream
of
bytes,
which
you
can
feel
free
to
repackage.
N
However,
you
choose
as
long
as
it
maintains
its
order,
so
that
so
far,
just
by
adding
the
two
new
protocol
values
gets
us
most
of
what
we're
looking
for.
With
the
exception
of
this
piece
for
peer-to-peer
communication,
because
right
now,
the
server
is
unable
to
send
that
back
to
a
client-
and
this
is
like
I,
said
useful
for
remote
IPC.
If
you're
trying
to
talk
between
two
different
peers,
it
also
comes
in
a
little
bit
handy
for
quick.
N
So
quick
is
interesting
because,
unlike
you
should
be
too
quick,
splits
out
the
transport
layer
from
the
HCP
mapping
on
top
of
it-
and
this
effectively
brings
that
concept
back
into
htv-2.
So
if
I'm,
using
HTTP
3
and
that's
mapped
on
top
of
quick
and
I
discovered
that
I
can't
use
quick
on
some
network
or
it's
been
disabled,
I
need
something
to
fall
back
to
so.
N
N
So
we
take
our
existing
solution,
which
is
defining
the
Additional
Protocol
values
for
byte
stream
and
Datagram,
and
we
defined
a
new
setting
that
allows
us
to
negotiate
this
as
a
further
extension
on
top
of
HTTP.
That
says
yes,
I'm
willing
to
process
these
frames
in
a
direction
that
other
people
would
be
very
confused
by
and
allow
the
server
to
send
me
a
connect
request,
saying:
hey
I'd
like
to
open
a
stream
to
you
and
we've
gotten
a
couple.
N
What
we're
trying
to
do
here
to
kind
of
recap
why
we
actually
care
from
a
transport
perspective
is
if
we
can
share
multiple
connections
and
byte
streams
to
the
server,
if,
if
all
of
that
can
go
over
a
single
underlying
transport
that
helps
us
out
a
lot,
it
also
helps
if
we
need
to
be
proxying
UDP
traffic,
which
is
one
of
the
things
that's
come
up
through
some
of
the
helium
and
hint
stuff.
That
Lucas
has
been
doing,
as
we
start
trying
to
make
more
room
for
that.
N
This
gives
you
a
framing
layer,
and
this
gives
you
a
way
to
to
traverse
the
bits
of
the
network
where
you
previously
couldn't,
and
this
also
gives
you
kind
of
built-in
security
the
same
way
that
you
get
with
quick
transport
and
the
same
set
of
you
know
low-cost
set
up
for
new
streams
and
and
all
the
benefits
that
come
with
RT
having
a
relationship
established
with
the
server
and
existing
communication
flowing
between
you
and
them.
The
bi-directional
part
of
the
connect
handshake
lets.
N
So
the
big
questions
that
we
have
here
and
the
reason
why
we're
trying
to
talk
about
this
so
much
from
a
transport
perspective,
is,
as
you
start
to
do
this.
Some
of
your
assumptions
about
what
you're
provided
by
the
network
change
and
the
biggest
and
most
this
one's
here
are
things
like
now.
You
have
head-of-line
blocking
in
a
place
where
quick
transport
previously
didn't.
N
I
have
an
additional
items
bullet
here
as
a
there
are
probably
other
things
that
come
up.
I
know
we
have
a
draft
that
we
talked
about
previously
I,
think
in
Montreal
about
trans,
encapsulating
other
things
within
TCP
and
that
hit
upon
some
of
the
same
now.
Your
multiplexing,
multiple
flows
over
a
single
underlying
flow
here
are
some
of
the
concerns,
so
this
may
be
somewhat
of
an
extension
of
that
conversation.
N
We
also
had
a
bit
of
a
question
of
how
much
we
want
to
make
this
a
little
bit
more
generic
to
discuss
how
this
applies
to
many
other
multiplex
transports
like
SCTP,
etc.
How
much
do
you
reference
that
include
it
talk
about
it
as
a
brief
kind
of
strawman
proposal
for
how
you
handle
this
in
an
interaction
sense.
The
current
thinking
is
that
you
would
both
allow
introspection
or
discoverability
of
what
happened.
N
So
if
I
say
please
get
me
a
connection
to
this
other
place,
I
would
like
a
new
stream
there,
and
I
was
expecting
it
to
be
over
quick
transport,
but
now,
all
of
a
sudden,
it's
over
h2
transport,
I
suddenly
have
head-of-line
blocking
I
may
want
to
adjust
my
behavior
or
the
amount
that
I'm
I'm,
balancing
fairly
what
I
send
on
different
streams,
etc,
etc.
So
you
need
to
be
able
to
say:
hey
now
that
I've
connected
what
happened.
N
What
are
the
properties
of
the
transport
that
I'm
going
over
now
and
then
there's
an
entire
other
subclass
of
people
who
are
very
likely
to
want
a
stricter
mode
where
they
say,
prohibit
this
and
basically
I
I
cannot
handle
having
head-of-line
blocking
my
application.
I
would
rather
not
connect,
then
connect
and
experience
some
of
those
those
caveats.
So
you
that's
currently
kind
of
the
bimodal
approach
that
we're
taking.
But
that's
where
the
that's?
Where
the
questions
and
the
ask
for
a
discussion
comes
from.
N
O
G
David
black,
from
from
the
floor,
so
we
have
additional
on,
have
additional
item
for
you,
the
first
approximation.
What
I've
got
is
yet
another
way
of
tunneling
UDP
over
something
which
means
you
need
to
put
on
your
what
goes
wrong
with
tunnels
and
framing,
and
the
first
thing
that
goes
wrong.
Is
them
to
you.
So
please
think
through
MT
MT,
you
from
the
start,
if
you're
running
basically
you're
running
UDP
over
what
looks
like
a
very
funky
link,
that
link
has
an
MT.
G
You
see
the
ante
area
tunnels
drafts
for
a
lot
of
a
lot
of
useful
thinking,
not
all
of
which
will
be
applicable
because
there's
an
awful
lot
going
on
in
this
going
on
in
in
the
stack
under
you.
This
is
particularly
important
because,
if
you
make
this
work
sooner
or
later,
somebody's
going
to
figure
out
how
to
Gateway
this
into
actual
UDP
over
IP
from
the
far
side.
Yes,
that
is
a
very
good
point.
H
Spitzer
Dawkins
responsible
area
director
for
this
working
group
for
about
forty
five
more
minutes
so
I
I
think
I
just
want
to
follow
along
what
David
says
and
I
think
you
know
you're
you're,
definitely
pushing
and
on.
This
is
an
interesting
play
in
interesting
ways
and
I
think
you're
doing
it
leaves
some
of
that
conversation
in
the
right
place
here.
Thank
you
for
coming
here
and
bringing
it
I
think
I.
H
Challenge
accepted
over
here
with
my
left
so
like
I,
say
things
I.
Just
remember,
you
know
you're
looking
at
general-purpose
protocols,
you
really
don't
have
a
lot
of
control
over
where
people
might
use
them.
So
you
really
need
to
be
thinking
about
what
the
worst
thing
that
could
happen
in
all
of
our
collective
imaginations
as
you're
doing
that.
Yes,.
N
And,
and
especially
as
we
look
at
other
references
to
pull
in
and
and
some
of
the
existing
work,
there
is
I
think
you
mentioned
at
least
one
and
there's
a
couple
more
that
people
have
pointed
out
to
us
that
are
that
are
really
good
to
pull
in.
So
we
should
make
sure
that
we
at
least
reference
them
and
hopefully
pull
some
blob
of
text
to
say,
hey
like
if
you
think
you're
going
to
do
anything
in
this
area.
Make
sure
you
thought
about
this,
and
if
that
sounds
scary
to
you,
go
read
that.
I
So
tell
me
Paulie
as
a
author,
just
a
question
on
process
stuff,
because
I
know
we're
quite
out
of
time
here
when
we
originally
presented
this
to
HDTV
Biss.
They
said:
hey
cool,
that
you're
doing
this.
Please
take
it
over
a
transport
to
see
what
they
think
and
AD
sensor
here
agreed.
So
we've
done
that
here,
I
think,
there's
a
lot
of
good
advice
that
you're
bringing
up
I
think
these
are
things
that
would
need
to
be
incorporated
into
the
document.
I
guess
the
question
is:
does
this
go
back?
I
So
we
have
an
agenda
item
two
on
Thursday
talkback
page,
you
be
best
to
say
what
did
Transport
think
and
so
we'll
summarize
some
of
these
things.
What
do
we
want
to
do
as
far
as
moving
the
document
forward?
Is
this
something
that
we
just
do
an
HTTP
and
come
back
here
to
say?
Please
review
our
transport
bits
or
the
other
way
around?
Oh
yeah
I
would.
A
Like
to
go
on
this
one
because
I
don't
answer
the
question,
but
can
I
give
a
hint
at
the
answer
to
the
question
and
if
it
was
to
come
here,
we
would
want
to
talk
to
the
Intel
people
about
tunnels
and
the
usage
they
have
of
this.
But
we
would
like
to
do
the
scary
stuff
about
how
the
transport
functions
work.
It
sounds
like
that's
the
place
where
the
scariness
is,
but
the
clue
for
doing
this.
It
looks
like
a
synapse,
so
it's
gonna
fit
between
all
of
these
things.
A
I
have
no
problem
currently
as
a
working
group
chair
and
giving
you
time
here
to
discuss
this
and
I.
Think
this
place
is
the
right
place
to
discuss
some
of
these
issues
where
your
home
is
I
need
to
speak
to
somebody
with
the
relevant
colored
dot,
a
yellow
doctor
to
figure
out
who
actually
wants
to
take
home.
That
we've
worked
with
documents
that
go
across
areas
and
I'm
sure
that's
fine
I
do
think
the
transport
properties
and
the
transport
features
have
to
be
dealt
with
first.
A
H
Fading
mr.
Dawkins
again
and
I
mean
you
know
seriously,
you
know
what
we're
pretty
good
at
stuff
that
fits
in
one
area
and
cross
area
stuff
is.
It
is
a
challenge,
but
it's
one
of
the
things
that
separates
the
IETF
from
a
lot
of
other
SPOs.
A
lot
of
other
technical
organizations
so
making
this
work
well
will
be
a
challenge.
H
I
hate
to
be
the
one
to
echo
what
has
been
said
before,
but
it
will
be
a
challenge,
but
it's
really
important
and
I
think
this
was
actually
one
of
the
better
places
that
you
could
take
a
shot
at
that.
So
like
I
say
thank
you
for
bringing
it
here,
and
good
luck
and
I
will
help
as
much
as
I
can
help
about
dots.
P
B
G
And
what
I
was
going
to
save
something
along
the
lines
of
what
both
Spencer
and
gorya
said,
which
is
that
such
first
one,
like
my
reactors,
a
lot
of
the
draft
content
is
going
to
belong
in
HTTP
bits,
because
it's
going
to
be
highly
specific
to
exactly
how
we,
how
how
how
HTTP
2
is
being
used
to
carry
UDP
nonetheless,
are
crucial
technical
issues.
Here.
N
Of
the
things
that's
interesting
is
we
do
have
that
other
document
about
some
of
the
tunneling
and
the
other
concerns
there,
so
it
it
is
one
possible
way
to
take.
This
is
to
stick
the
H,
be
specific.
You
know
we're
updating
a
registry
that
already
exists
do
all
that
stuff
in
Asia,
P
biz
and
have
that
be
very
tightly
coupled
to
have
a
lot
of
the
considerations
in
there
just
because
you
don't
want
people
to
miss
it
if
they
read
the
main
document,
but
have
the
other
one.
N
G
A
G
E
E
The
first
challenge
is
that
if
the
same
data
data
was
retransmitted
multiple
times,
then
you
can
distinguish
between
those
retransmitted
data,
but
still
it
brings
you
some
some
possibility
to
at
least
detect
spurious
retransmissions
so
and
the
other
challenge
here
is
that
if
you
get
packet
which
includes
data's,
build
and
without
ER
bid,
it
brings
some
complexity
of
implementation,
because
then
you
need
to
send
back
to
acknowledgments
one
with
RB
them
develop
the
other
one
without
our
bid.
So
the
current
version
is
0
0
and
there
are
a
couple
of
DVDs.
E
The
main
TBD
is
state
recovery,
after
spirit
transmission
detection.
So
we
we
need
to
describe
it.
It's
implemented
in
Arizona
city
B,
but
only
enabled
between
Arizona
city
endpoints.
We
have
local
patch
of
Linux
City
beef,
very
simple
implementation
without
negotiation
just
started
some
fears
into
probability,
which
is
successful,
and
our
plan
is
to
to
work
on
tivities,
hello
so
and
continue
into
probability
with
Linux
SCTP,
and
we
encourage
encourage
people
to
click
back
on
this
draft.
And
if
we
don't
have
serious
objections,
negative
feedback
we
like
to
adopt
it
in
the
world
room
or.
A
Ever
slightly
higher
bar
I
think
I
want
to
see
if
it
actually
gives
a
benefit
to
enough
people
to
want
to
adopt
it
so
so,
and
the
and
I
would
like
to
see
some
performance
and
analysis
of
the
results
as
you
go
forward
and
we
can
make
help
that
to
inform
the
adoption,
yeah,
ok
and
any
languages.
Thank
you
for
presenting
any
questions.
I
really
think
the
question
is:
can
we
take
it
on
the
list,
we're
short
of
time
yeah?
Thank
you.
A
This
may
come
back
again,
but
please
read
it
on
the
list
and
please
comment
on
the
draft.
If
you're
interested
in
SCTP,
this
may
be
a
useful
feature
or
maybe
something
you
want
to
experiment
with,
or
maybe
something
you
don't
want,
but
please
discuss
on
the
list.
We
have
any
last
question
last
comment.