[arin-ppml] CGN multiplier was: RE: Input on an article by Geoff Huston
mike at nationwideinc.com
Tue Sep 13 16:08:28 EDT 2011
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.
----- 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
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.
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.
> ----- 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...
> 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...
> On Sep 13, 2011, at 12:48 PM, Michel Py wrote:
>>> Mike Burns wrote:
>>> 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
>> 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:
>> 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.
>> 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:
>> Please contact info at arin.net if you experience any issues.
More information about the ARIN-PPML