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

[Tom Vest]

Hi Mike, 

Much better, thanks.

I would then suggest an additional addendum, to wit that (date X) cannot be usefully expressed as an ordinal value, because to do so would require a presumption of continuity of function/utility over time, -- which in this case would imply a continuity in terms of what unique, interoperable, public IP addresses do and what non-unique* (including "not transparently unique," i.e., translated and/or encapsulated) addresses do, or what they're good for -- which in fact  does not exist. If you were to acknowledge that hidden term -- e.g., as "u" in Xu -- then the basic question becomes: "As Y goes from more unique* to potentially much less unique* over time, how quickly does the overall utility/predictability/functionality of the Internet go from (whatever level we enjoy today) to bad to worse to zero?

I don't claim to know the answer, or even how one would go about calculating one, but then I believe that the value is "u" is very close to being the inverse of Y (at best), so I don't require an actual solution in order to be persuaded that CGNs wouldn't alter the results -- not in any direction that we might wish for, anyway.

Regards, 

TV

On Sep 13, 2011, at 3:12 PM, Mike Burns wrote:

> 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.
>