[ppml] Policy to help the little guys

[Ray Plzak]

Tom,

Taking this offline. Sent you a message.

Ray

> -----Original Message-----
> From: Tom Vest [mailto:tvest at pch.net]
> Sent: Wednesday, March 19, 2008 8:13 PM
> To: Ray Plzak
> Cc: arin ppml; michael.dillon at bt.com>
> Subject: Re: [ppml] Policy to help the little guys
>
> 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.
>