[arin-discuss] tweak to proposed fee schedule

[Owen DeLong]

>> However, there are some operational issues that arise from this use of
>> number policy to patch an issue with the fee schedule; these issues have
>> been discussed at length on PPML, and I refer the reader to the archive
>> of that discussion.  Briefly summarized:
>> 
>> o It results in a messy addressing plan, where the ISP is forced to fit
>> into a small corner of the potential space it has available to it.
>> This, in turn leads to two consequences:
>> 
>> o Customers will receive sub-standard reassignments as the ISP becomes
>> increasingly parsimonious with address space.
> 
> I think "will" is a little strong, I'd put it at "may" and that same may exists for any size IPv6 allocation.  Some ISP that really needs a /28 may decided to stick with a /32 and give their customers smaller than we'd like reassignments.  We can't dictate the size reassignments ISP make.  Why do you think this is more likely to occur for xx-small or x-small ISPs than the larger guys?
> 

I would put it at "will almost certainly"...

Because they are the ones that are most price sensitive. This may seem odd to you. You work for an organization that thinks nothing of an $18,000/year expenditure and likely spends more than that on network gear annually. This isn't atypical of a /28 and larger-sized ISP.
An ISP that would consider dipping below a /32, OTOH, is likely a very cost-conscious ISP. While I work for such an organization today,
I have also worked for a number of much smaller ISPs as well.

Further, every time you double the fee, you get 16x as much address space. At the low end, the doubling fee can seem a lot more significant than the address space growth because you're probably staring at an ability to use 1/8th of the expanded address space (double your current holdings) and the other 7/8ths don't seem to add much value. At the higher end, continued growth is more likely a simple expectation.

The further left you move on the bit-scale, the more likely that you are a long-established more stable business with the ability to absorb higher fees much more readily as your customer base grows.


>> o As the allocation grows toward the /32 boundary, it becomes less
>> likely that the ISP will be able to have internally aggregable routing,
>> and this may make it more likely that the ISP won't re-aggregate its
>> space as it increases the size of its allocation over time, *even* if
>> that space is from a single aggregable /32.
> 
> Why?  I'm not sure I see the reasoning here, yes they will likely have some messiness in their internal routing going from /40 to /36 to /32, but this is an internal business choice.  Why do you think it likely that they won't aggregate their announcements as they grow?  Do you expect the same thing will happen as other ISPs grow from /32 to /28 or /28 to /24?  If not why not, I don't see why this issue, if it exists, is unique to the small allocations.

Many smaller ISPs advertise discrete chunks of their network out of the closest exchanges to those POPs.

Again, as you move further up the food chain, you're more likely to encounter an organization that has large backbone interconnecting their various sites.

>> I'd like to propose a tweak to the proposed fee schedule as follows:
>> 
>> "ISPs which have IPv4 resources and an IPv6 allocation of exactly /32
>> will have their fees calculated from the fee schedule based only on
>> their IPv4 allocation.  All allocation sizes other than IPv6 /32 will be
>> calculated from the fee schedule based on the greater of their IPv4 or
>> IPv6 allocation."
>> 
>> This only affects ISPs whose IPv4 allocations are in the X-small or
>> XX-small range *and* who have a /32 allocation.  ISPs and end sites with
>> allocations/assignments in the small or greater category will still pay
>> the greater of their IPv4/IPv6 allocation-category fee.
> 
> Your proposal quoted above, doesn't say anything about end users assignments, I don't understand why you are bringing them up.  Do you expect to effect end user assignments?
> 

As I read the above paragraph, it specifically states that they would continue
as before. That they would not change. It appears he brought them up along
with the ISP categories that would not be affected as part of the list of things
not affected by his proposal.

