[ppml] Policy to help the little guys

[Tom Vest]

Hi Ray,

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  
mind.

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  
flag).

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  
that show:

Obs1: "In years (x,y,z...), for every initial allocation transaction,  
there were (B/A) subsequent allocations for prefixes of equal length  
or longer.
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  
prefixes.

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...

Thanks,

Tom








On Mar 19, 2008, at 10:27 AM, <michael.dillon at bt.com> <michael.dillon at bt.com 
 > wrote:
>> 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  
> that
> 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  
> the
> 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
> _______________________________________________
> PPML
> 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:
> http://lists.arin.net/mailman/listinfo/ppml
> Please contact the ARIN Member Services Help Desk at info at arin.net  
> if you experience any issues.