►
From YouTube: IRTF Open session
Description
The Internet Research Task Force (IRTF) Open session at IETF 108 will be held on 28 July 2020 at 11:00 UTC.
The IRTF Open session will include Applied Network Research Prize (ANRP) presentation by Shehar Bano, Chaoyi Lu, and Ingmar Poese.
A
A
A
A
My
name
is
colin
perkins,
I'm
the
irtf
chair
and
so
to
start
with,
I
just
wanted
to
remind
people.
This
is
an
irtf
session,
so
the
intellectual
property
disclosure
rules
apply,
and
in
particular,
just
to
remind
you
that
the
note
well,
which
you
is
here
on
the
slide,
applies
to
the
talks
in
the
discussion
in
this
meeting.
A
A
Also,
we
have
a
bunch
of
material
online
talking
about
the
irtf.
We
have
the
website.
We
have
a
twitter
account,
which
is
recently
active,
facebook
account,
which
is
much
less
so
and
also
there's
an
announce
and
a
discuss
mailing
list
which
are
both
relatively
low
traffic,
which
you
can
join.
In
addition
to
all
the
research
group
mailing
lists
as
well.
A
The
itf
is
organized
in
a
set
of
research
groups.
We
have
14
research
groups
which
are
active.
Those
highlighted
in
blue
on
the
slide.
I'm
meeting
this
week,
the
privacy
enhancements
group,
the
quantum
internet
group
and
the
network
coding
group
met
yesterday,
and
they
had
some
really
nice
discussions.
So
I'd
encourage
you
to
review
the
meeting
notes.
A
A
All
the
papers
are
online
on
the
website
at
the
url.
You
can
see
on
the
the
slides,
we're
very
pleased.
We've
got
a
really
nice
program
of
talks
coming
up
later
in
the
week,
and
those
who
are
registered
for
the
ietf
can
attend
those
talks
and
you'll
see
them
in
the
agenda
in
the
data
tracker,
all
the
proceedings,
all
the
papers.
If
you
go
to
the
the
website
linked,
there
should
be
available
open
access
as
well.
A
We've
got
three
talks
today
for
the
anrp.
The
the
first
will
be
by
banno,
who
will
be
talking
about
her
work.
Developing
a
taxonomy
of
internet
host
liveness
yi
liu
will
be
talking
about
his
work
on
measuring
dns
over
encryption
and
then
finally,
ingemar
will
be
talking
about
his
work
on
traffic
engineering.
A
A
And
that's
all
I
have
myself
the
agenda
for
the
rest
of
this
meeting.
We
have
the
the
talk
from
banno
on
scanning
the
internet
for
liveness.
First
of
all,
followed
by
cho
yi's
talk
on
dns
over
encryption
and
then
ingmar's
talk
on
steering
hypergiant's
traffic
talks
will
be
pre-recorded,
we'll
be
playing
them
into
the
session
and
then
the
the
authors
and
the
speakers
are
here
and
we'll
have
some
time
for
live
q
a
so
before
we
move
on.
Does
anyone
have
any
comments?
Any
agenda
bashing.
A
B
B
We
will
begin
with
the
taxonomy
focusing
on
each
layer
at
a
time,
so
we
begin
with
the
network
layer
when
we
send
a
prop
packet.
We
first
check.
If
there
is
a
reply.
If
there
is
no
reply,
then
we
say
that
the
target
ip
address
is
dark
at
the
network
layer.
So
in
this
example,
ip1
is
dark
at
the
network
layer
because
it
does
not
send
any
response
to
our
tcp
syn
on
port.
B
B
B
B
B
B
B
B
We
employed
a
few
considerations
to
ensure
the
soundness
of
our
measurements,
the
first
one
of
which
relates
to
temporal
churn
due
to
ip
addresses
legitimately
coming
online
and
offline
or
because
of
dynamic
ip
assignment
practices
so
to
mitigate
the
effects
of
temporal
churn.
We
carried
out
scans
for
all
the
eight
protocols
that
were
mentioned
on
the
previous
slide
simultaneously.
B
B
We
used
an
approach
which
we
call
delayed
retransmissions,
which
means
that
instead
of
sending
the
original
probe
and
the
re-transmission
to
a
target
ip
address
back-to-back,
we
instead
scanned
an
entire
block.
So
in
this
example,
we
have
ip
block
1
and
once
we
finished
with
that
block,
say
in
30
minutes,
then
we
sent
retransmissions
to
the
same
block
before
moving
on
to
the
next
block,
which
is
ip
block
2.
In
this
example,
and
then
we
send
3
transmissions
to
ip
block,
2
and
so
forth.
B
So,
in
summary,
we
carried
out
eight
concurrent
scans,
which
finished
in
about
24
hours,
generating
about
2.3
terabytes
of
data
and
overall,
our
scans
recorded
487
million
network
alive
ip
addresses
out
of
the
3.6
billion
ip
addresses
that
were
probed,
which
we
call
ip
all
in
the
remaining
slides.
I
will
present
a
main
result
from
our
study
in
the
context
of
ipol.
B
B
B
B
Next,
we
look
at
the
coverage
of
different
probe
responses,
so
here
we
break
down
our
previous
graph
by
response
type.
So
here
is
icmp
scan,
and
here
is
the
coverage
that
we
get
when
we
capture
different
response
types,
that
is
echo
reply,
icmp
error
both
and
here
tcp
reply,
icmp
error
and
both
and
for
udp
udp
reply,
icmp
error
and
both.
B
Now
this
wouldn't
be
a
relevant
question
if
an
ip
address
responded
to
all
ports
consistently,
but
we
found
that's
not
the
case.
Only
24
percent
of
active
hosts
respond
to
probe
packets
on
all
five
ports,
which
highlights
the
potential
effect
of
firewalling
or
filtering
practices
on
ip
liveness,
as
viewed
through
different
probes
on
different.
B
B
A
Okay,
thank
you
for
that.
I
I
I
know.
Looking
at
the
chat,
a
couple
of
people
were
having
trouble
with
the
video,
but
hopefully
most
people
could
see
that
the
slides
are
on
the
website
on
the
data
tracker
and
the
video
will
will
certainly
be
on
youtube
afterwards.
So
if
anyone
wasn't
able
to
see
the
video
and
wants
to,
then
it
should
be,
it
should
be
available
on
youtube
after
that.
A
C
Let's
see
looks
like
my
cat
looks
like
mike
is
running.
You
should
be
able
to
hear
me.
Yes,
that's
a
really
good
talk.
It's
wonder,
wonderful
work.
Thank
you.
My
question
is:
does
the
data
you
see
differ
depending
on
where
you're
doing
the
probing
from
heidemann
and
company
seem
to
have
investigated
that,
but
I've
forgotten
exactly
what
they
found
and
I'm
wondering
if
you
all
did,
did
a
a
similar
analysis.
A
A
C
A
D
A
A
A
A
A
A
Okay,
so
thank
you
for
the
for
that.
Apologies
for
the
difficulties
with
this
getting
the
system
working.
I
don't
know
why
this
is
not
working
so
well
this
time,
but
thank
you
very
much
for
the
the
questions
and
for
the
the
answers
and
those
are
very
nice
talk
and,
as
I
say,
the
talks
will
be
on
youtube
for
anyone
who
was
having
trouble
with
the
video.
A
A
A
E
Hello:
everyone,
I'm
charlie
lou
from
singhua
university
and
thanks
for
joining
us
in
this
talk,
we
will
discuss
encrypted
dns
protocols
or
what
we
call
here
dns
over
encryption.
We
present
a
large
scale
measurement
study
on
the
operational
status
of
the
protocols
from
angles
of
servers,
dns
clients
and
passive
traffic
and
given
early
view
into
this
ecosystem.
E
E
So
my
dns
queries
actually
can
say
something
about
my
internet
behaviors,
but
there
is
no
confidentiality
or
authentication
in
dns,
so
my
queries
are
susceptible
to
both
passive
and
active
attacks
for
all
these
people.
They
can
see
that
I
query
the
irtf
domain
often
and
learn
that
I
may
be
interested
in
the
activities,
so
that
was
just
a
juvenile
example
about
dns
privacy,
but
massive
dns
surveillance
and
manipulation
is
not
in
theory
only.
For
example,
release
documents
show
that
the
nsa
has
been
monitoring.
E
Dns
data
under
secret
projects
and
also
in
the
literature
works,
show
that
dns
data
can
be
used
for
privacy
threatening
activities
such
as
device,
fingerprinting,
user
tracking
and
user
behavior
analysis
so
to
mitigate
dns
privacy
issues.
One
of
the
mainstream
solutions
is
to
encrypt
dns
communications
or
what
we
call
here:
design
dns
over
encryption
protocols,
starting
from
2009.
E
We
see
some
early
protocols
from
the
industry
like
dns
curve
and
dns
crypt
from
around
2014
dns
privacy.
Problems
have
drawn
attention
from
the
ietf
leading
to
some
informational,
rfcs
and
since
then,
three
working
groups
have
been
established
to
work
on
solutions
and,
as
a
result,
we
have
seen
three
standardized
dns
over
encryption
protocols
and
of
course
there
are
still
more
protocols
and
tests
coming
to
solve
the
problem,
but
we
do
not
discuss
them
today.
E
In
this
study,
we
focus
on
two
standardized
and
extensively
supported
protocols,
dns
over
tls
or
dot
and
dns
over
https,
or
do
the
idea
of
dot
is
very
straightforward
before
dns
queries,
I
negotiate
a
tls
session
with
my
resolver
and
use
it
to
encrypt
wire
format.
Dns
packets
dot
runs
over
a
dedicated
port
853
and
to
use
it
some
client
software
needs
to
be
updated.
Like
the
stub
resolver
of
my
operating
system,
doe,
on
the
other
hand,
embeds
dns
packets,
into
https
messages,
it
shares
port
443
and
is
especially
convenient
for
user
space.
E
E
Do
queries
can
be
issued,
for
example,
from
a
browser
using
a
uri
template
like
this.
The
query,
names
or
dns
packets
can
be
embedded
into
the
url
or
http
message
body.
Actually,
the
standard
doe
uses
wire
format,
dns
packets
in
the
http
message
body.
The
format
displayed
here
is
the
json
format
adopted
by
some
public
resolvers,
and
I
use
it
here
because
it's
readable.
E
The
history
of
dns
over
encryption
protocols
is
not
long,
but
they
have
been
rapidly
developing
recently
from
the
industry.
Several
large
public,
dns,
resolvers,
dns
software
operating
systems
and
web
browsers
have
implemented
dot
order
and
some
more
recent
updates
that
will
further
push
them
forward.
Web
browsers
and
operating
systems
have
been
rolling
out
dns
over
encryption,
and
these
are
just
some
examples
from
large
vendors.
E
E
E
So,
first
up
how
many
servers
are
offering
dns
over
encryption
services
discovering
open
dot
servers
is
simple:
it
runs
over
a
dedicated
port,
so
an
internet
wide
scan
will
suffice.
Those
servers,
however,
are
different.
They
use
uri
templates
and
a
shared
port
443,
so
we
cannot
simply
use
port
scans
to
discover
them,
but
the
rfc
documents
and
large
providers
have
used
some
common
uri
templates,
such
as
slash
dns-query,
which
inspires
us
to
look
for
them
in
large-scale
url
datasets
and
in
more
detail
to
find
open
dot
resolvers.
E
B
E
E
For
example,
clean
browsing,
dns
alone
accounts
for
over
1
000
resolvers
in
almost
each
of
our
scan,
and
here
are
some
more
recent
updates
in
our
latest
scan
on
july,
the
1st
2020.
We
find
that
there
has
been
a
significant
increase
in
the
number
of
open
dot
resolvers
compared
to
a
year
ago,
which
is
july.
The
1st
2019,
the
number
of
open
dot
resolvers,
has
risen
to
over
7.8
000
almost
quadrupled,
and
our
results
also
show
that
there
have
been
more
providers
establishing
their
thought,
resolvers
and
meanwhile,
from
their
certificates.
E
E
E
Another
15
of
the
envelope
certificates
are
expired
and
one-third
of
them
have
expired
before
2020.
That
is
more
than
half
a
year,
which
could
have
already
been
out
of
maintenance.
The
rest
has
problems
in
their
certificate
chains,
which
cannot
be
correctly
validated
because
the
authentication
of
dodge
relies
on
the
certificates.
We
suggest
that
the
providers
keep
their
servers
under
regular
maintenance.
E
To
discover
open
dns
over
https
resolvers,
we
search
for
the
common
uri
templates
in
a
large
scale,
url
datasets,
provided
by
our
industrial
partner.
The
dataset
consists
of
urls
collected
from
their
web
crawlers
sandboxes
and
some
external
data
feeds.
We
find
that
the
number
of
doe
resolvers
is
modest
compared
to
that
of
dot
in
may
2019.
E
And
more
recently,
in
this
july,
the
number
of
open
door
resolvers
also
rises.
We
discover
over
50
valid
uris,
which
are
operated
by
37
providers,
and
our
lists
also
contain
several
resolvers
out
of
middle
lists,
and
here
we
give
some
examples
and
in
particular
we
find
that
the
lists
also
include
some
resolvers,
which
are
established
by
large
isps.
E
We
use
sox5
proxy
network
platforms
that
allow
large-scale,
client-side
measurements
to
explain
clear
text
and
encrypted
dns
queries
are
issued
by
our
measurement
client
passing
a
superproxy
forward
it
to
global
exit
nodes
and
eventually
reach
the
target
resolvers.
By
checking
its
response.
As
the
measurement
client,
we
can
tell
whether
a
dns
resolution
from
the
exit
node
is
successful.
E
To
perform
the
tests,
we
use
two
proxy
networks,
one
global
which
is
proxy
rack
and
one
in
china
only
to
see
the
behaviors
of
a
typical
sensor
network.
In
total
we
collect
29,
000
global
vantage
points
from
166
countries
and
85
000
chinese
vantage
points
and
for
each
exit
note.
We
first
issue
clear
text,
dns
dot
and
do
queries
of
our
control
domain
to
three
popular
dns
services,
cloudflare,
google
and
quad9,
to
see
whether
they
are
successful
from
the
nodes
which
fail
the
queries.
E
And
here
are
our
test
results
obtained
in
2019.
globally.
We
find
that
the
failure
rate
of
dns
over
encryption
is
lower
than
that
of
clear
text
dns.
We
suppose
it
is
because
interception
policies
are
currently
not
considering
port
853
or
443
and,
as
a
result,
clients
may
switch
to
dot
or
doe
when
their
traditional
dns
has
problems.
E
And
here
are
some
examples:
these
ports
are
not
open
on
the
cloudflare
quad
1
address,
but
from
the
failed
clients,
when
we
probe
these
ports
on
quad
1,
they
are
found
open.
So
these
clients
are
not
able
to
use
cloudflare
dot,
because
this
address
is
already
taken
by
something
else.
Like
network
devices.
E
And
back
to
the
results,
we
also
notice
a
high
failure
rate
for
quad
9
doe.
We
find
that
quad
9
forwards
dope
queries
to
itself
on
port
53
and
sets
a
small
timeout
for
this,
which
causes
unnecessary
server
failures.
We
have
reported
this
issue
and
they
are
considering
losing
the
timeout
another.
Finding
is
that
nearly
all
clients
in
china
fail
to
use
google
doe
and
yes,
it's
because
of
censorship.
E
We
aim
to
measure
the
relative
query,
time
of
clear
text,
dns
and
dns
over
encryption
and,
more
importantly,
we
measure
their
query
time
when
connection
is
reused,
as
required
by
their
standards.
Connection.
Reuse
is
also
supported
as
the
default
option
of
many
stub
and
recursive
resolvers
and
again
we
use
proxyrac
to
recruit
8
000
global
clients
for
the
test
on
each
client.
We
issue
clear
text,
dns
dot
and
do
queries
to
the
popular
resolvers
and
compare
their
differences
in
query
latency,
because
we
focus
on
connection
reviews.
E
Our
results
here
show
that,
when
connection
is
reused,
the
extra
query
latency
of
dns
over
encryption
is
tolerable.
Take
the
cloudflare
resolver
as
an
example
when
using
its
dns
over
encryption
services.
Our
global
vantage
points
see
extra
query
latency
on
the
order
of
several
milliseconds
compared
to
using
its
clear
text.
Dns
and
of
course,
we
also
see
that
for
individual
clients
or
vantages
in
different
countries,
their
performances
can
fluctuate,
but
on
average
the
overhead
is
modest.
E
E
E
If
we
zoom
into
the
client
subnets
of
dot
traffic,
we
find
some
giant
net
blocks
that
account
for
more
than
half
of
the
traffic.
We
suppose
that
they
could
be
associated
with
proxy
services
or
not,
but
on
the
other
hand
we
in
the
beginning
of
2019.
We
also
find
a
lot
of
temporary
dot
users,
which
were
only
active
for
less
than
one
week
for
do.
E
And
some
takeaways
and
recommendation
for
protocol
designers,
we
think
one
of
the
reasons
that
dot
and
doe
got
strong
support
is
that
they
are
built
on
well-developed
protocols
for
service
providers.
We
recommend
the
correctness
configurations
and
keep
their
servers
under
regular
maintenance
for
internet
users.
We
believe
education
is
necessary
to
let
them
know
the
benefits
of
dns
over
encryption.
E
And
finally,
a
quick
summary
on
our
key
observations.
First,
we
discover
thousands
of
active
dns
of
encryption
resolvers
in
the
wild
and
a
lot
of
small
providers
which
are
less
known
to
public,
but
their
implementations
are
not
always
secure.
A
quarter
of
them
use
invalid
tls
certificates
for
global
clients.
Dns
over
encryption
services
are
less
interrupted
by
empath
policies
and
their
performance
is
tolerable,
with
reused
connections
and
finally,
from
real
world
traffic.
We
find
the
usage
of
dns
over
encryption
is
still
less
than
traditional
dns,
but
there
has
been
a
growing
trend.
F
I
should
be
enabled:
oh
okay,
sorry,
the
speaker:
it's
5
a.m.
Here
I
don't
think
super
clearly
at
the
moment,
so
I
have
great
talk
thanks
very
much
for
it.
I
appreciate
you
know
looking
at
the
real
numbers
and
it's
good
to
see
numbers
growing
as
well
for
encryption.
One
question,
though,
you
were
trying
to
measure
both
the
the
popularity
of
dot
versus
the
popularity
of
do
and,
and
you
made
the
claim
that
do
is
used.
F
So,
in
order
to
compare
those
two,
you
really
need
to
look
at,
maybe
the
dns
name
and
the
certificate
that
is
used
by
dot
and,
as
you
noted
you
know,
a
large
number
of
the
the
dot
deployment
was
just
from
google
or
something
like
that.
So
did
you
try
and
compare
how
many
actual
end
organizations
are
deploying
you
know,
dot
versus
the
end
organizations
that
are
deploying
dough?
I
suspect
that
those
numbers
might
be.
E
E
Okay,
go
ahead.
Show
you,
okay,
thanks
for
the
comment.
Actually,
we
have
data
for
the
actual
providers
of
dot
and
doe
resolvers
in
our
latest
again
this
july,
the
7.8
thousand
dogs
open
dot
resolvers.
If
we,
if
we
identified
them
by
their
cert
by
the
common
names
in
their
certificates,
they
belong
to
around
a
thousand
and
two
hundred
providers,
but
though,
actually
it's
several
dozens.
E
A
G
G
Hi
that
was
an
excellent
talk
very
clear
and
interesting.
I
had
a
question
about
what
you
can
tell
about
the
clients
from
your
data.
As
noted,
you
had
a
few
a
few
dot
clients,
but
that
you
could
use,
but
when
you
see
the
dot
the
dot
usage
by
the
people
who
are
not
experimenters,
do
you
have
a
sense
of
what
what
resource
they're
using
to
do
to
do
that
for
from
themselves
from
the
stub
to
the
resolver?
E
H
I
I
So
could
you
try
and
use
that
the
same
technique?
You
used
to
discover
doh
servers
to
try
and
discover
dot
servers,
which
you
have
a
much
better
mechanism
and
you
can
see
what
proportion
are
found
with
the
with
one
mechanism
versus
the
other,
and
then
you
have
some
sort
of
idea
about
how
effective
it
is.
E
H
Hi
good
morning
this
is
patrick
mcmanus,
I'm
curious,
so
you
identified
a
lot
of
services,
myself,
they're,
mostly
dot
services
that
we're
operating
with
invalid
certificate
chains,
or
at
least
chains
that
don't
you
know,
validate
with
a
normal
pki,
and
then
you
later
had
some
data
about
sort
of
client
usage
based
on.
I
think
the
plaintext
lookup
of
the
service
names
themselves
was
there
any
you
know
correlation
there.
Were
you
able
to
find
that
clients
were
using
services
that
had
known
bad
searching?
Anything
like
that.
H
Between
what
excuse
me,
so
you
identified
a
large
number
of
dot
services
that
had
invalid
certificates
and
there's
a
dot
rule
that
says
the
client
has
to
validate
the
certificate.
So
I'm
curious,
if
you
have
any
insight
into
whether
clients
were
using
those
services
that
had
the
invalid
certificates.
E
H
H
E
They
have
been
out
of
maine
and
they
could
have
been
out
of
maintenance,
but
a
larger
portion
is
that
they
are
still
self-signed
certificates
installed
on
firewalls
and
tls
inspection
devices
it
it
could
be
that
they
are
inspection
inspecting
dodge
resolver,
dot,
dot
traffic.
But
yes,
we
have
seen
a
large
portion
of
of
english
certificates
installed
on
firewalls
and
firewall
devices,
but
we're
not
sure
the
reason
behind
this.
A
J
A
J
Hello,
welcome
everybody,
I'm
inga
prize
and
I'll
be
talking
about
our
connex
19
paper
steering
hyper
giants
traffic
at
scale.
This
is
joint
work
together
with
enrique
pejor,
johannes
dallas,
george,
smart,
darkest
and
anya
feldman,
and
with
that,
I'm
simply
going
to
start.
So
when
we're
talking
about
hyper
giants,
the
first
things.
The
first
thing
we
need
to
know
is:
what
actually
is
a
hypergiant
hyper
giants?
Are
there
are
multiple
definitions
for
it,
but
the
ones
that
we
have
chosen
is:
they
are
large
networks
that
provide
services
mostly
to
end
users.
J
They
run
global
distributed
infrastructures
and
they
generate
enormous
amounts
of
traffic,
which
means
they
are
the
ones
that
are
dominating
the
traffic
on
the
internet
in
when
we're
talking
about
traffic.
This
is
the
statistic
from
one
of
the
networks
that
we
were
fortunate
enough
to
have
information
about.
J
The
blue
line
is
the
traffic
share
of
the
top
10
hyper
giants
that
we
have
tracked
over
the
last
now
in
this
case
two
years,
you
can
see
that
it's
sort
of
steadily
between
70
and
80
percent
and
at
the
same
time,
in
the
background,
the
gray
area
is
the
traffic
increase
normalized
to
the
start
of
the
period.
You
can
see
that
over
the
course
of
the
two
years
we
have
quite
the
traffic
increase.
J
The
annual
traffic
growth
is
around
30
percent
per
year,
and
the
top
10
hyper
giants
have
a
traffic
share
of
more
than
75
percent
over
this
period
of
time,
but
also
we're
we're.
One
of
we
want
to
steer
traffic,
and
here
is
a
very,
very
simple
example
what
we
mean
when
it
comes
to
steering
traffic.
Let's
assume
we
have
our
little
network
here.
We
have
our
hypergiant
clusters
called
ht
clusters.
In
this
case,
there
is
three
interconnection
points:
whether
these
clusters
are
directly
connected
or
come
through.
B
J
J
Now
this
some
of
you
may
say
this
sounds
familiar
and
you've
seen
this
before
and
yes,
actually,
we
have
already
done
this
research
about
10
years
ago
back
then
we
introduced
the
system
patis
and
today
we're
actually
talking
about
the
same
thing.
It's
as
you
can
see,
there's
also
a
fair
amount
of
the
same
people
in
this.
So
the
question
is:
what's
new,
what
has
changed
between
10
years
ago,
and
now?
Why
are
we
revisiting
this
topic?
J
Second
thing
is:
we
initially
proposed
the
patis
infrastructure
and
we
here
show
the
differences
from
having
a
research
project.
This
called
this
in
this
case,
patis
go
into
a
fully
fledged
production
environment
called
the
flow
director
and
what
needed
to
be
changed
to
the
initial
system,
what
we
didn't
think
about
what
needed
to
be
added
in
order
for
this
to
actually
work.
And
thirdly,
the
flow
director
is
actually
operational.
J
J
This
is
over
the
past
two
years
we
have
looked
at
the
hyper
giant
traffic
and
we
have
looked
at
the
optimal
mapping
and
how
this
evolves
over
time.
This
basically
takes
the
traffic
that
the
hyper
giants
produce
and
checks
whether
it
matches
the
current
network
configuration
to
see
if
the
mapping
was
done
optimally
from
in
terms
of
the
mapping
function.
That
was
chosen
in
this
case.
The
mapping
function.
J
That
we
chose
is
a
combination
of
hops
and
distance
hops
in
order
to
reduce
the
load
on
the
ifp
distance,
in
order
to
reduce
the
latency
as
shorter
links
tend
to
have
lower
lower
ttls.
So,
as
you
can
see
over
time
here,
we're
steadily
around
70
to
60
percent
of
optimally
mapped
traffic.
So
there
is
a
huge
there
is
a
huge
potential
of
actually
optimizing.
Things
also
keep
in
mind
that
this
does
not
tell
you
how
badly
mismatched
this
is
this.
Just
this
is
just
a
binary
decision.
J
Now
we're
going
to
go
into
the
individual
hypergiants
that
we
tracked
like,
I
said
we
tracked
10
hypergiants
over
the
period
of
two
years
and
we're
just
going
to
focus
on
hypergiant
six
here,
which
used
to
run
one
single
interconnect
with
the
ifp
in
in
question
that
we
got
the
information
from.
They
then
decided
to
open
a
second
point
and
that
reduced
the
mapping
compliance
to
50,
which
means
this
was
basically
around
robin
and
50,
got
it
right.
50
got
it
wrong.
J
J
Secondly,
there
are
those
hypergiants
that
have
no
direct
incentive
to
actually
do
the
mapping
right.
They
just
go
around
robin
all
the
time
and
or
basically
they
just
don't
care
or
don't
have
any
incentive
to
do
this.
And
thirdly,
there
are
those
that
do
try
in
here,
but
they
they
still
sort
of
at
the
none
of
them
ever
gets
really
over
the
over
the
80
percent.
J
J
So
let
me
go
into
not
detail,
but
a
few
things
that
have
to
be
taken
into
consideration
when
when
doing
the
mapping
decision
first
of
all-
and
I'm
going
to
start
at
the
top
left
here,
we
have
to
think
about
how
many
number
of
pops
am
I
actually
in
so
how
many
different
mapping,
how
many
different
positions
am.
I
interesting
in
that
changes
over
time,
as,
as
you
can
see
in
in
the
graph
more
pops
get
connected,
mapping
gets
harder
changes
over
time.
J
Next
is
top
right,
the
capacity
changes
so
just
because
the
configuration
was
good
was
what
was
good
in
a
month
doesn't
mean
it
is
good
in
the
next
month,
in
this
case,
we're
talking
about
the
capacity
of
the
hypergiant
that
increases,
so
this
capacity
has
to
be
installed
at
the
right
place
or
has
to
be
mapped
from
the
right
place.
This
is
also
something
that
needs
to
be
taken.
Care
of
next
is
the
middle
left.
J
J
There
needs
to
be
information
that
is
provided
from
the
from
the
end
user,
from
from
the
isp
towards
the
cdn
or
hypergiant.
In
this
case,
of
course,
there
are
also
unknown
factors:
server,
loads
maintenance,
content,
availability,
cross
traffic,
and
I
can
only
refer
you
to
the
paper
at
this
point,
as
I
am
already
running
out
of
time
to,
if
you're
interested
more,
why
mapping
isn't
hard
issue,
but
collaboration
can
clear
this
lack
of
visibility.
J
So
what
have
we
done
here?
The
flow
director
is
in
a
nutshell.
It
collects
data
from
the
internal
state
of
the
ifp.
It
builds
an
inventory
and
map
of
the
forwarding,
forwarding
and
control
plane
of
the
internet,
and
it
regularly
does
inventory
checks
it
computes
the
best
mapping
and
compiles
that
into
an
easy
act,
easily
easily
accessible
database,
and
it
communicates
this
to
the
hyper
giants
that
want
to
collaborate
in
near
real
time
and
by
near
real
time
and
maximum
60
seconds
via
multiple
protocols.
J
J
All
components
are:
ifc
com
is
adhering
to
rfcs
and
we
also
build
this
horizontally
scalable.
So
we
can
pretty
much
take
in
take
on
any
network
that
we
connect
to.
Currently
we
do
run
this
fairly
large
environment
just
so
you
get
a
sort
of
feeling
we
see
over
one
gigabit
per
second
of
net
flow
at
a
at
a
low
sampling
rate
and
we
hold
about
600
bgp
sessions
and
we
have
about
a
60
second
reaction
time.
J
The
the
architecture
itself
is
split
into
three
parts.
We
have
the
southbound
that
does
all
the
data
collection
and
aggregation.
We
have
the
core
engine
which
does
all
the
model
building
and
calculations,
and
we
have
the
northbound,
which
does
all
the
communication
towards
the
cdn
so
that
the
path
rankers,
so
the
mapping
decision
can
actually
be
communicated
again
due
to
time
restrictions.
I
can
only
refer
you
to
the
paper
at
this
point.
If
you
want
to
know
more
about
this
now,
let's
go
into
the
operational
experience
here.
J
First
of
all,
we
have
we
have
a
collaboration
with
one
hypergiant
in
for
this
ifp.
So
this
is
this
at
this
point
was
a
one-on-one
relationship.
The
this
hypergiant
had
more
than
ten
percent
of
the
total
traffic
inside
the
ifps
network.
There
were
two
kpis
that
we
wanted
to
to
adhere
to
for
the
isp.
We
wanted
to
reduce
the
long-haul
traffic
for
the
hypergiant.
We
wanted
to
reduce
the
latency,
I.e,
bring
the
server
closer
to
the
user,
which
boiled
down
into
a
mapping,
function
or
path
anchor
function.
J
That
is
a
combination
of
the
path
length
and
the
distance
also
keep
in
mind
that
the
flow
director
when
it
gives
the
disc
when
it
gives
the
path
ranking,
is
a
suggestion
and
it
can
be
ignored
by
the
hyper
giant.
So
we
do
not
enforce
this.
We
put
this
really
on
collaboration
and
in
the
trial
run.
We
actually
did
this
as
a
progressive
roll
out,
so
we
we
didn't
turn
it
on
all
the
way,
but
we
did
this
in
a
progressive
manner.
J
What
you
see
here
is,
over
the
time
over
the
time
from
mid
2017
to
mid
2019,
the
traffic
of
the
hyper
giant
on
on
the
backbone
and
what
you
can
also.
What
you
can
also
see
is
the
traffic
on
the
long
haul
links.
There
is
a
steady
downward
trend.
We've
put
this
into
five
phases
denoted
by
the
colors
that
you
can
see
here.
J
At
the
same
time,
we
can
also
look
at
the
overall
traffic
produced
by
the
by
this
hypergiant
inside
the
isps
network,
and
also
what
you
can
see
here
is
that
we
reduce
the
overall
traffic
while
not
so.
This
is
this.
This
is
important.
We
do
not
move
away
any
traffic
from
the
end
users,
so
the
traffic
still
increases
throughout
the
time,
but
the
traffic,
the
traffic
on
the
long
haul
links
gets
reduced
so
which
means
we
localize
the
traffic
more.
J
That's
the
benefits
for
the
isp
next
is
the
benefits
for
the
hyper
giants
and,
as
I
said
before,
we
use
the
distance
as
a
proxy
for
latency
and
in
terms
of
distance,
we
reduced
the
the
gap
so
the
distance
between
the
the
server
and
the
client
or
the
end
user
by
about
40,
which
means
we
heavily
localize
traffic.
Again,
you
can
see
here
that
in
the
hold
phase,
this
goes
up
really
really
high,
as
the
mapping
got
broken.
J
J
There
is
a
huge
potential
for
reducing
backbone
traffic
and
optimizing
the
network.
Now
there
is
one
point
in
here:
we
do
not
assume
new
server
locations,
new
server
locations
can
have
an
even
greater
effect,
and
so
there
will
still
always
be
some
long-haul
traffic
left.
The
only
thing
we
assumed
is
that
those
that
the
infrastructure
as
it
existed
at
the
in
this
point
of
time,
with
the
routing
or
the
network
configuration
as
it
existed,
we
calculated
the
potential.
What
would
happen
if
we
remapped,
according
to
the
flow
director
across
the
board?
J
J
J
First
of
all,
we
want
to
see
what
happens
if
we
use
different
optimization
functions,
especially
for
different
types
of
content,
with
different
optimization
functions
from
the
same
hypergiant,
but
also
optimizing
multiple
hypergiants
at
the
same
same
in
the
same
network
and
secondly,
we
would
like
to
do
a
federated
flow
director,
which
means
we
do
a
multi-isp
hypergiant
collaboration,
and
with
that
I
am
at
the
end
of
this
talk.
Thank
you
for
your
attention
and
I
think
I
will
take
questions
now,
but
I'm
not
quite
sure.
Thank
you.
J
A
A
J
So
the
biggest
challenge
actually
is
twofold:
one
is
handling
the
massive
amount
of
data
that
suddenly
starts
streaming
into
the
system.
The
other
one
is
the
politics
that
come
with
it,
especially
trying
to
move
people
away
from
using
mapping
via
bgp,
which
I
have
a
lot
of
opinion
on,
but
getting
people
away
from
that
and
going
into
something
that's
actually
multi-dimensional
is
that
it
makes
makes
the
whole
problem
a
lot
easier.
I
understand
why
bgp
is
being
used
for
the
mapping,
but
I
still
believe
that
it
is
not
the
right
decision.
A
A
K
The
first
thing
x
mark
for
your
presentation,
great
presentation.
I,
regarding
the
last
slide
that
you
mentioned
the
federated
float
flow
director,
your
direction
about
that
regarding
the
the
aggregation
process.
That
is
a
key
part
on
that
is
later
to
have
multiple
instance
of
the
flow
director
and
the
user
or
the
client
will
be
the
aggregation
or
you
will
have
only
one
logical
flow
director
that
compute
all
the
aggregator
in
all
the
information
to
present
an
aggregation,
information
or
others
option
that
you
envisioned
on
that.
J
Now,
it's
not
him
again.
If
I
get
the
question
correctly,
it
is
about
whether
we
want
to
build
a
super
node
or
whether
we
do
this
as
a
sort
of
per
deployment
basis
working
with
each
other
or
if
there's
any
other,
any
other
way
for
political
reasons.
I
don't
think
there
will
ever
be
a
super
node.
No
three
or
four
ifps
will
agree
to
have
their
data
shared
on
the
same
system.
At
least
I
can't
see
it
at
the
moment.
J
Please,
please
prove
me
wrong
on
this
one,
if
you
feel
like
that's
a
good
idea,
so
I
think
it
would.
It
really
boils
down
to
how
do
we
do
the
discovery?
How
do
we
do
the
interconnection
between
them
and
what
information
can
we
safely
share
between
the
systems
and
in
what
direction,
but
we're
at
very
early
stages?
For
that
one?
I
have
a
few
ideas
on
how
to
do
it,
but
we
haven't
actually
started
any
implementation
on
this.
Yet.
A
I
J
Potentially
yes,
most
of
the
hypergiants,
however,
run
their
own
backbone
and
they
know
what
to
cash
where
so
they're
a
lot
better
at
the
whole
caching
thing
than
an
isp
ever
can
be,
which
means
that
if
the
caching
is
any
good,
so
cash
hit
rate
of
over
one,
then
it
is
definitely
more
effective
to
map
the
users
close
than
to
try
and
basically
not
get
the
mapping
right.
So,
yes,
you
are,
you
are
partially,
I
think,
correct
that
it
can
increase
the
long-haul
traffic,
but
taking
the
caching
into
account.
A
L
J
Yes,
of
course,
thank
you
so
traffic
that
is
not
affiliated
with
the
hyper
giants.
First
of
all,
is
in
our
case
it's
about
eighty
percent
of
the
traffic
it's
actually
most
of
the
traffic
is
either
bgp
bound
or
ttl
bound.
If
the
ttl
starts
to
drop
drastically,
they
will
remap.
So
I
think
we
haven't
had
that
scenario
yet,
but
I
think
it
would
push
away
the
traffic
that
is
mapped
solely
by
the
hyper
giant.
J
Also
keep
in
mind
that,
when
we're
talking
about
the
hyper
giants
here,
we're
usually
talking
about
direct
peering.
So
these
do
not
come
through
through
normal
or
public
peerings.
They
usually
have
direct
interconnects,
which
means
that
a
hypergiant
can,
especially
on
those
links
that
are
usually
overloaded,
which
has
appearing
links.
They
don't
usually
push
others
away.
They
just
take
burden
off
of
them
and
push
them
onto
the
private
parents
that
this
is
more
effective
and
cheaper,
usually
for
the
hypergiant.
A
J
B
J
J
C
A
Traffic.
Okay,
thank
you.
Thank
you.
Engema.
Thank
you
all
again
to
show
you
and
to
banos
for
the
talks
they
gave
earlier.
Apologies
for
the
trouble
with
the
videos
and
the
audio
that
some
people
had
the
talks
will
all
appear
on
the
itf
youtube
channel
in
in
the
next
few
hours,
hopefully
certainly
by
tomorrow.
A
Maybe
they
will
be
in
the
the
gather
room,
if
not
I'm
sure
they
will
be
be
happy
to
answer
questions
or
to
chat
further
about
the
work
by
email,
and
hopefully
we
will
come
back
to
in-person
meetings
before
too
long
and
we
can
bring
them
to
a
future
meeting,
so
you
can
meet
them
and
they
can
meet
you
again.
Thank
you.
Everybody
for
the
session.
Apologies
for
the
troubles.