[arin-ppml] Policy Proposal: IPv4 Recovery Fund

[Owen DeLong]

>>>
>>>
>> 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.
>
Desirable for the community as a whole.

>> 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 don't see it that way.

The way I see it, in the end game, there are pretty major disadvantages
to being a large requester no matter what.  There simply will be fewer
large blocks available and the smaller your need, the faster you're
likely to see a block in your size become available.

I believe that the case where a /19 comes available and there are
requests in the queue in the order:

/21
/21
/20
/21
/21
/22
/22
/21

Is an unlikely corner case.  I think you're far more likely to see 4 / 
21s
come back in than a /19 on any given day.

> 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.
>
The problem is this... The more likely scenario is something like
a /21 comes in, then, a /20.  The following day, you get two more /21s.
Now, you've got enough space to have filled all the requests, but,
because on the first day, you carved up the /20 just because the
second /21 was in front of him, you can not satisfy the /20 and what's
left has to fall to people even further back in the line.

>
> 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.
>
Assumptions regarding consolidation are virtually guaranteed to be
false in the IP address-block world.  The odds of coalescing two blocks
of any significant size into a single block are near zero.  Unlike  
memory
where things can be re-located into contiguous blocks (often by mere
act of MMU pointer swaps), IP can't easily be "garbage collected" to
achieve fresh contiguous space.

So, memory allocation is not really much of a valid model for IP address
allocation.

Owen