[arin-ppml] Does Moore's law help with routing table growth?

[Scott Leibrand]

On 12/22/2009 12:18 PM, Matthew Petach wrote:
> On Fri, Dec 18, 2009 at 9:34 PM, Scott Leibrand<scottleibrand at gmail.com>  wrote:
>    
>> On 12/18/2009 9:19 PM, Michel Py wrote:
>>      
>>> I don't think we have much maneuvering room though; the benefits of
>>> Moore's law helping building faster routers are more or less offset by
>>> the same Moore's law helping building more bandwidth-hungry consumer
>>> devices.
>>>        
>> Except that the bandwidth of consumer devices is completely independent of
>> the number of routes we have to stuff into our FIB.  That is dependent on
>> the number of independently multihomed networks, which is determined by
>> economic and business forces.
>>      
> Which seems to imply that one perfectly valid control point to limit the
> growth of the routing table is simply keep raising the price of registering
> an ASN to the point where few enough new business can afford to multihome;
>    

If we just raised the prices of ASNs, multihoming with private ASNs 
would become a lot more popular.

> if we keep the number of new multihomed networks entering the global
> tables to a rate slightly slower than the development and deployment
> curve of hardware able to do lookups on those new multihomed networks,
> then we should be able to continue to scale the DFZ as long as necessary.
>    

Which is, AFAICT, exactly what has been happening, without any policy or 
fee action on our part.  (Anyone can buy a cheap router off eBay, get a 
/24 from an upstream, and announce it into BGP.  The router doesn't need 
to be able to take a full BGP feed.)

> Just give the hardware engineers a means to feed back into the RIRs if
> they run into a roadblock, so that the appropriate fees for an ASN can be
> raised to slow down the rate of new multihoming entrants until the technology
> is able to overcome the roadblock and continue progressing again.
>
> Thus, the concern of DFZ routing table slots moves firmly into the business
> realm, subject to economic forces, and out of the policy-making arena.
>    

IMO the RIRs are not the proper tool for doing this.  If it becomes 
necessary to put a price on routing slots, I think it would be much more 
appropriate for ISPs to do it directly.  It wouldn't have to be an 
exactly equal charge across-the-board, either: they could do it much as 
airlines have done for checked bags.

>>>   In other words, growth of the DFZ table has to rely on router
>>> enhancements, not on riding Moore's law.
>>>
>>>        
>> I believe that enhancements in router FIB capacity are to some degree
>> dependent on the same forces driving Moore's law.  Obviously keeping Moore's
>> law going (whether in CPUs or in TCAMs) requires hard engineering work, but
>> that's not the point.  The point of Moore's law is that all that hard work
>> results in a periodic doubling of capacity (in this case, FIB routes) for
>> the same price.  For now, that improvement is keeping ahead of the growth
>> rate of networks seeking to multihome.
>>      
> We currently have a very loose economic feedback system in place;
> the hardware needed to effectively multihome via BGP4 is kept expensive
> because it's funding a rapid development cycle which is attempting to
> stay abreast of that curve. If we raise the costs to multihome, fewer
> networks will add to the DFZ routing table, and the pressure on growth
> and technology advancement decreases.   We can raise the cost to
> multihome in 2 ways; one, through the hardware costs (today's model);
> the other is via the one other item required for multihoming--number
> resources (IP addresses and ASNs).  ASNs are explicitly tied to
> multihoming, so those are an easy one to control; raise the price,
> and fewer new entrants show up to tie up slots in the DFZ RIB.
>    

Or they show up as two different announcements originated by both their 
upstreams, because they've switched to using a private ASN.

<snip>

> Would it help if we made route table advertisement registration via the
> registry's IRR mandatory, and charged each network for IRR services
> based on the number of route announcements they make--so, first
> announcement for the supernet/aggregate comes free with the number
> resource, but each additional more specific within the aggregate
> comes at increasing cost to register?  First deaggregation costs
> $100/year additional, second one from the same supernet costs
> $200/year additional, etc.
> That way, even if you have 1,000 prefixes assigned by the RIR, if
> all you announce is the aggregates, there's no net additional cost;
> but if you have a single /20 from the registry, and deaggregate it
> down to /24s, it'll cost you $12,000 extra per year (for the 15
> additional deaggregations you've added within the block).
> That would give  us very strong economic feedback systems for
> ensuring that companies are well-motivated to not deaggregate
> unless it is for very good business reasons (ie, the additional
> revenue they bring in by deaggregating more than offsets the
> additional costs for registering the deaggregates.)
>
> That would also bring about the benefit that we could all build
> very clean explicit route filters based on the contents of the
> routing registry; if you haven't paid to register the route, people
> won't listen to it.
>    

That would work, but only if you can get everyone to participate.  I'm 
not sure you could, and even if you could, you might need to get an 
anti-trust exemption from the federal government to make it legal.

> I suppose it's easier to charge more for IP addresses and
> ASNs to limit growth than it is to charge for route registrations
> because up to now, there's been no charge for route registrations,
> and there'd be a huge hue and cry if we tried to start charging
> for them, probably even more of a fuss than was heard when
> ASNs and IP address registrations were first charged for.
>    

Agreed.  There's also the question of who does the charging.  If it's 
ARIN, what do they do with the money?  Spend it?  Distribute it 
somehow?  Up until now, ARIN has operated on a cost recovery basis (with 
some reserves).  Changing that is fraught with complexity, IMO, and 
should only be done if we get to the point where they can't handle the 
problem directly (by charging customers, and through peering agreements 
and possibly filters on more-specific peer routes).

> Still...I do think it's valuable to realize that fundamentally the
> concerns people have over routing table growth are largely
> economic ones, so it would make sense to put the feedback
> controls squarely into the economic realm, rather than trying
> to figure a way to jury-rig them in via the policy system.
>    

Agreed.  But we're essentially talking about externalities here, which 
are a hard nut to crack.  But not an impossible one: the latest Nobel 
Economics prize was given out for research into various such 
externality/collective action/trajedy-of-the-commons problems, which 
demonstrated that it can be done when done right.

-Scott