►
From YouTube: IETF92-TSVAREA-20150323-1520
Description
TSVAREA meeting session at IETF92
2015/03/23 1520
A
Yes,
sir,
but
like
do
you
want
I?
What
group
go
research
group
who
wanna
me
best?
Do
we
were
both
another
workshop?
Another
goal
was:
was
better
understanding
of
how
the
transport
shouldn't
must
evolve,
including
looking
at
the
applicability
of
present
tan
sport
statistic.
Use
cases
of
this
sort
of
was
an
overlap
with
the
temple
interface
improvement,
exposing
more
of
the
applications
about
protector
in
the
right
way
and
a
question
we
and
hard
and
then
and
then
shying
away
from
where
the
trust
issues
and
deployment
incentives
and
cooperation
evolution
approaches
right.
A
So
every
time
we've
tried
to
do
this
sort
of
signaling
tuna
path
or
from
the
path,
there's
always
been
the
questionable.
How
can
I
trust
what
is
said?
How
do
I
know
who
you
are?
How
do
I
know
that
the
signaling
has
not
been
modified
on
path
and
that
the
trust
issue
is
just
unless
you
have?
You
know
a
perfect
solution
to
the
keying
and
key
distribution
problem.
A
This
is
hard
and
if
you
have
a
perfect
solution
to
the
keying
and
keep
distribution
problem,
then
everything
is
easy.
So
one
of
the
things
we
talked
about
was
a
measurement.
So
the
measurement
fell
out
relatively
early
on
in
the
discussions.
We
didn't
spend
a
lot
of
time
actually
talking
about
measurement,
because
there
was
pretty
clear
agreement
in
the
room
as
to
what
the
next
steps
were
and
those
next
steps
were
more
or
less
the
Hoffs
barb
off
on
Sunday
night
and
we'll
talk
about
that
in
a
minute.
A
But
really
the
question
here
is
okay,
where
we're
making
engineering
decisions
about
the
evolution
of
the
protocol
stack,
and
these
are
based
on
not
a
whole
lot
of
data.
We
need
more
data
if
we're
making
an
argument
that
you'll
never
be
able
to
deploy
a
given
protocol
because
it
only
works
in
ninety
nine
point:
five
percent
of
the
internet-
you-
maybe
we
can
put
some
effort
into
engineering
around
that
problem
and
if
it
breaks
in
five
five
tenths
of
a
percent
of
the
internet.
A
How
much
of
the
complete
complexity
to
engineer
around
that
is
too
much.
So
there's
a
trade-off
here
and
Aaron
will
talk
more
about
the
hops
barb
off
and
the
outcomes
of
that
which
is
actually
the
most
productive.
I've
ever
been
on
a
sunday
night
at
nine-thirty
p.m.
after
four
beers
and
an
18-hour
day,
so
on
the
middle
box
cooperation
thing,
we
spent
a
great
deal
of
time
talking
about
this
and
sort
of
the
discussion
points.
The
major
discussion
points
pulled
into
sort
of
three
areas.
A
One
of
them
identified
that
essentially
we're
talking
when
we
talk
about
putting
packets
in
the
network
and
how
those
pockets
are
handled.
A
lot
of
these
contracts
are
implicit
right.
The
I'm
going
to
send
you
a
syn
packet
and
you're,
going
to
set
up
some
state
on
your
NAT,
and
the
next
snap
will
set
up
some
state
or,
and
then
a
syn
ACK
will
come
back
and
then
the
firewall
will
decide
that
the
far
point,
the
other
endpoint
has
decided
that
this
is
good
and
delegate
that
decision.
A
We
spent
a
lot
of
time
on
incentives
as
well
its
weak.
It
does
it's
great
to
define
a
new
signaling
protocol,
it's
great
to
say,
okay.
Well,
we
have
this
engineering
solution
of
this
problem,
but
if
there's
no
incentive
for
anybody
to
deploy
it
and
those
incentives
have
to
be
incremental
right.
So
if
we
come
up
with
a
new
signaling
protocol
don't
day
one,
the
only
thing
that's
going
to
talk
that
new
signaling
protocol
or
the
first
two
boxes
in
your
test
lab.
A
B
This
this
thing
about
TLS
being
a
something
that
weaponized
is
it
it
doesn't
because
it
doesn't
do
anything
about
the
transvaal
Heather's
weight
is
inside
the
transporters.
I
think
the
hope
at
the
time
was
that
something
like
TC
being
may
cover
the
transport
editor,
and
it's
decided
not
to
do
that.
So.
A
B
A
So
this
is
we're
talking
about
the
the
encapsulation
for
path.
Exposure
in
userspace
transports,
that'll
be
spud
or
substrate
protocol
for
user
data
grams
90
on
Wednesday
in
the
international
room
which
I
just
looked
on
the
map,
and
it
turns
out
that's
the
plenary
room
so
thereby
we
have
like
400
seats,
so
come
early
vote,
often
so
the
general
architecture
here
is
you
have
you
know
what
it
looks
like
to
the
application?
A
Is
you
have
the
initiator,
the
responder
there's
a
bunch
of
stuff
in
the
middle
that
the
application
developers
can't
deal
with
and
then
from
the
the
application
developer
standpoint
you
have
the
user
data,
the
things
that
are
just
the
app.
This
is
none
of
the
past
business.
These
would
also
be
application
headers
if
you're
running
HTTP
here,
the
HTTP
headers
would
be
up
in
this
app
area.
Transport
prime
is,
and
these
slides
are
from
from
Joe
who
has
a
very
apps
view
of
this
stuff.
The
Falcon
Sivan
ensures
the
network
doesn't
run
down
right.
A
A
So
the
generic
I
mechanism
that
we've
come
up
with
in
the
spud
boff
will
actually
talk
about
a
prototype
that
I
don't
want
to
promise
too
much.
But
there
are
a
bunch
of
people
hacking
on
at
the
hackathon
I,
don't
want
to
say
running
code
at
the
ball,
because
that
will
jinx
it,
but
in
the
in
the
prototype
we
have
right
now.
Basically,
we
have
so
a
tube
identifier,
and
a
tube
is
just
a
set
of
packets
and
the
set
of
packets
could
be
a
flow.
They
could
be
something
like
an
sctp
stream.
A
A
There's
an
in-band
channel
with
an
extensible
syntax
that
allows
you
to
take
these
properties
and
bind
them
either
to
the
packet
or
to
the
tube
on
path.
Devices
can
single
back
to
either
end
point
using
the
same
in
band
channel,
and
we've
got
a
couple
of
drafts
on
this
that
describe.
First
of
all
the
instance.
The
generic
mechanism
for
experimentation
is
the
prototype,
that's
draft
Hildebrand's
bud
prototype
and
then
some
generic
constraints
for
signaling
over
UDP
based
encapsulations,
is
in
draft
trammell
stack,
evo,
new
t
for
a
new
transport
encapsulation.
A
The
aether
is
not
for
architecture,
but
I
forget
what
it
is
and
there
we
want
to
spend
a
lot
of
time
talking
about
the
vocabulary
right.
So
if
we
build
a
generic
signaling
mechanism,
the
success
or
failure
of
a
generic
signaling
mechanism
is
going
to
is
going
to
come
from
what
you
can
say
what
you
should
say
what
you
must
say
with
it.
So
when
looking
at
this,
there
need
to
be
incentives
to
expose
information.
The
application
has
to
potentially
get
something
by
saying
something.
A
C
A
And
then,
in
the
workshop,
we
split
this
sort
of
into
two
areas:
there's
a
the
app
to
path
area.
So
when
the
application
is
telling
the
path
things
the
path
to
app
area-
and
we
came
pretty
quickly
to
a
determination
that
that
the
app
to
path
thing
looks
tractable,
wait,
there's
probably
a
minimal
set
of
useful
information
things
like
session
lifetime.
Things
like
this
is
my
first
packet.
This
is
my
last
packet,
where
you
can
actually
get
some
benefit
by
signaling
it
by
where
you
can
take.
A
Essentially
the
transport
headers,
which
are
now
up
in
here
inside
inside
spud
inside
the
the
crypto
on
your
mobiles,
can't
see
your
sea
legs.
They
can't
see
your
fin
flags,
they
can
see
on
the
start
and
stop
chunks.
They
can't
see
you
need
a
signaling
for
the
transfer
protocol,
but
basic
signaling
for
session
lifetime,
so
that
you
can
actually
setup
and
teardown
state
explicitly
on
these
on
path
devices.
That
seems
that
seems
pretty
useful
and
like
it
can.
It
can
be
done,
and
this
information
is
also
useful
to
the
far
end
point.
A
There
are
a
few
other
potential
use
cases
that
will
get
into
at
this
bud
Bob
on
the
path
to
outside
the
way
forwards.
A
little
bit
less
clear
problem
might
be
tracked.
All
it's
basically
like
ICMP
I
would
be
like
in
band
ICMP
if
we
traded
as
advisory,
but
the
trust
issues
kind
of
make
the
path
signaling
to
the
app
things
that
are
mandatory
very
very
hard
to
deal
with.
So
we
might
come
back
to
that.
But
the
way
forward
on
that
really
is
much
less
clear.
A
B
B
So
things
like
watching
your
logs
to
see
whether
you're
stripping,
not
is
you
know,
getting
new
functions
that
you're
stripping
off
and
things
like
that
and
a
set
of
functions
so
I'd,
quite
like
I've,
encouraged
them
to
come
here
with
liaison
to
check
that
that
all
seems
reasonable
from
their
point
of
view.
But
I
think
it's
quite
nice
that
they're
writing
that,
because
it's
the
people
who
write
the
middle
boxes,
who
are
writing
their
own
rules,
which
you
know.
A
You
getting
in
line
for
a
point
for
here
David
yeah,
so
one
of
the
other
things
good
to
do
is
discussion
on
transport,
extensibility
and
area
meeting.
So
basically,
when
we're
moving
forward
on
this
just
sort
of
how,
once
we
have
something
more
concrete
like
basically
taking
this
out,
not
just
a
tsv
area,
but
also
to
apps
area,
since
it's
that
you
know
there
that
the
clients
at
this
there's
another
work
item
on
UDP
transport,
encapsulation
guidelines
David
as
one.
D
Of
the
recipient,
but
because
when
we
sit
pins
of
the
fines
of
the
scars
on
this
one
TS,
u
WG
is
working
this
one.
The
carriers
for
this
right
now
are
there's
a
GRE
and
UDP
draft
that
we're
going
to
talk
about
and,
more
importantly,
the
UDP
guidelines,
RFC
5405,
there's
a
four
or
five,
this
draft,
it
its
inner
vision,
the
extent
we've
got
anything
anything
new
and
gentle
say
that's
going
to
be
the
carrier
for
that.
So
please
come
to
us
p,
WG!
If
you
care
about
this.
Thank
you
cool.
A
And
then
another
identified
output
was
a
probable
IAB
statement
on
architectural
assumptions
and
transport
evolution.
This
has
been
referred
back
to
the
stack
evolution
program,
but
you
can
expect
something
to
come
out
of
the
IAB
soon
on
that.
So
further
discussions
of
these
points,
we
have
a
bunch
of
lists
join
the
lists
which
interests
you
so
the
middle
box
measurement
issues,
the
hops
off.
That
list
is
up
the
hops
at
I,
ATF,
org
and
Aaron
will
talk
about
that
a
bit
more.
A
So
if
you're
interested
in
spud
come
to
the
spud
Boff
and
join
the
spud
at
IETF
torg,
the
transport
services
working
group
is
working
on
a
lot
of
sort
of
a
side
issues
here
and
the
issues
with
the
application
interfaces
that
taps
at
I-80
org,
and
you
just
missed
it.
Sorry
I'm,
assuming
that
many
of
you
were
actually
in
there
and
other
future
work
is
in,
is
handled
by
the
stacking
program.
You
can
mail,
it
said
stack
evo
at
IEP
Doug,
so
questions.
E
Say
yes,
John's
a
hourglass
there's
we
had
this
whole
discussion
in
taps
about
real-time
apps
in
RTP
yep,
and
so
it
wasn't
really
explicitly
represented
I'm
wondering
whether
spewed
and
I
was
told
that
that's
what
how
it
was
pronounced.
So
whether
spewed
is
actually
what
the
the
RTP
Cabal
has.
It
was
aware
of
this.
If
there's
any
big
concerns
or
your
cobalt
rights
to
you
threw
the
ball.
C
F
F
A
F
Have
read
the
draft?
I
think
I
read
a
lot
of
drugs.
I
mean
I
think
we
have
developed
its.
You
know.
Any
God
CP
has
some
different
requirements
because,
because
that
there
there's
a
lot
of
interest
in
middle
boxes
which
actually
do
processing
and
a
part
of
the
trust
domain,
yep
in
RTP,
so
I
think
it.
It
has
slightly
different
set
of
requirements,
yeah
some
applications,
and
that
I
think,
means
that
spud
perhaps
doesn't
work
particularly
well
for
a
lot
of
us
locations.
A
F
B
Just
do
people
have
got
to
do
two
things.
That's
the
important
point
that
needs
to
be
got
over
and
I'm
looking
at
an
inn.
Ttp,
it's
going
to
have
to
be
different
but
I'm
looking
at
using
what
are
currently
the
TTP
options
to
talk
with
middleboxes
because
they're,
the
ones
that
mess
with
them
anyway
and
then
putting
the
other
TTP
options
inside
the
tcp
data
that
you
don't
want
to
be
messed
with.
And
so
that's
thing
called
in
a
space.
B
A
A
that's
a
good
point
yeah,
because
it
would
so
one
bit
of
hallway
conversation
data
that
I'm,
not
sure
I
can
quote,
but
the
numbers
that
were
quoted
in
terms
of
UDP
connectivity
is
so
ninety
percent
of
the
time
between
clients
and
servers.
You
can
get
you
TV
package
through
both
ways
right,
which
is,
and
it
works
most
of
the
time
sort
of
thing,
but
ninety
percent
is
not
good
enough
for
for
relying
on
it
without
having
fall
back.
C
C
C
A
G
A
D
C
A
So
this
is
something
that,
when
we
get
it
down
into
when
we
get
down
into
the
details,
the
discussion,
the
scope
of
the
identifier,
is
one
of
those
things
that
we
need
to
evaluate.
The
trade-offs
on
and
applicability
to
multicast
use
case
is
one
of
the
big
inputs
to
that
trade-off.
Discussion.
Okay,.
C
B
A
point
to
make
this
isn't
about
spot,
but
Bruce
Cogan
yeah,
and
that
is
the
the
point
about
when
ttp
decided
not
to
make
the
headers
or
mess
with
the
transport
headers.
That
sort
of
we
need
to
really
double
take
what
that
means,
because
we
made
the
decision
that
the
semi
workshop
that
we
were
there
was
the
possibility
of
middle
box
vendors
being
interested
in
talking
to
us
again
because
of
encryption,
and
now
they
won't
be
because
encryption
is
not
going
to
affect
them.
B
E
Hello
case,
you
show
hands
to
the
folks
who
were
at
the
hops
barb
off
on
Sunday,
okay,
so
most
of
you
actually
were
there
and
so
I,
don't
need
to
say
too
much
and
I
don't
have
slides.
So
what
I'm
showing
here
are
my
notes,
which
I'm
just
going
to
use
to
remind
me.
So
I
don't
miss
any
important
points.
E
So,
as
Brian
yeah
put
the
barb
off
in
good
context,
the
idea
is,
we
really
need
some
countries
about
what
little
boxes
are
doing,
that
there's
a
lot
of
different
kind
of
networks
and
different
kinds
of
little
boxes
and
they
interfere
with
protocols
in
a
variety
of
ways
and
there's
the
there's
not
a
whole
lot
of
measurement
of
how
they
interact
with
transport
protocols.
There's
a
few
papers
out
which
we
spend
some
time
talking
about,
but
the
idea
here
was
to.
E
The
proposal
that
we
tried
the
barb
off
was
was
to
instrument
some
browsers
on
fixed
and
mobile
end
systems,
to
make
active
measurements,
to
see
what
works
and
doesn't
work
and
then
across
the
internet,
from
a
variety
of
networks.
Cellular
Wi-Fi,
enterprise,
University,
hello,
fixed
residential
broadband.
That
sort
of
thing
the
discussion
sort
of
ranged
from
there
that
was
sort
of
what
I
put
on
the
table
was.
E
And
then,
as
we
start
to
talk
about
active
collection.
Well,
of
course,
that
takes
more
work.
Not
only
do
you
have
to
you
have
to
write
the
code.
Sometimes
you
have
to
you
need
both
ends
and
then,
once
you
start
to
cook,
you
know
collecting
this
data.
As
with
the
passive
data,
there
are
privacy
issues,
and
so
it's
important
to
sort
of
understand
the
risk
versus
reward
for
that.
But
there
was
a.
There
was
a
lot
of
interest
in
understanding
that
and
I
think
those
general
agreement
that
passive
data
is
only
going
to
help.
E
You
answer
some
questions.
Localization,
you
know
one
of
the
ideas
was
like.
Well,
if
you
start
making
lots
of
these
measurements
from
all
over
the
internet,
now
you
can
start
to
say
well,
gee.
You
know
these
networks
are
really
screwing
up
the
ability
to
play
new
transfer
protocols,
and
maybe
you
know,
shame
them
into
improving
the
middle
box.
Behavior.
E
Surprisingly,
it
was
a
network
operator
there
who
said
gee
I,
don't
really
know
how
well.
This
is
working
in
my
network
and
would
be
nice
to
have
a
toolkit
of
some
sort,
so
I
can
understand,
what's
broken
and
so
that
I
can
work
with
my
vendors
to
get
it
fixed,
and
then
you
can
go
from
there
to
maybe
having
a
general
toolkit
that
the
vendors
would
use,
and
so
you
know
a
lot
of
places
where
just
being
able
to
identify.
You
know
what
you
can
start
to
quantify.
E
What
kinds
of
what
kind
of
behavior
you
want
now
people
can
understand
whether
they
they're
able
to
provide
it
or
not.
As
we're
talking
about
the
privacy
issues
that
the
point
came
out,
that
aggregated
statistics
are
still
useful
to
under
stand.
How
prevalent
certain
kinds
of
bad
behavior
is
will
allow
you
to
make
some
trade-offs
as
you're
looking
at
sort
of
the
the
cost
benefit
of
doing
different
kinds
of
of
engineering,
and
so
that
seems
like
something
that
might
help
us
work
around
some
of
the
privacy
issues.
E
There's
a
some
folks
from
ripe
Atlas
were
there
who
talked
about
some
test
infrastructure
that
they
had
that's
a
widespread.
That
is
it.
This
is
a
way
of
doing
active
measurements
from
nodes
in
the
middle
of
the
network,
which
allows
you
to
make
a
certain
class
of
measurements.
It
doesn't
cover
everything
because,
based
on
some
of
the
research,
that's
been
done
so
far.
E
And
there
was
some
discussion
about
you
know:
what
are
we
shared?
We
share
descriptions
of
what
measurements
to
make
do
we
share
the
data
I
think
there's
a
lot
of
interest
in
in
all
the
above
and
I
think
that
was
a
little
early
to
talk
about
that
until
we
can
get
some
more
the
concrete
of
what's
available
and
what
are
we
going
to
do
and
then,
just
as
an
aside,
there
was
some
discussion
about
doing
a
fuzz
testing
where
you
sort
of
sin.
E
You
know
all
possible
permutations
of
values
and
packets
and
see
what
gets
ruin
what
doesn
and
that
was
I-
think
there
was
a
pretty
strong
consensus
that
that,
because
of
a
state
of
the
stuff
in
all
the
network
and
that
in
the
size
of
the
state
space,
that's
not
going
to
necessarily
give
you
a
very
good
return
for
the
amount
of
effort,
little
T.
So
that's
sort
of
that
a
short
summary
there's,
an
engelist
tops
at
ITF,
org
and
right
now.
E
D
Okay,
so
I'm
david
black,
I'm
not
quite
sure
how
it
is.
I
got
to
be
standing
up
here.
They
behave
ii
said
gee
you're
working
on
some
things.
I
seen
if
something
to
do
each
other.
We
found
a
common
theme
here.
Why
don't
you
explain
to
everybody
and
look?
Maybe
they'll
have
some
idea
about
what
else
ought
to
be
done?
So
common
thing
is
diffserv,
curious
and
browsers
and
really
starts
from.
Is
it's
not
your
father's
browser
or
your
mother's
browser
browsers,
have
turned
into
web
application
frameworks.
D
The
application
ones
in
the
browser
example
is
javascript.
People
are
writing
rather
fancy
applications
in
javascript
or
web
applications
run
at
the
same
time
they
separated
by
this
concept
of
web
origin
or
they're
supposed
to
be
seated
RFC,
but
this
is
a
fancy
name
for
for
for
the
URI
scheme,
the
host
and
the
pork
which
is
optional
and
that
combo
is
a
web
origin
browsers
are
supposed
to
separate
a
lot
of
those
lines
of
the
good
pub
the
ones
in
common
use
generally
get
Jenny
got
this
right,
so
we
get
to
web
application.
D
Networking
cure
West
you've
got
these
applications
running
in
the
browser.
They'd
like
to
have
a
differentiate
service
from
the
network.
Different
qos
by
application,
more
important
for
flows
within
an
application
and
WebRTC
is
a
great
example,
and
it's
not
that
simple,
so
I
want
to
talk
about
this.
But
first
let
me
start
new
option
brought
to
you
by
the
afternoon
police,
specifically
diffserv
branch.
D
This
space
is
for
acronyms
these
online
dscp
differentiated
services
code.
Point
that's
sitting
in
the
IP
header
to
request
Network
us
PHP.
We
call
the
Pearl
hot
behavior.
This
is
what
the
network
does,
which
sees
dscp
the
SCP
preparing
mapping
is
network
specific.
Now
you
start
to
see
why
this
gets
just
a
little
bit.
Interesting
CS
stands
for
class
selector.
This
is
sort
of
specific
CPS
that
were
which
select
the
selected
to
carry
the
former
IP
precedence
concept
for
words
of
caco-2
cs7.
You
typically
see
routing
traffic
or
running
running
at
cs6.
D
In
order
to
your
priority,
when
things
when
you're
going
gets
rough,
cs1
is
intended
for
lower
than
best
effort
servers,
so
they're,
not
linear
cs1
is
supposed
to
be
lower
than
CSU,
as
opposed
to
be
between
zero
and
two
more
on
that
in
a
few
slides.
Okay,
so
back
to
this
server
and
web
RTC,
WebRTC
means
web
real-time
conferencing,
audio
video
data
between
browsers,
ok,
the
first.
D
It's
not
that
simple,
as
natural
versal
has
to
work
every
single
one
of
those
home
router
box
and
put
router
in
quotes,
who
don't
have
to
argue
about
what
it
really
means
has
a
nap.
It's
doing.
Poor
translation
you're
going
to
get
one
IP
address
phone
from
your
isp
if
you're
lucky,
if
you're,
not
there's
more
Nats
upstream
and
you're,
going
to
spread
it
out,
so
natural
versal
has
to
work
NAT
reversal.
When
it
comes
down
to
is
about,
pin
hole,
punching
and
maintenance,
you
need
to
punch
a
pin
hole
for
every
local
port.
D
That's
in
use
that
you
intend
to
run
through
to
run
for
the
net,
so
traffic
and
get
if
you
get
back
to
it
and
well
pin
hole
punching
maintenance.
Your
pin
holes
means
less
work
open
your
mobile
bus,
okay,
sowing
oats
are
all
traffic
over
the
same
port.
Maybe
one
port,
UDP
encapsulation
is
preferred
for
this
see.
The
comment
I
made
in
the
middle
brian's
talk.
Okay,
so
we're
gonna
take
everything
we
take
this
entire
set
of
audio
video
data,
oh
by
the
way,
probably
doing
a
bulk
transfer.
D
D
What
I
say
the
result
was
this
was
a
draft
written
was
written
answers.
Question
of
the
I'll.
Show
you
the
draft
round
in
this
this.
This
led
to
the
dart
draft
on
our
youth
DCPS,
with
with
RTP
and
other
protocols.
In
essence,
the
dart
draft
set
up
to
answer
following
question:
where
is
it
okay
to
vary
QRS
15
triple
here
we're
talking
about
two
IP
addresses
protocol
to
UDP
ports?
D
That's
how
we
can't
divide
it
be
to
tcp
or
to
other
ports,
would
be
that
the
EDP
ones
or
the
really
interesting
ones
here
answer
only
when
the
transporters
UDP,
but
even
then
only
with
care.
It's
easy
to
get
wrong
network
made
more
or
remove
curious
differentiation
more
on
that
on
the
next
slide.
We
do
all
kinds
of
curious
things
in
the
network.
The
piece
advice
don't
very
curious,
dscp
or
phb
for
tcp
sctp
or
DC
CP,
and
the
reason
is
one.
When
you
first
thing,
you
start
sub
varying
things.
D
You
think,
if
you
think
about
prioritization,
you
think
about
different
cues
in
the
network.
Nodes
results,
traffic,
reordering
protocols
that
are
trying
to
do
congestion
response.
Have
this
nasty
habit
of
misinterpreting
reordering
as
drops
of
the
out
of
order,
packets
and
doing
a
congestion
response
that
you
didn't
want
the
other?
Let
me
get
down
to
local
drop
Preston's,
which
is
what,
if
we
vary,
drop
precedents
within
a
PHP
class
I've
one
session
I
want
multiply
three
drop
levels.
The
answer
for
the
reliable
protocols
is
for
TCP,
nothing
usual
happens
when
you
get
a
drop.
D
Tcp
does
no
delivery
until
it's
gotten
that
gut
gotten
that
packet
back.
There's
no
point
for
the
other
two.
We
don't
have
good
operational
experience.
We
just
don't
have
a
sufficient
understanding
of
what's
going
on,
and
so
the
draft
recommends
not
doing
this.
Okay.
So
that's
an
introduction
to
this
gallery
of
cars.
What
can
go
wrong
if
you
start
varying
curation
of
five
tools?
D
I've
got
this
UDP
52
/
/
UDP
I'm
running
sctp
for
my
gated
channel
I've
got
a
couple
video
channels
going
a
voice
channel
I
want
to
go
prioritize
things
when
going
itself.
My
voice
gets
through
first
well
network.
We
manage
coast
by
the
entire
five
tuple,
not
the
dscp
within
it.
So
entire
are
your
entire
web.
Rtc
session
male
and
one
router
q,
okay,
nope
nice,
a
core
networks
may
limit
curse.
Differentiation
been
working,
among
other
things,
with
some
carriers
on
what
happens
inside
the
core
networks.
D
If
they
do
this
differentiation,
all
three
to
four
classes
are
coming.
It's
very
easy
to
come
up
with
a
web
RTC
application
which
people
would
like
about
it
doesn't.
On
the
other
hand,
most
purest
problems
occur
in
the
edge
and
access
area
and
want
costs
a
word
in
sideways
here
for
a
possible
answer.
One
of
the
questions
that
Brian
was
asking:
what
is
it
useful
for
the
path
to
signal
back
to
the
application?
And
what
might
it
say?
Well,
it
turns
out.
D
Most
of
us
problems
occur
in
getting
from
the
end
node
to
the
first
know,
that's
really
hitting
the
core
cuz,
that's
where
all
the
Wi-Fi
and
the
cellular
and
the
bedding
that
home
routers
are,
and
if
we
could
just
get
get
you
straightened
out.
There
we'd
make
some
progress,
so
it
might
be.
That's
signaling
from
a
node,
that's
early
in
the
towards
the
internet
core,
but
beyond,
all
this
edge
stuff
back
to
the
application
about.
D
What's
actually
going
on
right
now
could
be
quite
useful
if
there's
a
term
server
involved
and
for
WebRTC
the
general
there
they're
often
will
be.
That
could
be
a
possible
possible
place
to
locate
that
stuff.
Ok
onward
network
may
review
remove
cures
differentiation.
It
is
very
common
to
remark,
I
think
what
I
think
it's
now
being
called
bleaching
to
CS
0
ye
best
effort
at
Network
boundaries
and
just
a
few
fleeting
thought
you
had
it
all
figured
out.
D
I
said
earlier:
where
do
net
rehearsal
because
it
turns
out,
we
have
gnats
at
both
ends
for
WebRTC.
You
need
a
middle
point
to
sort
out
the
who
goes
first
problem
in
punching
the
pin
holes.
That's
a
turn
server
and
turn.
Has
this
interesting
feature
that
may
decide
that
that
make
your
way
of
a
TCP,
sorry
at
which
point
forget
it
more
different,
nope,
no
difference,
you're
curious
for
you!
Next
lowly
best
efforts
is
a
crapshoot
UCS
one,
it
might
work
it
might
not.
Good
luck
is
cs1.
D
D
D
H
D
What
to
do
this
here?
Seven
foot,
some
some
initial
things.
First
of
all,
insulate
the
web
application
that
work
by
the
browser,
api,
okay,
credit
to
all
the
web,
RTC
folks,
I
did
this,
it's
a
good
start.
That's
also
the
point:
the
punch
line
toward
pilot
dead
lawyer
jokes,
because
the
there's
no
interface
to
ask
what
services
are
ye
page
views
are
available,
so
the
net
is
you've
got
this
api
which
you
could
set
this.
You
accept
these
values
that
translate
twister
to
request
for
service
and
the
browser's
note
services
are
available
net.
D
Is
that
if
you
set
the
dscp
on
private
leaving
a
browser,
it's
set
and
pray?
You
don't
know,
what's
going
to
happen,
there's
no
good
way
to
tell
you
what's
going
to
do
next,
good
question:
how
many
curious
service
levels
well,
depending
on
which
said
network
operators
on
talking
to
I
get
different
answers.
On
the
one
hand,
there's
some
fairly
rich
enterprise
networks
that
can
ease
four
dozen
service
levels,
I
other
hand,
I
talked
to
call
carriers
who
say
34,
no
more,
please,
that's!
D
That's
all
going
to
employers
in
particular
turns
out
to
be
a
very
strong
in
strong
influence
here,
because
the
curious
is
carried
is
carried
down
in
the
TC
field
inside
the
MPLS
label.
Current
web
kill
web
RTC
Chris
Wragge
uses
a
lot
of
levels.
The
goal
is
there
is
to
try
to
get
some
differentiation
least
at
the
sending
edge
open
issue
there.
D
Tbd
also,
given
that
one
first
light
loading
best
effort
by
diffserv
is
a
crapshoot
should,
at
the
very
least,
don't
try
for
lower
than
best
effort
service
unless
it
is
completely
okay,
they
have
all
that
what
you
photos
background
traffic
carried
as
best
effort.
If
that's
not
true,
you're
taking
a
risk,
the
network
is
not
going
to
help
you
and
then
just
if
you
want
to
explore
further
here
are
three
relevant
drafts.
G
G
D
Going
to
tell
you
that
web
RTC
got
this
right.
The
interface
that
WebRTC
application
uses
has
no
concert
dhcp.
It
has
a
motion
of
the
class
or
traffic
it's
sending
and
the
level
of
service
it
would
like
for
that
class
of
traffic.
The
browser
framework
is
then
responsible
for
mapping
that
interface
on
to
the
dhcp,
hopefully
with
some
knowledge
of
what
PHP's
are
available,
the
backs
of
festivus
pole
up
here,
the
web
RTC
got
it
right
there.
How
are
some
problems
are
trying
to
pull
the
browser
framework
because
you
know,
what's
out
there,
yeah.
G
D
Like
us,
you
offer
because
your
mix
bony
issue
that
is
answered
in
detail
in
the
dark.
Let
me
tell
you
to
go,
please
go
read,
please
go
read
the
dark
draft
I
had
extensive
conversations
with
the
sctp
community.
This
is
atf
rough
consensus,
which
is
doable
HTTP
when
some
major
experience
with.
What's
actually
that
happen,
how
it's
actually
work
apologize
for,
loving
you,
but
I've
got
the
scars.
I
was
rich,
I
would
even
with
lightweight
eyes
about
when
you
were
about
six.
Let's
go
home
come
on,
we
kind
of
be
able
to
do
HTTP
street.
D
G
Got
me
wrong,
though:
okay
I
didn't
say
them
I'll
be
streaming.
I
said
multihoming.
That
is
experience
that
we
have
with
using
multiple
network
interfaces
inside
of
one
HTTP
connection.
Each
network
interface
is
a
separate
condition,
control
context.
You
can
have
a
whole
bunch
of
sctp
streams,
mapped
into
one
congestion
control
context
there,
but
more
than
trying
to
make
here
is
that
an
application
doesn't
necessarily
know
exactly
how
it
is
getting
mapped
onto
conditional
total
contexts.
D
In
seeing
details
of
how
this
works
out,
the
conclusion
we
did
work
in
the
dart
draft
is
there's
some
tension
for
that
that
the
estimates
that
there
is
potential,
particularly
for
the
local
drop
whoops
they're,
cheap
ticket
move,
will
drop
precedence
and
this
may
fall
in
the
same
category,
but
there
was
no
native
any
operational
experience,
and
least
when
were
working
the
dart
draft.
The
answer
was
for
for
the
phb
selections
for
drop
precedence,
lack
of
operation
experience
suggested,
let's
make
sure
we
notice
works
first,
I.
G
That
may
have
been
from
multi
streaming
and
I'm
having
talked
off
later
on
about
multihoming,
but
I.
Think
my
hair,
or
the
point
was-
was
that
the
congestion
controller
ought
to
be
responsible
for
how
da
CD
bits
are
set
wherever
there
is
one
condition:
control
context:
it's
okay
to
have
one
dscp
core
point,
and
the
reason
is
because
a
congestion
controllers
is
trying
to
determine
characteristics
of
the
path
and
new
dact
code.
Point
results,
potentially
in
a
different
path,
and
by
now
I
thought
I
mean
different
properties
of
the
but
I'm.
D
I
Or
a
bless
Katie.
Can
you
please
our
move
forward?
One
slide
yeah
that
the
fact
that
lower
effort
is
more
or
less
random.
Outputs
right
is
it's
not
a
property
of
the
service
itself?
It's
just
a
matter
of
that.
The
dscp
to
PHP
mapping
is
very
yeah,
I
mean
it's
just
a
recommendation
in
the
RSC
in
the
original,
our
CEO
of
for
lower
effort
and
so
I
guess.
I
This
is
an
outcome
of
the
flexibility
of
the
deserve
architecture
that
you
can
have
various
methods
from
DSC,
p2p,
HP's
and
every
provider
can
do
it
in
their
own
way
and
I
guess
the
maybe
the
interconnection
draft
of
rüdiger
is
some
some
way
of
moving
forward.
Having
common,
let's
say:
recommendation
for
a
DCP
to
PHP
mappings.
That
would.
D
Be
the
third
draft
here
I'm
actually
a
co-author
on
that
one
hoping
we
move
forward.
However,
lower
effort
is
not
one
of
the
other
traffic
classes
that
the
draft
is
addressing
and
the
rest
of
comments
about
a
diff
server-based,
a
basic
mark.
They
happen
to
be
worse
for
a
lower
effort
than
some
of
the
other
PHP's,
but
I.
I
C
C
C
Of
that's
a
lot
of
a
quick
command
about
this
lower
than
best
effort
thing,
I.
Think
the
congestion
control
mechanisms
that
are
done
in
RM
cut
now
they're
all
delay
based
changing
them
to
be
lower
than
best
effort,
will
be
a
super,
simple
change,
I
think
I
think
it's
just
because
it's
hard
to
make
them
not
best
effort
I
mean
not
lower
than
best
effort.
So,
if
you
just
remove
some
of
this
extra
becomes
a
lower
than
best
effort
scheme,
you
have
it.
It's
very
easy.
C
Injure
McRae
yeah.
I
agree
that
that's
not
doing
lower
than
be
sniffing
directly
via
deficit.
The
real
thing
that
makes
it
a
crapshoot
is
that
there
are
very
widely
deployed
systems
like
a
large
fraction
of
the
world's
home
routers
that
do
have
that
inversion
that
treats
cs1
as
higher
than
best
effort
priority
and
that's
an
unfortunate
bug.
But
it's
so
widely
deployed.
It's
the
deployed
state
of
the
internet.
I
E
C
One
more
comment:
I
mean
this
X
relates
to
this
magnet
rest
Linkin
about
WebRTC,
and
this
part
ization
I
mean
WebRTC,
is
not
only
applying
diffserv
level
practice
ation.
It's
also
including
scheduling
prioritization
on
the
outcome
stream
so
and
that's
I,
think
worth
noting.
So
you
actually
get
something
from
the
congestion
control
and
the
scheduling
for
transmissions.
C
H
So,
for
the
rest
of
our
time
together
here,
you
know:
I
wanted
to
have
a
short
heads-up
about
some
of
the
discussions
that
we're
having
on
the
isg,
but
that
are
relevant
to
TSP.
Not
most
of
them
are
not
so
psv
specific.
Some
of
them
are,
if
you've
heard,
if
you've
noticed
anything
about
changes
to
the
area
structure
and
to
the
number
of
area,
directors,
/
area,
and
things
like
that.
That
have
happened
in
the
past
six
months
or
so
there's
actually
been
a
lot
more
going
on
than
there
has
been
in
previous
years
we've.
H
H
H
So
some
of
the
things
that
have
already
happened,
we've
done
the
thing
where
you
can,
where
we
can
assign
area
directors
to
working
groups
that
are
not
in
their
area.
That's
that's
started
out
being
a
lot
of
a
lot
of
the
work
that
we
were
doing
to
move
operations
working
groups
out
from
under
Benoit
so
that
he
could
focus
on
a
lot
of
the
gang
model.
Work.
That's
being
done
so,
if
you've
seen
anything
about
that.
That's
what's
going
on
with
that.
H
H
We
did
a
more
flexible
definition
of
area
directors
and
if
you
saw
RFC
74
75,
which
basically
said
we
were
able
to
have
more
than
two
area
directors
in
an
area
the
first,
the
first
area
that's
taken
advantage
of
that
has
been
routing.
If
you
guys
will
you
guys
will
see
three
area
directors
seated
for
the
next
coming
is
GI
Wednesday
night,
that's!
What's
going
on
with
that
we're
doing
a
lot
of
focus
on
denim
models.
H
Work
with
you
know,
like
I
said:
we've
been
why
and
then
with
a
coordinator
group
and
if
you
guys
have
seen
discussions
which
are
this
is
still
in
process,
but
but
reorganizing,
the
absent
area
and
the
rye
area
into
one
area
called
art
and
that's
going
along
with
going
down
from
23
80s
from
four
we're
still
the
process
of
creating
the
art
area.
One
of
the
things
that
is
going
on
there
is
that
we
are,
we
have
Alyssa.
Cooper
is
on
maternity
leave
right
now,
she's
one
of
the
affected
area
director.
H
H
We
were,
the
IHG
is
doing
a
lot
of
work
on
trying
to
improve
the
way
things
work
around
here
so
far.
They
very
little
of
it
has
been
transport
specific,
so
number
one
that
goes
along
with.
That
is
that
the
transport
area
has
more
tools
available
now
than
a
lot
of
us
think
about,
because
these
these
tools
were
put
in
place
to
solve
other
problems.
What
we
can
use
them
as
well,
but
the
other
thing
I
think
I
wanted
to
say
was
that.
H
We've
still
got,
we've
stood
at
work
to
do
on
the
transport
area,
beyond
what
hit
where
we
are
right
now
and
one
of
the
big
one
of
the
big
things,
passions
that
I've
had
and
we've
talked
about
it.
Various
TSP
area
meeting
since
I
became
an
area
director
not
quite
two
years
ago
is
basically
is
basically
saying.
H
We
want
to
make
sure
that
the
transport
area
has
the
management
that
the
area
deserves,
and
so
that
some
of
that
will
be
yeah,
so
that
will
be
making
sure
that
actually,
a
lot
of
that
will
be
making
sure
that
the
area
directors
that
the
Syrian
needs
are
able
to
serve.
You
know
that
is
that
this
is
a
manageable
commitment
for
them
and
that's
and
it's
been
I
hope
that's
been
I,
not
transform
is
not
the
only
area.
H
There
are
things
that
there
are
things
that
we
can.
There
are
things
that
we
can
take
advantage
of
now
that
it
and
RFC
74
75,
where
we
have
the
opportunity
of
using
three
area
directors
where
we
had
only
one
or
two
as
the
possibilities
previously
being
you
know
one
good
example
of
this,
but,
like
I
said
there
are
others,
but
there
may
be.
There
may
be
things
that
we
need
to
do
that
are
specific
to
transport
and
I'm
kind
of
you
know.
H
H
It's
been,
you
know
you
could
observe
that
it's
easier
to
get
people
to
sign
up
for
a
second
term
is
area
director
than
it
is
to
get
them
to
sign
up
for
a
first
term.
Our
Martin
is
in
his
second
term
right
now
and
I'm
I'll
be
starting
my
second
term
on
wednesday
night.
So
you
know,
we've
had
we've
had
some
time
to
try
to
get
things
in
place.
We've
gotten
some
stuff
in
place.
We
have
more
work
to
do
and
I
just
encourage
you
guys
to
be.
G
H
Let's
say
you
know
we
can
we
can
chat
for
a
minute
or
two
here
if
people
have
things
like
to
chat
about,
but
because
they
recognize
what
a
little
have
you
know
discussion
at
the
wesley
night,
minori
admin
planaria
at
open
mic
time
and
that
we've
got
time
slotted
on
friday,
tsv
area
session,
to
give
you
guys
more
of
an
opportunity
to
do
feedback
and
share
ideas,
even
given
that
you've
had
some
time
to
think
about
it.
I.
B
Think
I
wouldn't
say
too
much
about
this,
but
I
think
one
thing
we
should
consider
in
terms
of
restructuring
is
that
there
is
more
and
more
work
in
the
applications
area.
That's
actually
doing
transport
work
like
HTTP
to
was
very
much
a
transport
protocol
and
it's
not
really
getting
reviewed
in
the
transport
area
and
the
two
seem
to
be
a
bit
disconnected
so
that
there
may
be
some
structural
problem
there.
I
can
talk
about
it
more,
maybe
I'll
talk
about
more
privately
and
then
we
can
frame
it.
But.
H
C
Maybe
when
one's
lots
last
slide,
for
is
one
thing
which
is
being
discussed
in
the
isg
but
also
may
be
with
people
who
are
interested
to
become
lady
in
the
future
is
their
first
bullet
here
is
reducing
the
time
commitment
that
somebody
has
to
have
to
be
an
ad
right.
Now,
it's
suddenly
like
75,
two
hundred
percent,
but
we
want
to
get
down
to
fifty
percent
and
there
will
be
pried
quite
good.