►
From YouTube: IETF-CORE-20230215-1500
Description
CORE meeting session at IETF
2023/02/15 1500
https://datatracker.ietf.org/meeting//proceedings/
A
B
C
A
A
Okay,
so
being
for
past
I
think
we
can
start
and
then
Karsten
should
be
able
to
join
a
bit
later
today,
but
welcome
everyone
to
the
intermitting
of
the
co-working
group.
I
am
marketing
and
Carson
Mormon
and
as
usual,
this
is
an
officiality
of
meetings.
So
the
not
well
applies.
Please
be
familiar
with
that.
A
If
you
are
not
already
it's
not
about
IPR,
it's
also
in
the
special
about
our
conduct,
so
be
nice
and
professional
with
one
another,
and
the
agenda
for
today
is
only
about
two
points:
I'll
quickly
go
through
the
status
of
some
working
of
documents
and
their
progress,
but
then
we
will
mainly
focus
on
a
tutorial
about
the
ippm,
mechanics
and
building
blocks
in
the
interest
of
the
co-op
PM
document.
I
think
Giuseppe
will
mainly
present.
What
is
the
other
cultures
also
in
the
roster?
A
A
Recently,
it's
pretty
clear
to
to
the
others
what
you
have
to
do,
but
they
plan
to
have
one
more
round
of
feedback
in
order
to
produce
a
revision
before
the
cutoff,
so
that
we
can
consider
a
working
group
plus
call
right
after
that,
and
then
we
would
be
able
to
to
process
the
outcome
of
that
at
itf1
16..
So
that's
on
track,
and
yesterday
we
also
started
intentionally
in
parallel.
A
The
working
group
was
called
for
two
other
documents
that
profiling,
a
webdoc
for
Co-Op
and
those
score
involving
also
the
lake
working
group
is
very
much
related
and
the
contact
attribute
registry
document,
which
is
very
short.
So,
of
course,
please
have
a
look
at
the
documents
even
saying
their
finances
is
good
feedback.
Please
provide
your
comment
on
the
list
or
on
the
GitHub,
especially
if
it's
about
nits
and
editorial
suggesting
and
the
call
will
end
on
February
28th
for
both
of
them.
A
D
Yeah
I
will
present
the
let's
say
the
the
general
idea
or
the
draft
and
some
aspect
of
the
methodologies.
Then
I
I
also
invited
other
quotas
from
Telecom
Italia.
Now,
in
fact,
that
we
will
describe
you
also
much
more
details
about
the
implementation
and
also
the
let's
say
the
academic
activities
around
these
methodologies.
So
Telecom
Italian
has
also
a
field
implementation
of
they
further
discussed
the
implementation
details,
so
I
can
can
I
present
or.
A
D
D
Let's
say
the
the
the
background
for
this
kind
of
techniques
are
the
the
reason
that,
for
example,
for
quick,
you
have
that
the
header
is
encrypted,
so
a
non-part
Observer
that
can
be
an
operator
or,
let's
say,
a
segment
Network
that
want
to
measure.
For
example,
the
performance
of
quick
of
TCB
of
rtcp
cannot
implement
the
measurement.
D
So
let's
say
there
was
this
new
effort
to
employ
a
few
marking
beads
in
let's
say
in
the
in
an
encrypted
header
of
quick
or
TCP,
in
order
to
allow
on-pot
Observer
that
can
be
Network
operators
or
network
probes
to
to
make
the
measurement
of
these
encrypted
protocols.
So
this
is
the
motivation
for,
let's
say
the
original
drafts,
so
we
have
the
idea
to
extend
this
kind
of
measurement
also
to
co-op
protocol,
since
we
believe
that
this
kind
of
measurements
are
really
really
easy
to
apply.
Also
in
the
context
of
Corp.
A
D
C
C
Can
brief
question
here
you
mentioned
in
quick?
Basically,
the
endpoints
are
cooperating,
even
though
the
rest
of
the
traffic
is
encrypted.
Is
this
something
that
is
widely
happen?
Kind
of?
Is
this
something
that
clients
widely
collaborate
on
so
say,
yeah
I'm,
using
Firefox
to
download
a
gigabyte
of
data?
Will
it
use
a
quick
connection
and
play
along
with
EFM.
D
Yeah,
this
is
a
good
question,
because
in
in
in
this
in
this
draft
there
are
several
methodologies
that
are
in
that
are
described.
This
is
an
informational
draft
in
quick.
Only
one
bit
of
these
of
the
several
bits
that
are
described
in
this
draft
is
optional
and
is
the
is:
is
the
spin
beat
but
let's
say
the
so,
there
is
the
spin
bit
that
is
dedicated
regarding
the
real
implementation.
I
know
that
telecom
Italia
make
an
implementation
through
a
client
on
the
smartphone.
D
Maybe
later
on,
Fabio
and
Mauro
will
will
describe
much
more
details,
but
I
don't
think
that
from
what
I
know,
I
don't
know
if
Firefox
or
apple
really
implemented
this
optional
bit,
but
it
is
really.
It
is
optional.
In
the
quick,
let's
say,
standard
documents:
I,
don't
have
this
information
about
the
real
implementation
of
in
Firefox
or
Safari
or
or
Microsoft
Edge,
and
so
on.
D
D
The
idea
is
really
simple,
so
is
to
create,
let's
say,
a
square
wave
signal
between
client
and
server
using
only
a
bit
and
the
liked
of
the
the
signal
is
the
round
trip
time.
So
in
this
way,
an
observer
on
path
can
measure
the
end-to-end
round
trip
time
only
watching
the
spin
beat.
So
the
the
good
way
is
that
the
Observer
does
not
need
to
take
any
time
timestamp
or
ID.
So
you
just
need
to
measure
the
length
of
the
square
wave,
because
the
length
of
the
square
wave
is
equal
to
round
trip
time.
D
C
D
D
But,
of
course,
if
there
is
traffic,
I
think
that
the
measurement
can
be
done,
because
if
you
send
a
packet,
it
is
supposed,
for
example,
for
TCP,
quick,
that
you
will
receive
an
act,
so
at
least
you
will
make
one
cycle,
and
at
least
one
sample
you
are
able
to
to
measure
one
sample
at
least
of
course,
if
you
have
a
continuous
traffic,
you
are
able
to
measure
much
more
samples
and
you
you
can
have
much
more
statistical
data
about
the
round
trip
time.
Yeah
foreign.
D
D
Measurement
of
a
one-way
packet
loss,
so
also
in
this
case
there
is
a
an
RFC
that
is
the
alternate
marking.
This
is
a
standard
track
document
defined
in
RFC
9341.
The
applicability
to
Quick
is
also
described
in
these
individual
draft
from
Orange
and
Akamai
that
they
also
implemented
these
methods
in
in
a
real
Network.
D
D
D
This
is
the
square
bit
signal,
so
the
idea
in
in
our
draft-
maybe
you
may
recall
the
the
past
presentation-
is
to
define
a
new
option
where
we
can
use
one
or
two
bits,
depending
on
which
kind
of
measurement
we
want
to
do
or
if
packet,
loss
or
delay,
and
we
also
added
other
event
bits
that
can
be
used,
for
example,
to
to
Signal
some
loss
event
or
delay
event
bits
for
for
probes.
That,
for
example,
do
not
support
this
kind
of
measurement,
so
we
can
make
use
of
the
additional
bit.
D
D
Now
we
can
go
through
the
co-op
applicability.
So
what
are
the
reality?
Usage
scenarios
for
this
kind
of
measurement?
Basically,
the
co-op
performance
measurement
options
allow
these
end-to-end
measurement,
but
split
measurements
are
also
possible
because,
if
you
have
on
part
of
servers
and
as
you
as
you
may
notice
in
the
previous
slides,
so
both
spin
bit
and
square
bit
allow
on
path
measurement
from
in
observers.
So
you
may
have
Network
function,
probes
or
Gateway
or
code
proxies
that
can
perform
also
measurements.
D
D
So
the
first
two
cases
are
really
simple.
So
in
case
of
non-proxies
and
points,
let's
say
the
you
have
a
very
simple
scenario.
So
in
general,
you
have
client
and
server
with
the
observer
in
the
middle,
and
in
this
case
you
can
make
end-to-end
measurement,
and
but
since
you
have
the
observer
in
the
middle,
that
can
be
a
network,
Pro
bar
can
be
a
network
Gateway
and
so
on.
That,
of
course,
need
to
be
able
to
read.
D
A
D
My
colleague
maximum
out
of
also
plan
to
work
on
an
implementation.
So
for
this
we
want
to
discuss
with
you
because
for
a
score,
we
we
just
read
the
let's
say
the
the
standard
document.
We
see
the
opportunity
to
have
an
author
option
to
to
make
visible
this
kind
of
information
also
on
patents,
but
how
to
implement
that.
We
need
your
advice.
Of
course,
yeah.
D
D
Yeah
regarding
the
the
the
other
scenarios,
with
the
proxies,
let's
say
that
things
are
a
little
bit
more
complicated
because
of
course,
we
Define
the
this
option
that
can
be
applied,
end-to-end
between
client
and
server
or
between
the
collaborating
proxies,
and
we
Define
this
option
as
a
safe
to
forward.
So
it
means
that
it
is
intended
to
be
forwarded
by
an
uncollaborating
proxy
in
either
way.
Also
in
the
case
of
non-collaborating
proxy,
we
should
be
able
to
make
some
measurement
so
in
case
of
collaborating
proxies.
D
Of
course,
you
have
three
session
right,
so
between
client,
Pro
and
the
first
proxy
between
the
two
proxies
and
between.
So
this
is
the
let's
say
the
MOX,
the
the
most
complicated
use
case
where
you
have
the
three
separate
session,
and
in
this
case
you
can,
since
the
the
session
are
separated,
you
can
measure
the
three
connection
also
separately,
so
you
can
do
in
the
end
end-to-end
measurement,
but
also
on
part
upstream
and
downstream
bottom
deals
of
the
Observer.
D
Because
of,
of
course,
the
Observer
can
also
read
the
the
performance,
the
the
performance,
information
between
client
and
proxy,
or
if
you
have
an
observer
between
the
two
proxy.
Also,
the
Observer
can
read
the
performance
information
between
the
two
proxies
and
so
on,
and
also
you
can
do
intra
domain
measurement
if
you
have
more
than
one
Observer
on
a
single
connection.
For
example,
if
you
have
between
the
two
proxy,
if
you
have
more
than
one
of
the
server,
you
can
also
make
the
measurement
between
the
two
Observer,
for
example.
D
We
suppose
that
here
between
the
two
proxy
you
have
internet,
so
it
is
supposed
that
a
network
operator
can
also
make,
for
example,
a
segmented
measurement
in
case
of
non-collaborating
proxies.
If
we
suppose
that
the
option
is
safe
to
forward
you
have
in
theory,
you
have
a
single
connection
and
you
can
do
always
end
to
end,
but
also,
if
you
have,
the
Observer,
of
course,
did
the
you
cannot
make
the
measurement
on
the
proxy,
because
the
proxy
is
not
collaborating.
D
C
Please
please
I
think
this
is
the
topic
that
we
will
need
to
discuss
most,
like
the
other
scenarios,
have
to
me
pretty
clear.
This
is
the
one
where
we
should
probably
go
through
one
example,
and
then
either
you
see
that
it
doesn't
work
or
I
see
that
it
does
work,
but
this
is
the
one.
I
would
like
to
focus
on.
D
Yeah
I
fully
agree
with
you,
because
this
is
a
the
most
complicated
case,
because
since
you
have
that
proxy
safe
to
forward
there
are
a
lot
of
complications
here,
because
we
have
to
decide
whether
the
proxy
went
forward.
The
let's
say
the
option
if
it
can
be
forwarded
for
all
the
the
packets
came
from
all
the
clients
here
or
if
we
suppose
that
it
is
just
one
client.
So
it
is.
This
need
to
be
further
analyzed.
We
also
plan
to
make
an
implementation.
D
Indeed,
in
this
regard,
we
also
have
a
question
for
you
about
any
suggestion
on
the
open
source
implementation,
because
since
we
already
implemented
all
this
kind
of
measurement
on
quick,
we
can
easily
do
also
on
Co-op.
So
so
we
we
would
like,
maybe
to
to
analyze
much
more
because
since
the
this,
this
use
case
is
a
bit
more
complicated.
I
think
that,
with
the
real
implementation,
we
can
have
much
more
metamor
knowledge
about
how
to
really
implement
it.
But
I
agree
with
you.
This
is
the
most
complicated
case
that
need
to
be
analyzed.
D
Since
Marco
asked
also
to
describe
the
additional
methods
that
are
are
reported
in
the
in
the
explicit
flow
measurement,
draft
I
just
want
to
give
you
an
highlights
of
the
other
methodology.
So
for
now
we
only
proposed
the
spin
beat
and
the
square
beat
because
are
let's
say
the
most
straightforward
are
the
most
easy.
Also
are
really
easy
to
implement,
as
you
will
notice,
but
just
for
your
knowledge,
I
want
to
describe
the
other
methods
that
are
under
discussion.
D
This
is
the
an
additional
beat
that
is
called.
The
delay
beat
is
not
like
the
speed
meet,
but
is
a
is.
It
allows
like
this
pin
bit
allows
a
round
trip
time
measurement
and
the
marking
bit
is
called
delay
beat,
and
the
packet
with
the
delay
bit
equal
to
one
is
called
the
delay
bit
sample.
So
you
only
select
one
sample
each
round
trip
time,
so
you
have
a
single
Market
packet
generated
by
the
client
and
bounce
between
client
and
server,
using
the
production
traffic.
D
So
let's
say
it
is
really
similar
to
to
the
idea
of
the
spin
beat,
but
you
only
have
one
packet,
so
you
don't
have
a
square
wave.
So
in
few
words,
of
course,
when
the
client
does
not
detect
the
sample,
you
need
to
wait
a
specific
time.
Otherwise
you
have
to
declare
the
packet
lost
and
you
have
to
regenerate
the
delay
bit
sample.
So,
let's
say
in
short,
there
are.
There
is
an
algorith
also
in
this
case
that
is
really
very
well
described
in
draft,
but
just
to
give
you
the
idea.
D
D
D
So
in
this
case
you
have
blue
blue
packets
that
are
not
marked
and
the
red
packets
that
are
Market,
so
the
server
let's
say
reflect
always
the
same
number
of
packets
that
receive,
but
will,
let's
say,
We'll,
select
only
only
some
packets,
according
to
the
the
the
packet
rate
that
there
is
so
it
is
always
the
the
lower
bucket
rate
that
decide
the
number
of
packets
that
will
be
generated.
In
this
way,
you
can
measure
the
the
packet
loss.
This
is
an
additional
beat
that
is
defined
together
with
the
square
bit.
D
D
Another
bit
is
the
reflection
Square
bit
before
I
mentioned
that
the
square
bit
is
only
allow
only
one-way
measurement,
but
if
you
want
to
reflect
the
square
bit
in
the
opposite
direction,
you
can
Define
these
reflection.
Square
bit
that
let's
say
the
where
the
sides
of
the
transmit
their
bit
blocks
are.
Let's
say
the
average
sides
of
the
received
qubit
blocks,
and
in
this
way
you
can
have
a
continuous
alternate
Market
blocks
in
both
directions.
D
That
is
only
one
way
and
also
in
this
case
there
is
this
summary
that
is
also
described
in
our
draft
and
a
report
to
the
different
options.
So
you
can
use
the
Tibet
alone.
You
can
use
the
square
bit
alone
on
Los
Civitan,
or
you
can
also
couple
the
square
bit
and
loss
even
bit
or
the
square
bit
and
the
reflection
Square
bit.
D
The
area
is,
to,
let's
say,
improve
the
the
measurement
accuracy
to
couple
more
methods
and
also
to
to
make
more
measurement,
because
in
one
case,
for
example,
with
the
square
bit
alone,
you
can
only
do
Upstream,
but
with
the
other
by
coupling,
for
example,
the
qubit
with
the
air
bit.
You
can
also
do
much
more
measurement.
According
to
the
number
of
web
servers
that
you
you
can
put
on
path.
D
An
additional
proposal
is
to
because,
if
we
can,
if
we
can
implement
this
probe
directly
on
a
user
device
or
on
a
server
the
device
over
the
device
owner
or
the
server
owner
besides
whether
to
Mark
the
traffic
and
decide
whether
to
share
this
performance
information,
so
there
are
some
strengths
to
implement.
The
probe
on
board
on
the
client
or
on
the
server
is
is
the
same
because
they
are
scalability.
You
can
have
more
scalability
because
on
the
user
device
there
are
few
connections
to
monitor.
D
You
can
say
some
equipment,
because
it
is
possible
to
set
alarm
thresholds
on
user
device
and
to
signal
to
the
network
probe
to
all
to
have
a
sort
of
coordination
between
the
host
and
the
probes.
But
this
is
an
additional
idea
just
to
just
to
describe
you.
What
is
what
is
progressing
in
in
ippi
yeah
I,
pretty
much
finished,
my
my
presentation,
yeah.
This
is
just
to
discuss
the
next
steps.
D
Now
I
want
to
give
the
floor
to
I,
don't
know
Massimo
Fabio
or
if
they
want
to
add
much
more
details
about
the
telecommittal
implementation
to
the
hackathon
implementation,
because
there
are
also
implementation
from
Ericsson
from
Akamai
that
are
collaborating
with
us,
mailing
quick
but
of
course,
with
Fabio
and
maximum.
We
discussed
how
to
implement
this
also
in
Co-op.
So.
E
A
A
A
E
A
A
A
E
B
A
E
Okay,
with
I
will
send
you
on
your
email,
thanks:
okay,
okay
I
tried
to
go
full
screen.
Okay,
it's
okay!
It's
full
screen!
Now,
okay,
perfect!
Yes,
this
is
about
the
architecture
of
our.
Let
me
say
our
like
a
proof
of
concept
of
our
implementation
of
performance.
Monitoring
in
the
in
particular
is
about
the
use
case
in
the
in
our
mobile
network.
E
Here
is
a
overview
about
the
implementations
that
are
already
made
like,
for
example,
in
the
arcaton
ITF.
We
have
a
project.
Normally
that
is
called
the
quick
measurements
and
the
then
there
are
also
some
explicit
form:
monitoring,
implementations
and
some
contributors.
Obviously,
our
implementation
in
under
on
Android
mobile
devices
probe
there
is
an
implementation
inside
Ericsson
network
with
network
crops.
E
E
We
have
also
had
some
collaboration
with
the
haken
university
in
Austria,
and
there
is
also
some
wet
paper
in
that
was
presented
in
nnlw
about
the
different
methods
that
we
have
implemented
for
packet
loss,
Miss
movements
that
we
proposed
sorry
and
kind
of
pork,
also
related
on
implementation
or
Intel
Tofino.
In
P4
language.
E
Here
you
can
view
our
overview
of
our
mobile
implementation
with
mobile
devices,
in
particular
on
Android
smartphones.
Here
on
the
left,
you
can
see
the
mobile
device
on
board
on
the
user
device.
There
is
a
client
that
is
involved
in
the
implementation
of
the
alternate
marking,
so
we
can
give
a
color
to
the
packets
and
we
can
use
it
for
the
performance
measurements.
E
This
on
the
left.
You
can
see
the
the
client
on
the
right.
There
is
a
a
normal
server.
Let
me
say
it
could
be
a
generic,
for
example,
web
server
that
only
implements
the
the
part
that
is
related
to
the
to
the
server
side.
That
normally
is
involved
on.
The
only
is
removing
in
the
reflection
of
the
packets
with
the
marking.
E
Another
actors
in
This
architecture
is
the
Observer.
Oh
sorry,
in
this
case
the
server
is
an
app.
This
is
installed
inside
the
smartphone
on
board
and
this
it
is
involved
on
only
on
make
the
the
measurement
about
mainly
about
the
delay
and
the
round
trip
time.
The
long
trip
delay
and
the
eventually
the
loss
depends
on
the
method
that
we
use.
E
E
F
B
B
C
B
Yes,
okay
in
this
case,
for
for
quick,
the
context
is
that
is
the
single
flow,
the
the
single
connection.
So
yes,
it's
the
is
the
fourth
for
to
play.
If
we,
if
we
haven't
a
connection
ID,
if
we
have
a
connection
ID,
it
is
related
to
the
to
the
session
that
is
related
to
the
to
the
to
the
specific
session
ID
in
the
TCP.
Yes,
it
would
be
the
the
four
to
play.
B
Yes,
it's
you're
welcome,
okay,
so
the
the
computational
is
really
small
and,
as
you
can
see,
the
implementation
needs
only
few
lines
of
code.
So
so
it's
really
easy
to
to
implement
the
the
this
kind
of
marking
in
the
in
the
product.
Also,
obviously
spin
B10
Square
bits
are
the
are
the
most
simple.
The
other
bits
are
just
a
little
bit
more
complicated
to
implement,
but
nothing
nothing's
scary.
It's
really
really
simple.
For
for
all
the
bits
NASA,
you
can
continue.
E
E
E
We
can
see,
live
directly
now
in
the
demo
and
I
own,
only
to
underline
that
that
are,
for
example,
these
are
some
kind
of
the
methods
that
we
have
implemented,
so
we
can
have
a
measurement
about
the
the
spin
bit
only
the
delay
bit
only
that
is
our
what
one
of
the
the
methods
that
were
proposed.
The
hidden
bit
is
a
variation
of
the
delay
bit
and
then
we
can
also
or
able
the
the
bought
the
measurements
about
the
delay
and
the
loss.
E
In
this
case,
for
example,
we
use
two
or
three
bits
in
the
heater
and
we
can
have
the
delay
measurement
with
spin
bit
or
delay
bit
or
in
the
beat,
plus
the
loss
with
the
Q
and
there
okay,
okay.
This
is
a
a
screenshot
instead
about
the
what
we
call
team,
quick,
that
is
the
Observer
that
stay
on
the
user
device
in
this
case,
but
could
be
everywhere
on
the
path
of
the
traffic,
and
this
is
a
quick
overview
about
what
we
can
measure
related
to
the
pre-connection
and
okay
I.
E
Think
I
can
show
you
directly
display
now
the
what
we
can
see
and
then
after
we
can
see,
live
on
the
demo,
mainly
about
every
connection
that
we
describe
here.
For
example,
a
connection
of
the
protocol
is
quick
in
this
case.
This
is
the
server
the
destination
the
state
of
the
connection
is
closed.
This
is
the
total
number
so
packet
transferred.
This
is
a
a
quick
overview
about
the
LTT.
We
have
an
average
LTT.
E
This
is
the
kind
of
measurement
method
that
we
have
in
this
case
is
telecom
Italia,
delay
bit
QR
loss
and
then
the
important
things
is
this
row
and
the
second
row
the
last
row.
Sorry,
this
row
is
about
all
the
measurements
that
we
have.
Let
me
see
traced,
let
me
say,
traced,
and
mainly
the
interesting
one,
these
three
that
is
related
to
the
minimum
rdt
in
the
running
of
the
connection,
the
maximum
electricity
and
the
average
LTT.
E
The
last
one
is
the
measurement
about
the
loss,
and
we
have
two
kind
of
in
this
in
this
application.
Obviously
we
have
a.
We
show
a
number
a
parameter
related
to
round
three
plus.
That
is,
this
is
a
percentage.
So,
in
this
connection,
we
have
a
loss.
We
have
other
loss
about
0.344
L
Center
of
the
of
the
packets,
and
here
is
the
parameter
related
only
to
the
downlink
direction.
C
But
I
would
guess
that
doing
this
example
together
would
take
something
in
the
order
of
magnitude
of
15
to
20
minutes
and
I.
Don't
want
to
to
cut
out
like
the
other
questions.
Marco
has
Mark
has
a
few
in
there
as
well,
so
Marco,
maybe
I'd,
leave
it
to
you
to
to
make
a
decision
on
on
how
to
schedule
those
against
each
other.
A
E
C
So
the
setup
that
I
would
that
I
would
like
to
work
with
here
is
one
with
just
a
single
proxy.
It
should
be
should
be
easy
and
should
be
kind
of
complex
enough
already,
with
two
clients
connected
to
the
proxy
and
two
servers
behind
the
proxy,
whether
the
proxy
being
non-collaborative,
because
if
proxy
collaborates
and
we're
using
this
as
a
proxy
unsafe
option,
then
to
me
this
is
like
okay
yeah:
let's
just
do
it,
you
describe
the
options
we
review.
It
thing
done
if.
D
D
C
C
C
Okay,
so
we
the
Assumption,
the
assumption
that
I
would
like
to
work
with
here
is
that
we
are
having
a
proxy
we
having
if
we
are
having
a
distinct
set
of
clients
and
servers,
and
so
on
both
ends.
The
proxy
has
more
than
one
connection
now,
what
I
think
what
would
happen
and
I
would
like
to
take
as
an
example,
please
pick
a
better
one
if
you,
if
you
think,
there's
a
better
one,
the
this
queer
bit.
C
Square
bit
so
the
client
sends
packets
and
for
for
the
moment,
I
would
only
think
of
the
client
sending
packets
to
the
server
because,
like
let's,
let's
pick
the
simplest
way,
things
can
look
like.
So
what
the
client
is
sending
is
one
one
one,
one
one
one
one
one:
one:
zero:
zero:
zero,
zero,
zero,
zero,
zero,
zero
and
mixing
that
yeah
yeah,
that's.
That
is
what
the
client
would
send.
C
C
Packets,
that
are
all
from
proxy
public
IP
from
proxies
outbound
IP
single
port
server
in
servers,
IP
5683,
because
that
is
the
that
is
the
regular
Port
that
would
be
used
here
and
I
should
not
be
flipping
around
the
sizes,
because
this
looks
weak
to
you.
So
what
the
Observer
would
see
would
be
one
one
one,
one
one
one
one
one
one
one
that
is
like
handling
the
first
nibble
of
packets.
Then
it
might
see
one
one:
zero,
zero,
zero
one,
zero
one
followed
by
eight.
D
D
C
D
Yeah
yeah
yeah
and
after
that
discussion
we
we
explain
this
kind
of
assumption
in
the
draft
because,
of
course,
in
the
middle
after
the
proxy,
you
cannot
recognize
the
client.
So
everything
is
mixed
and
yeah
you
you,
you
lose
the
signal,
so
you
lose
the
marking
information
so,
of
course
so-
and
we
have
to-
and
in
this
case
in
particular,
considering
that
we
are,
we
are
now,
supposing
that
we
are
in
the
most
complicated
case
and
we
have
a
non-collaborating
proxy.
D
C
E
C
C
D
Because
otherwise,
you
are
supposed
to
include
some
identification
right.
If
you
want
to
monitor
more
clients,
you
need
some
more
identification,
but
in
this
case
you
let's
say
that
you
lose
the
proxy
function
because
you
are,
you
are
also.
There
are
also
security
and
privacy
problems
in
this
case.
So
maybe
it's
not
easy.
D
C
C
Suggestions
my
opinion,
my
opinion
here
right
as
things
are
now,
is
that
you
will
need
to
carry
this
assumption
and
if
you,
if
you
kind
of
you,
can
work
around
it
by
adding
server
and
client
identifying
data
on
both
ends.
But
at
this
point,
why
use
a
proxy
anymore
at
all,
or
in
other
words
your
kind
of
things
things
get
things
get
so
complex
that
it's
probably
easier
to
to
ask
the
proxy
to
collaborate,
but
there's
there's
more
than
the
multiple
clients
and
multiple
servers.
C
C
So
the
Observer
in
this
scenario,
we'll
see
everything
here
this
one
and
that
it
will
not
see
this
anymore
and
it
will
start
seeing
things
over
here
again
and
maybe
let
me
for
illustration
purposes
shift
the
phase
a
bit
so
that
it
becomes
more
visible.
Yet
if
we
do
it
like
this,
because
otherwise
it's
keyboards.
D
C
C
And
given
that,
in
this
whole
scenario,
the
client
and
the
server
already
have
to
cooperate-
and
there
is
a
very
tight
set
of
restrictions
applying
all
around
I-
think
that's
not
a
not
a
quite
so
that's,
not
a
not
an
excessive
Demand
on
a
proxy
to
just
have
one
more
option
where
it
knows
that
Yep.
This
is
something
that
I
can
forward
without
further
consideration.
C
Cash
Stuff
Etc
that
this
proxy
will
just
send
it
on
okay,
but
if
the
proxy
has
just
like
read
the
first
three
lines
of
the
specification
that
say
this
is
critically
before
this
is
not
safe
to
forward.
But
if
you
tick
these
three
boxes,
like
you
only
you
you're
in
a
controlled
environment
where
you
only
where
you
know
that
you
only
have
one
client
that
does
this
and
you
are
not
caching
and
your
kind
of
we
might
extend
that
list
further
down.
C
There
is
there
is,
there
is
a
number
of
thing
of
ways
this
could
be
implemented,
for
example
this
proxy
code.
If
the
proxy
has
caching
in
general,
it
could
bypass
caching
for
this
option.
Okay,
that
that
would
be.
That
would
be
one
way
for
proxy
or
to
just
say,
yep,
it's
not
to
say
that
proxy
isn't.
Caching,
anyway,.
C
The
proxy
can't
do
so
much
about
about
making
sure
that
this
all
goes
only
to
particular
clients
and
a
particular
server,
because
the
proxy
will
not
know
all
those
details,
but
there
are
some
input
that
comes
from
the
proxy
operator
where
the
proxy
operator
says.
Yes,
we
are
using
this
in
such
a
scenario
where
you
may
do
this,
so
we
are
provide,
we
are
taking
the
one
box
and
the
proxy
can
take
some
of
the
other
boxes
like
not
applying.
Caching,
here.
C
D
No
it
it
looks
reasonable
for
me,
because
I
I
will
I
will
look
carefully
at
the
let's
say
at
the
relevant
RFC
about
the
proxy
safe,
no
proxy
safe
rule,
because
I
I
didn't
notice
that,
as
I
said,
I'm
new
of
this
product,
so
I
need
your
your
your
guidance
and,
of
course,
I
will
I
will
carefully
read
that
part,
but
considering
your
explanation,
I'm,
confident
that
this
is
this
is
something
that
can
be
can
be
modified
in
the
next
radiation
and
yeah.
I.
Think
you
you
you.
D
A
D
Yeah
we
use
the
Observer-
let's
say
nothing,
quick
in
in
the
ippm
work,
because
since
the
ippm
work
is,
let's
say,
transport
agnostic,
so
it
aims
to
Define
methodologies
that
can
be
applicable
to
several
client
server
transport
product
a
lot.
So
it
may
be
quick.
It
may
be
TCP,
so
we
just
Define
on
Pat
Observer,
but
if
of
course
cope
folks
are
more
familiar
with
probes,
we
can
simply
replace
the
wording.
Is
not
it's
not
a
big
deal,
so
yeah
yeah.
D
A
A
A
F
D
Yeah
otherwise,
of
course,
you
can,
because
you
see
that,
for
example,
the
square
bit
allowed
to
monitor
Only
One
Direction.
Otherwise
you
can,
you
can
only
monitor
One
Direction,
in
that
case
you,
so
it's
something
that
that
maybe
we
can
also
consider
this
case
as
an
additional
scenario
to
mention
in
the
draft.
Maybe.
D
D
C
Unquote,
regular
Co-op
has
does
does
not
does
not
do
this
normally,
so
there
are
situations
in
which
you
can,
in
which
you
can
have
multiple
a
different
number
of
packets
in
both
directions,
but
the
say
regular
flow
of
requests
and
responses.
If
there
are
no
things
like
observe
or
no
response
in
play,
is
that
there
is.
There
is
lock
stepping
between
those,
so
in
in
the
in
the
figures
that
you've
given.
C
D
C
No,
so
if,
if
a
client
is
running
co-op
with
the
default
set
of
options-
and
it
has
multiple
requests
to
a
single
server,
then
it
will
send
one
request:
wait
for
at
least
an
empty
act
to
come
back,
quite
possibly
even
for
the
response.
I,
don't
know
that
of
my
head
and
will
not
send
another
request
to
that
server
until
at
least
that
round
trip
has
completed.
There
are
protocol.
D
B
C
D
Yes
yeah.
This
is
similar
to
the
to
the
answer
to
the
previous
question,
so
maybe,
in
that
case
we
can
own.
We
can
only
do
the
measurement
one
way,
because
if
the
acknowledge
is
not
able
to
carry
any
option,
we
can
only
do
the
measurement
in
the
Upstream.
Let's
say
in
the
Upstream
Direction
only
one
way:
yeah.
C
C
C
Things
that
you
could
utilize
if
your
measurements
are
sitting
on
the
end
device,
which
is
something
that
you've
indicated,
is
is
happening.
There
might
already
be
round
trip,
estimates
being
taken
because
there
is
a
flow.
So,
especially
when
you're
using
larger
data
flows,
then
there
might
be
a
flow
control
protocol
sitting
inside
Co-op.
That
already
provides
around
trip
time
estimates.
C
D
A
It
has
a
question
from
massive
in
the
chat
only
about
the
empty
act.
Why
not
having
options
yeah
it's
intended
to
be
very
minimalistic,
and
only
the
the
four
bytes
header,
and
especially
with
the
MTR,
acknowledging
a
confirmable
separate
response.
That's
about
it
confirming
reception
and
carry-on
options
are
for
full-fledged
requests
and
responses.
D
But
even
if
there
is
no
option,
you
are
able
to
recognize
the
acknowledge
so
and
you
can
create
the
the
square
wave
but
All
in
One
Direction,
because
you
can
only
populate
to
the
beats
in
for
the
option
in
One
Direction,
but
the
only
limitation
that
you
can
only
do
the
measurement
if
you
have
an
observer
on
the
Upstream,
Direction
and
The
on
not
in
download
Direction,
but
normally,
let's
say
an
observer
that
a
probe
that
can
see
the
Upstream
direction
is
supposed
also
to
to
be
able
to
see
the
download
Direction.
So
it's
not.
D
A
And
and
I
planned
and
still
plan
to
provide
a
review.
I
was
just
waiting
to
to
have
a
better
Direction
on
this
document
altogether,
and
this
tutorial
now
so
I
hope
I
can
send
out
a
radio
version
3
in
the
next
10
days,
or
so
it's
great.
If
you
can
at
least
partially
take
into
account
for
the
next
revision
and
then.
D
Yeah
yeah,
of
course,
I
will
I
plan
to
review
the
draft.
This
is
I
think
that
this
is
very
good
discussion,
so
we
got
much
more
information.
Much
more
I
have
much
more
clear
idea
on
how
to
consider
all
the
other
cases
that
we
didn't
consider
in
the
previous
version.
So
do
you
mean
the
cutoff
of
the
for
the
next.