From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Sun, 16 Nov 2008 07:24:24 +0000 From: Eris Discordia To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [9fans] Do we have a catalog of 9P servers? Topicbox-Message-UUID: 45f26080-ead4-11e9-9d60-3106f5b1d025 > I don't quite follow. If by resources you mean process related resources > than I would agree. My very first comment didn't have anything to do > with process related resources. And for the TCP related resources I > maintain that the amount of overhead in Plan9's case is definitely > comparable to a Linux's case. The key phrase is: transience versus persistence. From the very beginning NAT could be implemented using persistent connections but it wasn't because it had a problem at hand that would not yield to that solution. In fact, there exist methods of "NATting" with exactly that approach--namely VPN, PPTP, L2TP, and any "tunneling" application like GNU's httptunnel--but for obvious reasons they haven't supplanted NAT. According to the RFC that describes it NAT was adopted primarily to address the "temporary" scarcity of IP addresses (before IPv6 took on, and it didn't, how many IPv6 connections do you make outside of your organization in a day). It was expected that large organizations without Class A ranges would soon want one--GM had one, why not them?--and nearly all Class A's were already allocated. NAT was invented so that late-coming organizations could share _one_ class A range (192.x.x.x and any one of the others). Every sensible NAT solution must be implemented with that in mind--not that existing ones have been. Even imagining persistent connections from an entire Class A network makes one shudder. Needless to say, the wreak of havoc occurs _long_ before over 16 million hosts need persistent connections. The costliness of this type of persistence must be understood with regard to the fact that most hosts on most organizations' internal networks rarely, but not never, access the outside world and when they do they only need some traffic routed to and fro not an entire copy of protocol stack reserved for them in the gateway's memory. The /net-import doesn't scale (well or at all?) because a side-effect of generality is lack of granularity. --On Saturday, November 15, 2008 9:47 PM -0800 Roman Shaposhnik wrote: > On Nov 15, 2008, at 2:13 PM, Micah Stetson wrote: >>>> I'm unclear as to what "amount of state" iptables needs to keep >>> >>> After you do something like: >>> # iptables -t nat -A POSTROUTING -p TCP -j MASQUERADE >>> the Linux kernel module called nf_conntrack starts allocating >>> data structures to do its job. I'll leave it up to you to see how >>> much >>> memory gets wasted on each connection. Here's a hint, >>> though: /proc/net/nf_conntrack >> >> I don't think Plan 9 is keeping any less state, is it? > > Not really, no. My point was that the amount of state in a typical > Linux-based NAT box was quite comparable and thus couldn't > be used to bash Plan9's approach as being visibly less efficient > as far as TCP overhead goes. > >> Plan 9 does need one extra connection per client and a process (or >> two?) to do the export. > > Yes it does need one extra connection for /net to be imported. Depending > on the setup that extra connection could be reduced to one per host > importing the /net. I specifically didn't address the point of extra > processes running on the GW simply because I agree -- there's a price > there that Linux doesn't pay (although as I've learned from Bruce > Inferno has reduced the price for running identical processes quite > significantly by implementing silent page sharing). > >> I think Eris is saying that this makes Plan >> 9's resource requirements grow with the number of hosts behind the >> gateway -- not just with the number of connections through it like >> Linux. > > I don't quite follow. If by resources you mean process related resources > than I would agree. My very first comment didn't have anything to do > with process related resources. And for the TCP related resources I > maintain that the amount of overhead in Plan9's case is definitely > comparable to a Linux's case. > > Thanks, > Roman. >