On Thu, Apr 19, 2012 at 10:36 AM, maina
<dmaishe@gmail.com> wrote:
Orange here i come.!
On Thu, Apr 19, 2012 at 10:33 AM, stephen wanjau
<stevewanjau@wikimedia.or.ke> wrote:
> Ni Kuhama...
>
>
>
>
>
> On Thu, Apr 19, 2012 at 10:31 AM, wambugu esther <essiekui@gmail.com> wrote:
>>
>> coool analysis
>>
>> On Thu, Apr 19, 2012 at 10:23 AM, Kevin Mutuma <kkmtumah@gmail.com> wrote:
>>>
>>> QueenB Feeling the pressure...this is good for the competition.:-)
>>>
>>>
>>>
>>> Why Unlimited Internet is a Big Revenue Drain for Operators
>>>
>>> The announcement by Safaricom that it’s doing away with its unlimited
>>> Internet bundle did not come as a surprise to me. I had discussed the
>>> historical reason behind the billing model that is used by ISP’s and mobile
>>> operators in a previous blog post here in Feb 2011.
>>>
>>> The billing model used in unlimited Internet offering is flawed. This is
>>> because the unit of billing is not a valid and quantifiable measure of
>>> consumption of service. An ISP or mobile operator charging a customer a flat
>>> fee for a size of Internet pipe (measured in Kbps) is equivalent to a water
>>> utility company charging you based on the radius of the pipe coming into
>>> your house and not the quantity of water you consume (download) or sewerage
>>> released (upload).
>>>
>>> What will happen if the local water company billed users by a flat rate
>>> fee based on per-centimeter radius of pipe going into their homes rather
>>> than volume of water consumed? A user with a pipe of radius that is 1% more
>>> than the neighbor enjoys 2% more water flow into their house (do the math!).
>>> The problem is that their bills will not differ by 2% but by 1% based on the
>>> difference in radius of the pipes. A 2% difference yields a 4% difference in
>>> consumption but a 2% difference in billing. The result is that a small group
>>> of about 1% users end up consuming about 70% of all the water. This figure
>>> is arrived at as follows: A marginal unit increase in resource leads to a
>>> near doubling of marginal utility. This is a logarithmic gain (Ln 2=0.693
>>> which means that 69% of utility is enjoyed by about 1% of consumers) . This
>>> is the figure issued by Bob Collymore the CEO of Safaricom who said that 1%
>>> of unlimited users are consuming about 70% of the resources. This
>>> essentially means costs could outstrip revenues by 70:1. This does not make
>>> any business sense. Not even a hypothetical NGO engaged in giving ‘free’
>>> Internet through donor funding can carry such a cost to revenue ratio. As to
>>> why ISP’s and mobile operators thought billing by size of pipe to the
>>> Internet could make money is beyond me.
>>>
>>> Bandwidth Consumption Is Not Linear
>>>
>>> One mistake that network engineers make is to assume that a 512Kbps user
>>> will consume double what a 256Kbps user does and therefore advice the
>>> billing team that billing the 512Kbps twice the price of the 256Kbps can
>>> cover all costs. This is not true. There are things or activities that a
>>> 256Kbps user will not be able to do online, like comfortably do Youtube
>>> videos. A 512Kbps user will however be able to do Youtube without a problem.
>>> The result is that a 512Kbps user will do much more Youtube videos as the
>>> 256Kbps user becomes more frustrated with all the buffering and stops all
>>> together attempting to watch online videos. The result is that the
>>> consumption of the 512Kbps user will be much higher than double that of the
>>> 256Kbps user. Other than Youtube, websites can detect your link speed and
>>> present differentiated rich content based on that. I’m sure some of us have
>>> been given an option to load a ‘basic’ version of Gmail when it detects a
>>> slow link. The big pipe guy never gets to be asked if he can load lighter
>>> web pages, rich content is downloaded to his browser by default while the
>>> smaller pipe guy gets less content downloaded to his browser in as much that
>>> they are both connected to the same website. The problem here is that the
>>> difference in content downloaded by the two people on 512K and 256K link is
>>> not linear or even double but takes a more logarithmic shape.
>>>
>>> Nature Of Contention: Its a Transport and not Network problem
>>>
>>> The second mistake that the network engineers make in a network is to
>>> assume that if you put a group of customers in a very fat IP pipe and let
>>> them fight it out for speeds based on an IP based QoS mechanism is that with
>>> time each customer will get a fair chance of getting some bandwidth out of
>>> the pool. The problem is that nearly all network QoS equipment characterize
>>> a TCP flow as a host-to-host (H2H) connection and not a port-to-port (P2P
>>> not to be confused with Peer2Peer) connection. There could be two users with
>>> one H2H connection each but one of them might posses about 3000 P2P flows.
>>> The problem here is that bandwidth is consumed by the P2P flows and not the
>>> H2H flows. User with the 3000 P2P flows ends up taking up most of the
>>> bandwidth. This explains why peer to peer (which establishes thousands of
>>> P2P flows) is a real bandwidth hog.
>>>
>>> So what happens when an ISP dumps the angelic you in a pipe with other
>>> malevolent users who are doing peer to peer traffic such as bit-torrent?
>>> They will hog up all the bandwidth and the equipment and policies set will
>>> not be able to ensure fair allocation of bandwidth to all users including
>>> you. So some few users doing bit-torrent end up enjoying massive amounts of
>>> bandwidth while the rest doing normal browsing suffer. That explains why
>>> some users on the Safaricom Network could download over 35GB of data per
>>> week as percomments by Bob Collymore. Please read more on how TCP H2H and
>>> P2P flows work here. Many ISP’s engage engineers proficient in layer3
>>> operations (CCNP’s, CCIP’s, CCIE’s etc ) to provide expertise on a layer 4
>>> issue of TCP H2H and P2P flows. You cannot control TCP flows by using layer
>>> 3 techniques. IP Network engineers are assigned the duties of transport
>>> engineers. Good luck with that
>>> Mr-CTO-in-an-ISP-wanting-a-fair-access-policy-for-your-customers!
>>>
>>> At the end of the day, there will be a very small fraction of ‘happy’
>>> customers and a large group of dissatisfied and angry customers. The few
>>> happy customers flat rate revenues are not able to cover all costs as the
>>> unhappy customers churn. If on the other hand these bandwidth hogs paid by
>>> the GB, the story would be very different. This is what operators are
>>> realizing now and moving with speed to implement. Safaricom is not the only
>>> one affected by this; Verizon, AT&T, T-Mobile in the US are all in different
>>> stages of doing away with unlimited service due to their unprofitable
>>> nature.
>>>
>>>
>>>
>>> Sent from my iPhone
>>> _______________________________________________
>>> Skunkworks mailing list
>>> Skunkworks@lists.my.co.ke
>>> ------------
>>> List info, subscribe/unsubscribe
>>> http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks
>>> ------------
>>>
>>> Skunkworks Rules
>>> http://my.co.ke/phpbb/viewtopic.php?f=24&t=94
>>> ------------
>>> Other services @ http://my.co.ke
>>
>>
>>
>>
>> --
>>
>>
>> Best regards
>> Esther Wambugu
>>
>>
>> _______________________________________________
>> Skunkworks mailing list
>> Skunkworks@lists.my.co.ke
>> ------------
>> List info, subscribe/unsubscribe
>> http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks
>> ------------
>>
>> Skunkworks Rules
>> http://my.co.ke/phpbb/viewtopic.php?f=24&t=94
>> ------------
>> Other services @ http://my.co.ke
>
>
>
> _______________________________________________
> Skunkworks mailing list
> Skunkworks@lists.my.co.ke
> ------------
> List info, subscribe/unsubscribe
> http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks
> ------------
>
> Skunkworks Rules
> http://my.co.ke/phpbb/viewtopic.php?f=24&t=94
> ------------
> Other services @ http://my.co.ke
--
P. O. Box 8310-00200,
NAIROBI,
KENYA..
Cell:+254-721-950073.
Registered Linux User #407239.
----------------------------------------------------------------------
"By golly, I'm beginning to think Linux really *is* the best thing
since sliced bread."