[arin-ppml] Policy Proposal: IPv4 Recovery Fund

[Robert Bonomi]

> From owen at delong.com  Sun Nov 23 19:08:03 2008
> Cc: arin-ppml at arin.net
> From: Owen DeLong <owen at delong.com>
> To: Robert Bonomi <bonomi at mail.r-bonomi.com>
> Subject: Re: [arin-ppml] Policy Proposal: IPv4 Recovery Fund
> Date: Sun, 23 Nov 2008 17:07:33 -0800
>
> >
> > 2) The allocation methodology specified/required by the language at  
> > the end of
> >   the section named "Distribution of Recovered Space" has a major,  
> > if not
> >   fatal, flaw.  To wit:
> >
> >     IF, for example, while nothing of a /21 or larger is available,  
> > two ORGs
> > 	   are each approved for a /21 on May 15, two more are approved (for
> > 	   /21s) on June 1, AND an ORG is approved for a /20 on July 1,
> >     THEN, when a /19 becomes available on July 15, under the 'best  
> > prefix
> > 	   match' rule, the "July 1" ORG would get a /20, and each "May 15"
> > 	   ORG would get a /21, with the two "June 1" ORGs being left out.
> >
> >   I  believe that the 'desirable' outcome in that situation is that  
> > all 4 of
> >   the /21 requesters should get space, and that the /20 requester  
> > should have
> >   to wait for the -next- free block.
> >
> I actually thought about this, and, frankly, I think that the  
> desirable outcome
> is that the /20 requester gets in front of the two /21s.

Desirable for whom?   <grin>

It's obviously not desirable for the 3rd/4th requesters of the /21s,
who _have_ been waiting longer -- and thus, their 'need' _is_ more 
acute than the party requesting the /20.

> The reason being that /21s are, by definition more likely to come up  
> more
> often. However, even in a situation where /20s  or /19s are more  
> frequent,
> the end result would be that the next /19 or /20 would most likely  
> fill the
> two /21s needs.  Since block fragmentation tends to be pretty much a
> one-way process, I think minimizing block fragmentation in this way
> is actually a desirable outcome.

This approach favors the large requester over the smaller one.  Obviously,
those making larger requests will prefer this.  ;)

I will point out that the "tighter" the return market is, the longer
people will have to wait for a block to become available.  AND, the longer
they have to wait, the more likely it is that someone needing a 'slightly'
bigger allocation will show up into the queue.  If the bigger requests
are always given preference, then the littler guy is going to get a chance
_only_ when something =exactly= his size comes along.  If most of what does
come back is 'bigger' than his needs, this could be a _long_ wait.  This is
*not* fair to the smaller requester.


I will also note that it is statistically proven that "best fit" match causes 
_more_ fragmentation (over time) than "first fit".  I don't have cites
to hand, but this was a routine part of late-1970s undergrad CS coursework 
having to do with memory allocator schemes.  'Power of 2' block-sizing 
greatly reduces, but does not completely eliminate the downside of best-
fit.  I will concede that there are assumptions in that analysis concerning 
repeated return, consolidation, and re-allocation -- assumptions that may 
not be applicable to IP address-block allocations.