[kictanet] State Wrong on Internet Exchange Point , is it true

Michuki Mwangi michuki at swiftkenya.com
Thu Jan 7 15:15:56 EAT 2010


Hi Walu,

See my comments inline,

Walubengo J wrote:
> my only comment arises from the broad understanding that IXPs (Internet
> eXchange Points)  are building blocks or concentration points for
> Internet traffic. 

Indeed, see them as a commodity market, where anyone can participate.
The only thing being traded here is content. Barter (peering) and
ordinary trade (transit and fee-based peering) are the main forms of
exchange mechanisms that take place.

Traditional growth/concentration patterns(IXPs) have
> often followed an open and trusting relationship between the connecting
> parties. Obviously a "Government IXP" will not be obliged to be open nor
> trusting to non-government players.
>  

This will have to be the policy of the IXP - remember the peering policy
determines the folks you attract to the facility. Just like in a
commodity market if it does not trade in perishables, you can expect
that potential traders will all go to a different market that accepts
their goods.

> Is this a bad thing for the growth of the internet in Kenya? Its too
> early to say, but definately it is a big blow the the Kenya-IXP which
> will obviously lose a big chunk of "goverment" traffic to the
> Government-IXP. I was involved in some IXP research a while back and if
> one has time they can go through the paper @
>  

>From my initial understanding, again i have not looked at the revised
tender document for the GIXP, i was under the impression that the GIXP
will be connected to the KIXP. If this is still the case, then it adds
value to the KIXP. The reason being ISPs connect to the end-users who
need to reach the e-govt content. For them to do so, it means they have
to pass through the KIXP to reach the GIXP.


On the other hand if the GIXP will not be directly connected to the KIXP
then it means traffic will flow as it does today i.e via transit. This
also has no negative impact to the KIXP as well. However, in this
configuration, the ISPs will definitely loose the inter-ministry traffic
revenue. They will still hold the end-user traffic and since not all
end-users are connected to one ISP, it means that the KIXP will continue
to serve its purpose of keeping the traffic local for the benefit of all.

Let me try and explain how. Today, most Govt agencies/ministries procure
internet services from different ISPs in the market today. All traffic
in and out of Ministry X will go through their ISP. If traffic is coming
from an end-user, served by a different ISP, then the traffic will go
via KIXP to the Ministries X ISP and to the Ministry and vise versa
(transit).

In addition, This is the same path that inter-ministry traffic follows
which am sure you can deduce the concerns that are bound to rise as a
result (transit).

The only instance where the KIXP will loose a big chunk of the traffic
to the GIXP is if by design all ISPs will be required to connect at the
GIXP individually for access to Govt content. Now if you think about
this the GIXP model will inadvertently break its own role since not only
will the ISP be loosing inter-ministry traffic, it will have to pay for
a circuit to the GIXP and deliver end-user traffic as peering (which now
is paid for through transit).

Now if you recall my earlier email on IXPs, peering, big players and
small players. Well this is one of such, ISPs like having the choice to
choose whom to peer with. If they would rather provide you with transit
than peer with you - then thats what they will do - its all in their
business model. As such, IMHO its less likely that any ISP will peer at
the GIXP since they would want to keep being profitable in the
interconnection ecosystem.

In conclusion Walu, its not too early to discuss this, in any case am
pleased to see this discussion going on since its addressing the issue
of Interconnection. Interconnection is one of those areas where very few
talk about yet it makes the internet what it is.

HTH

Michuki.




More information about the KICTANet mailing list