[ppml] Policy Proposal 2003-15: IPv4 Allocation Policy for the Africa Portion of the ARIN Region

Leo Bicknell bicknell at ufp.org
Tue Sep 23 21:12:35 EDT 2003


In a message written on Wed, Sep 24, 2003 at 01:24:09AM +0200, William Stucke wrote:
> I couldn't find a Podunk in Iowa (I gather that the term means "nowhere
> town" in American?) but I did find Bonaparte, Iowa, population 465. If I was
> an ISP in Bonaparte, Iowa, and I wanted a T1 line to the BWW (Big Wide World
> [tm]), it would cost me $1,024 to $1,052 per month from one of two providers
> (http://shopfort1.com). If I was an ISP in Africa and I got it from my
> state-legislated monopoly Telco, it would cost me ~$55,000 per month for the
> same dedicated T1 symmetrical bandwidth.
[snip]
> On the income side, the picture is just as bleak. My company charges $14 per
> month for an unlimited access dial-up connection, for example. That compares
> rather well with a typical North American ISP, I suspect, especially
> considering that my primary input cost is 55 times higher than in Podunk (or
> 75 times higher than in California) ;-)

[Note; Yes, Podunk is a generic small town.]

You're getting right to my point with this response.  I've been
told small ISP's (eg, 1-5 T1's in a small town, single upstream,
no real network) plan on 50-100 dial-up users per T1.  Let me assume
Africa, being more bandwidth starved, is 10 times worse, so 500-1000.
At 1000 users * $14 per user = 14000, if your T1 costs $55000 you're
losing $41000 per month.

Now, let's say I have you a /16 today, free and clear.  How are you
ever going to be able to afford to use it?  How does having it make
your costs go down?  How does having it encourage more people to
buy service from you?  Or, most directly to the point, why can't
you get addresses from your upstream to meet your needs?  I know
my employer (which doesn't sell IPL's, admittedly) would happily
give you up to a /20, all you have to do is document your usage to
the same guidelines ARIN requires.  Is that process broken?  Would
multi-homing significantly change the cost model for the better (I would
think it would make it worse)?

> A "really big ISP" (think AOL, Earthlink) in Africa has a few 100,000
> dial-up subscribers, or a few hundred leased lines. There are only a handful
> of these (I can think of three, off hand), which is why there are only 19
> LIRs in sub-Saharan Africa. The overwhelming majority of African ISPs are
> far, far, smaller. For them, 1,000 subscribers is a lot.

Let's say 10% are online at any one time (I'm assuming dial up,
which if there are no free local calls seems optimistic).  the ISP
needs a /25 for the dial pool, let's give them another /25 for
"infrastructure".  They fit in a /24.

Is there a problem getting a /24 from the upstream?  Do you think it
would be possible to multihome with a /24 (hint, depending on block it
may or may not work)?  Does it make sense to require a 25% usage
requirement (assuming we give them a /22, per the proposal)?  Is a 75%
waste factor something we want to encourage anywhere?

> I understand your point, but consider this: there's something else that
> leaves a bad taste in my mouth. If I send an email to you in Bonaparte, say,
> from anywhere in Africa, I pay the full cost of international transit - both
> half circuits. If you send me an email from Bonaparte, I pay the full cost
> of international transit - both half circuits. You don't pay a penny for the
> international transit. You only pay your "local" connectivity costs of $750
> for a T1 in California or $1000 in Bonaparte, Iowa. This represents an
> enormous export of scarce foreign currency from the developing world to the
> developed world. In fact, Africa pays the developed world some $400M per
> year just to send African traffic from one African country to another, via
> the USA, Europe and the Far East. (See "The Halfway Proposition"
> http://www.afrispa.org)

I agree 100% that this model is broken.  That said, I don't see where
IP's (or lack of them) make any difference in the fact that there is an
imbalance in who pays for the traffic.

All of these arguments come back to the same thing for me, "bandwidth is
expensive".  I 100% agree with that statement in Africa.  I 100% think
it is an unfair situation.  I have yet to see anyone establish a direct
link between IP's (or lack of them) and the problem though.  It looks
like a problem that needs, in order of impact:

1) Deregulating state run monopoly telco's.
2) Creating a competitive local enviornment.
3) Raising the general standard of living in that area of the world.
4) Foreign ISP's building into Africa for local peering.
5) African ISP's building their own infrastructure (eg cables) to
   other countries for peering.
6) Investment by all parties in infrastructure (eg, undersea and
   overland cables).

I have a hard time putting IP's on the list at all, but if I did it
would be way down at the bottom, and it would be because they can
facilitate things like peering.  However, with a lack of any peering
points in Africa, and bandwith being too expensive to go to peering
points outside of africa that seems to be putting the cart before the
horse.  If there were an African peering point where at least 25% of the
African ISP's showed up, and they could document the problems of
accepting more specifics of other providers space across the exchange I
might have a change of heart.

While I admit this is my self serving position, I suggest if you want
smaller allocations you get behind 2003-3, or a similar proposal.  You
can have your own opinion on if it is American arrogance or that we
really do know better, but I don't think you're going to find any real
support for 2003-15 outside of Africa with the reasons given so far.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20030923/4b808954/attachment.sig>


More information about the ARIN-PPML mailing list