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

[Mike Burns]

Hi Tom,

In Geoff's article, the concern about CGN brokenness is not really 
addressed, and I wanted to better understand how much time could conceivably 
be bought through its deployment.

Here is the way you might have worded it:

If CGN brokenness prevents its being profitably deployed, then IPv4 exhaust 
occurs at date X.

If CGN brokenness does not prevent its being profitably deployed, IPv4 
exhaust occurs at date X + Y.

I want to solve for Y.

Better?

Regards,
Mike

----- Original Message ----- 
From: "Tom Vest" <tvest at eyeconomics.com>
To: "Mike Burns" <mike at nationwideinc.com>
Cc: <arin-ppml at arin.net>; "Michel Py" <michel at arneill-py.sacramento.ca.us>
Sent: Tuesday, September 13, 2011 2:58 PM
Subject: Re: [arin-ppml] CGN multiplier was: RE: Input on an article by 
Geoff Huston


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.