[ppml] Policy to help the little guys
tvest at pch.net
Wed Mar 19 20:13:24 EDT 2008
Sorry for delayed response -- laptop failure this morning :-|
Michael's suggestion is interesting, and would probably be very useful
for a variety of questions , but I have something fairly specific in
Imagine that all of the IPv4 entries in the ARIN "delegated" file had
two additional columns. For PA IPv4 allocations, the first new column
for each of the entries would contain an "i" or an "s", to indicate
whether they were an initial or a subsequent allocation. PI
allocations would be marked with an "i" also. In the second column,
each entry would be annotated with the policy-defined minimum size
initial allocation for that particular time period (note: this second
data point is far less important than the first, and could probably be
guessed fairly easily using the other delegated data plus that s/i
Once the entries were so annotated, all of the "delegated" entries
would be sorted/counted, ideally by year and by "policy period" (e.g.,
the entries corresponding to the /19 min. allocation era would be
grouped together, separately from the entries for the /20 min., et al.
periods). If this proved to be too difficult, annual groupings would
be almost as helpful.
For each time period or policy era, the counts of interest would be:
(A) Number, PA initial or PI allocations (of prefix length i)
(B) Number, PA subsequent allocations (of prefix length i or longer).
(C) Number, PA subsequent allocations (of prefix length i minus one).
(D) Number, PA subsequent allocations (shorter than (i minus one)).
With these data points, you could make rough statements about the
frequency of occasions when "new entrants" and "incumbents" were
seeking prefixes of roughly the same length. For example, if ARIN
staff had to make these calculations (e.g., to preserve
confidentiality, etc.), they might come back with statements/graphs
Obs1: "In years (x,y,z...), for every initial allocation transaction,
there were (B/A) subsequent allocations for prefixes of equal length
Obs2: In years (x,y,z...), of the (A+B+C+D) total IPv4 delegations,
(one - (C+D)/(A+B+C+D)) percent involved operators seeking roughly the
same (initial-alloc) size prefix.
Obs3: In years (x,y,z...), of the (A+B+C=D) total IPv4 delegations,
(C) delegations or (C/(A+B+C+D)) percent of the total were subsequent
allocations that could have been satisfied by two initial-alloc sized
Here's why I think this data would be illuminating.
If I'm interpreting 2008-02 correctly, many of the limitations in
deaggregation, exact "need" to prefix length matching, etc. are
included in part to foster the emergence of "convex pricing", wherein
each /32 that's part of a shorter prefix is worth more the equivalent
in a longer prefix -- so for example, a single /20 would always
command a higher price than would 2x /21. Over the course of multiple
conversations with 2008-02 supporters over the last couple of weeks,
this "convex pricing" pattern has been repeatedly identified as the
primary mechanism to help "the little guys". If I followed those
conversations correctly, the reasoning is that if such a pattern
emerges, and a supply of long-ish prefixes persists, then those
resources would remain accessible to new entrants and small operators,
and thereby keep the industry open.
Here's where the data request comes in. If either or both (Obs1, Obs2)
are large numbers, then history would suggest that even if all address
seekers want to follow the 2008-02 process, there could be frequent
contention for prefixes of the same size. If convex pricing does
emerge for other (e.g., policy-driven) reasons, prefixes of the same
size will be priced roughly the same -- at least in the sense that
they'll cost more than 2x (next longest prefix) and less than (0.5*
next shortest prefix). However, if those (Obs1, Obs2) numbers are
large, that suggests that operators are going to be frequently
confronting temptation, e.g., to engage in bidding wars that might
undermine the convex pricing pattern, or alternately to seek address
space outside of the approved process -- e.g., the "gray market" for
prefixes of the same size or longer. Obs3 would also provide some
insight on how much more this pressure might affect "the littlest
guys", i.e., new entrants.
Granted history proves nothing, and historical lessons are doubly
questionable across periods of radical change, but I think all of
these observations would be useful as indications of how much/often
the approved process (and/or the process administrators) might be
subject to major stresses, and how often commercial operators might
have to resist strong incentives to seek address space in ways that
would undermine the quality of the ARIN registry. If the decentralized
resource transfers are legitimized, and no other compliance-promoting
mechanisms are instituted, then "convex pricing" and the intrinsic
appeal of the 2008-02 process may have to carry most/all of the weight
to keep the industry open and the ARIN central registry viable. Thus I
think the community ought to have as much relevant information and
analysis as possible before they have to make that choice.
Needless to say, I'd be happy to help with the data crunching...
On Mar 19, 2008, at 10:27 AM, <michael.dillon at bt.com> <michael.dillon at bt.com
>> Not sure what you are asking for, and then, don't know how
>> long it will take to produce it.
> To me, it sounded like this, or perhaps a subset of this.
> For every ARIN IPv4 ISP/LIR, record the size of the base allocation
> they first received and the date. Call this B.
> Then go through all the B's and figure the average size of B for each
> month. Call this A.
> The go through all the ISP/LIR subsequent allocations and record the
> date the size called S and two calculated values PB and PA. PB = S
> as a
> percent of B, and PA = S as a percent of A.
> Provide this data as a table in CSV format
> ISP #, B, A, Base Date, Subsequent Date, S, PA, PB
> That should be sufficiently parseable that people can do some charts
> with it. For instance charting the average of PA and/or PB over time
> would show if subsequent allocations are trending larger compared to
> base allocation or compared to all other allocations made at the time
> the base allocation was made.
> Or perhaps Tom could suggest a slightly different algorithm.
> --Michael Dillon
> You are receiving this message because you are subscribed to the
> ARIN Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> Please contact the ARIN Member Services Help Desk at info at arin.net
> if you experience any issues.
More information about the ARIN-PPML