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

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

> Yet you're still contending the following:
>
>> What I pointed out to Anant Narayanan was that his proposed _new_
>> capability which involved _packet analysis_ would _have to_ operate on
>> network layer data units, ergo, NAT again.
>>
>> Packet analysis == Network layer operations ~= NAT
>
> That's not correct.  NAT is network address translation.  It
> implicitly requires that IP headers be rewritten, and when
> doing port translation as well, the TCP header must also
> be rewritten.  It is a technique that allows machines with
> non-routable addresses to talk outside the local network.
> Hence the need for translating addresses.  Importing /net
> doesn't involve any translation of addresses.  In fact,
> as Erik pointed out, the machine on the local network
> might not even be talking TCP/IP at all!  The "packet
> analysis" that appears to have arisen from a discussion
> of load balancing is a red herring.  NAT is not a technique
> for load balancing.  RFC1631 is where NAT is described.
> If you're not rewriting the IP header, then it's not NAT,
> it's not approximately NAT, it has no similarity to NAT
> at all.

1. Thanks for helping me revise previous learning.

2. I read RFC 1631 for the sole purpose of supporting a few assertions I
made on this thread. I also did reference it on this same thread. Why not
read previous postings before acting as if your intended audience
understood nothing?

3. You are (deliberately?) taking this out of context. I said, and continue
to say, that NAT and a number of other applications, nearly all implemented
in the Linux netfilter and *BSD ipfw/pf/dummynet/natd, depend on operating
on network layer entities, i.e. packets. And that it would be a violation
of layered design to handle this task at application layer.

4. There are no red herrings here. It's a change of course and I didn't
initiate it. Anant Narayanan pointed out that Plan 9's native application
layer protocol, 9P, did not forbid implementing whatever network layer
hijinks one felt like. I responded by merely saying that would be exactly
the sort of "ugly" software Plan 9 wants to avoid. To summarize: Plan 9's
network-transparent environment, or _any_ network-transparent for that
matter, relies on assuming a measure of homogeneity in the network. IP was
conceived with exactly the opposite premise, hence the name
_inter_networking/_inter_net. So when it comes to adding a feature of IP,
e.g. NAT, to Plan 9 there will be no shortage of trouble. There's all the
trouble operating system X has to go through, and then some. Of course,
there may be nearly-solutions to the problem that preserve the original
foundation the network-transparent environment was built upon but it will
never be quite the same. One of Murphy's "bylaws" forbids for a specific
functionality to become available without less than a specific amount of
toil, pre-determined by the problem at hand.

5. You do understand the difference between ~= and ==, don't you? At least,
you have to suspect there _must_ be a difference. NAT relies totally on
packet "analysis," i.e. analyzing of packets (== network layer data units),
which is why it is nearly equivalent but not necessarily equal to packet
analysis. This is a strictly true statement.

--------------------------------------------------------------------------------

> It is true that I wasn't particularly pedantic with my
> terms, but if we're going to be pedantic, we might as
> well get it right.  [...]

1. Thanks again. The definitions do help a lot.

2. But you are so obviously sidestepping the meaning of the paragraph you
have quoted. In particular, you have quoted is aside from the paragraph
above with reference to which my comment could be qualified. The remark on
the meaning of packets was _certainly_ not pedantry on my part--it amounted
to turning your attention to a certain fact; namely, that "packet analysis"
is network layer hijinks.

--------------------------------------------------------------------------------

> Of course TCP/IP has layers.  Indeed layering can be seen
> in most good designs.  It is especially natural in network
> stacks because of the encapsulation of messages.  For that
> matter, I doubt any student of mine has ever gotten away
> without hearing me say something about the value of layering;
> I even mentioned it in my book.

So what? It wasn't I who wrote:

> The OSI protocols are  largely forgotten for a reason.
> It's not bad as a conceptual model, but as soon as you
> try to force any predefined definitions of layers on real
> networks, you soon lose your grip on sanity.

My comment wasn't at all about forcing any predefined definitions on
TCP/IP. It was about the reality of TCP/IP, in which "packets" are mainly
network layer entities no matter what other significations a "packet" may
have to the academically inclined. It was also about that most good IP
software pays attention to a certain de facto layering, which I referred to
as "rather clearly-defined boundaries." A perfectly fine name.

--------------------------------------------------------------------------------

> And it's true that we sometimes are a bit loose with the
> terms and allow ourselves to use OSI terminology when
> talking about TCP/IP.  However, you can't take that usage
> too literally, and certainly can't base an argument on
> that usage.  The layers in the two just don't line up
> exactly.  The division of responsibilities among the layers
> is different between TCP/IP and OSI.  For that matter,
> they don't even have the same number of layers.

