►
From YouTube: IETF103-INTAREA-20181107-1540
Description
INTAREA meeting session at IETF103
2018/11/07 1540
https://datatracker.ietf.org/meeting/103/proceedings/
A
A
Yeah
so
blue
shits
about
to
load
around
thanks
that
care,
and
so
please
make
sure
that
you
are
familiar
with
the
no
dwell
and
obligations
responsibilities
that
this
entitles
to
you
as
a
reminder
means
start
taking
the
meeting
is
being
recorded.
Your
presence
is
logged,
described
thanks
a
lot
Ian
for
taking
care
of
that,
as
well
as
the
Jabbar
Michael,
and
our
agenda
has
been
slightly
updated
and
there
were
a
few
last-minute
changes.
So
this
is
what
it
looks
like
now.
A
So
this
was
a
light
minute
submission
that
fortunately
made
it
into
the
agenda
because
we
had
a
drop-off,
that's
the
main
change,
but
please,
when
we
send
the
request
for
presentations,
make
sure
that
you
send
a
long
time
because
otherwise
it's
hard
to
play
with
the
agenda
and
make
sure
that
we
can
accommodate
everyone
all
right.
So
there
any
Bastion
to
the
agenda.
As
you
see.
B
Thank
you
so
refresh,
or
rather
an
update
on
the
0-3,
so
my
name
is
Vivek
link,
nothing
for
the
authors.
What
has
changed
since
IETF
102
is
basically
that
I
was
able
to
present
the
complete
protocol
and
the
complete
draft
to
v6
ops,
because
of
course
they
got
an
impact
there.
It
was
well
received
it
also.
Now
the
draft
reference
by
two
other
draft
at
least
right
now,
I,
don't
know
all
of
them,
of
course,
so
it
proved
the
interest
of
it
and
release
the
0-3
change
in
0
3
with
make
two
main
changes.
B
One
is
a
clarification
when
we
need
to
send
a
large
PVD
option
in
multiple
arrays
by
sending
piece
by
piece,
that's
allowed
and
we
simply
clarify
it
and
exquisite
exactly
what
to
do
a
recline
and
also
suggested
to
make
some
change
into
the
path
connection
sharing
body
also
for
tethering
for
catering
and
the
like,
it
was
trailer
before
what
will
be
small.
To
be
honest,
so
we
try
to
expand
it.
So
there's
a
major
change
in
the
0
3.
B
We
didn't
change
anything
in
the
protocol,
packet
format
or
whatever,
and
the
text
really
like
this
I
send
it
to
the
list,
because
I
think
that's
really
important
for
us
to
reach
a
consensus
and
go
through
looking
group
last
call.
It's
basically
says
when
we
receive
from
let's
say
the
3gpp
interface
array
containing
the
PVD
ID
option.
B
Then
it's
up
to
the
choice
of
the
phone
operator
being
a
guy
or
being
an
operating
system
or
whatever
to
push
down
the
same
DVD,
and
we
specify
that
we
should
as
well
do
it
keeping
of
course
the
same
three
qualified
domain
name.
This
is
all
we
go
and
fetch
the
JSON.
This
is
all
one.
Application
can
select
a
specific
DVD,
of
course,
if
it's
receiving
multiple
pvd's
of
the
3gpp,
it
can
also
forward
the
multiple
PVD
below
a
bit.
B
B
This
is
all
we
refresh
or
we
push
a
refresh
of
all
the
JSON
file,
the
alb.
It
stands
for
legacy.
This
is
basically
whether
the
PVD
and
the
JSON
file
associated
to
it
is
also
applicable
to
the
ipv4
address
that
you
receive
by
DHCP
as
long
as
the
v6
router
and
the
v4
try,
the
same
I
put
it
in
blue,
because
I
do
not
sure
not
seen
him,
but
that
lemon
says
something
is
a
little
bit
fuzzy
there
and
a
bit
for
the
reserved
field
must
be
zero.
B
Simply
and
now
we
say
the
value
of
the
orbit.
The
orbit
is
basically
whether
inside
the
PVD
ID
option
itself,
you
repeat
the
complete
route
advertisement
header
for
fusing,
like
MTU,
for
instance,
so
we
say
a
if
the
Arbutus
set
on
the
3gp
P,
so
meaning
that
the
PVD
ID
contains
a
copy
and
a
different
copy
of
the
Arrieta.
You
do
the
same
thing
below
which
I
think
does
make
sense.
B
Now
whether
the
sentence
in
blue
is
fuzzy
as
well
as
whether
the
connectivity
should
be
shared
only
by
PVD,
aware
oast
or
not,
when
PMI
server
running
this
sentence.
In
our
mind,
it
was
crystal
clear,
but
obviously
it's
not
okay,
so
and
I
fully
agree
with
that
lemon
in
the
next
time.
Petrescu
on
this
one,
we
need
to
review
it
and
we
want
it
to
make
it
in
one
sentence,
but
I'm
afraid
that
we
need
to
consider
a
lot
of
case
and
enumerate
them.
B
Do
we
receive
ipv4
connectivity
from
the
3gpp,
for
instance,
do
we
need
to
share
that
the
ipv4
connectivity?
Do
we
receive
one
PVD,
multiple
PVD?
Do
we
want
to
push
the
PVD
below
and
in
all
those
case
we
will
say
recommendation,
so
this
is
still
on
our
plate.
There
and
I
hope
to
get
some
assistance
from
the
list
to
cut
out
all
those
case.
So
now,
basically,
we
went
from
three
sentence
on
this
part
on
zero.
We
are
about
15
sentence
on
0-3,
we'll
end
up
with
one
page
on
zero
for
all.
B
We
simply
consider
I
mean
if
we
cannot
resolve
it
in
a
before
I
tend
to
say
to
be
D,
okay
in
another
draft
or
whatever,
but
then
it's
annoying,
because
I
really
want
to
put
this
so
next
step.
Issue
Adagio
for
one
minor
change:
I
100
term
exchange
of
company,
so
we
need
to
clarify
this
and
put
this
extension
to
mostly
one
page
of
text
review
by
six.
It's
mandatory
I
wasn't
able
to
be
on
the
agenda
part
in
my
photo
asking
late
this
morning.
B
I
get
a
side
meeting
the
post
and
downs
of
the
six
man
meaning
list.
We
were
in
the
room,
so
I
don't
consider
this
as
a
real
review,
even
if
the
known
face
here
that
I'm
interested
in
the
draft,
also
in
six
million
v6
up.
So
that's
not
a
big
surprise.
I,
don't
expect
anything
bad
or
good
from
the
six-month
presentation
review
because
of
the
same
people.
That
will
do
the
review
there.
B
C
Mean
fara
just
a
small
point,
while
you're
clearing
things
up
you've
added
a
reference
to
3633
and
Burton
0-3,
that's
gonna
be
obsolete
to
go
in
33,
15
base
case
I've,
rented,
so
I
think
most
things
are
referencing
the
best
now,
okay,
so
a
million
a
third
point,
with
a
revision
of
your
fault.
Thank
you.
Okay,.
A
E
E
Okay,
after
a
little
conversation
with
Tom,
Herbert
I,
think
I
can
describe
the
problem
and
the
recommendation,
while
standing
on
one
foot
in
just
in
case
I,
couldn't
do
that
I
studied
yoga
for
a
while,
so
I
can
stand
on
one
foot
for
a
long
time.
Anyhow,
the
problem
is
when
a
packet
is
fragmented.
The
upper
layer
header
appears
only
in
the
first
fragment
many
stateless,
middleboxes,
firewalls
load
balancers
and
the
like
require
access
to
the
upper
layer.
E
Header
now,
by
definition,
a
stateless
middle
box
doesn't
perform
virtual
reassembly
anyhow,
fragmented
packets
cause
these
stateful
middle
boxes
to
behave
badly.
So
what
do
we
do?
Well,
we
have
a
two-part
recommendation.
One
part
of
the
applet
of
the
recommendation
is
for
application
developers.
New
applications
should
break
their
reliance
on
IP
fragmentation.
What
we
want
them
to
do
is
push
the
problem
of
fragmentation
up
to
the
IP
to
the
upper
layer.
So
you
won't
see
IP
fragmentation
that
much
anymore.
We
realize
it's
not
always
possible.
So
there's
a
part.
E
E
E
E
There's
an
outstanding
comment
that
I
prefer
should
be
in
that
list
of
examples,
and
we've
had
pushback
in
either
direction,
since
it's
only
in
examples,
I
think
the
right
thing
to
do
is
leave
it
out,
since
it's
really
kind
of
not
the
main
point
of
the
document.
It's
just
examples
also,
if
there
are
any
other
outstanding
issues
that
I
haven't
gleaned
from
that
very
long
list
on
the
conversation
on
email
list,
please
bring
them
out
here,
there's
also
a
merciless
reality
check.
Well,
applications
heed
direct
recommendations
of
this
are
draft.
E
Well,
the
cost
of
compliance
for
new
applications
is
probably
relatively
low.
Hopefully
they
will
heed
the
recommendation,
as
for
others,
if
they're
economically
motivated
yes,
they
will
heed
the
recommendation
if
they're
not
economically
motivated
their
behavior
is
predictable.
The
same
question
applies
for
middle
box
developers.
Will
they
heed
the
recommendation?
Well,
the
cost
of
compliance
depends
on
the
middle
box
type.
Probably
a
sex-based
middle
boxes
will
be
a
little
more
difficult
to
comply.
Also,
there's
the
problem
of
installed
base.
So
the
ultimate
answer
to
both
of
these
questions
is
the
market
will
decide.
E
F
F
Now
in
discussion
of
it
in
TS
utility
this
morning,
I
think
we
were
a
little
uncertain
about
the
value
and
likely
utilization
of
this.
In
light
of
what
you
have
to
say
here,
which
basically
is
a
I'm
hearing
as
almost
a
ringing
recommendation
from
int
area
to
stop
using
IP
fragmentation,
I'd
be
interested
in
views
from
this
community
on
the
potential
value
of
UDP
options
for
UDP
level,
fragmentation
as
a
tool
to
get
there
from
here,
UDP
UDP.
E
G
Michael
abramson,
so
I
think
I
support
this
conclusion.
That
I
think
this
is
as
close.
We're
going
to
get
to
you
know.
Recommendation
coming
out
of
this
is
a
pragmatic
approach
and
I
think
the
transport
is
there.
Are
these
stateless
boxes
they
it's
very
efficient
to
do
stateless
things,
so
please
include
in
every
packet
what
these
faceless
devices
need
to
make
a
decision
on
what
to
do
so
that
going
forward
so
saying
fragmentation
be
it.
The
problem
is
not
IP.
G
E
G
Do
it
yes,
I
even
I
mean
I
I
was
supportive
of
saying
that
these
middle
books
devices
all
that
there
should
be
a
must
in
there
and
support
fragmentation,
but
I
know
that
we
don't
have
approach
called
police
anyway,
so
it
doesn't
matter
so,
but
I
think
this
is
a.
This
is
a
reasonable
it
roughly.
It
reflects
reality
and
it's
a
you
know,
it's
a
sensible
recommendation.
Thank
you.
Fred.
What's.
H
H
E
E
H
I
A
J
Yes,
it
is
Krishnan,
so
a
couple
of
things,
so
one
of
them
is
like
kind
of
we
somehow
need
a
way
to
expose
the
path
MTU
to
the
upper
layers
right.
So
this
is
not
like
something.
That's
it's
just
a
specification
here
like
there's
an
interface
that
in
here
there
like
some,
some
application
discovers
what
the
path
MTU
is
use
from
the
IP
side,
so
I
think
that
needs
to
get
specified
somewhere
and
since
we
decided
whole
sentence,
awesome
very
good.
Okay
done,
okay,
see
the
best.
Let
me
save
a.
A
K
A
E
And
it's
kind
of
a
strange
invocation
of
pastels
law.
You
know
be
conservative
and
what
you
send
and
liberal
and
what
you
accept.
So
since
we
know
that
there's
this
sensitive
area,
IP
fragmentation-
don't
get
into
it
if
you
don't
have
to
if
you're
an
application
developer
and
if
your
middle
box
developer
deal
with
it.
If
the
application
developer
didn't
stay
away.
Okay,.
L
Erik
Lane
just
wanted
to
observe,
I,
think
or
ask
you
about
section,
seven
point:
four
recommendations
for
network
operators.
Is
it
worth
it
just
basically
says
be
standards,
compliance,
meaning
you
know,
make
bheegi
bheegi,
or
is
it
worth
a
one
line
sentence
saying
that
operators
should
make
sure
they
m2
use
on
their
links
are
fit
for
purpose
whatever?
That
purpose
may
be
sure,
if
you
could
send
me
around
reminder,
I'll
put
it
in
the
next
version.
G
Okay,
Michael
Irvin's
I
just
wanted
to
comment
here
that
there
are
operating
system
vendors
right
now
that
do
expose
the
path
unto
you
to
applications
so
that
the
application
developer
he
was
sending
a
UDP
packet.
He
can,
he
can
understand
if
this
will
be
fragmented
or
not
mm-hmm.
So
it
would
be
good
that
yeah
I
know
if
it
don't
know
if
that
should
go
into
another
document
or
something,
but
is
a
good
recommendation
for
replicate
for
operating
system
developers
to
including
their
UDP
acts.
I.
M
Gory
fares
trying
to
rapidly
catch
up
as
I,
walked
in
the
room
and
two
things
I
heard,
which
at
lights
just
immediately
comment
on
and
I
think
that
interface
has
to
exist.
The
MPS
thing
has
been
maximum
packet
size
passed
up.
The
transport
has
been
discussed
in
taps.
We
have
lots
of
thoughts
about
how
to
do
it
there
that
needs
to
start
appearing
in
other
groups
in
the
IETF
and
become
real.
It
doesn't
think
this
currently.
J
Situation
so
I
think
are
answered
until
today
has
been
not
in
the
IDs
okay,
so
like
we
haven't
really
so
like
every
time
we
had
to
like.
We
want
to
write
something
socket
over
the
past
10
years.
We
push
back
on
it
and
say
it
doesn't
belong
to
that.
Yes,
okay,
like
go
to
POSIX
whatever
to
do
it
right,
but
I
think
Dave
Taylor.
If
he's
in
the
room,
he'll
say
some.
J
That's
kind
of
been
the
answer,
so
I
think
the
last
one
we
did
was
like
probably
10
years
ago,
right
like
with
a
socket
interface
and
I,
think
what
they
will
say
is
like.
Oh,
we
are
fine
to
write
like
non
concrete.
Like
did
you
have
another
name
for
it
day
after
second,
the
face
is
fine
for
a
siddha
fine,
but
not
like
a
real
interface
for
somebody
to
use
so
I'll
leave
you
today
because
he
talks
much
better
than
me.
N
Thanks
riff,
so
I
think
part
of
the
question
was:
where
does
the
discussion
belong
and
I
think
what
we
heard
is
right
now
that
discussions
and
taps
separately
does
the
IETF
do
like
abstract
or
concrete,
and
this
both
things
are
interesting
for
abstract
things.
I
think
caps
is
a
good
place
for
it
for
concrete
things.
N
Posix
w3c
pick
the
pick.
The
language
I'll
tell
you
what
the
organization
is
is
a
good
place
for
it
right
now.
The
closest
thing
that
we
have
to
a
liaison
for
POSIX
is
me
I'm
on
the
mailing
list
for
the
C++,
a
loving
group
which
also
does
C
stuff,
and
so,
if
there's
things
that
we
want
to
say,
let
me
know
I
monitor
the
list.
N
If
there
are
things
we
want
that
community
to
do
I'm
happy
to
post
that
to
the
list,
because
it's
a
group
that's
hard
to
get
into
it's
basically
invite-only
and
I'm,
the
IETF
representative
and
there's
at
least
I
think
two
other
IETF
people
that
are
on
that
list.
Not
just
me.
But
if
there's
things
we
want
to
say
I'm
happy
to
convey
that,
but
so
far
I
keep
asking
at
each
I
TFSI
things
we
want
to
convey,
and
so
far
the
answer
is
not
yet
not
yet
not
yet
and
I'm
figuring
someday.
M
M
Gonna
have
to
be
careful
when
we
define
this,
that
we
don't
have
Network
layer,
making
one
decision
on
transport
layer
making
another
and
up
on
top
trying
to
do
probing
in
your
taxes
is
taking
time
to
figure
out
how
to
do
this,
but
they
are
going
to
try
and
figure
out
some
guidance
for
the
transport
bit
and
the
network
people
probably
have
to
figure
out
whether
they
need
a
separate
API
or
whether
they
just
simply
expose
to
the
transport.
But
remember
for.
E
M
M
Scared
about
what
you
put
in
the
socket
layer
of
the
stack,
it's
all
I
say:
I
mean
if
you
don't
want
to
do
fragmentation
reassembly
at
the
IP
layer,
then
don't
do
to
the
socket
layer
either.
I
think
I
really
should
be
doing
application
space.
If
you're,
really
pushing
up
to
the
application
like
a
tunnel
would
do
as
an
application.
This
graph.
E
Do
it
in
the
upper
layer,
it
doesn't
say
how
to
do
it
in
the
upper
layer
or
even
more
Thanks,
so
I
think
the
action
item
I
have
is.
There
is
a
recommendation
for
a
new
interface.
That's
suresh
suggests
that
if
you
can
send
me
a
one-liner
reminder
to
put
that
in,
and
I
think
david
you
were
the
guy
who
had
another
somebody
had
another
one
sentence
that
I
should
put
in
and
I
seemed.
F
E
E
O
I
Great
so
I'm
going
to
give
a
short
update
on
generic
UDP
encapsulation,
and
this
cover
is
for
drafts,
so
the
first
two
are
in
working
group
last
call
and
then
two
new
drafts
that
I'll
describe
briefly
next
slide,
please
so
the
base
GU
draft
version,
six
fred
Templin-
is
doing
the
shepherd
right
up.
Thank
you
for
that
Fred
and
then
the
extensions
which
is
also
working
group
last
call.
We
need
a
shepherd
for
that
I
believe
so.
I
would
ask
the
chairs
to
possibly
assign
that
next
slide
please.
I
So
this
is
a
new
draft
control
messages
for
generic
UDP
encapsulation
sogu
allows
both
data
messages
and
control
messages.
Control
messages
are
designed
to
kind
of
Express
control
information
between
the
tunnel
endpoints.
So
the
initial
messages
there's
four
of
those
capabilities,
query
and
capability
response.
So
these
are
messages
to
determine
what
a
GU
receiver
can
handle
so,
for
instance,
which
flags
or
which
security
settings.
What
have
you
so?
It's
exchanges
basically
parameter
information
and
then
there's
kind
of
the
more
typical
echo
request.
Like
a
reply,
the
echo
request
reply
allows
for
timing.
I
Sequence
numbers
looks
a
lot
like
ICMP
echo
request.
Reply
next
slide,
please,
so
the
capabilities
are
encoded
in
tlvs
and
right
now,
there's
four
tlvs
that
are
used
for
this.
So
the
GU
variants
is
a
simple
bitmap
and
right
now,
there's
up24
groove
Aryans.
So
there's
only
two
bits
or
four
bits
used
in
the
bitmap:
the
control
messages
type
again.
The
data
and
the
TLV
is
a
bitmap.
So
this
is
a
number
a
bitmap
between
0
and
256.
That's
the
goo
flags
just
map
the
flags
of
the
goo
header.
I
So
if
the
flag
is
set
in
the
data,
that
means
the
receiver
supports
that
particular
flag.
Multi-Bit
flags
are
a
little
bit
tricky
in
some
sense,
so
they
will
hold
the
max
value.
We
may
need
TLB
for
specific
multi
bit
flags
if,
for
instance,
it's
a
3
bit
flag
and
value
5
is
supported,
but
no
other
values.
So
we
could
have
a
TLB
for
that
and
then
the
payload
transform
types,
that's
the
the
last
one
again,
that's
a
bitmap
and
B.
That's
a
byte
field,
so
it's
a
bitmap
from
0
to
255
next
slide.
Please.
I
The
other
draft
is
generic
TCP
encapsulation.
This
was
actually
inspired
from
a
TSV
working
group
discussion
where
we
wanted
to
use
tunnels
over
TCP
in
order
to
get
through
firewalls.
So
this
would
be
layer,
3,
layer,
4
encapsulation
over
TCP
to
get
through
a
firewall
say,
for
instance,
this
was
an
application
when
using
UDP
and
UDP
was
being
blocked
by
the
firewall.
The
idea
would
be:
okay,
just
use
that
over
TCP
and
then
you
can
get
through
the
firewall.
So
in
this
case
we're
encoding
GU
messages
into
the
tcp
stream.
I
The
one
thing
that
we
need
is
message
demarcation,
so
the
message
length
precedes
headers.
As
I
said
it
can
do
layer,
3,
layer,
4
encapsulation.
If
it
is
layer,
4
encapsulation,
the
IP
header,
for
each
message,
each
layer,
4
message
2-
is
derived
from
the
outer
header,
so
we
can
get
the
address
as
the
rest
of
the
fields
from
the
outer
header.
I
The
one
caveat
here
for
the
layer,
4
encapsulation,
is
that
if
an
encapsulated
transport
layer
includes
a
checksum
like
a
UDP
or
encapsulated
TCP,
and
the
outer
packet
goes
through
an
at
the
addresses
are
changed
such
that
the
checksum
would
be
invalid.
So
the
NAT
address
checksum
option
we
defined
and
you
actually
should
support
or
should
solve
that
problem
as
long
as
that's
set
correctly
next
slide,
please.
I
So
this
is
what
the
GTE,
the
GU
transporting
capsulation
or
generic
transport
encapsulation
looks
like
and,
as
you
can
see,
it's
pretty
straightforward.
The
message
format
has
just
preceded.
A
GU
header
is
preceded
by
a
length
field
followed
by
the
GU
header,
followed
by
the
payload.
The
length
is
the
complete
message
from
the
start
of
the
length
field
to
the
end
of
the
payload
and
then
on
the
right.
These
are
simply
sequentially
placed
in
the
packet
one
message
after
another
next
slide.
I
Please
one
thing
we
can
do
is
since
this
is
a
TCP
stream,
is
do
some
creative
header
compression,
similar
to
van
jacobson
compression
for
PPP
and
there's
two
variants
right
now
that
are
allowed.
So
one
is.
We
can
set
the
message
length
through
a
GU
control
message
and
the
idea
is
that
the
message
length
field
could
be
1,
2,
3
or
4
bytes.
So
if,
for
instance,
we
were
just
encapsulating
UDP
messages,
they
would
have
a
maximum
length
of
only
only
2
bytes
would
be
needed
to
express
the
length.
A
A
M
It
was
going
to
be
a
question,
but
I
come
from
30
and
Gauri
first,
as
a
TSP
WG,
chair,
I
didn't
quite
get
why
this
was
being
proposed
and
I
did
notice.
The
draft
content
es
vwg
in
the
title
and
that's
this
is
the
sort
of
thing
TS
vwg
does.
So
if
this
group
thinks
that's
really
cool
and
please
come
talk
to
TS
vwg
about
it,.
G
M
Gory
wanted
to
be
able
to
comment
on
it
on
the
transport
people
simulate
and
whether
we
need
yet
another
version
of
an
encapsulation
depends
upon
the
use
case
and
the
number
of
people
who
are
implementing
and
the
need
for
interoperability,
etc,
etc,
etc.
So
we're
gonna
charge
this
as
a
buff
I've
got
lots
of
questions.
I
want
to
ask
about
why
we're
doing
it
and
I
don't
know.
Probably
gue
but
and
I
do
see.
A
growing
number
of
drafts
here
and
I
see
a
growing
expanse
of
the
Arielle
is
covered.
M
J
Suresh
again
so
yeah
I
agree.
Could
you
write
like
it?
It's
really.
If
there's
a
significant
amount
of
work
here,
I
would
think
like
a
buff
would
be
like
a
better
way
to
go
and
then
figure
out,
like
you
know
where
it's
gonna
end
up
after
so
as
I
said
like
I.
Don't
think
here
is
the
right
training
for
this,
because
I
think
most
of
the
baby
expertise
is
somewhere
else,
and
so
we
can
talk
offline,
I,
think
like
Raleigh
or
email,
but
Tom
as
well,
and
then
figure
out
very
pick
up.
Okay
sounds.
A
Good
yeah,
that
was
good
feedback
and
volley
favorite,
couldn't
hear
it
sure
is
going
to
be
minute
and
recorded.
So
that's
good!
A
A
P
P
P
P
For
the
taxonomy,
first
of
all,
for
the
domain,
why
it
should
be
exist,
what
technology
it
is
used.
It's
a
io2
network
or
l3
network,
it's
a
geography,
locality
or
it's
a
kind
of
overlay
drawn
together
through
a
public
internet.
So
that's
something
we
need
to
define
for
the
domain
itself,
zoom
for
the
notes.
We
also
want
to
define
the
note
whether
it's
security
enrollment
and
whether
the
note
is
belong
to
one
domain
or
multiple
domains,
et
cetera,
and
we
definitely
need
to
define
the
domain
boundary
expressly
and
also
the
topology
accenture.
P
For
the
scope
of
the
limit
means,
as
we
know
that
it
has
always
been
protocols
or
mechanism
are
actually
designed
and
operated
within
some
exploit
or
maybe
increase
domains
rather
than
a
real
end-to-end
across
the
universal
internet.
So
this
is
happening
and
the
trend
seems
like
more
and
more
technologies
are
released
at
the
llanto
limited
term
use.
P
So
our
basic
goal
of
this
work
is
to
whether
we
can
come
up
with
some
common
requirements
and
common
cause
of
the
regions,
so
that
it
is
actually
a
challenge
to
the
current
notion
that
every
Internet
Protocol
is
defined
in
the
scope
of
Universal
interoperability.
So
that's
a
bottom
line
and
we
want
to
hear
opinions
from
you
whether
you
agree
with
the
trend
and
whether
you
agree
with
the
principle.
P
P
P
So
so,
with
a
functional
requirement.
First
of
all,
we
need
to
assign
a
domain
and
identity
so
that
every
note
and
every
protocol
can,
I
really
knows
about
the
existence
of
atomy
and
then
the
note
eligibility.
The
law
have
to
determine
myself,
okay,
which
domain
it
will
join,
and
when
the
node
joiner
to
mean
we
must
provide
a
kind
of
secure
enrollment
and
that
to
me
the
null
can
also
withdraw
the
ointment
to
a
specific
domain,
and
we
should
also
allow
the
North
temporarily
join
a
domain.
And
yes,.
B
Eric,
can
you
go
back
on
the
previous
slide
Erie
link?
Maybe
I
missed
the
concept
of
domain,
but
when
I
see
the
requirement
to
join
a
domain,
that
could
be
simply
my
old
laptop
connected
over
an
Ethernet
cable
to
my
new
laptop
I.
Don't
think
this
thing's
free
to
come?
Oh,
did
I
miss
completely
the
domain
definition.
B
P
The
limited
to
men
define
in
this
draft
basically
several
basic
scheme:
one
is
just
a
geographical
or
physical,
local
T
and
they
may
be
standalone,
and
then
they
may
be
connect
to
the
internet,
but
the
operation
functions
only
within
their
their
scope.
That's
one
can
the
other
is
logical
limit.
It
means
they
may
be
distributed
among
very
wider
or
much
wider
area,
but
drawn
together
through
repeal
kind
of
technologies.
Yeah.
B
P
P
F
Airport,
so
I've
I
have
I,
have
a
number
of
scars
from
living
through
Oz
Mitch's
adventures
in
transport.
That
eventually
resulted
in
us
to
finding
the
notion
of
controlled
environment.
Anybody
want
to
look
for
that
see.
The
UDP
guidelines
are
rx
youth,
which
I
believe
is
80
85,
trying
to
figure
out
how
controlled
environment
relates
to
limited
domain,
and
particularly
with
all
of
the
security
requirements
you
have
around
enrollment.
F
It
sounds
like
you're,
asserting
that
the
more
I
get
away
from
geographically
isolated
that
you're
thinking
about
an
overlay
domain
where
the
nodes
are
scared
here
there
and
everywhere
and
somehow
have
to
have
to
associate
with
each
other
for
controlled
environment.
We
wound
up
leaning
heavily
in
many
cases
in
practice
on
the
notion
of
common
network
operations
and
administration.
In
some
sense,
you
could
think
of
this
as
dividing
up
the
intranet
by
a
s
and
there's
certain
protocols
that
you
simply
don't
want
to
offer
it
beyond
a
single.
A
s.
P
Personally,
I
believe
the
controlled
environment
definitely
has
some
overlap
or
maybe
very
big
overlap
with
the
living
in
the
means.
I,
don't
know
the
controlled
environment
very
much
in
detail,
but
for
limited,
amend
this
draft
for
the
terminology.
I
think
the
the
essential
point
is
that
maybe
we
need
some
expert
definition
and
excrete
regulations
of
operation
and
that
might
be
expressed
as
kind
of
options
or
metadata
in
the
protocol,
rather
than
the
current
module
that
it
is
always
be
done.
F
L
Eric
claim
I'm
not
really
sure
philosophically
I
agree.
This
seems
like
a
way
to
get
exemptions
for
things
that
people
will
tell
you
our
bad
ideas,
and
then
you
say:
oh
what
it
doesn't
harm
the
Internet.
Therefore,
it's
a
limited
domain.
Therefore
I
can
we
can
do
whatever
we
want
and
sometimes
things
jump
domains.
You
know
sometimes
things
connect
to
multiple
domains
and
and
even
if
it's
not
like
physical
things,
sometimes
standards
can
jump
domains,
things
that
are
applicable
and
right.
L
P
L
F
David
black
doesn't
have
to
be
had,
doesn't
have
to
be
both
scenarios
with,
in
fact,
in
controlled
environment
done
it
both
ways.
The
two
poster
children
for
controlled
environment
are
MPLS
over
UDP,
which
thou
shalt
run
in
a
controlled
environment,
because
otherwise,
heaven
heaven
heaven
help
you
with
misbehavior
of
the
MPLS
forwarding,
plane
and
GRE
over
UDP,
which
actually
is
an
example
that
we
SPECT
that
we
expect
twice
and
has
different
constraints
on,
depending
on
whether
you're
in
a
controlled
environment,
a
controlled
environment
or
not.
F
F
And
that
yes
controlled
environment
for
those
who
protocols
Maps
very
strongly
on
to
administrative
domain
and,
in
particular,
appeals
to
to
awake
and
aware
Network
administration
to
catch
things
that
may
go
wrong
when
we
allow
the
relaxed
operating
parameters
in
a
controlled
environment.
Somebody's
got
to
be
paying
attention
if.
L
J
Hi
so
dis
Krishnan,
so
I
have
read
the
draft
and
I
I
do
think
this
is
a
conversation.
That's
not
limited
to
this
working
group.
I
just
don't
know
like
a
good
venue
for
this,
but
I
think
it's
something
that
we
need
to
talk
about
at
the
IETF
level.
I,
don't
think
it's
really
limited
to
something
we
can
do
here.
So
I
think
it
requires
a
wider
audience
and
I
don't
know
where
it
is
like
it
is
this
a
nonworking,
deforming
buff,
maybe
next
meeting
or
something
like
that.
J
I
do
think
we
need
more
on
this,
because
I
think
it
strongly
affects
like
pretty
much
all
the
area
so
like,
because
I
think
I
could
apply
this
to
IOT
domains,
for
example,
that,
like
you
know,
people
do
different
things
and
like
transport,
like
David
like
like
routing
to
write
like
you
know,
some
people
say
hey,
we
don't
need
security
for
routing
right
and
like
it's
administrative
domain,
so
that
kind
of
thing
kind
of,
like
you
know,
probably
has
to
be
looked
over
at
a
higher
level
than
here.
Thank.
Q
P
P
Q
Q
Q
R
All
right
yeah,
so
this
is
about
the
the
maps
together
with
a
few
folks.
The
man
stand
for
multi
access
management
services,
and
here
we
are
present
the
the
latest
job
that
we
are
working
on
the
main
protocols
and
the
draft
is
1006
and
this
virtual
instrumentation
we
did
in
this
group,
but
we
did
a
lot
of
work
on
flying
between
the
draft
working
with
other
folks.
So
that's
like
a
little
bit
word
about
the
reference
architecture
formats.
So
mom's
is
meaningful
management
and
managing
the
multiple
access
it
introduces.
A
R
Functionality
or
logical
blocks
in
the
network
and
the
car
client,
the
user
plain,
the
network,
multi
access
data,
proxy,
handles
user
plan
functionalities
in
the
network
and
then
the
kind
access
to
the
proxy
functionalities
a
client
and
they
knew
the
plane
protocol-
is
basic.
The
protocol
rounds
between
the
nm
ATP
and
the
CM
ATP,
and
that's
the
main
focus
of
this
draft
yeah
next
line
just
list.
R
My
example
could
be
that
you
have
a
DC
control
speech
sessions
and
you
may
want
to
send
a
downlink
PCB
traffic
over
one
access
and
they
are
playing
TCP
traffic
on
the
other
access
and
we
want
to
be
able
to
adaptively
switching
the
paths
from
different
between
different
access
and
also
be
able
to
aggregate
it.
Just
like
TCP
utilizing,
multiple
access
to
the
end
and
when
we
switch
from
one
has
to
be
other
pans.
A
R
R
R
R
I
think
this
sub
layer
we
have
defined
and
three
solutions.
That
is
available.
At
least
we
can,
including
this
framework.
The
first
one
is
a
multi-party
CPE
proxy,
which
is
basically
reusing
existing
protocol
that
has
been
defiled,
developing
ITF
community.
The
second
one
is
this:
one
is
basically
layer,
four
solutions
and
the
second
one.
Third
one
is
layer,
three
solutions
and
the
third
one
is
the
GRE
based
protocol
and
then
the
basic.
R
We
are
reusing
the
gie
encapsulation,
but
we
carry
additional
information
in
order
to
support
the
amounts
functions
and
then
the
last
one
is
a
completely
new
function
of
protocols.
We
call
trailer
page
conversion
protocols
compared
to
gie.
It
is
because
it's
a
new,
so
we
have
the
flexibility
functionalities
as
well
as
remove
some
limitation
of
GRE
with
an
IP
IP.
R
A
R
Head
and
then
the
the
second
layer
of
the
second
player
is
adaptation
sub
layer,
this
layer,
addressing
all
the
access,
specific
constraints,
acuity,
tunneling
or
transferring
transporting
traversing
over
the
net.
We
have
right
now
defined
for
different
methods.
We
can
use
UTP
paneling
and
then
we
can
also
use.
R
R
R
R
R
R
R
R
In
padded
off
the
transport
layer,
protocols
rise
basically
and
UDP.
The
limitations,
though,
is
kind
of
requiring
always
IP
almighty,
encapsulation
and
also
because
of
GI.
A
hat
is
already
defined,
so
we
kind
of
reuse
the
fields
of
view
there,
for
example,
the
key
field
to
carry
the
map
specific
information.
So
that's
the
that
is
the
second
option
and
next
slide.
R
R
Yeah,
the
slides,
the
last
one
is
a
two-page
filler
based.
This
Y
is
a
new
we're
proposing
and
the
main
difference
here.
You
don't
get
rid
of
the
IP
over
IP
tunneling
and
we
add
a
control
information
at
the
end
of
the
packet,
and
then
we
have
this
IP
protocol
type
to
use
either
we
can
define
a
new
type
to
indicate
the
presence
of
trader
or
we
can
use
the
1
1
4,
which
is
kind
of
an
easy
roja
protocol,
generic
type
that
we
can
use.
In
this
case.
Of
course
our
preference
would
be.
R
J
R
J
J
So
the
like,
if
you
think,
that's
like
you,
want
to
put
your
ATF
work,
like
you
know,
come
to
me,
talk
to
me
for
a
walk
or
talk
to
any
ad
for
a
buff,
because
this
is
not
like
a
one-off
item
for
sure
right,
I've
seen
them
I
read
the
mom's
draft
like
the
framework
graph
I
was
the
shepherding
ad
for
the
conflict
review.
So
I
know
like
the
scope
of
the
thing,
and
it's
pretty
big
huge
if
I
may
say
so
right.
So
it's
like
yeah.
J
R
R
O
I'm
going
to
present
this
overlay
the
past
segment.
Actually,
we
have
presented
in
the
transport
area
working
group
I,
believe
quite
a
number
of
work
actually
belong
in
the
transport
area,
but
we
won.
The
prison
here
want
to
bring
some
attention
in
the
internet
areas
because
we
kind
of
think
eventually
some
encapsulations
could
be
done.
So
it's
something
like
call
for
interest
or
kapha
expert
to
your
for
your
attention,
and
so
the
motivation
here
is
is
actually
pretty
straightforward.
O
There
are
quite
a
number
of
researchers
and
even
some
deployments
trying
to
leverage
the
cloud
router
nodes
in
various
clouds
to
establish
a
better
path
in
order
to
provide
a
performance
closer
to
the
leased
lines.
So
we
also
ran
some
of
the
experiments
by
ourselves.
Then
we
find
out
actually
quite
a
high
chance
that
17
one
percent
chance
we
can
find
a
better
overlap,
has
compared
to
the
default
one.
O
So
now,
this
kind
of
approach
is
becoming
more
and
more
practical
for
various
reasons,
like
it's
becoming
more
inexpensive
and
they're
in
every
based,
distinct
and
is
easily
scaling
in
the
wider
number
of
cloud
providers
can
provides
the
enhanced
network
performance
instances.
They
give
better
PPS
forwarding
capabilities.
So
I
roughly
show
some
of
the
experiments
here.
We
we
create.
Basically,
we
create
120
overlay
nose,
I
mean
in
different
provider.
Sorry
clouds,
then
this
is
part
of
them.
So
what
we
want
to
show
is
actually
the
default
path
is
not
always
promising.
O
Some
of
them
are
really
good,
but
some
of
the
money-
let's
see
their
red
circles,
actually
it
constant.
It
constantly
give
their
bad
past
latency.
Then
this
shows
we
measure
regarding
the
packet
loss,
so
some
map
has
actually
almost
always
keep
their
high
loss
rate.
Actually
this
is
one
is
bangkok
and
for
some
some
other
paths,
the
sometimes
is
good,
sometimes
not
so
good.
So
what
we
are
trying
to
do
is
actually.
O
This
problem
is
quite
well-known
for
a
while,
so
the
slow
loss
recovery
over
long-haul
network,
so
for
some
certain
applications,
and
especially
for
when
I
mean
the
Intercontinental,
our
networks,
the
end-to-end
pack,
a
loss
recovery
is
not
good
enough
to
meet
the
requirements,
so
potential
methods
is
the
local
recovery
either
retransmission
or
doing
something
I
could
replicate.
I
mean
the
facts,
focusing
so
why
we
want
to
bring
that
up
now,
as
mentioned
just
now,
the
cloud
internet
allows
us
to
do
the
path
selection,
and
it
naturally
has
already
been
broken.
O
I
mean
I
mean
partitioned
into
multiple
path
segments
we
can
menu
manipulated.
This
overlay
nodes
in
in
some
emerging
technologies,
like
virtual
IO,
gives
mock,
gives
them
more
forwarding
capabilities
in
the
other.
The
second
problem
is
this:
we
know
the
TCP
sender
actually
decreases
a
standing
rate
normally
by
a
fixed
ratio.
Whenever
there
is
a
packet
loss
is
conceived.
So
basically,
it's
because
sender
has
a
hamachi
information
available
to
determine
how
much
to
decrease
otherwise.
So
there's
some
pay
I
mean
some
researchers
are
me
on
this.
O
In
this
particular
scenario,
actually,
the
Overland
nodes
could
provide
more
richer
information.
Like
the
loss,
information,
congestion,
information
to
the
sender,
so
to
let
the
sender
better
decide
whether
it
wants
you
decrease
the
sending
rate
or
how
much
to
decrease.
So
these
are
the
second
problem.
We
want
to
take
these
opportunities
to
do
loops,
which
is
localized,
optimization
or
path
segments
here.
The
localized
actually
may
not
be
so
accurate
because
the
local
means
the
beach
in
to
overlay
nodes
by
it
physically.
It
could
be
I
mean
far
apart,
so
to
dress
their
problems.
O
We
we
mentioned
it
just
now
for
and
also
to
address
the
problem
that
the
overlay
nodes.
Normally,
they
have
limited
capacity
and,
in
case
of
impairment,
of
the
hop
of
the
link
between
overlay
nodes
now
Howie,
how
we
should
fix
that
now
briefly,
we
figure
out
there
may
have
three
key
elements
of
a
solution.
The
first
one
is
a
local
recovery
over
the
tunnel
in
for
sure
we
we
might
or
we
would
require
the
loss
detection,
any
indication
in
the
mirror,
the
segment
RTT
in.
O
O
So
basically,
we
kind
of
think
that
some
common
elements
are
required
for
local
recovery
and
the
traffic
splitting.
We
are
trying
to
figure
out
a
feasible
way
to
interact
with
upper
layer
for
congestion
control,
so
the
third
bullet
actually
possibly
more
relevant
to
the
internet
area.
The
overlay
protocol
extensions
we
we
haven't,
we
haven't
figure
out
a
feasible
way
to
work
on
it.
O
O
B
D
Right
so
I'm
gonna
give
you
an
update
on
our
latest
work
on
the
Sox
protocol,
so
we've
got
three
major
changes
in
version
5
of
the
draft.
First
up
we're
gonna
handle
wave
change.
The
way
we
handle
the
first
bytes
of
the
of
the
application
data.
We've
also
improved
the
reverse,
TCP
proxy
functionality.
D
So
now
you
can
process
so
now
the
client
can
receive
multiple
incoming
connections
and
process
them
in
parallel,
even
if
the
all
of
the
incoming
connections
are
for
the
same
port
and
also
we've
also
revamped
a
UDP
behavior
behavior,
so
the
P
behavior
in
stock
version
5
was
problematic
and
we've
I
hope
we've
fixed
it.
So
first
of
all
starts.
D
So
the
basic
premise
of
this
is
that
was
core.
State
machine
is
pretty
simple,
so
the
client
sends
a
request
and
the
the
proxy
has
two
chances
to
say
no.
First
up
it.
Yes,
it's
a
no
because
it
doesn't
trust
who
the
client
is,
and
then
it
gets
the
chance
to
say
no,
because
the
connection
failed
now
complicating
this
state
machine
is
only
possible
if
the
client
signals
that
it
wishes
to
do
so.
D
So,
in
this
case,
if
the
client
includes
an
authentication
method
option
and
as
part
of
the
request,
they
can
do
the
classic
authentication
as
as
in
similar
as
it's
done
in
such
version
5.
So
the
basic
idea
before
start
is
that
the
client
can
start
sending
application
as
soon
as
possible
as
long
as
it
doesn't
risk
breaking
the
state
machine.
D
This
of
course
depends
on
the
authentication
method
used
now,
given
that
four
starts
are
outright,
are
not
only
possible
at
outright
recommended
by
the
draft.
The
concept
of
initial
later
doesn't
really
serve
any
purpose
unless
the
client
is
willing
to
go
through
the
authentication
phase.
So
the
initial
later
length
field
was
moved
from
the
request.
There's
no
longer
a
core
feature.
D
It
has
me
move
to
the
authentication
method
option
now
initial
data
length,
we've
kept
initial
data
length
at
16
kilobytes
and
it
can
no
longer
be
dropped
by
the
proxies
now
16
kilobytes
is
a
reasonably
small
number
and
it's
in
fact
more
than
typical
kernel
buffer
size
is
used
by
TCP
stacks.
So
there
wasn't
much
point
in
allowing
in
giving
a
proxy
a
chance
to
drop
that
initial
later,
so
it
can
no
longer
drop
it.
So
and
as
such,
we
remove
the
initial
eight
officer
from
the
operation
reply.
D
Next
up,
we've
added
a
payload
length
field
to
the
T
of
option.
Now,
when
the
proxy
does
TFO
on
behalf
of
a
client,
the
problems
can
arise
if
it
sends
too
much
data
or
too
little
data,
so
problem
so
too
much
so
TF.
The
TF
o
since
payload
is
couple
has
different,
is
covered
by
different
semantics.
It
has
different
guarantees
and,
as
such,
the
client
should
be
able
to
signal
how
much
data
@k
it
can
tolerate
being
replayed.
D
Now
now,
there's
also
a
corner
case
in
which,
if
the
fatal
is
too
small,
bad
things
happen
in
terms
timing,
let
me
show
you
what
I
mean
so,
let's
say
we,
the
client
sends
out
a
request
and
it
also
tries
to
do
an
HTTP
GET.
Now,
for
some
reason
and
the
request,
the
HTTP
GET
gets
fragmented
either
because
the
request
is
too
large
and
it
didn't
fit
in
the
since
payload
or
some
middle
box
drop
part
of
the
payload.
D
The
proxy
immediately
sends
an
HTTP
GET
to
the
server
now,
assuming
that
there's
high
itt
between
the
proxy
and
the
server
and
low
RTT
between
the
client
and
the
proxy,
the
the
client
can
send
the
rest
of
the
get
request
relatively
quickly,
but
the
proxies
hands
are
tied
until
it
gets
the
syn
ack
from
the
server.
Only
after
it
receives
a
scenic,
can
it
send
the
rest
of
the
HTTP
requests.
D
Ideally,
the
client
should
tell
should
be
able
to
tell
the
proxy
how
much
data
it
expects
to
be
part
of
since
payload,
so
that
the
proxy,
so
that
the
proxy
delays
sending
sending
the
CFO's
hand
over
to
the
server
next.
Next
up,
tcp
reverse
proxy,
so
the
buying
command
works
as
follows.
The
client
sends
a
bind
request
to
the
server
the
to
the
proxy.
The
proxy
list
listens
and
accepts
one
incoming
connection
and
then
closes
the
listening
socket
and
then
relays
the
data
from
the
connection,
so
the
connection
initiated
by
the
client.
D
Now
we
would
like
to
emulate
typical
server
behavior.
That
is,
we
want
the
proxy
to
listen
and
then
keep
accepting
multiple
connections
on
behalf
of
the
client.
So
we
do
that.
So
if
the
client
wishes
do
that,
it
can
include
a
listen
backlog
option
as
part
of
a
binary
quest.
This
prompts
the
proxy
to
listen
for
as
long
as
the
connection
is
open
now
that
first
connection
no
longer
real
relays.
Data
from
one
accepted
connection.
D
Next,
the
proxy
issues
for
the
bind
requests
and
each
point
requests
will
basically
translate
into
an
accept
on
at
proxy
done
and
I
only.
Needless
to
say,
this
is
only
for
authenticated
clients,
because
we
don't
want
the
client
accepting
connections
from
a
socket
that
was
bound
by
some
other
clients
and
finally,
we've
revamped
the
UDP
relay
behavior.
We
now
have
support
and
it
is
a
lot
more
firewall
friendly,
so
we
no
longer
have
the
clients
and
UDP
datagrams
to
arbitrary
ports.
D
We
use
we
use
the
we
use
one
port
180
by
default,
and
the
DTLS
port
is
still
to
be
located
by
a
Ayana.
So
now
the
P
relaying
works
as
follows:
the
client
issues
a
requester
with
over
TCP
telling
the
proxy
what
bind
address
and
port
it
wishes
to
use.
Of
course
it
can
use
0
if
it
doesn't
know
or
doesn't
care
what
what
address
or
what
port
it
receives.
D
The
operation
reply
tells
the
client
what
bind
address
and
port
it
has
received,
and
the
proxy
sends
one
for
the
message
called
an
association
initialization
message
that
tells
the
client
what
Association
I
did.
Can
you
it
can.
It
has
been
allocated
for
that
particular
UDP
association.
So
next
up
the
client
sends
UDP
Datagram.
Now
it's
the
first
UDP
Datagram,
the
client
consent,
the
UDP
Datagram,
either
over
vanilla,
UDP
or
over
DTLS.
D
When
the
proxy
receives
the
this
Datagram.
It
sends
an
association
confirmation
over
TCP
and
from
that
point
on
the
Association
ID
is
forever
bound
to
the
beauty,
peak
or
DTLS
conversation,
and
that
the
first
UDP
Datagram
was
sent
over
now.
This
association
confirmation
message
helps
the
client
reach
standards.
Let
the
client
know
that
first
UDP
Datagram
has
been
received
and
in
cases
where
the
client
wishes
to
run
a
server,
it
can
just
keep
presenting
that
data
gram
until
it
receives
an
association
confirmation.
After
the
association
confirmation,
UDP
traffic
can
flow
in
both
directions.
D
D
D
We've
moved
any
remaining
idempotence
options
from
operation
replies
over
to
our
certification
replies.
There
was
a
slight
oversight
in
draft
and
draft
3,
which
allowed
multiple
authentication
phases
to
take
place.
That
was
not
intended
and
has
been
fixed
and
we
removed
your
option
options
from
your
operation
replies
because
we
couldn't
find
any
use
case
for
them.
D
D
So
what's
next
I've
been
talking
to
the
tour
guys
and
it
turns
out
that
they
they
have
a
new
use
case
for
me,
so
they've
been
making
use
of
the
username
field
in
order
to
signal
to
the
proxy.
What
tour
relay
should
be
used?
That's
that's
a
very
hawkish
use
of
the
username
or
the
username
and
the
password
it
would
be
nice
to
add
some
functionality
to
cater
to
them.
So
I've
been
toying
with
the
idea
of
introducing
versions
to
Sox
versions,
have
been
over.
D
The
contraceptive
versions
have
been
of
part
of
facts
on
the
forum
on
one
other.
Ever
since
I
introduced
the
add
importance
options
now,
I'm
going
to
make
it
explicit
and
allow
authenticated
clients
to
have
multiple
sessions.
That's
allowing
multiple
clients
use
the
same
credentials
yet
have
different
session
state
associated
with
them
at
the
proxy
and
that's
about
it.
For
me,
okay,
thanks.