Hi everyone, my name is Shazeh Mustafa and I will
be presenting Metapeering today.
So finding a suitable ISP to pair with is a slow
process and ISP admins put a lot of
effort and a lot of time into selecting suitable
peers.
Why is that?
Because ISP admins often attend events sponsored
by PeeringDB, Nano, etc. where they network
with each other.
And using these events, they identify ISPs for
potential peering.
And after that, they negotiate traffic exchange
terms and conditions which may include the
max traffic volume they are willing to exchange
or the specific points that they are willing
to pair at or whether or not it will be a public
peering, etc.
And then after this step, if and only if both of
the ISPs agree to the terms and conditions,
the BGP forwarding rules are written so the
deployment actually takes place.
So I mean, overall, since the whole process
requires a ton of manual work, it is extremely
slow and it oftentimes takes a couple weeks to
months.
And even with such an elaborate and lengthy
process, finding the right peer is hard.
And say you've put in like two months into
selecting your peer, it's not guaranteed that
it's going to be an optimal option.
Because see, the internet is far more dynamic
than these interconnection deals, which means
that during the negotiation and finding process,
plenty of great peering opportunities are
discarded.
Under or overestimation of various metrics can
lead to future disagreements.
ISPs can be part of suboptimal relations knowingly
or unknowingly.
And we have also seen cases of ISPs ending peering
contracts because of disagreements
and violations.
Now, bad selection can also mean that your
resources are not optimally utilized.
So sort of your load balancing factor is suboptimal.
And in the bigger picture and in the longer run,
such relations, suboptimal relations
or disagreements or missed opportunities,
everything, in the longer run, such relations
can hurt ISPs, both ISPs financially.
So it's clear why it's so important for these to
be optimal and along with that to be dynamic.
So if you've identified an issue, you can fix it
quickly.
Now we present MetaPeering, a tool that will help
identify optimal peering ISP peers.
And it also gives you the best peering contracts.
So say for two given ISPs, we need to decide
whether or not they should be peering.
And if yes, which particular locations they
should be peering at.
We first calculate the traffic matrices for both
the ISPs, which is sort of their internal
traffic flow.
We calculate these using POP or points of
presence locations, which are locations where
an ISP has connection capability.
So this can be an IXP or a private facility too.
We also identify the locations where both these
ISPs have a presence, because these
are the points where peering is possible.
Then we gather the gridded population data for
the United States, which basically divides
the whole country into small segments.
And now we know the population for each of these
segments.
And we take all of this data, all of these computations
and feed them into this policy
generator machine, which churns it up, extracts
all the useful information.
It knows what's important, what's not.
So it does that while respecting any additional
peering policies injected using the policy
filter.
Now, how does it do that?
It basically gives out three different outputs.
The first is, so it basically uses the POP
locations and the population data to construct
an overlap map between the two ISPs.
And what it represents is the number of people
each ISP presumably covers, and how many more
people can become accessible with a peering deal.
This is summed up in the affinity score.
The next one is, it uses the same POP locations
and also the traffic matrices to give out
peering willingness scores for each of the common
POP locations from the perspective
of both ISPs.
So the overall willingness score for a particular
peering deal is just the average of these
scores at particular points.
Third, it optimizes the selection of POP
locations using the individual willingness scores
to
generate acceptable peering contracts.
We then take the geometric mean of the
willingness score, which is the representative of
the
willingness to peer, and affinity score, which is
the representative of the non-overlapping
areas and population, to get the Felicity score,
which tells us whether or not these
ISPs should peer.
Now, please note that these scores are novel.
They're not like an industry standard.
We came up with these scores, and we have
discussed how we came up with this and what
they represent.
So with the Felicity score, ISP admins can set a
threshold, "Okay, if this pair has a
Felicity score of more than 0.6 or 0.7, we'll be
peering.
Otherwise, we will not."
So this is the deciding factor for whether or not
they should be peering.
And along with that, we give them the acceptable
peering contracts that, "Okay, if you decide
to peer, these are the locations that you should
be peering at."
Now, both of these results can be used by ISP admins
to decide whether a peering deal
will be worth it.
Now, in an effort to expedite the development of
this model, we have deployed a web application
to showcase the workings of this tool.
These screenshots provide an overview of the
website for Sprint and eBay.
We can see the overlap map, which is calculated
using the POP locations, as mentioned earlier.
We can also see the willingness scores for each
of the contracts that are possible.
Not all of them are listed in the screenshot, but
they are possible.
And at the bottom, we can see a sample contract
recommendation, which is given as Sprint and
eBay decide that they are peering, Metapeering,
our tool, recommends that they should be peering
in Los Angeles and Chicago.
So the website lists top three such contracts.
So this is the best one, and then there's the
second best option and the third best
option.
And just for reference, here's another example
for Columbus and eBay.
And in this case, the same overlap map is given,
the willingness graph is given, and
a sample contract is given.
But in this particular case, our model does not
recommend peering.
But in case they do end up deciding that they
should peer, they should peer at San Jose
and Ashburn.
We tested this model on 23 different ISPs, which
basically means 506 pairs using two
heuristics.
Now, the X-axis, on the X-axis, we can see the ISP
pair type, where A is access, C is
content, and T is transit.
So AT, for example, means that it is an access-transit
ISP pair.
So the first heuristic, the ISP view, we
recommend peering if any one of the two ISPs has
a felicity
score greater than a certain threshold.
In this case, we used 0.55.
For the second heuristic, the holistic view, we'd
recommend peering if and only if both
of the ISPs have a felicity score greater than 0.55.
The figures show a slightly more detailed
confusion matrix, sort of.
So the top left is the true positive, the pairs
we suggested and were peering according
to KEDA.
The bottom right shows the true negative, the
pairs we didn't suggest peering and were
also not peering according to KEDA.
The top right shows the new recommendations that
we generate, and the bottom left shows
the peering ISPs that we recommend that they
should not be peering.
And it can be seen that there's a lot of missed
opportunities and some suboptimal relations
as well.
We believe that metapeering is a step in the
direction of a more dynamic and automated
inter-ISP relation management, and we are working
on an extended model, a more complex
model, a more complex metapeering model which
uses machine learning techniques to learn
from previous data to learn what's important in a
peering deal before giving out its
recommendations.
So this concludes my presentation.
I hope you liked it.
If you have any related questions, I would be
happy to address them now.
Thank you.
[End of Audio]
1
Page PAGE of NUMPAGES www.verbalink.com