►
From YouTube: IETF-DETNET-20230621-1200
Description
DETNET meeting session at IETF
2023/06/21 1200
https://datatracker.ietf.org/meeting//proceedings/
A
A
A
A
B
B
A
Okay,
great
and
we
know
from
discussion
in
a
past
meeting,
the
csqf
uses
the
same
mechanism
in
the
data
plane.
The
same
sched
scheduling,
queuing
mechanism
on
the
Node,
but
has
a
has
a
different
control
mechanism
and
passes
different
information
between
the
notes,
but
I,
don't
know,
don't
know
yet
what
we
ought
to
do
about
drafts
to
recognize
that.
B
A
C
A
A
D
I
think
this
setting
is
obvious,
so
I
will
go
to
the
next
item.
For
the
item
support
large
single
propagation
latency
is
yes,
because
the
the
link
delay
is
nationally
considered
during
this
calculation,
that
is
to
determine
the
Tas
transmission
data
window
position
under
GCL
is
independently
is
stored
on
each
node.
A
D
D
F
It
sounds
like
you
refer
to
a
particular
use
of
IEEE
added
to
Define
qbd,
so
which
is
the
enhancements
of
scheduled
traffic,
because
she
said
generous,
outfellow
and
so
on.
But
the
enhancements
for
scheduled
traffic
provides
you
some
form
of
programmable
machine,
so
it
can
be
used
in
one
or
another
way.
For
example,
you
can
even
with
some
other
extensions,
create
a
cqf-like
behavior
with
this
enhancements
or
scheduled
traffic.
D
F
I
think
it's
just
understood
that
you're
using
Tas
or
802.1
qbv,
which
is
the
project
name
of
p802.1
qbv.
It's
enhancements
for
scheduled
traffic,
so
standard
does
not
contain
cas
and
it
can
be
used
in
various
ways.
But,
for
example,
in
3.7
you
say:
delay
Jitter
is
Alpha
low
and
it
really
depends
on
how
you
use
the
gate,
control
lists,
and
my
question
is
therefore:
do
you
assume
802.1
qbv
is
used
in
a
Time
division,
multiplexing.
A
I
believe
he
already
said
yes
to
that
question.
Oh
okay,
I
didn't
hear
this
yeah
I'm
pretty
sure
he
said
yes
to
that
question
and
beyond
that
there's
a
separate.
We
had
a
separate
discretion
of
the
prior
meeting
about
cqf.
So
if
Tas
were
used
to
implement,
cqf
I
would
I
would
suggest
referring
to
evaluation
of
cqf.
F
B
F
A
D
A
G
A
All
right,
it
sounds
like
that
might
be
something
that
would
be
useful
to
add,
because
if
I
understand
what
xiaofu
has
written,
he
said
that
Tas
will
not
scale
to
a
large
number
of
flows,
because
the
control
plane
problem
is
very
bad,
but
Tas
per
traffic
class
will
scale
to
large
number
of
flows
by
virtue
of
traffic
classes
and
I.
Guess
we
need
something
in
the
requirements:
draft
to
talk
about
use
of
traffic
classes
versus
individual
flows.
Does
that
make
sense.
H
Yes,
but
I
have
a
question
or
concerned
about
to
evaluate
TS
because
in
my
mind
as
I
know,
I
don't
see
any
extension
to
TS
to
use
in
a
large
scale
Network
if
I'm,
not
wrong,
I
think
in
most
people's
mind
they
think
it
can't
be
used
in
the
last
skill
Network
so
and
there's
no
just
trial
or
more
work
on
that.
So
we
can
just
give
them
inference.
I
think.
A
I,
don't
think,
there's
a
problem.
There
I
mean,
for
example,
there
are
two
clear
nodes
in
the
evaluation
column
which
suggests
the
Tas
and
large-scale
network
is
not
going
to
work.
However,
one
of
the
purposes
of
this
exercise
is
to
better
understand
the
requirements
draft
and
that's.
Why
that's
why
I'm
raising
this
here,
because
I
would
not
be
at
all
surprised
to
see
traffic
class
versus
individual
flows
turn
up
in
the
evaluation
of
some
of
the
new
mechanisms
that
are
appropriate
for
large-scale
Networks.
H
A
And-
and
the
concern
is
completely
valid,
I
in
in
encouraging
this
evaluation
exercise,
I'm,
not
believing
that
any
of
the
TSN
mechanisms
are
going
to
be
completely
super
large-scale
networks,
but
it
does.
It
does
serve
the
purpose
of
understanding
where
the
gaps
are
and
where
we,
where
some
refinement
requirements
draft,
will
help
us
work
through
the
new
mechanisms.
B
That
I'm
a
little
bit
surprised
of
of
bringing
in
traffic
classes,
so
I'm
I'm
not
quite
sure
that
we've
done
that
in
the
past
or
or
as
goals
right,
I
think
I
when
I
was
talking,
for
example,
about
tcqf.
I
was
just
saying
that
the
scaling
behavior
that
we
achieve
is
similar
to
that
what
we
have
with
with
traffic
classes,
but
that
was
just
meant
as
as
a
comparison
form,
but
not
as,
as
you
know,
specifically
saying
that
here
there
is
a
dead
net
idea
for
traffic
classes,
which
I
don't
think
we
have.
H
D
B
Isn't
that,
rather
than
what
what
I
would
be
calling?
What
I
think
I've
also
seen
in
other
papers
being
called
priorities
in
in
terms
of
that
an
individual
flow
belongs
also
to
a
traffic
class,
and
then
the
behavior,
the
the
latency
throughput
or
whatever
it
is.
Four
different
traffic
classes
is
given
different
parameters
there.
So
it's
not
independent
of
the
per
flow
Behavior,
but
it's
an
additional
parameter
of
each
flow.
D
Okay,
I
think
the
policy
to
write
the
TS
mechanism
is
actually
operator
based
on
eight
of
trump
class
and
multiple
flows.
Consider
a
single
two
specific,
a
publicist
specific
coup,
for
example
the
flow
one
to
a
floating
concealer,
the
the
the
glue
with
a
specific
type
of
class,
but
but
the
flu
one
and
the
flu
return.
And
why
would
the
simulate
at
the
different
time
so
there
arrive
at
the.
D
B
C
D
B
Okay,
but
but
isn't
it
true
that
we
okay,
so
in
the
control
plane
we
we
need
to
capture
per
flow
information
and
calculate
per
flow
which
which
each
flow
given
a
traffic
class
and
then
in
the
forwarding
plane
we
have
like
in
you
know
the
the
derived
solution,
like
cqf,
tcaf
and
so
on.
We
only
have
the
the
different
traffic
classes.
A
F
A
Okay,
all
right
so
I
think
the
the
evaluation
is
reasonable
and
I
think
we
do
need
to
say
as
this
as
mentioned
earlier,
do
you
need
to
say
something:
the
requirements,
draft
about
use
of
traffic
classes
and
flow
and
and
flow
aggregation
for
scalability?
Okay,
let's
go
ahead
and
move
on
to
high
utilization.
Thank
you.
D
D
D
A
D
D
A
D
F
D
D
F
F
Yeah,
okay,
if
it's
just
just
to
give
you
a
hint
if
it's
the
paper,
where
CBS
and
ATS
are
entertained
for
the
same
traffic
class
in
the
same
Bridgeport
or
end
station
port,
this
is
nothing
that
is
specified
by
electrically
802.1
Q,
this
combination,
so
this
mechanism
is
not
standardized.
This
combination.
D
F
D
D
D
D
G
A
D
A
I
A
I
B
A
B
But
you
do
know
that
I
had
proposed
on
at
last
ITF
meeting
a
draft
which
had
a
more
detailed
list
of
evaluation
criteria
here
right
without
making
that
be
necessarily
each
of
these
criteria
be
a
requirement
and
I
think
that
that's
in
an
easier
starting
point
than
to
coming
up
to
these
evaluation
judgments.
That's
that's
I!
Think
what
I'm
a
little
bit
struggling
with.
A
Let's
see
I
need
to
choose
words
careful
here,
I'm,
looking
to
make
progress
with
some
initial
evaluation
that
is
tractable
and
comprehensible
across
a
variety
of
mechanisms.
We're
going
going
to
be
looking
at
so
at
the
moment.
I
I
think,
let's
see
put
another
way,
I
greatly
appreciate
the
depth
of
the
draft.
You
wrote
to
our
list,
but
at
this
point,
I
want
to
make
sure
that
we've
encompassed
the
breadth
of
the
proposals,
perhaps
before
diving
into
that
depth.
A
H
Some
points
here,
one
question
that
if
we
only
use
CBS,
can
it
guaranteed
latency.
For
example,
if
we
see
the
result
of
the
chat
with
some
of
the
evaluations,
results
were
yes
and
some
of
them
were
partial,
so
it
will
give
impression
that
it
may
be
used
into
the
SQL
Network,
but
it
may
has
its
own
problems,
such
as
latency
guarantee
and
also
some
efficiency
issues.
I
think
that's
one
of
the
point
and
the
second
one
is
that
I
recognize
the
requirements.
3.4.
H
H
For
this
point
it
means
if
there
is
no
more
bandwidth,
can
be
used
into
for
the
and
then
that
flows,
how
it
can,
what
more
work
can
be
done
to
to
schedule
a
schedule,
the
the
the
capability
and
now
I
think
maybe
there's
a
little
problem
for
the
requirement
to
draft
for
this
point.
So,
oh,
it's
led
to
the
results
that,
for
example,
for
for
this
one.
A
H
Yes,
and
for
this
point
it's
it
says
if
the
thing
as
flow
doesn't
send
packages
depend
with
his
waste,
so
so
so
I
mean
the
a
different
to
evaluate
for
this
point.
But
maybe
that
point
has
its
own
problem
and
not
so
some
major
in
at
this
stage
and
I
will
think
more
about
this
point.
For
this
requirement.
D
H
Okay,
okay,
sorry,
I
I
I
understand
what
do
you
mean?
You
use
the
same
evaluation
method,
but
I
really
don't
get
two
requirements
of
this
one,
but
I
don't
mean
their
quantities
is
cracked.
Now
you
mean
that
the
to
reach
a
high
utilization
of
the
bandwidth
right,
but
now
in
the
text
it
it
says,
if
the
for
example,
more
than
17
17
percent
or
just
up
to
100,
and
how
to
how
to
how
to
treat
more
flows
of
it.
A
H
B
With
respect
to
the
requirements,
looking
here
at
CBS,
I
think
the
one
big
thing
we're
missing
is
a
requirement
about
Jitter
that
is
lower
than
you
know:
the
maximum
latency
minus
the
physical
link,
propagation
latency.
So
because
I
think
that's,
that's
the
the
key
differentiation,
of
course,
between
the
current
asynchronous
mechanisms
like
CBS
and
the
most
infamous
mechanisms
which
is
most
of
the
others.
B
So
I
think
that's
that's
something
we
need
to
add
in
the
requirements
and
the
evaluations
and
then
going
back
to
the
evaluation
overall
here.
I
think
the
problem
that
that
we
have
with
this,
which
is
I,
think
an
excellent
you
know
understanding
from,
or
you
know,
that's
very
good
that
these
evaluations
were
done
here
on
this
basis,
that
CBS
and
tests
are
by
themselves.
B
I.
Think
not
not
really.
Mechanisms
in
in
the
way
I
think
I
would
have
imagined
mechanisms,
but
rather
the
building
blocks
right
so
in
terms
of
tasks
being
building
blocks
that
can
be
used
for
tdma
or
for
cqf
and
CBS
being
building
blocks
for
and
I
think.
That's
the
question:
what
what
what
are
the
profiles
of
that
other
than
APS
right?
B
A
F
B
C
A
A
B
Yeah
and
I
think
it'd
also
impact
3-7
right.
If
we
remove
any
any
shaping,
then
three
seven
will
also
be
even
more
difficult,
but
in
any
in
any
case
how,
however,
we
adopt
the
evaluation
right,
as
Johanna
said.
If,
if
ATS
is
a
separate
spec
and
the
reshaping
of
ATS
is
really
you
know
not
within
the
scope
of
CBS
proper,
then
we
should
assume
CBS
evaluation
without
it.
A
J
A
H
J
A
H
H
D
D
H
D
Because
the
traffic
engineer
passed
the
underground,
the
the
possible
the
access
and
the
work
that
are
located
in
the
network
and
the
bug
bone
Network
I
in
this
networks,
the
link
speed
are
different.
So
the
proposal
mechanism
should
support
the
the
end
to
work
between
the
higher
linger
speed
under
the
low
ending
speed.
H
H
H
D
A
A
K
K
G
A
A
K
So
I'm
very
grateful
of
the
working
group
to
give
me
the
opportunity
to
present
a
draft
that
we
published
a
few
weeks
ago.
This
draft
is
entitled
and
Crossing
end-to-end
delay
bounds.
They
are
queue
resizing.
This
is
a
joint
work
with
my
colleagues
and
Sebastian.
Polos
are
listed
in
the
draft
and
I
will
take
the
opportunity
of
the
presentation
today
to
present
you
this.
This
draft
I
will
use
a
very
original
agenda,
as
I
will
follow
the
structure
of
the
document.
K
So
you
know
where
we
stand
at
three
given
points
in
the
presentation
with
no
further
Ado
I
will
go
to
the
introduction,
so
I
guess
people
in
the
ihcf
that
networking
group
are
already
aware
that
there
are
some
use
cases
for
deterministic
networking
and
for
bounded
latency
over
large
scale
networks,
because
otherwise
you
would
not
have
the
discussion
we
had
today.
One
of
the
use
cases
that
we
see
in
the
consumer
market
for
bounded
delay
without
the
digital
constraint
is
online
gaming.
K
So
this
is
a
main
draft
ID.
We
cover
this
gap
between
TSN
or
determatic
IP
Technologies,
which
are
used
to
enforce
those
latency
and
Jitter
guarantees
at
a
cost,
sometimes
centralized
management,
and
it
was
synchronization
in
small
scale,
Network
complex
screen
management,
complex
traffic,
shaping
mechanisms
and
more
traditional
quality
of
service
enforcement
mechanisms
that
enforce
latency
properties
on
average,
for
instance
with
active
fuel
management.
You
can
variety
you
in
order
to
meet
some
delay
Targets
on
average,
but
not
in
absolute.
So
we
are
in
between
those
two
families
of
solutions.
K
Okay,
so
bounding
a
at
the
switches.
So
first
I
need
to
show
you
what
are
the
rationals
behind
our
ID
to
to
perform
end
to
end
delay
enforced
and
to
any
delay
bounds
by
acting
on
the
Q
depths.
In
fact,
this
is
from
Network
calculus.
We
know
that
if
cues
are
served
as
first
in
first
out
and
and
the
buffer
as
a
capacity
that
is
given
by
pe
to
the
k,
the
delay
can
be
expressed
as
t0
plus
the
capacity
overall,
the
committed
information
rate.
K
If,
if
we
have
a
fixed
committed
information
rate,
so
this
is
a
substrate
only
so
in
the
following.
If
we
take
the
committed
information
rate
as
a
static
value
and
we
adapted
buffer
capacity
by
changing
the
buffer
capacity,
we
can
act
on
the
worst.
You
delay.
So,
for
instance,
here,
if
we
increase
the
capacity
of
the
queue
there
must
be
capacity,
delay
is
increased
if
we
decrease
the.
If
you
want
to
decrease
the
delay,
we
have
a
decrease
in
the
buffer
capacity.
K
So
we
took
from
this
idea
and
looked
at
the
python
architecture
for
switches,
and
if
you
look
in
the
base
architecture-
and
you
look
at
the
packet
forwarding
engine,
you
can
you
can
abstract
the
packet
programming
engine
as
a
set
of
cues.
That
can
be
of
variable
capacity
that
are
served
by
scheduler
and
the
scheduler
can
adopt
a
set
of
this
of
disciplines
for
serving
the
different
cues.
One
of
those
disciplines
is
a
deterministic
from
grabbing,
meaning
that
each
fuse
is
served
for
a
specific
period
of
time
over
over
a
period.
K
So
if
we,
if
we
combine
those
viable
buffer
capacities
and
and
random
database
from
Adobe
to
schedule
a
discipline,
then
we
can
have
Express
the
maximum
surgeon
time
of
packets
in
use
as
a
formula
that
is
given
at
the
bottom
of
the
slides
here.
So
the
maximum
delay
is
constant
t,
0,
plus
plus
Factor
here
that
depends
on
the
capacity
of
the
queue
so
now
that
we
presented
how
adapting
the
before
capacity
can
help
enforcing
the
delay.
K
Whenever
a
requests
foreign
capacity
allocation
arrive
at
the
node,
either
the
risk
capacity
in
a
queue
that
and
the
node
can
respect
a
delay
contract
that
is
compatible
with
the
end-to-end
delay
reservation
that
is
requested.
So
that's
fine.
We
just
place
a
temporary
reservation
and
we
are
good
to
go,
but
if
we
are
in
two
permanent
cases,
we
look
at
the
thresholds
first.
The
first
programming
cases
is
that
we
can't
serve
the
reservation
for
a
flow,
because
the
the
delay
that
is
requested
to
that
the
flow
needs
respect
is
too
low.
K
So
I
made
the
schema
to
to
present
those
mechanisms.
So
this
is
the
adaptation
of
the
queue
to
meet
the
delay
constraint.
So
here
we
see
that
this
queue
is
occupied
below
the
minimal
occupancy
threshold.
We
see
a
demand
arriving
here
for
end-to-end
delay,
that
is
40
milliseconds.
The
qcon
serves
end-to-end
delay
for
50
milliseconds
and
there's
been
more
contractors
to
50
milliseconds.
We
are
going
to
reduce
the
capacity
in
order
to
meet
the
maximum
end-to-end
delay
for
the
queue
and
accommodate
the
your
reservation
that
is
requested.
K
On
the
other
hand,
if
now
we
have
a
q
that
is
nearly
freely
occupied
by
a
set
of
reservation
and
see
your
demand
arriving
for
capacity
that
exceeds
the
capacity
of
the
cube.
We
look
at
the
minimal
contract
for
ongoing
reservation
in
the
queue
here.
We
compare
it
with
the
maximum
end-to-end
delay,
for
instance.
Here
there
is
a
difference
by
10
millisecond.
We
can
increase
the
capacity
of
the
queue
while
meeting
the
minimum
contract
and
push
and
accommodate
the
reservation
that
we
received
okay.
So
this
curing
adaptation
system
is
in
maybe
very
simple.
K
So
I
will
present
the
three
name
mechanism
we
put
in
place
by
taking
as
an
example
the
network
that
is
presented
here.
So
we
imagine
that
node
a
wants
to
use
a
reservation
protocol
to
send
a
reservation
resource
reservation,
request
to
node
f
for
a
flow
for
which
the
maximum
end-to-end
delay
requirement
is
85
milliseconds
and
the
maximum
capacity,
including
the
burst
of
the
flow,
is
2
megabits
per
second,
so
I'm
going
to
present
the
signaling
mechanism
I'm
going
to
present
the
first
from
RSVP
in
two
ways.
K
K
So
there
are
some
document
defining
the
behavior
or
rgp
and
the
multi-pass
environment,
and
we
didn't
find
it
I
would
be
very
happy
if
you
have
a
pointer
to
such
a
document
somewhere
and
in
our
mechanism.
We
allow
either
the
destination
or
the
source
to
take
the
decision
about
the
path
to
take
for
the
reservation
so
compared
to
RSVP.
This
is
different
because
there
are
narrow
sdp
when
you
send
a
resource
reservation
message
to
destination
the
destination.
K
Is
on
the
decision,
only
is
responsible
for
acknowledging
the
reservation
and
confirming
so,
let's
start
so
a
shapes,
a
request
and
sends
it
to
app
through
its
two
ongoing
nodes,
so
A
to
B
and
a
to
c.
The
message
here
has
a
set
of
parameters
compared
to
the
message
format
that
I
presented
in
the
draft.
The
message
format
that
I
present
here
is
slightly
reduced
for
the
sake
of
PFT
presentability,
so
most
information,
the
most
important
information
in
this
message
are
the
maximum
end-to-end
delay.
K
Then
this
message,
which
is
B
and
C
here
we
see
that
yeah,
for
instance,
if
I
take
the
behavior
of
node
B
compared
with
the
message
that
you
see
in
the
previous
slide
here,
B
has
allocated
a
temporary
reservation.
It's
in
its
qq1,
for
which
the
maximum
delay
is
20
millisecond
and
before
relaying
the
request
to
its
own
outgoing
interface
to
Which
F,
which
are
B
to
D
and
B
to
E
it
does.
K
It
has
added
the
maximum
delay
of
the
queue
for
which
it
did
a
temporary
reservation
to
the
end-to-end
delay
commitment.
So
we
know
that
b
takes
20,
milliseconds
out
of
the
85
millisecond
maximum
and
20
lay
credit,
and
it
has
added
its
identifier
to
the
record
root.
So
now
we
know
that
those
messages
went
through
a
and
b
and
the
and
20
millisecond
delay
is
taken
out
of
the
85
millisecond
delay
credit
the
same
for
C
here
so
now
we,
the
message,
arrive
at
D
and
E.
K
Here,
D
only
relays,
one
message,
because
here
its
maximum,
the
maximum
delay
for
execute
q1
is
40
milliseconds
and
the
difference
between
the
maximum
and
twin
delay
of
the
message.
From
C
to
D
is
35
milliseconds,
so
there
is
no
no
way
D
can
conserve
this.
This
reservation,
but
other
message
can
go
through,
so
they
are
related
to
F
with
the
maximum
and
20
delays
delay
then
20
commitment,
the
capacity
and
now
we
have
two
alternatives.
K
So
first
we
make
it.
We
make
our
protocol
behave
like
a
recipe.
It
means
that
the
destination
is
choosing
the
is
acknowledging
and
fixing
the
password
is
reserved.
So
out
of
the
three
message,
signaling
request,
messages
that
have
been
received:
F
chooses
one
message:
for
instance,
the
the
message
for
which
the
difference
between
the
end-to-end
delay,
commitment
and
the
maximum
end-to-end
delay
is
the
largest
and
shapes
a
reply
with
the
maximum
end-to-end
delay,
the
end-to-end
delay
commitment.
It
has
received
the
capacity
and
the
explicit
route.
K
This
message
is
relayed
along
the
Route
that
is
given
in
the
reply
message
to
A
and
after
AO
receives
a
message.
If
the
flow
can
be
exchanged
following
this
route,
with
respect
for
the
end-to-end
delay
commitment,
then
another
method
would
be
to
let
the
source
choose
the
path
that
is
going
to
be
taken.
So
this
Behavior,
we
ask
F
to
reflect
all
the
requests
it
has
received
with
the
reply
stating
the
maximum
intent
delays,
end-to-end,
delay,
commitment,
that's
received
and
the
route
that
is
taken
by
the
message.
K
Agree
with
that,
but
the
the
issue
we
had
when
designing
the
around
the
formatting
of
the
information
we
needed
in
this
protocol
with
RSVP
is
that
if
we
want
to
stick
to
already
existing
RSVP
objects,
the
encoding
of
the
information
can
be
tedious
requires
some
competition
at
the
various
nodes
and
is
not
really
direct.
We
looked,
we
looked
after
RSVP
object
that
was
suitable
for
deterministic
networking.
K
We
encountered
a
document
draft
frozen.netracy
ptsn
that
expired
a
few
months
ago,
and
we
wonder
whether
it
would
be
appropriate
to
have
a
more
direct
encoding
of
the
information
that
we
will
use
in
our
signaling
protocol
in
future
versions.
But
for
the
current
draft
we
try
to
stick
to
the
RSVP
formatting
as
it
sounds
today.
K
K
K
We
found
a
limitation
in
the
session
that
object
about
the
the
identification
of
flows,
because
in
RSVP
the
identification
flows
is
based
on
five
tuples.
So
if
you
want
to
to
send
IP
traffic
while
respecting
end-to-end
delay
bound
that
is
not
tied
to
a
specific
transport
protocol,
this
may
be
a
problem
with
the
identification
of
the
flow.
The
recall
record
root
list
that
is
carried
in
the
request
message
can
be
presented
as
a
root
record
object
in
RSVP.
K
We
found
out
that
the
best
option
we
had
was
to
convey
the
maximum
delay,
but
with
a
standard
t-spec
or
a
flow
spec
object,
depending
on
the
message
with
a
general
can
back
at
the
spec
parameter
and
the
guaranteed
service
aspect
parameter.
So
I
will
show
this
message
later
and
the
delay
commitment
by
the
nodes
is
carried
by
an
ad
spec
object,
including
a
set
of
default
General
parameters
with
a
fragment
carrying
guaranteed
service
parameters.
K
So
I
will
present
the
formatting
that
we
have
for
for
the
for
those
two
parameters.
So,
first
the
maximum
end-to-end
delay.
So
in
the
RSVP
rfcs
we
found
that
there
is
an
formula
that
is
giving
the
end-to-end
delay
in
a
situation
in
which
P,
which
is
the
the
peak
data
rate,
little
r,
which
is
tuck
and
bucket
rate
and
Big
R,
which
is
the
rate,
are
equal.
K
So
here
the
delay,
the
maximum
delay
is
given
by
S,
which
is
the
slack
term
here.
Plus
B
the
token
bucket
size
divided
by
r,
so
the
end-to-end
delay
requirement
can
be
given
by
RBP,
R
and
S,
and
the
capacity
is
given
by
the
peak
data
rate
P.
So
we
can
use
this
token
back
at
this
spec
and
mounted
service
aspect
parameters.
So
here
is
the
test
taken.
Here.
Is
your
aspect
to
convey
this
information,
but
it's
not
a
direct
read
from
the
router.
K
It
needs
to
do
some
competition,
so
it's
we
think
it
can
be
more
simple
in
the
aspect
object.
The
aspect
object
is
a
bit
more
complex.
You
have
far
more
parameters,
but
the
end-to-end
delay.
Commitment
can
be
carried
by
setting
the
minimum
path.
Latency
here,
as
undetermined
value
specified
by
RC
2215.
K
K
We
think
that
this
this
encoding
is
a
bit
complex,
but
we,
as
I
mentioned
earlier,
we
tried
to
stick
to
the
typical
RSVP
message
encoding.
But
if
this
message,
if
this
mechanism
gets
traction,
we
feel
that
there
would
be
a
potential
optimization
with
a
thinner
RSVP
object,
carries
information,
so
I
hope
that
this
presentation
triggered
your
interest
in
this
document.
I
would
be
very
interested
in
Reading
from
in
hearing
from
your
from
you
about
your
interest
in
this
draft
in
the
next
steps
I'm.
K
That
net
mechanism,
with
requirement
for
large-scale
Nets
in
large
scale
networks,
so
we
are
going
to
make
the
exercise
that
you
that
has
been
presented
earlier
to
align
to
to
tell
how
the
mechanism
we
present
in
this
draft
can
respect
the
requirements
that
are
presented
in
the
requirement
plot
around
the
follow-ups.
We
are
wondering
whether
there
is
interest
in
this
document.
K
Maybe
is
it
belong
to
this
draft?
Maybe
the
group
thinks
that
there
is
a
potential
for
separating
those
recipe
protocol
mechanism
and
making
them
in
appear
in
a
separate
draft,
and
also,
we
think
that
there
is
an
interest
in
having
a
cleaner
rzp
object
to
carry
information
about
deterministic
Network
flows,
and
we
would
be
motivated
to
work
in
this
Direction
with
the
group.
K
C
E
B
You
would
want
to
do,
let's
say
as
opposed
to
RFC
2212,
which
would
be
the
forwarding
plane
for
guaranteed
service,
which
is
what
the
iitf
originally
did
in
conjunction
with
RS
SVP.
So,
but
just
let
me
add
two
more
points
because
that
that's
what
I
would
like
to
have
an
answer
from,
but
in
general,
with
what
what
you
were
talking
about,
RSVP
itself
does
not
specify
where
the
RSVP
messages
are
routed
across
in
terms
of
multi-path
of
what
the
path
is.
B
That
is
being
that
is
supposed
to
be
exactly
the
same
path
that
the
traffic
would
take.
So
to
do
anything
that
you
want
to
do.
You
first
need
to
have
a
mechanism
by
which
you
can
steer
the
traffic
across
different
path
and
in
in
Native
IP
multi-path.
You
can't
do
that
explicitly
right.
So
if,
if
you
use
IP
multi-path,
it
means
that
traffic,
for
example,
for
different
ports
to
the
same
destination
or
to
this
different
IP
addresses
to
the
same
destination
would
go
different
paths.
So
you
need
to
rely
on
that.
B
The
the
explicit
route
object,
for
example,
is
from
RSVP
te
so
that
doesn't
work
with
IP.
So
there
is
all
type
of
I
think
issues
that
that
you
would
need
to
resolve
going
forward.
But
you
know:
steering
the
traffic
to
to
get
to
different
path
with
different
bandwidth
might
be
actually
part
of
a
better
solution
for
doing
the
the
death
net
forwarding
plane,
but
I
think
it's
highly
unlikely
that
we
would
want
to
do
anything
for
steering
other
than
what
the
ietf
has
already
done.
B
K
B
I'm
sorry,
I'm
I'm,
I'm,
I'm
too
old
to
still
learn
that
so
I
think
in
general.
The
the
problem
I
have
with
RSVP
is
that
we
already
saw
you
know
more
than
10
12
years
ago
or
or
longer
that
we
have
scaling
issues
with
RSVP
in
the
network,
which
is
why
we
went
to
segment
routing
as
a
way
to
not
do
RSVP
signaling
in
networks.
So
I'm
I'm,
not
sure
that
RSVP
signaling
for
individual
flows
would
ever
be
a
good
fit
for
the
large-scale
net
deployments.
E
K
Yes,
in
fact,
this
is
what
I
mentioned
when
I
presented
the
issue
we
have
with
the
identification
of
the
flow
in
the
way
a
recipe
does
in
fact
in
in
RSVP,
you
can
identify
a
flow
by
the
typical
five-stopper,
IP,
Source,
IP
destination,
soft
spots,
destination,
port
and
protocol
in
RSVP.
If
I,
remember
well
as
I
need
to
check,
there
is
a
possibility
to
use
to
use
the
flow
level
in
in
the
IP
header
to
help
with
this
identification.
K
But
if
we
use
a
slow
level,
we
need
to
make
sure
that
over
the
path
the
full
label
is
not
tempered
with
so
I
think
that
if
we,
if
we
want
to
identify
a
flow,
that
is
specific,
that
is
a
metric
flow
and
not
a
transport
layer
flow
and
we
we
need
to
stick
to
ipsource
and
IP
destination
and
the
user.
It
has
limitations.
But,
as
I
mentioned,
we
wanted
to
stick
to
the
format
of
our
SVP
to
try
whether
it
was
possible
and
probe
interest
in
having
other
mechanisms
in
the
record
group.
E
K
K
K
C
Yeah
I
actually
wanted
to
make
some
comments
to
Dollars
like
pretty
much
all
each
point.
That
RCP
is
not
has
issues
you
as
he
explained,
trends
and
so
on,
and
we
have
at
the
first
place
you
should.
You
should
get
the
questions
or
some
news
of
ISP
for
that,
not
that
large
in
the
working
group.
But
it's
it's
more
about
data
plane
enhancements,
not
controlling.
C
D
K
K
D
Okay,
thank
you
so
so.
My
second
questions
is
that,
according
to
your
slides
that
the
the
formula
is
actually
simple,
yeah
but
I
I
still
be
confused,
that
maybe
we
just
change
the
buffer
capacity
is
not
enough.
Good
bounded
latency,
because
the
the
password
said,
the
the
buffer
capacity
is
a
node
just
an
attribute
of
the
queue,
but
but
it's
the
the
size
of
a
wall,
aggregated
flows
that
can
be
permit
per
permitted
to
release
to
the
network.
Studies
on
my
second
coincidence,
I
think
yeah.
K
K
K
So
if
we
use
more
complex
scheduler,
for
instance,
introducing
priority
or
this
kind
of
things
and
the
queue
can
be
a
fifo
with
a
preemption
for
some
to
place
at
the
beginning
of
the
Q,
some
urgent
packets,
we
need
to
have
a
more
complex
model
for
the
for
the
competition
of
the
end
to
land
delay
depending
on
the
buffer
capacity.
But
we
are
confident
that
we
can
still
have
a
bound
depending
on
the
welfare
capacity,
and
this
mechanism
can
be
can
be
used.
D
C
D
G
Just
a
quick
question:
thanks
for
the
presentation,
it's
very
interesting
as
far
as
I
can
recall
the
rspp.
It
has
the
overhead
of
the
regular
refresh
messages,
part
and
reservation
in
opposite
direction,
and
your
work
did
you
consider
using
those
messages
or
exploiting
those
messages,
to
send
additional
information
in
order
to
maintain
the
guarantees
of
the
past.
K
Yeah
yeah,
in
fact,
we
we
try
to
track
those
changes,
but
we
stick
to
our
LCP
objects
that
were
attribute
the
Yana
page
for
a
zp.
So
once
again
we
may
be
wrong,
but
and
if
you
have
ID
for
format
for
most
object
formats
that
we
may
use
I
would
be
very
happy
to
hear
from
you,
but
to
the
best
of
our
knowledge
and
from
the
objects
that
has
been
published
on
the
Yana
page
for
RSVP.
This
is
the
best
we
could
do.
C
Okay,
thank
you
very
much,
everyone
for
the
presentations
and
the
good
discussion.
We
are
running
two
minutes
over
time,
so
I
suggest
to
close
this
call
as
David
mentioned
the
next
one
is
four
weeks
from
now
as
two
weeks
from
nice
July,
the
fourth
and
we
can
continue
the
discussions
on
the
list
until
the
next
meeting.