[arin-ppml] CGN multiplier was: RE: Input on an article by Geoff Huston

[Tom Vest]

Is it possible for one to logically/coherently "leaves aside" concerns about the brokenness of CGNs while hanging onto concerns about the upper bounds of CGN scalability?

If so, then I guess there's no reason to think that a 10:1 or 100:1 ratio of ISPs/routing domains per IP address would be infeasible...

http://www.rferl.org/content/kazakh_bloggers_say_blockage_of_blog_website_for_political_reasons/24264250.html

In fact, since an entire national economy can demonstrably fit under a single IP address, perhaps a 10:1 or greater address multiplexing rate at the national level would also be possible...

http://en.wikipedia.org/wiki/User:82.148.97.69/header

TV

On Sep 13, 2011, at 12:48 PM, Michel Py wrote:

>> Mike Burns wrote:
>> http://www.circleid.com/posts/ipv6_transitional_uncertainties/
>> In this article Geoff posits the possibility of moving content
>> inside walled gardens using Content Distribution Networks and
>> extensive use of ALGs as IPv4 conservation methods.
> 
> There is nothing new about these concepts, though.
> 
> 
>> Leaving aside the idea of brokenness brought about by CGN
>> deployment, does anybody have any data which answers the question
>> of what the effective adress multiplier is for CGN deployment?
>> My impression is that a 10:1 ratio is quite feasible, (assuming
>> you want to punish your customers with degraded service, yada yada).
> 
> Even 100:1 or more is quite feasible, see below.
>  
> 
>> I guess I am asking how many ports the average user
>> (not server) wants to keep open and available
> 
> This does not matter for most users: they don't manually open static ports in their home gateway NAT box bur rather rely on some kind of rendezvous mechanism that opens the connection egress. For the geeks who want to map a static bittorent or a game port, give each geek 10 ports and you still have 6400 hosts behind one natted IP.
> 
> As of dynamically open ports (egress) there is a false common assumption that there could be only 64000 connections per IP address in the NAT pool. In fact, the limit is 64000 connections per destination IP times the size of the pool, so in theory you could have a million hosts behind one IP and it would still work as long as they access different destinations at the same time. The NAT table entry is often a quintuplet: Protocol, Inside global, Inside local, Outside local, Outside global.
> 
> Remember that the server being accessed also has this 64000 limit, which has a long time ago moved content providers to load-balance the load by having servers with multiple IP addresses and a DNS-based load-balancing that randomizes the IP handed to the requesting client.
> 
> In practice, a good CGN will have some understanding of the load-balancing scheme used by popular destinations, and/or provide some caching/load balancing of its own inside the NAT boundary. One of the annoyances of CGNs is that each IP address in the GCN pool may be considered a unique host and therefore not being load-balanced correctly.
> 
> 
> 
>> or whether there are processing or logging limits which serve to
>> restrict that multiplier? Are there other scaling limits?
> 
> One of the scaling limits is the size of the NAT pool. A small NAT pool (of one IP) will encounter limitations earlier than a larger one. If n is the practical number of hosts behind a one-IP pool, the practical number behind a 128-IP pool is greater than n*128, simply because a greater number of hosts brings more diversity and therefore helps to alleviate the #1 issue with CGNs: everyone talking to the same server at the same time.
> 
> There obviously are CPU, disk I/O and bandwidth limits; I expect this part to be the limiting factor, not the number of ports. A given GCN appliance can handle only that many connections per second. 
> 
> However, just looking at the strictly PC-based box, there have been recent advances based on using graphic coprocessors that could lead to monstrous PC-based NAT appliances. One of these advances is Packetshader:
> http://www.ndsl.kaist.edu/~kyoungsoo/papers/2010-lanman-100Gbps.pdf
> http://shader.kaist.edu/packetshader/
> In many cases, the NAT process could be offloaded to the GPUs as well. 
> 
> 
>> Trends towards higher per-user port use?
> 
> In theory, yes. In practice, be more specific: as explained above, the per-user port count is not really an issue.
> 
> 
> Michel.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.