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

Tue Sep 13 16:08:28 EDT 2011

Hi Tom,

Sometimes we assign values to these unknowns to see what how those values 
affect the results.
In your case, let us assume that u approaches 1 asymptotically, as 
workarounds for shared addresses are refined over time.
But that's another way of saying "leaving aside brokenness", which it 
appears you cannot do.

I understand that you do not agree with Geoff that CGN deployment will have 
some effect on IPv4 exhaust date(s).

Thanks to Michel for the information he provided.

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 3:49 PM
Subject: Re: [arin-ppml] CGN multiplier was: RE: Input on an article by 
Geoff Huston

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