[lugm.org] My adventures with the Mauritius Internet Exchange Point

Fri Oct 23 11:34:43 UTC 2015

Hi All,

Just wanted to add my 2cents.
There doesn't seem to be any obligation for ISPs to peer at IXPs.
However, there is clearly benefits for peering at IXPs. For instance,
peering directly with the big content providers at LINX is much cheaper
than buying transit.
Why is LINX so appealing to ISPs. I guess coz there is quite a number of
Content providers and ISPs present there + it is quite easy to peer
multilaterally - LINX provides Route Servers to facilitate Multilateral
peerings for providers that are willing to participate.

That would probably help answer why there is less motivation for any
peerings at MIXP.
What is the rate of traffic between ISPs in Mauritius? From my past
experience, between MT and Emtel that was quite low ~10Mbps. That was
happening through a private Interconnect peering, nothing to do with MIXP.

I will now get to another potential problem as I see it.
It is the provider's responsibility to have the transport circuit upto the
MIXP which is in Ebene.
Let's say MT provides a circuit of 10Mbps. We have all providers [Emtel,
Bharat Telecom, DCL, MTML etc] drawing traffic from MT or vice-versa.
Generally, we would see more inbound traffic into MIXP from MT as they have
more content on their network than other providers - email, web etc. Ever
wondered why Bharat Telecom, DCL representatives are so adamant about
drawing traffic from MIXP??

What happens if the traffic demand is increasing beyond 10Mbps outbound
from MT to the IXP. Demand being greater than capacity, the circuit cannot
sustain this demand, drops start to appear and quality of experience gets
worse including latency increasing as well. Most likely, customers
downloading content would start complaining to their ISPs. E.g Emtel
subscribers would start complaining about their connectivity and obviously
use an MT connection to compare with the latter being flawless.

Q: Who has the leverage on MT to increase its capacity to MIXP??? Do you
think MT would care?
I guess Network Engineers from other ISPs would have a routing solution to
that - Prefer MT prefixes from their transit [latency increases, but no
drops], keeping their customers happy.

IMHO, the main issue in Mauritius is the level of competition in the
Telecommunications/Service Provider sector.  Regulatory framework is not
helping either. In Mauritius, if you want fast broadband there are few
options but not all of them are using the same access technology - there is
no level playing field.

Simply compare Reunion island to Mauritius. They have LLU which opens the
incumbent's network and increases competition, eventually customers have
wider choice of ISPs for more or less same service. I am a big supporter of
LLU and would want to see that in Mauritius. I even queried the previous
Minister of ICT on this matter but that was left unanswered.

I agree with Nishal's comments about how to promote an MIXP. There needs to
be proper organisation and real drive within the MIXP and its members. I
can remember the MIXP meeting happening only once in 2-3 years, discussed
about some action points, then no follow-up.

- how we can, as the open-source, non-tech affiliated community help?
Count me in to contribute.

Have a great weekend.

Cheers,
Ashvin

Ashvin

On Fri, Oct 23, 2015 at 7:22 AM, Loganaden Velvindron <gnukid1 at yahoo.co.uk>
wrote:

> Hi Nishal,
>
> I'm updating the blog post, based on your feedback.
>
> Thank you again for bring some light into this.
>
> My personal opinion on this is that we need better statistics. What could
> be done is requiring ISPs put RIPE atlas probes at each ISP's end on at
> least 2 customers. Then, the website for MIXP should constantly display
> statistics such as latency. Showing only traffic transiting like it does
> right now does not with diagnosing peering problems.
>
> So, for ISP A to ISP B, we would get the latency. For ISP B to ISP A, we
> would get another latency.
>
>
>
> On Friday, 23 October 2015, 0:35, Nishal Goburdhan <
> nishal at controlfreak.co.za> wrote:
>
>
> On 22 Oct 2015, at 22:01, Loganaden Velvindron wrote:
>
> > Hi All,
> > I wrote about my adventures at attempting to fix the huge latency in
> > Mauritius:
> > URL:
> > http://logan.hackers.mu/2015/10/mixp-latency-problem
>
>
> logan,
>
> i think that you have some misconception on how the MIXP (or any IXP) is
> meant to operate.
> this sentence is correct:
> “The Mauritius Internet Exchange Point is where my traffic and his
> internet traffic can meet other.”
>
> this sentence is incorrect:
> “for traffic which is supposed to be managed by the Mauritius Internet
> Exchange Point”
>
> …it’s likely that you haven’t worked for any length of time at a
> network operator, or any network that participates in internet peering,
> so let me help you understand how this all ties in together.
>
> an internet exchange point IXP is - by almost anyone’s definition - a
> neutral meeting ground where network operators exchange traffic.  the
> IXP itself *does not* and *should not* participate in the traffic
> exchange.
> that is to say, that the IXP operator (let’s call it the MIXP
> management, in this case) does nothing to the traffic, other than to
> support a platform for it to be exchanged, as quickly, and cheaply,
> across - in this case, they would be responsible for the availability of
> the ethernet switches that are in use as the foundation of the MIXP (ie.
>   is the peering switch up?)
>
> that’s it.
>
> the choice to *use* the IXP to move traffic between networks, is
> fundamentally, a decision of the networks that choose to peer (or not!).
>   a good IXP operator doesn’t enforce any sort of mandatory
> multilateral peering policy, and in fact, there’s zero history in the
> 22years of IXPs, of this MMLP succeeding.  a good IXP operator performs
> introductions, and encourages networks to peer;  but the choice is
> really that of the network provider.  then again, the onus is on *both*
> operators to peer.  if operator A advertises his network prefixes to
> operator B, but operator B does not advertise B’s prefixes back to A,
> we only have half of the solution.  traffic would flow from B->A and
> then A->outside world->B.  (this is more common that you might imagine)
>
> i’m correcting you, because, i think it’s important that you
> understand that it’s *not* the MIXP that’s playing tricks with your
> traffic, and *not* the MIXP that needs to take action here;  indeed, you
> did the right thing:  complain to your ISP.  and if they don’t fix it,
> complain louder, and then vote with your feet and wallet!    and do the
> same at your workplace.  and tell your friends…
> in your case, there was some improvement made;  clearly you feel
> there’s more that could be done, and i’m sure with the help of
> “man traceroute” you can guide your ISP further :-)
>
> so this sentence “I sincerely hope that the Mauritius Internet
> Exchange Point fixes the latency issue.” … is quite incorrect;  what
> you mean is:  “i sincerely hope that the two networks resolve their
> peering problems”.  you might even find that they don’t use the
> MIXP at all, but choose to peer elsewhere in-country (and that’s ok!)
>
> perhaps, you should be asking instead:
> - what can the MIXP do to promote peering, and teach networks about why
> this is important?  i think that’s a reasonable request, and one that
> the MIXP management team should be able to do.
> - what tools can the MIXP use to make it easier for peering participants
> to get started peering;  also, reasonable, imho.
> - how we can, as the open-source, non-tech affiliated community help?
> …etc.
>
> i hope you understand a little better, about how truly non-intrusive, an
> IXP is.
>
> best,
>
> —n.
>
>
>
> __________________________________________________________
> Linux User Group of Mauritius (LUGM) Discuss mailing list
> Website: http://lugm.org
> Mailing list archive:
> http://discuss.lugm.org/pipermail/discuss_discuss.lugm.org/
> Forum: http://lugm.org/forum/
> IRC: #linux.mu on Freenode
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://discuss.lugm.org/pipermail/discuss_discuss.lugm.org/attachments/20151023/be66e7e4/attachment.html>