►
From YouTube: IETF104-TSVWG-20190325-1610
Description
TSVWG meeting session at IETF104
2019/03/25 1610
https://datatracker.ietf.org/meeting/104/proceedings/
A
A
There's
anybody
in
the
room
feel
able
to
take
a
few
notes
for
us
notes
are
always
appreciated.
We're
happy
to
take
whatever
we're
provided
with
and
make
sure
that
all
little
bits
and
pieces
are
correct.
So
it's
just
really
really
useful
to
have
a
note-taker
who
provides
with
that
starting
point,
because
we
may
forget
something,
and
we
really
can't
have
the
meeting
not
being
recorded.
B
B
B
Okay,
we
have
taken
care
of
note,
takers,
Brian
and
young
Jen
and
Mike
a
person
has
agreed
to
to
handle
jabbers
privately.
Thank
you.
Thank
you
folks,
quick
reminder.
There's
been
a
bunch
of
reviews
on
the
list.
Please
keep
please
please
more.
The
same
reviews
are
what
makes
the
aqua
what
makes
makes
it
makes
IETF
function
and
remember
to
put
TS
vwg
in
the
name
of
any
draft
that
you'd,
like
written
teachers,
pay
attention
to.
B
B
Okay.
Now
we
get
to
the
the
important
administrative
stuff
progress
the
status,
so
we've
had
an
RFC
published
since
the
last
ITF.
This
is
our
C
eighty,
its
RFC
thanks.
Eighty
five,
four
DS,
the
actual
number
but
I
have
to
go.
I
will
have
to
go,
go
fix,
X,
likely
made
to
a
class,
and
in
case
the
erotic
issues
draft
has
has
has
has
been
published
and
I
have
to
go
fix
that
slide.
B
B
In
addition,
the
diffserv
and
art
and
Weber
gqs
wraps
at
the
RFC
editor.
This
is
gonna,
sell
like
a
broken
record,
because
it's
part
of
the
well-known
web
RTC
cluster
238
at
some
point
will
finally
emerge
the
RSC
editor,
a
new
ad
that
is
getting
close.
He's
he's
inherited
part
of
this.
We
have
two
ideas:
ISU
is
going
to
talk
about
on
a
little
talk
about
in
a
little
bit
of
part
of
chairs.
What
happened
is
that
the
the
FEC,
the
FEC
drafts
are
basically
done
good
work.
B
Okay,
we
still
intend
to
send
a
couple
of
drafts
to
hourglass
calls
soon.
I
think
this
is
like
the
third
IETF
meeting,
which
we've
done
this.
We
somehow
have
to
figure
out
how
to
get
these
to
work.
All
this
this
this
is.
This
is
my
problem
that
I
was
supposed
to
Berger
last
column
and
I
thought
other
things
consuming
my
time.
B
B
There
are
a
couple
of
drafts
over
in
in
six-man
on
path,
MTU
discovery
for
ipv6,
the
the
elf
race
and
diffserv
draft.
One
up
on
a
bob's
draft
is
probably
is
before
this
birth
group.
We're
not
going
to
be
talking
about
it
talking
about
this
time,
but
it's
worth
having
a
look
at
it
is.
It
is
a
fairly
important
concept,
likewise,
the
diffserv
too
cute
to
qci
mapping
for
for
cellphones.
We
didn't
hear
a
lot
more
about
that
one,
since
that
we
last.
B
B
So
that's
that's
the
loops
draft.
There
is
Tom
Cruise
from
Britain
running
a
bunch
of
trash.
You've
got
a
UDP
space,
header
draft
and
and
several
GUI
drafts
over
in
inter
area
for
the
most
part,
pay
attention
to
interior
working
group
is
a
primary
form
for
these,
at
least
for
now.
Something
changes
will
let
you
know
alright,
the
the
EC
n
for
n
sh
draft
in
SF
co1
of
what
what
what
an
acronym
sue
is
now
an
official
working
draft
over
there
that
is
related
to
toleration.
B
Feedback
draft,
as
that
draft
moves
forward
in
SF,
see
there's
a
very
good
chance
that
will
that
will
bring
the
total
congestion
feedback
draft
back
up
here
and
move
that
forward
underlying
mechanism.
There's
an
informational
draft
on
low
latency
DOCSIS
for
those
who
are
interested
in
that
stuff
over
in
inc
area.
B
Okay
onto
the
agenda
you're
in
the
middle
of
the
chairs,
slides
we've,
we've
read:
we've
we've
read
read
the
note
well
done.
Document
off
document
of
conscience,
status,
milestones,
review
drafts
and
more
drafts
are
coming
up.
We
can
go
bash
the
agenda
as
we
go
along.
If
it's
in
any
change
any
changes
we
need
and
I
think
that's.
The
last
minute
slide
arranging
right:
yep,
yep,
okay,
Monday's,
not
that
when
you
start
on
Monday
it's
not
it's
often
the
case
that
slides
don't
come
apart.
All
that
far
in
advance,
oh
well,
but.
A
B
Milestones
review,
okay,
so
the
first
two
milestones
in
yellow
are
orange.
Every
color
that's
showing
up,
as
are
the
two
of
EC,
an
encapsulation
drafts.
Those
need
to
be
last
called,
if
anybody's
interested
in
being
a
shepherd
for
the
drafts.
Please
let
us
know
as
the
existing
shepherd
it
be.
Yours
truly
as
in
timpa,
tick
hasn't
been
hasn't,
been
particularly
diligent
or
attentive,
but
we
will
get
these
draft
drafts
called
one
way
or
another,
but
last
call
before
the
next
IETF
other
sub
squares
happen
for
the
next
IETF
we're
kinda
optimistic
here.
B
I'm
sorry
other
SEVIS
always
happen
for
the
next
IETF
SCTP
nat
draft.
We'll
talk
about
that
tomorrow,
transfer
algae
to
DP,
talk
about
that
tomorrow.
The
three
l4s
trash
we'll
talk
about
those
today
and
then
after
the
next
IETF
packetization
imbues
can
refer
for
Datagram
and
the
transfer
header
encryption
draft
before
the
the
the
third
IETF
this
year.
Then
after
that,
sometime
of
the
next
version
of
SCTP
I'm
not
sure
how
good
an
estimate
that
ND
year
milestone
is
that's
what
worked
from
now
and
tell
congestion
feedback
again.
That's
a
that's
a
guess!
B
That's
a
guesstimate!
So
that's
where
the
milestone
stand
and
the
big
one
we
will
have
to
figure
out
is
what
we're
going
to
do
with
the
the
the
the
big
one
we
have
to
figure
out
is
how
we're
going
to
make
sure
that
the
two
ecn,
encapsulation
of
just
layered
ECM
drafts,
actually
do
go
through
work
through
glass
call
in
the
next
cycle
got
a
whole
bunch
of
stuff
with
that
is
on
the
list
to
be
done
between
now
the
next
IETF,
okay.
B
So
all
right,
so,
okay,
so
the
agenda
for
today.
So
this
is
how
Pina
Bausch
the
agenda
right
now
on
item
1,
which
is
document
status
charter
and
accomplishments.
You'll
see
agenda
bosch.
This
is
Jenna
bashing.
A
hackathon
update
will
Q
will
queue
the
hackathon
an
update,
just
after
I
couldn't
run
through
these
slides.
Then
we
do
transfer
header
encryption,
followed
by
l4s,
followed
by
some
addition
experience
the
non
queue,
building
flows,
draft
and
multipath
DC
CP.
B
If
there's
time
left
over
a
primary
purpose
of
this
meeting
is
to
unsee
makes
get
some
clarity
on
what's
going
on
with
both
the
l4
s
and
the
some
congestion
experienced
topics,
then
on
Wednesday
there's
only
a
there
is
I
think
there's
only
a
part,
one
I
don't
think
as
a
part.
There's
a
part.
Two
to
this
we
have
the
SCTP
drafts,
which
is
both
in
that
draft
and
the
plan
for
the
next
version
of
RFC
4960
and
Datagram.
B
Mtu
and
piu
discovery
you'd,
be
options
and
if
time
permits
a
couple
presentations
on
proposed
new
work,
one
is
HTTP,
two
is
transport
and
the
other
is
the
SCTP.
We
track
the
TV.
We
transmit
bit.
Okay,
anybody
want
to
bash
the
agenda
and
I
need
to
go
quickly.
Revise
these
slides.
Nothing
else
to
it,
took
to
fix
that
RFC
number
goof
on
the
SCTP
errata
RFC
all
right.
Consider
the
agenda
bashed
hackathon
update
in
particular
somebody
should
say
some
of
our
tcp
Prague.
A
D
Okay,
Olivia
Tillman's
arranged
a
bunch
of
people
to
work
on
l4s
things,
TCP
Prague,
surprising,
also
quick,
Prague
that
surprised
me
and
that
that's
something
built
already,
which
is
a
l4s
version
of
quick,
the
m4s
congestion,
control
or
and
feedback
in
it
see
to
be
proud
and
being
built,
and
the
main
thing
they
were
doing
at
the
hackathon
was
working
out
how
to
work
with
software.
Generic
receive
offload
and
segmentation
offload.
D
Send
the
segmentation
offload
sort
of
patching
the
the
linux
offload
engine
and
built
a
virtual
in
test
environment
for
it
all
as
well,
and
did
a
bit
of
interworking
testing
and
things
so
it
made
a
lot
of
progress.
I
was
really
I
was
really
very
happy
with
them.
All
thank
Scott
I
was
about
810
people
doing.
E
Tom
Jones
University
of
Aberdeen
and
just
an
update
on
the
the
related
stuff
from
six
man
on
path,
MTU
discovery
and
we
had
seven
people
working
on
implementations.
We
got
a
Linux,
she
just
basic
accommodation,
working
a
Wireshark
to
sector
and
to
routier
implementations
working,
so
VP,
P
and
P
for
and
and
so
this
is
really
good
progress.
What
what
still
remains
to
be
seen
is
how
we
integrate
these
signals
into
transport
and
what
we
do
them,
but
it
was
a
good
strong
start
and
was
love
at
rest.
F
Hi
Sheikh
Holland
I
had
a
couple
of
specific
questions
regarding
TCP
Prague
at
the
hackathon
was
any
work
done.
Does
anybody
know
if
any
work
was
done
on
there's
a
few
requirements
Anil
for
us
draft
about
I,
believe
the
accurate
ecn
and
the
and
the
RAC
support
in
the
endpoints,
and
so
I
was
curious
as
to
whether
any
issues
were
attempted
addressed
encountered
along
the
implementation
path.
Thank
you.
D
D
That
was
largely
well
with
here
so
Jo
stuff.
It
was
that
crate
easier
than
it
was
where
that
was
all
we
issue,
and
that
was
there
was
some
subtle
interactions
we
found
between
Acura
Ian
and
that
the
nail
it's
code,
which
is
what
they
were
trying
to
sort
out
I'm
going
to
tell
if
you
want
Bert's,
probably
probably
for
just
those
that
are
interested
I,
can
go
afterwards
rather
than
right
now:
yeah,
yeah,
yeah,
okay,
thanks.
D
G
A
H
Very
quickly,
so
we
updated
these
two
drafts
quickly.
Taking
two
accounts
is
GE
comments.
I
think
we
cleared
all
the
issues,
technical
issues-
that
was
one
big
issue
remaining
concerning
the
licensing
of
copyrights
for
this
source
code.
So
the
solution
right.
The
good
solution
was
to
remove
this
source
code
source
code
from
the
draft
and
move
it
to
an
initial
draft
that
would
be
covered
with
the
two
Japanese
researchers
who
designed
this
TNG.
So
this
is
what
we'd
done
and
thereby
only
license,
and
the
copyright
is
clean
because
it's
now
the
IETF
trust
stuff.
H
H
Interoperability,
it's
about
issuing
specifying
out
to
what
is
the
negative
format
for
so
for
C.
So
there
was
some
ambiguity,
so
we
cleared
also
this
issue
by
doing
it
in
a
slightly
different
way.
So,
from
my
point
of
view,
everything
is
now
operates
or
is
now
correct,
and
we
therefore
have
this
normative
dependency
from
the
RLC
effects
scheme.
Internal
draft
to
this
tinium
t42
internal
draft.
So
now,
I
give
you
floor
thanks.
A
I
Spencer
Dawkins
responsible
area
director
for
this
draft.
Thank
you
for
chasing
this
down,
and
this
was
you
know.
I
said
just
for
the
community.
This
is
a
complicated
thing
where
we
say
we
have
to
have
this
particular
copyright
statement
in
the
part
of
the
draft,
a
part
of
the
draft
where
somebody
else
has
to
have
the
other
specific
statement,
and
it's
not
totally
obvious
how
we
mix
to
match
those.
Thank
you
for
doing
the
homework
to
make
that
possible
for
this
draft.
I
The
other
thing
I
wanted
to
mention
that
came
up
as
a
late
surprise.
During
IHG
evaluation
was
the
thing
about
how
portable
is
this
code
yeah,
and
there
was
not
something
that
anybody
who
had
looked
at
it
was
looking
for
before
it
got
to
the
is
G
and
I.
Don't
I,
don't
see
that
happen
yo,
so
I
was
on
the
ice
tree
for
six
years.
I
I
haven't
seen
that
happen
before
so
it
doesn't
happen
often,
but
just
something
for
people
to
be
aware
of
his
effect
is
that
there
was
that
concern
about
how
portable
the
code
would
be
in
different
environments
that
you
had
to
chase
down
to
and
I
wanted
to.
Thank
you
for
doing
that,
also,
but
I
say
just
for
other
people
to
be
aware.
Yeah.
H
And
thank
you
to
is
G
to
identify,
so
she
should
school.
I
was
not
well
this
tuning
to
complement
stuff,
not
being
specified
normatively
in
the
specification,
as
19
I
know,
whatever
you
may
think
about
concerning
C
along
with
specification,
so
that
was
greater
flow
from
oh
good,
a
very
good
feedback
from
ISD.
B
A
Okay
and
I'm
going
to
be
talking
about
the
draft.
That's
entitled
the
impact
of
Transport
header,
confidentiality
on
network
operations
and
evolution
of
the
Internet,
and
the
intention
of
this
draft
is
to
talk
about
network
operation.
History
what's
been
done
in
the
past
and
what
we
think
might
be
factors
that
impact
the
evolution
of
the
internet,
meaning
Transport
evolution,
because
it's
a
transport
draft
we're
currently
at
draft
rf5.
A
We
got
a
review
from
sector
of
this
draft
because
we
think
it's
nearly
finished
and
in
the
review.
The
first
line
of
text
had
the
document
lays
out
a
comprehensive
assessment
of
the
impact
of
Transport
header
encryption
on
network
users
and
operators,
which
was
exactly
our
goal,
so
that
is
now
the
goal
of
this
draft.
Next
one
am
I
doing
this.
Oh
you
do
all
right.
A
At
that
point,
we
got
sector
review
and
we
asked
for
up
art
review
as
well,
which
we're
still
currently
pending
as
David
tweaks
this
and
since
then,
we've
had
a
number
of
updates
responding
to
these
comments,
and
other
people
have
chipped
in
on
the
list
and
that's
very
much
appreciated
to
get
this
a
readable
document
next
page,
please,
when
we
got
they
set
their
review.
They
had
a
few
comments.
Aha,
here
we
all
go,
and
there
are
lots
of
comments.
The
document
they
said
had
issues
which
is
fair
enough
firm.
A
A
We
think
it's
sufficient
so
and
that's
me
telling
you
the
working
group,
if
you
think
different-
and
please
suggest
a
few
extra
sentences
that
you
think
are
really
important-
will
happily
up
them.
We
made
lots
of
sections
clearer.
Obviously
it
is
great
to
get
SEC
purity
inputs
on
the
document
that
talks
about
security
and
their
use
of
words
is
somewhat
different
to
the
transport
areas.
So
now,
hopefully,
things
match
both
sides
and
floor
labels
proved
to
be
more
contentious
than
we
expected
because
transporting
into
people
didn't
think
they
were
contentious
and
security.
A
People
wondered
about
this,
and
so,
in
the
end
we
we
decide.
We
wouldn't
make
it
pinions
on.
This
group
simply
cite
the
current
publishing,
psays
and
BCPs
that
refer
to
these,
and
they
said
more
or
less
the
right
things.
So
we
rephrased
and
we
use
that
and
added
text
on
the
spin
bit
work
in
quick
and
because
that
by
the
time
we
got
to
this
stage.
That
was
no
part
of
the
quick
specification.
So
that's
good
an
added
section
on
end
point
logs.
A
We
didn't
talk
much
on
endpoint
logs,
because
I
don't
think
endpoint
loss
particularly
helped
you
in
finding
out
how
the
network
treats
your
packets,
but
they
do
help
you
debug
a
transport
protocol
when
you
want
to
find
out
what
the
other
engineering
as
you'll
find
out.
If
we
go
to
the
quick
working
group,
so
we
know
references.
A
Made
up
made
a
separate
section:
oh
yeah,
we
made
a
separate
section
on
research
and
development
because
I
think
that's
actually
an
important
topic
as
we
move
forward.
What
is
the
impact
of
encryption
on
the
research
community
or
the
way
which
we
develop
standards
here,
and
it's
not
the
same
as
on
operators?
It's
a
different
community
who've
been
closely
with
Transport
over
the
years,
but
we
have
to
figure
out
how
we
go
forward.
So
we
don't
provide
solutions.
A
We
don't
even
identify
the
real
problems,
but
we
say
this
is
what
was
done
and
now
we
need
to
think
now.
We
added
more
references.
We've
got
lots
of
comments
from
people
individually
and
we
hope
we
address
them
all.
We
didn't
add
speculation
about
new
proposals
that
were
going
on
in
the
IETF
or
RTF,
we're
aware
of
stuff,
like
in
the
privacy,
enhancing
research
grip
which
might
be
really
relevant,
but
currently
it's
not
received
much
attention
in
the
ITF.
A
It's
big
room
when
he
met
this
time,
so
it
would
be
exciting
to
see
his
happen
in
future,
but
we
don't
really
have
operational
experience
for
that
and
we
didn't
also
comment
on
things
are
presented
in
mapache,
which
were
things
in
progress
which
will
naturally
mature
over
the
years.
It
suggests
you
go
and
look
at
these
groups
if
you're
interested
in
this
cuz
there's
lots
of
good
things
going
on
next
slide,
please!
A
G
G
J
The
impact,
but
that
assumes
that
the
part
of
the
impact
is
not
that
people
will
adapt
to
it
so
and
I
said
this
before
I
think
it's
a
one-way
ticket
encryption
of
transport
headers
is
coming
clearly.
Quick
has
gone
that
way.
The
privacy
and
the
all
cific
anti
ossification
arguments
are
too
strong.
So
when
I
read
this
document,
I'm
reading
this
in
the
light
of
ok,
we
have
a
problem
now.
The
next
question
is:
how
are
we
going
to
adapt
the
world
to
solve
this
and
I
think
it
might
be
helpful
to
describe
more?
J
What
exactly
is
the
information
that
is
needed?
That
would
not
be
present
anymore
with
the
encryption
of
the
transport
header
and
then
what
are
the
alternatives
to
get
that
information?
So
I
think
I
said
before,
for
instance,
we
do
have
extension
headers
they
could.
You
could
put
transport
layer
related
information
into
extension,
headers,
and
that
would
allow
the
exposure
of
this
information.
So
if
we
can
just
define
the
information
that's
needed,
we
could
develop
standard
ways
to
overcome
this
loss
of
information.
I
think.
A
We
could
and
I
think
that
when
we
started
this,
this
is
an
extremely
contentious
document
to
start
working
on
to
try
and
say
that,
by
the
way
people
regard
privacy
as
important,
they
regard
encryption
as
important.
Quick
is
important,
but
operators
are
unhappy
about
some
aspects
of
this
with
respect
to
what
they
currently
do
now,
even
without
going
further.
A
That
I
believe
that
that
is
a
useful
thing
to
document
and
it
doesn't
solve
the
problems
and
the
unhappiness
will
change
as
people
understand
more
I'm
a
little
bit
frightened
to
try
and
dig
further
in
the
next
step.
I
think
it
probably
requires
a
new
document.
A
new
start
I
mean
to
get
those
recommendations
out.
Yes,
I
agree
you
by
the
way
extension
headers
are
cool
I,
think
we
say
that
extension
had
as
a
curl
worthy
work,
so.
J
One
quick
additional
comment,
so
I
think
in
the
drafts,
the
parts
where
this
exposure
is
required
for
protocol
development
I'm
not
entirely
convinced
of
that
we've
done
a
lot
of
stuff,
for
instance,
at
Google,
with
TCP
quick,
was
developed
without
any
ability
to
look
at
on
the
network.
So
clearly
you
can
do
serious
protocol
development
without
being
in
the
network,
at
least
for
that
part
right.
A
J
Of
it,
this
way,
I'm,
Google,
I'm,
deploying
to
the
whole
world
I,
don't
want
to
have
insight
to
every
Network,
because
it's
just
a
mass
jumble
of
information.
It's
very
rare
that
we'd
have
to
go
into
a
particular
network
to
see
what's
happening.
We
can
get
immense
amounts
of
data
at
the
endpoints
and
that,
to
a
large
extent,
that's
valuable
enough
to
deploy
major
protocol
features.
I
Mr.
Dawkins
says
the
soon-to-be
former
Area
Director
for
this
draft.
This
is
a
conversation
that
Cory
and
I
had
early
in
the
like:
zero
zero
zero
one
stage
where
basically,
we
did
not
see
any
I
think
you
just
said
this,
but
I
did
not
see
any
way
forward
to
do
anything.
That
was
not
the
most
bland
form
of
description.
You
know
and
basically
that
there
were
people
working
in
this
space
that
didn't
have
a
description
done
by
experts
and
transport
to
work
from.
So
you
know
they
were
saying.
I
Well,
you
know
people
do
this
whatever
this
is
and
searching
and
entrails-
and
maybe
they
know
you
know-
maybe
they
know
things,
and
that
was
the
level
of
that.
That
was
the
quality
of
conversation
that
we
were
having
and
that
was
resulting
in
nice.
Long
ATF
last
calls
and
nice
long
is
G
evaluations.
And
if
you
look
at
the
I
mean
it
wasn't
just
the
IETF,
the
IAB
workshop
on
the
Marnie
workshop
report
I
think
I
waited
up
taking
that
over
and
it
you
know
in
editing.
I
B
K
D
D
I
guess
I
can
start
introducing
myself
and
stuff.
This
is
about
low
latency,
low
last
scalable,
throughput
or
l4s.
There
are
three
drafts
on
this
is
the
airport
architecture
which
I'm
not
really
going
to
talk
about
today,
there's
and
then
there's
essentially
one
for
a
network
node.
Your
cue
couple
of
a
QM
and
I'm
going
to
explain
today
how
that
could
also
be
a
flow
cue
system
and
the
other
for
the
host
the
sender.
D
D
It's
the
IP,
our
slide,
which
is,
it
may
be
worth
just
carrying
on
with
it
as
it
is,
because
the
whole
point
was
not
to
draw
attention
to
it.
B
Little
bit
game
plan
on
time,
ten
minutes
or
less
for
presentation,
then
we
will
allow
some
additional
slack
country
how
on
which
we
do
have
any
agenda
for
quite
for
a
question
of
discussion.
So
the
goal
is
is
to
get
to
a
brief
presentation
and
then
any
questions
and
discussion
would
start
to
off
from
there
and
we
have
sometimes
we
have
kind
of
some
time
to
allow
it
to
run
and
we're
going
to
do
the
same
for
the
some
congestion
experience,
presentation,
okay,.
D
This
is
internet
paths,
not
datacenters,
getting
in
queuing
delay
in
microseconds,
hundreds
of
microseconds,
as
opposed
to
the
5
or
15
of
fq,
coddle
or
PI,
and
the
intent
of
that
is
to
enable
all
the
new
applications
that
have
been
sort
of
arm
waved
about
for
years.
You
know
that
they
are
the
controlling
nuclear
power
stations
or
what
you
want
to
do
over
the
Internet
these
days.
D
D
The
lower
orange
queue
is
not
intended
to
be
a
sort
of
lower
priority
queue.
It's
to
intend
it
to
be
for
old
stuff.
It's
it's.
The
legacy
transport
protocols
go
in
there
and
it
would
be
the
same
with
a
multi
cue
system
of
F
Q
system.
Some
Q's
would
be
for
the
old
traffic
and
some
would
be
for
the
new
and
the
the
sort
of
key
invention
here
was
really
to
find
a
way
to
do
this.
Get
such
low
latencies
in
what
is
effectively
a
FIFO
queue.
D
D
The
99th
percentile
in
the
middle
there
somewhere
means
that
99%
of
packets
have
queuing
delay
lower
than
that
and
you'll
see
high
with
EC
and
without
fql,
with
ecn
without
and
then
dual
pi/2,
which
is
the
Alpha
architecture
with
ECM
and
without
the
red
ones
without
which
is
then
in
this
classic
queue.
The
blue
one
is
with,
and
that's
where
you're
getting
your
hundred
or
200
microseconds
alais
1
to
2
millisecond,
99th
percentile.
D
But
the
impressive
thing
about
this
is
the
traffic
model
which
I'll
put
in
tiny
letters
just
because
it's
not
really
for
presentation,
but
you
can
go
and
read
it
if
you
want,
there
are
300
web
flows
per
second,
hammering
this
over
a
10
millisecond
round-trip
time,
all
different
file
sizes
and
we're
still
getting
below
one
and
full
utilization
as
well.
I
should
say
and
we're
getting
below
200
microsecond
median
delay
and
below
2
milliseconds.
Otherwise.
D
So
essentially
this
means
you
could
put
all
your
traffic
in
this
queue
as
long
as
your
TCP
supports
it,
and
the
opressed
TCP
we've
been
building.
Is
this
thing
TCB,
Prague
or
quick-quick
Prague,
and
so
on?
Right,
so
at
any
percentile
we're
getting
about
10
times
lower
delay
than
the
current
state
of
the
art?
And
that's
we're
not
it's
not
a
pissing
contest.
We're
not
saying
it's,
because
it's
a
better
aqm
is
because
we're
using
a
new
congestion
control
as
well.
It's
the
interaction
between
the
network
and
the
end
system.
That's
yeah,
which.
D
So
this
is
a
cut
from
a
paste
from
the
landing
page
with
all
the
code
on
it.
So
as
you've
heard
about
all
these
different
pieces
now
all
implemented
in
various
stages
of
development,
that
none
of
them
are,
you
know
absolutely
cool
and
finished,
but
you're
working
on
it
and
then
the
component
parts,
accurate
ezn
and
so
on.
D
There's
a
white
paper
on
it
as
well.
Those
orange
things
are
all
hyperlinks
in
the
slides
and
certification
test
plans
and
nearing
completion
and
implementation
is
in
progress.
So
anyone
interested
come
see
me
afterwards
and
we
can
talk
about
trials
and
all
the
rest
of
it
and
applications
to
run
over
it
and
stuff
and
I
should
add
that
CableLabs,
obviously
the
working
group
that's
been
working
on
this
is
with
all
the
vendors
around
the
world
or
all
the
cable
operators
around
the
world.
D
So
it's
not
just
us,
it's
not
just
any
particular
country,
it's
everywhere
right.
Moving
on
to
what
we're
doing
the
idea
for
the
l4s.
Thank
you
to
all
these
people
for
their
reviews.
It's
a
bit
of
an
awkward
slide
because,
obviously
reviewed
you
don't
know
whether
people
support
you
or
not.
So
when
I
put
non-supportive
there,
that
doesn't
mean
to
say
all
the
rest
of
them
support
it
they're
just
giving
comments
you
know,
but
but
those
that
specifically
said
that
you'd
support
it
over
there
and
some
people
I'm
just
trying
to
find
out
more
information.
L
D
Okay,
so
they've
been
full
reviews
from
Nikolaj,
Coonan,
Gauri,
twice
and
Richard
and
as
I
say,
I'm,
not
necessarily
saying
Gauri
supports
this
and
he's
just
reviewed
it
in
full
or
any
of
those
people
and
more
focused
reviews
from
Michael
Ingemar,
Praveen
and
David.
Ingham
are
male
mainly
on
the
effect
on
real-time
transports.
Praveen
on
TCP
David
on
the
sort
of
wrapped
requirements,
they've
had
refused
from
the
slides
going
up
and
down
we're
trainable.
D
D
Okay,
this
is
the
criticism
and
I'm
trying
to
deal
with
it.
The
track
map
yeah.
So
if,
if
those
classic
ECM
bottlenecks
on
the
internet
that
are
giving
out
these
CES
or
in
FQ
systems,
which
is
what
we
assumed,
then
there's
no
problem
because
we're
talking
about
safety
from
other
flows
inside
an
FQ
system.
So
the
FQ
scheduler
deals
with
that.
If
someone
started
turning
on
old,
cisco,
reuters
with
red
with
ACN
in
those,
then
it
is
a
problem
and
we
need
to
deal
with
it
and
so
worked
out
a
way
to
see.
D
If
we
can
measure
which
sort
of
things
they
are
offline,
not
sorry,
you
know
online
and
I
have
to
deal
with
that.
I'm
gonna
skip
over
this
one.
These
were
all
misconceptions:
oh
no,
the
middle
one
I
think
just
just
to
point
out
that
an
FQ
system
is
a
very
easy
thing
to
make
it
support
l4s.
So
we
hardly
ever
talked
about
it
because
it
was
just
so
easy
and
some
people
have
got
the
impression
that
that
means
it's
not
going
to
support
your
frets.
Well,
it's
just.
D
We
didn't
bother
saying
much
about
it,
because
it
was
so
obvious
and
I
have
to
fix
that
in
the
next
version.
I
think
you
got
off
on.
A
D
That's
what
it
says
there:
intellectual
property.
There
is
an
IPR
declaration
on
this
from
Nokia
on
the
Joule
cute
couple
day,
QM
with
Fran
terms.
There's
a
GPL
v2
license
on
the
limit.
Linux
implementation
of
this,
which
of
the
same
thing
with
Nokia
people
on
it,
and
so
that's
all
I'm
allowed
to
say
I'm
just
stating
facts.
A
A
To
stop
you,
let
you
talk
after
we've
talked,
but
on
that
one
I
think
the
church
would
be
interested
in
finding
out
more
about
the
IPR
and
whether
the
drafts
are
able
to
be
implemented
without
the
IPR
right.
That's
an
observation,
and
we
will
be
continuing
that
if
you
have
opinions
on
this,
please
come
to
the
mic
or
please
talk
to
the
chairs
and.
D
There
has
been
some
discussion
on
the
list
and
obviously
the
discussion
would
just
I've
just
been
having
about
FQ
being
an
alternative
and
so
on
and
and
the
fact
that
there's
gplv2
on
the
limits
code
is
another
way
to
get
around
it.
Sorry,
oh
that's
my
personal
comment,
not
on
behalf
of
all
the
authors.
D
This
is
the
last
slide,
so
we've
got
to
deal
with
that
classic
ecn
bottleneck
case
and
some
minor
text
updates
to
all
three
drafts,
and
once
is
that's
all
satisfactorily
resolved
I'm
hoping
we
can
go
for
working
great
last
call
on
the
three
of
them
and
then
you
know
I
mean
well.
These
experiment
is
already
starting
with
being
fairly
careful
about
releasing
the
codes.
Obviously
we're
using
an
East
t1
on
the
internet,
this
last
unicorn,
so
you
have
to
manually
configure
it
to
be
nothing's
by
default.
A
M
D
But
when
you
go
to
that
page,
which
that
URL
at
the
top
there's
your
cue
Kappa
like
a
cone
for
Linux
only
at
the
moment,
that's
the
GPIB
to
decode
the
curvy
read.
Implementation
is
not
public.
Yet
that's
in
hardware
for
high
speed
switches
and
I'm
not
allowed
to
say
who
it
is
yet
because
they
want
to
announce
it
when
they
do
it.
D
M
D
They're
all
the
things
I
said
about
limits
were
the
most
they're
against
the
most
recent
kernel
and
we're
putting
those
patches
onto
the
onto
the
negative
list.
We
would
have
put
them
on,
except
that
the
guy
who,
ironically,
who
had
to
do
that,
couldn't
get
access
to
his
email,
cuz,
the
VPN.
We
couldn't
get
access
to
an
email
but
formatted
things
in
the
right
way.
For
that
list.
You
know.
M
M
M
D
D
D
So
the
modem,
the
modem
implementations
they're
all
going
to
be
software
upgradeable
field
upgradeable.
So
this
is
all
going
to
be
done
in
software
on
top
of
the
existing
3.1
modem
hardware
and
the
software
for
that
key
protection
has
already
well
an
NS
3.
Implementation
has
been
done
to
simulate
it
and
it's
now
being
implemented
for
the
particular
hardware
platforms.
That's
the
Intel
and
Broadcom
Bob.
B
So
what,
while
games
that
the
next
question,
could
you
quickly
summarize
the
note
you
sent
the
list
about
pi/2,
curvy,
red
and
the
patent
right?
This
will
have
to
be
me
individually,
not
as
on
behalf
the
co-authors
that
you
individually,
that
will
have
to
do
because
message
are
sent
as
individuals.
That
seem
to
be
an
important
message
that
bears
on
how
we
fly
about
that
pattern.
With
respect
to
what
you've
done
here,
yeah.
D
So
this
this
starts
to
get
conjectural
because
there's
there
are
actually
three
IPR
declarations
and
one
of
the
earliest
one
is
very
general
so
and
I've
got
I
I
believe
there's
prior
art
on
most
of
the
things,
and
so
it's
but
beliefs
aren't
important
in
an
IPR.
So
I'm
not
gonna,
say
much
more
about
that.
D
D
Your
cute
couple
take
and
all
the
claims
in
that,
as
far
as
I
can
tell
them
as
far
as
Alex,
who
posted
the
note
on
the
list,
could
tell
require
that
the
Gil
PI
squared
aqm
and
the
whole
idea
of
the
dual
q
AQ
m
couple
couple
of
aqm
internet
draft
is
that
it's
a
general
framework
for
slotting
aq
ends
into
it,
not
just
the
dual
PI
squared
one.
So
the
third
patent
seems
to
be
only
about
dual
PI
squared
as
an
ache
inside
that
framework.
D
But
you
could
put
other
ones
in
and
the
second
appendix
in
that
draft
is
about
using
red
and
kirby
red
as
the
2aq
MS
there's
another
way
to
do.
It
I
believe
now,
I'm
not
going
to
say,
there's
no
IPR
on
those
things,
because
you
can
never
prove
a
negative,
but
you
know
I'm
not
aware
of
anything.
Okay.
B
D
I
mean
I
will
say
that
we
we
stopped
doing
it
because
we
were
getting
better
results
from
the
duel
pi
squared
1,
but
I
don't
know
how
far
we'd
have
got
with
with
pushing
harder.
On
the
you
know,
the
kirby
red
one
and
kobe
red
is
the
one
that's
being
used
in
the
high
speed
switches
area
so
yeah.
I
I
can't
really
answer
that
question
because
we
haven't
fully
tested
it
because
we
never.
We
never
went
continued
down
that
direction,
but
yep.
D
Only
part
where
vendors,
the
only
piece
that
isn't
is
this
cube
protection
function
that
we
just
talked
about
as
optional,
and
we
intend
to
put
that
into
an
internet
draft.
It's
just
with
all
this
blowing
up
recently.
I
didn't
get
it
to
to
the
draft
deadline,
but
it's
you
know
it's.
The
the
doctors
spec
within
is
openly
available.
The
links
were
on
these
slides.
Thank
you.
D
And
the
other
thing
is
Tom
Henderson
is
is
pushing
as
hard
as
he
can
to
get
the
NS
3
implementation
of
that
q
protection
function
and
the
your
QA
QM
for
DOCSIS
or
or
released
and
there's
a
DOCSIS
model
underneath
it
which
may
take
a
bit
longer
to
bring
out.
But
the
whole
intention
is
to
bring
it
all
out,
but
the
trouble
is
we're
sort
of
working
on
it.
D
D
A
Okay,
so
right
and
anybody
get
more
questions,
my
question
to
Bob
is:
do
you
think
now?
It
might
be
an
appropriate
time
to
arrange
an
early
review
from
the
people
who
come
to
the
IETF?
Who
might
need
to
read
this
who
come
to
transport?
In
other
words,
can
we
send
it
to
maybe
interior
review
team
to
get
some
feedback
on
whether
the
interior
has
problems
with
the
ID
and
architecture
drafts?
That
would
be
a
very
good
idea.
Yeah
then,
please
tell
us
when
you've
applied
the
edits
and
your
position.
Q
You
have
high
delay
and
sometimes
it
will
be
too
small
a
congestion
window
and
it
won't
get
enough
throughput
to
fill
the
capacity
and
that's
because
the
network
doesn't
give
them
enough
information.
We
have
a
binary
signal
once
per
RTT,
and
it's
like
your
refrigerator.
It
will
go
above
and
below
and
oscillation
is
pretty
much
guaranteed.
Q
Q
Seh
self
is
ignored
safely
by
existing
ec
n,
capable
transport
flows
SEO,
where
middleboxes
will
still
signal
congestion
experienced,
as
at
present
SEO,
where
flows
will
respond
normally
to
congestion.
Experience
marks
by
existing
middle
boxes,
the
meanings
of
e
TT,
0,
dot,
e
c
t
and
c
e
the
remain
stable
with
their
current
meaning
current
semantics
and
that's
key
to
backwards
compatibility
and
incremental
deployability.
Q
Have
to
congestion
signals.
Sae
means
that
there
is
detectable
congestion.
We
have
something
in
the
queue,
but
maybe
less
than
justifies
setting
us
congestion
experienced
Marc
because
sitting
congestion
experience
gives
us
a
big
drop
in
the
congestion
window,
which
is
too
much
SAE
is
not
a
binary
signal,
but
a
stochastic
one.
This
conveys
more
information
independent
of
round-trip
time
cycles.
Q
Q
Q
Q
We
have
a
state
diagram
for
watch.
We're
allowed
to
do
with
this
EC
Enfield,
it's
a
very
simple
two
bit
field,
not
ECT
always
has
to
stay,
not
ECT
our
FCC
one.
Six
eight
defines
how
the
EC
Enfield
could
be
changed
by
middleboxes,
allowing
either
ET
t
zero
or
ECT.
One
widgets,
which
becomes
SCE
to
be
changed
to
seee
with
SCE,
is
also
permitted
to
take
this
extra
diagonal
path
from
EC
T
0
to
EC
T
1,
from
easy
T
to
SC
e
as
to
preserve
congestion
information.
Q
Now
we
are
developing
diagnostic
tools
to
help
develop
the
experiments
using
SC,
and
here
there's
the
output
from
one
of
these.
This
is
a
100
packet.
Windowed
average
traffic
Papa
gave
traffic
the
portion
versus
time
the
from
just
a
few
seconds
at
the
beginning
of
a
flow.
So
this
is
very
early
results
and
the
yellow
trace
is
SCE
marking,
and
you
can
see
clearly
that
this
comes
in
before
the
red
see
e
marks
and
the
SCE
proportion
goes
down.
Q
As
evident
from
the
previous
slide,
we
have
some
running
code.
This
is
very
simple:
middle
box
code.
It's
two
slightly
modified
code,
LT
I've,
a
QMS
in
the
nooks,
one
uses
a
step
function,
the
other
event
function,
SAE
marks
are
emitted
successfully
and
they
survive
across
real
internet
paths.
This
was
not
very
difficult
to
test.
Q
Work
is
ongoing
to
define
a
system
level
behavior,
hence
experiment,
3
checking
our
maps
and
we
currently
believe
we
can
achieve.
We
are
bound
to
triumph
air
convergence
using
a
single
qaq
M.
So
this
has
implications
for
high
capacity
links
in
the
faster
parts
of
the
Internet,
we're
legacy
hardware
or
even
the
difficulty
of
implementing
multi
q.
A
q
ms
becomes
important.
B
Q
B
This
this
is
what
so,
to
me:
simulator
experiment,
to
figure
out
what
the
entire
congestion
whole
feedback
loop
looks
like
before
you
tackle
or
impair
Eleazer
number
for
the
tackles
details
of
how
to
make
it
work
with
the
transport
protocol
and,
basically,
yes,
okay
thanks
it
was
it
check
check
our
mass
might
have
been
all
we're.
Gonna
write,
we're
gonna
write
a
theory
paper.
It's
trying
to
figure
out
how
that
lined
up
in
the
experiment
now
I
understand.
Thank
you.
Q
C
I
Q
B
B
Okay,
what
I
think
I'm
looking
at
is
is
we
have
a
flow
here
who
send
a
reacts
according
to
RFC
3168
running
into
a
box
that
is
marking
both
SCE
and
Cee,
so
that
the
output
is
a
mixture
of
SC
ence
marks
and
there's
enough
C
marks
being
applied
to
get
the
360
sender
to
respond?
The
way
it's
supposed
to
is
that
correct?
That's
correct.
F
Hi
Colin
I
I
was
I,
wanted
to
ask
another
document,
question
about
I
believe
the
SAE
draft
had
a
bit
of
a
hand,
wavy
proposal
about
doing
it
from
the
receiver
side,
with
our
wind
and
I
think,
there's
been
a
little
bit
of
discussion
on
the
list
about
doing
a
feedback
mechanism.
That's
either
similar
to
a
CCC
N
or
you
know,
either
option
based
or
a
few
other
ideas.
Could
you
speak
to?
How
do
you
see
the
the
separate
proposals
and
a
separate
bill
'ti
of
different
proposals
in
in
the
upcoming
documents?
Like?
Q
Q
We
put
forward
the
receiver
side
implementation
because
it
was
like
it
has
had
the
least
number
of
changes
on
the
wire
yeah.
It's
not
necessarily
the
best
performing
solution.
Q
We've
also
come
up
with
since
then
something
using
the
NS
bit
to
feedback.
This
information,
which
it's
a
nice
symmetry
with
the
reuse
of
ECT,
one
from
Nantes
I,
think
it
would
also
be
possible
to
use
a
DCP
option,
including
well,
at
least
in
theory.
A
qcn
would
work,
as
is.
O
D
But
once
once
you're
got
us
in
system
congestion,
control
that
recognizes
the
SCE
markings
I
think
it's
very
unlikely
you're
going
to
get
both
at
the
same
time,
I
mean,
as
you
saw
in
the
in
the
percentile
plot,
I
showed
second
side.
Also
the
the
threshold,
the
lower
threshold
level,
the
shallow
threshold
tends
to
be
a
ceiling
for
for
where
your
congestion
control
gets
to,
and
so
you,
if
you're,
getting
some
Cee
marks
as
well.
D
That
means
your
percentile
of
queuing
delay
is
also
going
right
up
into
the
queue,
and
we
just
don't
find
that
so
yeah.
You
know
the
ideas
on
having
a
mixed
signal
and
being
able
to
get
more
information
out.
That
way
might
happen
for
slow
start
or
something
like
that,
but
you
said
you
essentially
don't
want
to
have
that
happening
if
you
want
a
low
delay
congestion
control
anyway,
you
want
to
stay,
you
don't
to
go
and
get
the
seee
signal,
because
then
that
means
you've
effectively
failed
because
you
got
too
far
into
the
queue
so.
P
D
That
was
a
point
I
suppose.
The
question
is
regarding
the
the
behavior
of
tunnels,
with
the
SCE
marking
and
I
have
prepared.
I
had
prepared
a
slide
that
that's
at
the
end
of
my
slide,
set
in
a
spare
slide
to
explain
this
I,
don't
know
whether
you
can
jump
back
to
that,
essentially
up
until
not
that
long
ago,
2010
ish,
because
the
originally
CN
spec
didn't
have
this
extra
transition.
D
All
the
tunneling
specs
for
for
ec
n
did
not
allow
for
the
fact
that
if
you're
marking
or
changing
ET
0
to
ECT
one
inside
on
the
outer
of
a
tunnel
when
it
gets
the
end,
it
will
just
change
it
back
to
zero
again.
So
the
these
graphs
here
come
from
the
time
when
I
got
that
tunnel
mechanism
changed
which
benefits
you,
because
but
I'm
pretty
sure
you'll
find
a
large
number
of
tunnels
on
the
Internet.
Q
D
B
I
want
to
gently
emphasize
the
third
bullet
on
Bob's
slide,
which
is
that
this
is
misbehavior
of
deployed
code.
There's
pre
RFC,
sixty
forty
one
of
the
things
that
us
transport
reviewers
are
trying
to
impress
on
those
who
do
tunnels
as
RFC.
Sixty
forty
is
how
you're
supposed
to
do.
Ec
and
D
cap
period,
yeah.
D
Q
D
A
One
of
the
I
suspect,
I
suspect,
would
be
a
number
of
these
things
to
check
through
as
we
that
we
as
a
document
matures
and
we'll
just
have
to
look
at
them.
I'm.
Please
look
at
the
draft
and
please
and
look
at
the
next
version,
which
you'll
probably
be
and
enough
time
to
actually
and
provide
some
of
the
details.
You've
talked
about
here
and.
B
A
S
A
S
S
The
third
point,
there's
currently
a
draft
that
fills
traits
potentially
used
on
LTE
or
5g
links
and
I've
exchanged
an
email
with
the
author
of
that
draft
to
work
on
coordinating
progress
on
on
this
code
point
also,
potentially
an
FQ
caudal
link.
There
could
be
value
in
having
a
sender
more
packets
as
non
queue,
building,
fq
caudal
as
I
think.
Most
folks
probably
know
already
has
a
mechanism
to
identify
sparse
flows
and
give
them
a
priority
treatment
in
in
the
the
scheduler
at
EQ
time,
yeah,
but
potentially
marked
NQ,
be
marked.
S
Flows
could
be
given
a
slightly
different
treatment
and
an
F
Q
system,
potentially
disabling.
The
coddle
packet
drops
to
allow
those
non
congestion,
control
flows
to
not
experience,
coddle
coddle
induced
to
drop
them
now,
just
go
back
to
the
goals
again.
I
mentioned
the
first
one.
The
other
two
goal
here
is
that
this
code
point
is
not
conveying
a
value
judgment
or
an
expression
of
relative
importance
of
the
traffic
relative
to
other
traffic
moment
on
the
network.
S
It's
intended
to
describe
a
verifiable
behavior
of
the
traffic,
and
so
as
a
result
of
that,
the
intention
is
that
there
would
not
be
an
incentive
for
applications
to
miss
mark
their
travel.
All
right
next
slide.
Thank
you.
So
the
use
case
above
already
Bob
Brisco,
already
mentioned
that
we
are
supporting
l4s
in
DOCSIS
3.1
in
the
Box
on
the
lower
right.
There's
a
link
again
to
the
informational
draft
that
we
submitted
that
describes
the
use
of
l4s
in
doctors
and
also
the
pointer
there
to
the
shoe
protection
algorithm.
S
So
the
diagram
at
the
upper
right
shows
the
functionality
here
ever
set
of
classifiers
that
map
incoming
packets
into
either
the
little
HC
key
or
the
classic.
You
in
DOCSIS
3.1
we're
looking
at
either
the
diffserv
code
point
being
this
nqb
value
or
the
packets
are
marked
with
e
CN,
with
ECT
one
value
or
c
e,
and
that
would
direct
a
packet
towards
the
low
latency
Q,
all
over
packets.
S
That
flow
through
that
or
or
destined
for
the
little
hcq
flow
through
a
queue
protection
algorithm,
which
there's
a
little
bit
of
discussion
on
that
on
the
list
as
well,
as
is
mentioned
previously
in
this
session,
and
the
goal
of
that
algorithm
is
to
track
the
latency
of
the
Luigi
queue.
If
there
is
a
cutest
order
to
form
there
to
identify
the
flow
or
flows
that
are
causing
that
and
to
redirect
the
packets
from
those
flows
to
the
classic.
S
Ok
next
slide,
so
the
definition
of
a
non
queue
building
flow.
So
the
idea
here
is
that
again,
this
is
a
non
congestion,
controlled
flow
and
by
marking
itself,
as
nqb
is
claiming
that
it
will
not
cause
a
queue
in
the
network,
in
other
words,
it's
sending
at
a
relatively
low
peak
data
rate
such
that
it
it
expects
that
it's
going
to
remain
below
the
available
capacity
in
the
path.
S
Nonetheless,
if
such
a
flow
does
cause
queue,
build
up,
the
expectations
for
the
source
should
be
that
it
may
suffer
some
consequences
in
that
case.
So,
in
the
l4s
case,
with
queue
protection,
the
mismarked,
packets
or
packets
that
were
marked
non
q
building
but
or
causing
the
queue
to
form
would
be
classified
to
the
classic
you
and,
as
a
result,
they
may
see
higher
latency.
They
might
may
arrive
out
of
order
from
some
of
the
other
packets
in
that
flow.
That
may
have
gone
on
a
little
late,
CQ
in
the
case
of
LTE
or
5g.
S
This
is
a
suggestion.
I
guess
it
that
sucked
well
missed
more
packets
in
in
that
case,
may
see
higher
loss
question
mark
there,
because
that
is
not
an
aspect.
That's
been
discussed
in
detail
in
the
in
a
Lola
graph,
but
we
would
work
on
integrating
the
right
treatment
for
that
scenario
as
well
and
then,
finally,
in
fq
caudal,
supposing
that
the
implementation,
fq
caudal,
does
disable
carl
packet
drops
or
n
QB
flows
due
to
the
fact
they're,
not
congestion,
controlled.
S
S
Qb
would
likely
have
a
greater
chance
of
achieving
ultra-low
queuing
delay
and
in
more
network
conditions,
so
that
the
three
requirements
listed
here
that
a
node
supporting
the
n
QB
per
hop
behavior
must
cue
the
non
Q
building
traffic
separately
from
the
Q
building
traffic.
The
second
one
is
not
currently
in
the
draft,
but
would
say
this
Q,
this
n
QV
q
should
disable
the
a
QM
induced
packet
ROPS
for
the
n,
QV
mark
packets
and
then
the
third
requirement.
S
S
D
B
T
O
A
Cute
and
the
penalty
I
guess
the
Greg
identify
D
is,
it
could
be
higher
loss
and
it
could
also
be
the
last
one
and
it
could
just
Billie's
all
cute
and
therefore
suffer
greater
delay,
because
it's
done
it
this
way.
Okay,
thank
you,
and
my
guess
is
that
that
and
the
other
things
here
will
actually
require
a
bit
of
work
as
we
go
forward.
If
we
decide
to
do
this
work.
This
is
something
interesting
to
figure
out
how
all
these
things
for
two
different
environments-
I'm
Greg,
I'm
gonna,
go
back
to
the
slide.
S
Right,
yes,
so
the
proposal
here
is
to
assign
a
particular
code
point:
that's
currently
unassigned
the
value,
a
hex
QA
or
decimal
42.
This
is
currently
unassigned
in
the
gifts
of
code
point
pool
one
that's
set
aside
for
standards,
action
and
the
reason
we're
suggesting
that
this
would
be
a
particularly
good
code.
S
With
this
code
point
also
many
Wi-Fi
ApS
commonly
map
diffserv
code
points
into
wmm
access
categories,
using
the
first
three
bits
of
the
district
code
point
a
little
table
on
the
lower
right
shows
some
common
defaults
Wi-Fi,
and
so
this
cook
choice
of
this
code
point
would
again
align
it
with
EF
expired
forwarding
as
well
as
voice,
admit
and
cs5
in
going
in
the
video
access
category,
which
is
a
lower
latency
media
access
on
Wi-Fi
as
well.
Okay,.
B
Greg
I've
got
it
I've
got
it
to
do.
This
is
David
again.
I
have
a
to-do
item
for
you
next
version
this
draft,
please
please
read
our
FCAT
3:25
and
write
up
how
this
interacts
with
what
was
done
there
on
diffserv
to
to
to
you.
P
mapping
you'll
want
a
normative
reference,
283
25
and
let's
not
go
down
that
rathole
now,
but
it
does
make
changes
to
those
defaults.
Yeah.
Q
S
That
my
understanding
is
are
not
widely
implemented
if
at
all,
and
so
this
is
kind
of
a
a
way
that
this
mechanism
would
fit
into
existing
Wi-Fi
quality
of
service
mechanism.
Tell
you
it
wasn't
the
goal
really
of
the
definition
that
any
QB
exactly
aligns
with
the
way
scheduling
is
done
in
Wi-Fi,
ApS
and
Wi-Fi
stations,
but
it's
a
useful
by-product,
I.
Think
of
n.
M
O
A
B
K
B
S
The
updates
for
this
draft,
so
the
original
draft
was
submitted
as
an
informational
draft
and
I
promoted.
This
version
two
standards
crack
and
added
the
requirement
statements
that
were
listed
on
the
previous
slide
as
well
as
writing
it
as
a
proposal,
and
then
there
was
a
fair
amount
of
new
texts
added
into
the
comparison
for
the
person
to
existing
approaches.
Section
I
update
the
discussion
on
fq
coddled
as
a
result
of
the
comments
on
the
list.
S
I
also
added
a
discussion
of
a
couple
of
other
existing
approaches
that
were
I
was
made
aware
of
the
heavy
hitter
filter
in
Linux
is
one
and
the
dynamic
packet
prioritization
mechanism,
but
that
cisco
supports
on
some
of
this,
which
is
mentioned
both
of
those
then
I
added
the
ionic
considerations
and
security
considerations.
Ok,.
S
U
R
Colligan,
it
would
be
in
your
discussion
about
Cisco
heavy
hitter
in
Cisco
DPP
you're
you're,
commenting
about
their
method
in
which
they're
identifying
mice
forces,
elephants,
I,
said
simply
looking
at
packet
or
by
counts.
But
you
didn't
provide
a
reference
to
anything.
They
use
a
more
accurate
measure
of
elephants
or
is
there
do
you
have
such
a
reference.
S
U
A
U
A
I
have
a
question
for
the
group
who,
in
the
room,
has
read
the
nqb
internet
drafts.
If
you
put
your
hand
up,
if
you've
read
them,
half
a
dozen
okay
and
all
those
people
and
or
anyone
else,
and
do
you
think
this
is
an
interesting
problem?
I
think
I'd
like
to
take
a
hum
as
to
whether
the
problem
rather
than
the
draft
is
something
that
we
should
be
looking
at
further.
A
B
A
A
This
is
an
individual
draft
I'm
something
a
little
bit
different
and
those
of
you
know
my
history.
It's
wonderful
to
see
the
word
DC
CTP
from
the
chairs
position.
Yes
again
and
oh
you're,
probably
going
to
tell
a
story
which
is
actually
more
useful
than
just
reminiscing.
Can
you
oh
yeah,
just
me:
we
need
to
do
as
one
more
thing.
So
just
wait.
A
A
second
and
the
first
thing
that
I
would
like
to
announce
is
that
the
tiny
mt-32
draft
and
which
you'll
remember,
was
it
used
to
put
a
document
for
the
chord
contribution
from
Vincent?
We
would
like
to
adopt
this
in
the
working
group
because
we've
adopted
the
original
document.
So
if
you
have
comments
on
this,
please
send
comments
to
the
list.
We
are
proposing
adoption
as
chairs
of
that
item.
B
Right
so
in
essence,
what
we
absent
comments,
it
will
be
it
it
will
be
adopted
because
it
solves
a
problem
that
I
wrote
that
the
rosy
is
G.
The
other
thing
to
announce
is
that
presentation
about
to
see
was
one
of
about
half
a
dozen
presentations
on
new
work
we
were
or
other
drafts
would
have
liked
to
accommodatin,
can't
so
I
suspect
going
to
ask
for
four
hours
next
IETF
and
with
that
said,
please
take
the
mic.
V
I
want
to
talk
about
multipath,
DC
CP,
which
extends
the
well
standardized
datagram
congressional
control
protocol,
and
we
want
to
use
it
for
anything
transfer
of
a
UDP
or
IP
traffic
or
well
multiple
data,
part
in
multi
connectivity
networks,
and
that
is
also
subject
of
three
drafts.
We
submitted
right
for
this
meeting.
He
makes
you
talk.
A
V
So
what
is
what
is
our
motivation,
so
the
main
motivation
or
multi
access
networks
which
we
can
use
to
provide
higher
bandwidth,
which
you
can
use
to
provide
a
better
quality
of
service
which
you
can
use
for
resilience
against
outages
and
I?
Think
well-known.
Multi
access
network
architecture
is
on
the
bottom
that
it's
hyper
Texas,
which
was
already
discussed
at
ITF,
but
provides
multi,
X's
multi
connectivity
for
residential
customers
by
combining
fixed
end
and
cellular
access
inside
a
home
gateway.
O
V
So
we
cannot
say
anymore
that
we
can
use
multiple
TCP
to
cover
any
traffic
for
for
multiple
transmission.
So
we
need
something
else
so,
but
first
of
all
the
demand,
but
what
we
see
multi
connectivity
should
cover
the
whole
IP
traffic
mix
in
which,
as
I
stated,
TCP
loses
its
dominating
role
because
of
earthquake.
So
what?
V
V
Finding
from
multiple
TCP
is
that
it's
a
congestion,
control
and
power
beneficially
a
benefit
low
traffic,
splitting
multipath
support
for
UDP
or
even
IP
does
not
exist
so
far,
UDP
or
IP
encapsulation
into
multicast.
You
see
P.
That
was
something
that
was
discussed
some
some
years
ago.
It's
not
an
option,
as
it
would
impose
reliable
in
order
delivery.
V
I
Yeah,
you
know
I
just
I
just
wanted
to
say
thank
you
for
bringing
this
up,
Spencer
Dawkins,
probably
as
an
individual
on
this.
So
you
know
the
the
suggestion
that
I
could
make
fairly
early
in
this
conversation
is
be
thinking
about
whether
you
need
multipath
IP
or
whether
multipath
UDP
would
do
be
everything
you'd
need.
The
high
order
bit
for
me
is
that
this
is
a
hard
problem
and
solving
it
one
for
in
letting
transports
use
the
one
way
you've
solved.
I
V
I
Know
so
if
it
was
possible
for
somebody
to
work
on
this
without
annoying
the
people
in
the
quick
working
group
and
every
other
working
group
that
is
going
to
want
to
do
multipath.
This
seems
like
a
really
a
really
helpful
suggestion,
or
you
know,
maybe
a
good
place
to
dig
for
a
while.
Thank
you,
yeah.
V
Thank
you
for
your
comment
on
this,
but
not
the
path,
quick
or
quick
is
also
part
of
my
slides
at
soon.
I
will
come
to
this
right
now,
yeah,
why
not
using
multiple,
quick
instead
so
far,
multipath
quick
from
at
least
from
my
perspective.
It's
a
reliable
and
end-to-end
encrypted
protocol
and
its
application
for
enabling
multi-part
transfer
for
UDP.
More
quick
traffic
only
works.
If
we
apply
it
has
a
quick
tongue
meant
by
multipath,
quick,
so
that
is
depicted
in
this
in
this
picture.
V
If
you
could
send
even
quick
as
guest,
then
we
have
encrypted
over
encryption
and
yeah,
and
then
we
have
flow
control
over
control,
congestion,
control,
work,
again
control
and
so
on,
yeah,
and
that
also
fits
for.
If
you
would
send
TCP
through
quick
yeah,
then
as
I
said,
we
have
this
flow
control
over
control
and
and
so
on.
So
I
think
that
should
be
the
preferred
way
to
go,
or
we
have
to
change
quick
and
multi-part
quick
so
that
I
have
in
the
back
up
a
slide.
So
you
can
check
this
offline.
V
What
we
would
what
we
proposed
to
change
Creek
accordingly
and
yeah.
What
we
proposed
is
multi
pass
or
a
DCP
and
a
framework
for
it.
So
that
is
subject
of
the
three
trough.
So
maybe
you
can
check
it
so
more
or
less
you
can
compare
both
multipass
TCP
is
or
multiple
TCP
manage
several
TCP
flows,
and
we
say
now
or
instead
of
using
TCP,
we
switch
to
DCP
so
multiply.
V
This
is
managed
several
TCP
flows
and
if
you
put
this
inside
a
encapsulation
scheme,
encapsulation
framework,
so
that
is
a
subject
of
the
second
draft
we
proposed
and
then
we
make
it
UDP
or
IP
capable.
So
you
can
trust
decide
by
routing.
If
you
want
to
use
the
multi
path,
this
is
the
keys
or
whenever
we
send
a
Nike
or
UDP
packet
towards
this
virtual
network
interface,
then
we
bring
it
to
multiple
pieces,
apiece
or
multiple
cities.
V
V
Then
we
have
to
apply
a
some
reordering
mechanisms
and
that
is
compared
to
multi-part
tcp,
something
new
and
let
us
where
we
have
to
put
the
intelligence
yeah
and
the
last
draft
is
dealing
with
how
we
can
traverse
middle
boxes
which
cannot
handle
this
is
City,
and
that
is
pretty
much
likely
in
today
in
in
the
Internet
today.
So
most
of
the
middle
box,
we
can
assume
will
not
handle
DCP
and
maybe
they
even
work
it.
V
So
we
found
a
solution
of
you,
propose
a
solution
to
change
the
TCP
header,
so
send
it
through
convert
or
rearrange
the
header
a
little
bit
without
losing
any
information
without
introducing
extra
overhead.
So
that
looks
like
UDP
that
we
can
traverse
any
middle
box
which
exists
today
and
which
understands
UDP
or
at
least
accept
UDP,
so
just
to
give
you
some
effect
or
a
summary
of
what
we
have
already
reached.
So
in
principle
we
can
say
this
architecture
is
IP
and
UDP
capable
and
leverage
the
standardized
TCP.
V
The
architecture
can
be
applied
for
load,
balancing
for
seamless
handover
in
traffic
splitting
or
exactly
what
is
at
rest.
For
example,
in
this
sleeve
TVPA
TSSs,
it
does
not
impose
any
other
transfer
characteristic
than
congestion
control,
and
that
is
pretty
important.
If
you
talk
about
IP
or
UDP
transmission,
it
would
not
be
supportive
if
we
would,
we
would
apply
flow
control
or
real
or
reliable
transmission.
It
uses
TCP
tunnel
per
path,
leveraging
the
congestion
control
for
efficient
traffic
distribution,
so
that
is
similar
to
multipass,
tcp,
so
more
or
less.
V
We
can
state
that
the
sender
side
of
multiple
seasons
if
he
is
like
multipath
TCP,
a
prototype,
is
available
Linux
past,
and
so
we
implemented
everything
in
the
in
the
Linux
kernel,
but
it
is
not
published
yet
so
it's
just
an
internal
prototype
and
be
covering
all
the
three
IDF
drafts
inside
this
prototype.
The
implementations
further
comprises
a
modular
scheduler
scheme,
as
you
have
seen
in
the
picture,
so
we
have
several
schedulers
implemented
and,
as
I
said,
it's
comparable
to
multipath
TCP,
but,
and
that
is
new.
V
So
there's
already
something
available
in
any
three
years
as
well.
Yes,
stammering
out
work
yeah,
it
is
challenging,
and
that
was
I.
Think
what
what
you
have
already
stated
and
to
develop
a
multi-part
protocol
for
transmission
of
unreliable
traffic
like
UDP
and
IP,
compared
to
multipath
TCP,
as
I
said
several
times,
the
reordering
becomes
a
critical
part
when
a
linux-based
prototype
was
develop
and
evaluate
it
successfully
and
results
will
be
published
as
soon
as
a
paper
independent
of
the
multipath
TCP
proposal
and
its
success
here
at
ITF.
V
If
we
would
go
for
for
a
quick
or
a
multipath,
quick
solution
to
cover
multi-part
UDP
transmission,
the
challenge
for
unreliable
multipath
exists
is
exactly
the
same
and
could
profit
from
the
multiple
TCP
findings.
We
already.
We
already
earned
it,
and
my
expectation
today
is
to
get
some
feedback
from
you
who
have
maybe
an
intensive
discussion
on
the
TSB,
w
xi
mailing
list,
and
maybe
I,
have
the
chance
at
the
next
ITF
to
give
you
an
extended
presentation
about
what
we
developed
about
to
find,
and
so
just
before
you
put
some
questions.
A
W
V
Yeah
sure
so
in
case,
so
let's
jump
back
to
the
architecture.
So
in
case
we
would
send
VP
traffic
through
this
multiple
CCP
and
blitz,
this
UDP
traffic
over
different
paths
and
they
have
different
licensees.
So
the
packet,
the
packet
stream,
gets
trembled
and
we
kind
of
assumed
trust
because
we
use
UDP
that
we
do
not
have
to
care
about
this,
and
so
we
have
to
reorder
it
to
some
extent
whatever
it
means,
but
I
think
it's
not
necessary
to
do
it
like
TCP
today,
so
random
or
just
art.
J
P
I
B
B
X
A
The
former
dtc
feature
we
talked
about
that
hockey,
DC
CP
islam,
but
thank
you
ever
so
much
for
bringing
this
here
and
I.
Look
the
DC
CP
come
back,
but
I
think
the
the
greater
thing
is
underneath
the
idea
of
doing
congestion
control
with
UDP
of
a
multipath
and
how
do
we
bring
these
together?
This
is
this
is
a
really
interesting
area.