>> It's revenue-neutral with respect to the pending fee schedule, combined
>> with proposal 2013-3 because that proposal calls for the reservation of
>> the /32 for that ISP anyway.  I believe this tweak still allows for a
>> sustainable revenue model for ARIN until such a time as ARIN ceases to
>> provide IPv4 services, at which point the fee schedule will likely need
>> to be revisited anyway.
> 
> I think there is a long-term problem created by this proposal, I agree it is revenue-neutral currently, and it works pretty good with IPv4 still being the primary driver for ISPs.  However, as IPv6 becomes the primary driver for ISPs overtime, there will need to be a different way to differentiate these xx-small and x-small ISPs from the just plane small ISPs when IPv4 is no longer functionally doing that for us.  I'll admit that is probably 5 to 10 years from now, but I believe it will happen eventually.
> 

ISPs that had both could be categorized based on their last IPv4 status
until they grew to a /28 or beyond.

ISPs that never had IPv4 could default to Small unless they provide
documentation of a limited number of end-sites served. For X-Small,
this could be ≤ 4,000 end-sites served. For XX-Small, more like ≤200
end-sites served. (4,000 is just over the 3,072 minfree point for an
IPv6 /36 worth of /48s and 200 is just over the 192 minfree point for
an IPv6 /40 worth of /48s).

In this way, the billing is based on end-sites served and priced according
to /48s so as not to create a disincentive to rational addressing.

>> I am interested in this community's thought on this tweak.  I realize
>> the fee schedule is always a contentious issue, and I am reluctant to
>> get into a general discussion of fees (for more general discussions,
>> please create a separate thread).  However, I would like to know if
>> there are specific issues or incentive problems with what I am proposing.
> 
> As I said, I believe your proposal has a long-term problem.  I'm not sure that disqualifies it.  However, it will eventually become a problem that will likely require another change in the fee schedule.   The bigger issue for me is, I'm not sure what the alternative is to fix that long-term problem when it inevitably comes to pass.  I worried that we just end up right back with the something like ARIN-2013-3 and the corrected proposed fee schedule, but 5 or 10 years from now.

I expect the fee schedule will change several times in the next 10 years anyway. I expect ARIN to be a pretty different organization in 10 years from what it is today.

> In contrast the corrected proposed fee schedule with ARIN-2013-3 allows ISPs to differentiate themselves, rather than using IPv4 to do that. They can elect to start with a /32 because they think it is the right thing to do and believe it is the better long-run business and technical decision for them.  Or, they can choose /36 or /40 if that is a better business and technical decision for them.

Do you really think that situation doesn't also have several long-term problems?

> Yes, this could have incentive problems.  However, are we really sure that a /40 is always technically inappropriate, even for the smallest (xx-small) 0.1%* of the ISPs in the ARIN region?  More important, who is better equipped to make that decision, the mob on ARIN-PPML and ARIN-Discuss or the individual ISPs that have to live with the business and technical consequences?

It _DOES_ have incentive problems. Yes, I am quite sure that /40 is always technically inappropriate for an ISP.

I'll address the second half of that paragraph in private email.

> Are we really going to say that a remote rural ISP with a customer base of 50 to 100 customers couldn't make valid business and technical choice of using a /40 of IPv6?  Or what about a boutique Business IT support shop that includes ISP services for 20 to 50 of its customers that don't want be bothered with separate ISP bill.  I believe there are several business models that it would be a valid technical choice to use a /40 option.

These are extreme corner cases. Sure, they could, but there's no benefit to them or the community from not giving them a /32 if they aren't forced to pay more than they would be able to get the /40 for.

> Finally, I'm not opposed to this proposal.  But I'm not convinced that it is fundamentally creates any better set of trade-offs than the corrected proposed fee schedule with ARIN-2013-3.  Especially when you consider this proposal dependency on IPv4 to differentiate among xx-small, x-small, and small ISPs.  In the short-run this proposal has some small advantage, but in the long-run if IPv4 was viable, we wouldn't need IPv6.  So, I think this only punts the problem down the road, but I will acknowledge sometime that is the right answer.

I believe the tradeoffs are considerably better. Further, I believe that there are ways to address the long-term problem this proposal creates.

Do you see any way to address the long term problems created by the negative incentives inherent in 2013-3 and the "corrected" as you call it fee schedule?

Owen


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-discuss/attachments/20130412/ab5c86a2/attachment.html>