Re: [9fans] Do we have a catalog of 9P servers?

[Eris Discordia <eris.discordia@gmail.com>]

> It would be helpful if you can quote exactly the part on which you are
> requesting
> my opinion.

This part:

> It actually does qualify. I believe (though I could be wrong) state
> information and communication buffers are the biggest memory spending for
> network operations.
>
> There _could_ be a trade-off between the transient NAT with its
> processing power toll and the persistent /net-import with its memory
> cost. However, systems like FreeBSD pre-allocate and always keep a number
> of network buffers so the processing power toll for transience almost
> vanishes if the kernel is fine-tuned for its load. By contrast, on a
> large network /net-import strategy could make a "powerful" gateway
> unavoidable because every machine on the network will need a session with
> the gateway even if it only rarely communicates with the outside world,
> unless you implement an uglier-than-NAT client-side dial-on-demand.

And this:

> There is a huge difference. Almost as much difference there is between
> NAT and RSVP.

Where importing /net is compared to RSVP because it uses a persistent
application layer overlay to do a job that is usually done with transient
connections. In case of RSVP there's a motive to do that, in case of NAT,
well, NAT solutions already exist and work pretty well--I've actually been
saying that /net-imported may be useful (!= usable) for some applications I
don't know about but very probably not for NAT.

> What field?

Out of the field := clueless, a soccer player who follows the ball outside
the field

> I am only familiar with Linux implementation.

Which is only a small subset of iptables, right?

> Yes. And that's the NAT that *I* and a million Linux lemming out there
> are familiar with.

Not right. As late as SuSE v9.0 people used the much lighter and less
sophisticated "masquerading" ipmasq which didn't involve iptables
(beginning with v10's iptables became the default). It was the Linux
equivalent of the sort of half-assed "NAT" that importing /net will give
you. Easy but incomplete.

In case of iptables as I pointed out before you have at your disposal a
very sophisticated tool--that you put the tool to uses it is too big for is
mostly your fault. There are many other Linux NAT solutions that do NAT
proper.

> data structures to do its job. I'll leave it up to you to see how much
> memory gets wasted on each connection.

Do you claim you have compared that to doing the same thing on Plan 9? If X
bytes of memory get used up for a task you don't call it a "waste of
memory" unless the task could be done with (X - x) bytes being used up.

> I have no clue what netfilter does, thus I can't answer your question.

Netfilter (or NetFilter) is the larger framework iptables is part of. It
provides every conceivable capability at network layer--everything,
including NAT.

> I thought the original discussion was dedicated to comparing an overhead
> that the general purpose NAT box has with an overhead of a Plan9 box from
> which /net was imported. Since I haven't seen specifics I gave the
> example of a typical Linux NAT built using iptables. That's the area I'm
> familiar with.

It's OK. But you haven't made any comparison of the overhead, yet.

> Define port forwarding. And I really mean it: define. Then I can may be
> offer a bit of  functionality on Plan9 that would be capable of fitting
> your definition.

The traditional definition of NAT is (of course) here:
<http://asg.andrew.cmu.edu/rfc/rfc1631.html>

Here's a definition of port forwarding:
<http://hasenstein.com/linux-ip-nat/diplom/node7.html#SECTION00071300000000000000>

However I give an operational definition which involves what is nowadays
_expected_ from any NAT solution:

A packet arrives at the gateway. Behind the gateway there is a machine
dedicated to serving FTP and another to HTTP, or two machines both
dedicated to serving HTTP that are meant to balance each other's loads. You
want the gateway to decide on how to rewrite the packet so that inbound
traffic to port 21 goes to the FTP machine and inbound traffic to port 80
goes to the HTTP machine, or the inbound traffic in one session goes to one
HTTP machine and the inbound traffic in another session goes to the other
HTTP machine. To add to the hassle you may also want--for security
reasons--to run your server software on other ports than 21 and 80, and the
gateway needs to rewrite the packet so that it reaches the right endpoint
(IP:port, in this case). The process shall be transparent to the internal
and external networks.

How should the two imported /net's on the two machines on the internal
network rewrite packets without becoming NAT re-invented?

--On Saturday, November 15, 2008 12:01 PM -0800 Roman Shaposhnik
<rvs@sun.com> wrote:

> On Nov 15, 2008, at 3:21 AM, Eris Discordia wrote:
>>> Exactly! An idle TCP connection costs you nothing except the state
>>> that
>>
>> Would you mind reading my response, too, and then informing me of
>> your opinion?
>
> It would be helpful if you can quote exactly the part on which you are
> requesting
> my opinion.
>
>>> Not only that, but if you look at the amount of state something like
>>> iptables on Linux needs to keep in order to provide NAT
>>> capabilities it
>>> becomes a complete toss.
>>
>> You seem to be extremely out of the field
>
> What field?
>
>> with respect to what iptables does and how normal NAT is implemented
>> on a *BSD system (which was my example).
>
> I have no knowledge of how NAT is implemented on a *BSD system and thus
> I can not comment. I am only familiar with Linux implementation. Thus if
> that's
> not what you're interested in discussing -- lets stop right now.
>
>> Iptables provides very sophisticated routing and filtering
>> capabilities. It's used as a back-end for stateful inspection,
>> packet rewriting, logging, routing, intrusion detection, and
>> firewalling applications. That's NAT... plus one million other
>> applications.
>
> Yes. And that's the NAT that *I* and a million Linux lemming out there
> are familiar with.
> Arguing that your OS can do that in a simpler way is as useful as trying
> to convince
> Windows users to migrate to Linux 'en masse.
>
>> 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
>
>> that makes imported /net a "complete toss" assuming you can
>> magically make /net provide the same functionality netfilter does.
>
> I have no clue what netfilter does, thus I can't answer your question.
>
> I thought the original discussion was dedicated to comparing an overhead
> that the general
> purpose NAT box has with an overhead of a Plan9 box from which /net was
> imported.
> Since I haven't seen specifics I gave the example of a typical Linux NAT
> built using
> iptables. That's the area I'm familiar with. If you're interested in
> something else -- there
> are others on the list who might have an opinion.
>
>> Also, neither you nor anyone else have addressed the question of
>> port forwarding using an imported /net.
>
> Define port forwarding. And I really mean it: define. Then I can may be
> offer a bit of functionality
> on Plan9 that would be capable of fitting your definition.
>
> Thanks,
> Roman.
>