I happen to know that. I also happen to have read Andrew Tanenbaum's
"Computer Networks"--and always have a copy nearby for reference--which is
the usual canon all over the planet for non-CS/CE majors, enthusiasts, and
the like (your book isn't). That book happens to feature a pedagogic
instrument dubbed the "hyprid reference model" which is used _not only_ to
introduce _both_ OSI and TCP/IP to new learners but also to teach them good
design by enlightening them as to what in general is expected from each
layer--and why, under current circumstances, it is more or less good to
have like 5 layers with such-and-such functions and neither 2 nor 10.

--------------------------------------------------------------------------------

> The luxury I have in this situation is that because you're
> not my student, I don't have any obligation to make sure
> you've understood it all.  But if you were my student, my
> first recommendation would be to read *and understand*
> the RFCs, and the best way to know that you've understood
> them is to write some network protocol code.  If you would
> like to have help understanding something, I, and I'm sure
> others here, would be happy to answer if you present your
> questions as questions.  I don't plan to answer any more
> incorrect assertions.

I was about to use seriously foul language in response to this but then I
thought to myself, "why bother." Heed this, Mr. Professor: you _always_
have the luxury of keeping silent, but when you do speak please reserve the
right for your audience to respond, even if you deem them dim. It's pretty
philosophical, nah?

Also, thank you for the offering of help. I may rage quite often but I
appreciate, value, and always remember any helpful act on part of others.

--On Thursday, November 20, 2008 5:34 PM +0000 "Brian L. Stuart"
<blstuart@bellsouth.net> wrote:

> This is why I've been trying to stay out of it.
>
>> > So how to think about it?  First, it's *not* NAT,  because
>> > there's no address translation going on.
>>
>> I know. I understood this after the discussions of the past few days.
>
> Yet you're still contending the following:
>
>> What I pointed out to Anant Narayanan was that his proposed _new_
>> capability which involved _packet analysis_ would _have to_ operate on
>> network layer data units, ergo, NAT again.
>>
>> Packet analysis == Network layer operations ~= NAT
>
> That's not correct.  NAT is network address translation.  It
> implicitly requires that IP headers be rewritten, and when
> doing port translation as well, the TCP header must also
> be rewritten.  It is a technique that allows machines with
> non-routable addresses to talk outside the local network.
> Hence the need for translating addresses.  Importing /net
> doesn't involve any translation of addresses.  In fact,
> as Erik pointed out, the machine on the local network
> might not even be talking TCP/IP at all!  The "packet
> analysis" that appears to have arisen from a discussion
> of load balancing is a red herring.  NAT is not a technique
> for load balancing.  RFC1631 is where NAT is described.
> If you're not rewriting the IP header, then it's not NAT,
> it's not approximately NAT, it has no similarity to NAT
> at all.
>
>> Because packet is the name for specific data units, entities at network
>> layer. Above it you have datagrams (UDP) or streams (TCP), below it you
>> have frames.
>
> It is true that I wasn't particularly pedantic with my
> terms, but if we're going to be pedantic, we might as
> well get it right.  RFC791 defines IP and the proper terminology
> associated with it.  Comer does an excellent job distilling
> the RFCs and phrases it this way: "The internet calls its
> basic transfer unit an _Internet datagram_, sometimes referred
> to as an _IP datagram_ or merely a _datagram_."  You can find
> the definition of UDP in RFC768.  Again Comer's phrasing:
> "Each UDP message is called a _user datagram_."  Finally,
> read RFC793 for the details on TCP.  Comer's phrasing
> is "The unit of transfer between the TCP software on two
> machines is called a _segment_."  Comer's definition of
> a packet is also instructive:
>
> "The unit of data sent across a packet switching network.
> The term is used loosely.  While some TCP/IP literature
> uses it to refer specifically to data sent across a
> physical network, other literature views an entire TCP/IP
> internet as a packet switching network and describes IP
> datagrams as packets."
>
> (BTW the reason I've chosen to use Comer's phrasing is that
> his book arose as a result of an IETF meeting where even
> some of the attendees didn't understand how it all worked--at
> least that's the story I heard when I was at Purdue.)
>
>> > The OSI protocols are  largely forgotten for a reason.
>> > It's not bad as a conceptual model, but as soon as you
>> > try to force any predefined definitions of layers on real
>> > networks, you soon lose your grip on sanity.
>>
>> There are rather clearly-defined boundaries in TCP/IP, too. Without the
>> layered design approach one would lose one's sanity, not with it.
>
> Of course TCP/IP has layers.  Indeed layering can be seen
> in most good designs.  It is especially natural in network
> stacks because of the encapsulation of messages.  For that
> matter, I doubt any student of mine has ever gotten away
> without hearing me say something about the value of layering;
> I even mentioned it in my book.
>
> And it's true that we sometimes are a bit loose with the
> terms and allow ourselves to use OSI terminology when
> talking about TCP/IP.  However, you can't take that usage
> too literally, and certainly can't base an argument on
> that usage.  The layers in the two just don't line up
> exactly.  The division of responsibilities among the layers
> is different between TCP/IP and OSI.  For that matter,
> they don't even have the same number of layers.
>
> The luxury I have in this situation is that because you're
> not my student, I don't have any obligation to make sure
> you've understood it all.  But if you were my student, my
> first recommendation would be to read *and understand*
> the RFCs, and the best way to know that you've understood
> them is to write some network protocol code.  If you would
> like to have help understanding something, I, and I'm sure
> others here, would be happy to answer if you present your
> questions as questions.  I don't plan to answer any more
> incorrect assertions.
>
> BLS
>
>