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

Fri Oct 23 11:48:04 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 9:16 AM, Loganaden Velvindron <gnukid1 at yahoo.co.uk>
wrote:

> Sorry Nishal, I meant ISPs, not IXPs.
>
> For the XMPP server, it would *really* help if we could get latencies of
> around 2-20ms across the different Local ISPs. Don't you think so ?
>
> I have a 10Mb/s upload speed, and I think that for a voice call among
> people in Mauritius is a good idea.
>
> Btw, Nishal what is your opinion about putting probes such as RIPE atlas
> probes between different Local ISPs to see the latency among them to raise
> awareness of the peering problems ?
>
>
>
>
> On Friday, 23 October 2015, 12:05, Nishal Goburdhan <
> nishal at controlfreak.co.za> wrote:
>
>
> On 23 Oct 2015, at 08:57, Loganaden Velvindron <gnukid1 at yahoo.co.uk>
> wrote:
>
> Hi Cyril,
>
> It doesn't use peer-to-peer, as far as I know. However, if we had a viber
> server in Emtel datacenter, we can leverage a low latency across different
> IXPs to get better quality.
>
>
> no this is incorrect.
> in its life cycle, a packet will not traverse _different_ IXPs.
> there is no economic model for that.
> i would be interested to see a traceroute showing otherwise.
>
>
> It wouldn't matter if the viber customer is at Orange, or Bharat. As long
> as there's good peering, the latency will be ok, and so will the voice
> quality.
>
> We could also host our own XMPP server somewhere in Mauritius, and set up
> a service :-D
>
>
>
> this, is what you want to do!
> so what's stopping you?
>
>
>
>
>
>
>
> On Friday, 23 October 2015, 10:23, Cyril Bouthors <cyril at boutho.rs> wrote:
>
>
>
> On Fri, Oct 23, 2015 at 12:29 AM, Loganaden Velvindron <
> gnukid1 at yahoo.co.uk> wrote:
>
> I have horrible voip quality with viber when I talk to Mauritian across a
> different ISP. I have 30Mb/s, whereas she has 10Mbit FTTH. Here bandwidth
> does not help, it's latency :)
>
> Same goes for gamers hosting matches within Mauritius, but across
> different ISPs.
>
>
> Does Viber use peer to peer technology for calls?
>
> --
> Cyril Bouthors http://cyril.boutho.rs/
>
>
> __________________________________________________________
> 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
>
>
>
>
> __________________________________________________________
> 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/cf2e102b/attachment-0001.html>