Re: [9fans] on TCP vs IL

Re: [9fans] on TCP vs IL

[Russ Cox]

> EBCDIC.  But since "byte" does not logically always imply
> 8 bits, careful specifications such as the IETF Internet RFPs
> tend to use the term "octet" when exactly 8 bits are meant.

grep octet /sys/games/lib/fortunes

Re: [9fans] on TCP vs IL

[Douglas A. Gwyn]

"Thomas Bushnell, BSG" wrote:
> ...  Though, as I was once taught, a "byte"
> is officially the minimal addressible unit on an architecture...

No, although within C the term "byte" is practically synonymous
with "minimum unit addresable by standard language constructs".

Generally, a byte is a collection of bits within a machine word
that are treated as representing a complete field.  Some systems
had variable-sized byte instructions, some had fixed-size byte
operations, some had no direct support for bytes (although one
could use word-oriented instructions to manipulate artificially
defined byte fields).

> But these days the philistines have forgotten about fine old 36-bit
> wordsize machines and the like, and have just synonymized "byte" and
> the neologism "octet".

The 8-bit byte became common with 16-bit minicomputers and the
IBM System/360.  Consequently when storage devices for those
platforms had their capacity specified in "bytes", everyone
understood that to mean 8-bit bytes.  This carried over into
other processors, especially since the 8-bit byte sufficed for
the most common character encodings of the time, ASCII and
EBCDIC.  But since "byte" does not logically always imply
8 bits, careful specifications such as the IETF Internet RFPs
tend to use the term "octet" when exactly 8 bits are meant.

Re: [9fans] on TCP vs IL

[Thomas Bushnell, BSG]

"Douglas A. Gwyn" <DAGwyn@null.net> writes:

> "Thomas Bushnell, BSG" wrote:
> > dhog@plan9.bell-labs.com (David Gordon Hogan) writes:
> > > Do you really want each byte to have its own IP address?
> > Yes, frankly, I would love that.  It might be too expensive, but if
> > not, it would truly be wonderful to have.
>
> Personally I wish each *bit* in the universe had a unique address.

Heh, yeah, that would be nice.  Though, as I was once taught, a "byte"
is officially the minimal addressible unit on an architecture... if
every bit is separately addressed, then hey, we've just switched to
one-bit bytes, right?

But these days the philistines have forgotten about fine old 36-bit
wordsize machines and the like, and have just synonymized "byte" and
the neologism "octet".

Sic transit gloria computorum.

Re: [9fans] on TCP vs IL

[Boyd Roberts]

> ...Whether IL support actually predated TCP support is a different matter...

IIRC philw did the IP stack before IL was developed.

Re: [9fans] on TCP vs IL

[Douglas A. Gwyn]

"Thomas Bushnell, BSG" wrote:
> dhog@plan9.bell-labs.com (David Gordon Hogan) writes:
> > Do you really want each byte to have its own IP address?
> Yes, frankly, I would love that.  It might be too expensive, but if
> not, it would truly be wonderful to have.

Personally I wish each *bit* in the universe had a unique address.

Re: [9fans] on TCP vs IL

[Steve Kilbane]

One justification for the presence of IL is that it's a simpler
protocol to implement - quicker time to get your system off the
ground, if you're starting everything from scratch. Whether IL
support actually predated TCP support is a different matter...

steve

Re: [9fans] on TCP vs IL

[Thomas Bushnell, BSG]

dhog@plan9.bell-labs.com (David Gordon Hogan) writes:

> > Not to
> > mention gorgeously huge address-space, which makes for consideration of
> > interesting mappings of persistant datastore into the network address space.
>
> You _could_ do that.  But some of us would Persistantly Object.
>
> Do you really want each byte to have its own IP address?

Yes, frankly, I would love that.  It might be too expensive, but if
not, it would truly be wonderful to have.

Re: [9fans] on TCP vs IL

[Scott Schwartz]

| Unfortuantely, since PSU's Computer Science department has seen fit to
| put the 9fans archives on an SSL protected web server that I can't talk
| to using the only computer I have net access on right now, I can't look
| up the exact citation.  :-(

Coincidentally, I keep a snapshot of the archives on my own system.
Go to http://www.cse.psu.edu/~schwartz/software.html and follow the link
labeled "older 9fans archives".

Re: [9fans] on TCP vs IL

[Dan Cross]

In article <20011121192737.D5817199E7@mail.cse.psu.edu> you write:
>> These decisions are all based on the personal taste of the technical
>> people doing the work.  "smoky back rooms" are not our style.
>
>Some of us happen to like smoky night clubs, but we don't
>do any of our work there...

Are those really smokey night clubs, or are they fog filled clubs?
I'm not sure the people in the latter are likely to know the difference.
And some of us do do work in smoke filled bars (which are different
again).

	- Dan C.

Re: [9fans] on TCP vs IL

[Dan Cross]

In article <20011121010744.C4DBB19A46@mail.cse.psu.edu> you write:
>TCP is usable over long and short networks.  IL is usable only over
>short networks.  If I had to pick just one, guess which one I'd use?
>Wouldn't you rather use the general solution than the specialized one?

A chainsaw will cut both butter and trees.  A butter knife will cut
both as well, but will be very much less efficient cutting down a
tree.

If I had to choose only one....  I'd probably pick the chainsaw so as
to also be able to terrorize those who ask such silly rhetorical
questions.  :-)

The analogy is strained, perhaps, but apropos.  il seems like the
buffer knife.  It's great for cutting butter.  TCP is like the
chainsaw, it's great for cutting down trees (and terrorizing half-naked
coeds in B flicks), but makes a huge mess when buttering your toast.
What ever happened to the right tool for the job?  Is il just too much
of a maintenance hassle so as to be not worth it for local area networks?

(And no, I've never terrorized anyone with a chainsaw, nor would I.  :-)

>TCP is probably only slightly less efficient on the wire than IL.

I've read differently; see below.

>TCP has all that baggage, yes, but it won't get used on local
>ethernets unless the net is in big trouble.

Some of that baggage gets used no matter what (all the window size
negotiation stuff, for instance).

>I have no numbers to back up my ``only slightly less efficient''
>assertion.  But then, you haven't presented any numbers either.

Of course I didn't post any numbers; I was asking a question.  If I'd
already known the answer, why would I have asked?  :-)  But since you
brought it up....

Once, I sat down on a Saturday (it was raining) and I read the entire
9fans archives.  Contained there in was a detailing of someone's
experience running Plan 9 over a 10Mbps Ethernet.  When using IL, they
used up something like 30% of the available bandwidth to move data at
some rate.  When they switched to TCP, bandwidth utilization jumped up
to something like 80%.  Granted, that's on a much slower form of
Ethernet than what's commonly used today, and the TCP implementation
has been much improved, but one gets the impression that IL requires
rather less overhead than TCP.

Unfortuantely, since PSU's Computer Science department has seen fit to
put the 9fans archives on an SSL protected web server that I can't talk
to using the only computer I have net access on right now, I can't look
up the exact citation.  :-(

>Local networks are fast enough that it just doesn't matter.

Fair enough.

	- Dan C.

Re: [9fans] on TCP vs IL

[David Gordon Hogan]

> These decisions are all based on the personal taste of the technical
> people doing the work.  "smoky back rooms" are not our style.

Some of us happen to like smoky night clubs, but we don't
do any of our work there...

[9fans] on TCP vs IL

[George Michaelson]

To be fair, I suspect many who wish to complain of TCP actually
are complaining of sockets.

If you remove the I/O abstraction from consideration, I personally think
you're left with a transport layer which is less like an egregious
collection of hacks and tweaks, than a reflection of the history of
knowledge about large dynamic networks. For IPv4, if people had known a
bit more about what was coming, I think they too would have simplified
rather than accreted. Certainly what little I hear at IETF suggests that.

Maybe Plan 9 can leapfrog into IPv6 and get a clean stack on a protocol
which has efficient header layout, embedded IPSEC, and some rather
interesting re-addressing and host/self-discovery features. Not to
mention gorgeously huge address-space, which makes for consideration of
interesting mappings of persistant datastore into the network address space.

In designing IL over IP, I suspect the network transport people face the
same problems TCP does. To argue successfully for a *radically*
different approach demands a bit of rigour. What is the core abstraction in
IL which makes it so compelling? Whats its addressing schema in the packets.
What does it offer routers in terms of knowledge of end-to-end flows, or
in proving for the Clark end-to-end model irrespective of the attempts to
make routers over-smart?

The roadside is littered with very interesting transports. I speak not
of OSI, but perhaps ST-II or RSVP comes to mind. ST-II was not designed
by dumbheads, (I think it behoves us to respect the smarts of IBM
research, even if we don't agree with their corporate outcomes) Likewise
multicast has to be faced as a very compelling story in distributed
data.

There are reasons we don't all run over Chaosnet/XNS or dare I say it
Appletalk, or DECnet and they aren't just to do with economics or
political computing history. These protocols didn't provide enough
operational flexibility to scale worldwide or off-planet. And to bring
OSI back into the equation, Its pretty clear the stack as a whole was a
write-off for all but academic theorizing, but some core components such
as IS-IS are really quite respectably useful.

cheers
	-George

[9fans] on TCP vs IL

[Eric Grosse]

yet another perspective from Bell Labs experience:

For the reasons Presotto mentioned regarding loss of back-to-back packets,
when at home and connecting to our IL-only fileserver, I use TCP to import
/ from a cpu server, thus using IL just across the machine room.  The local
TCP performance is good enough that I won't care if IL goes away someday.
On the other hand, there's no immediate push to get rid of it;  we support
IL in our new NAT code.

We have an initial implementation of IPv6 in Plan 9, thanks mainly to the
efforts of Lakshman Yagati.  It doesn't do IPsec yet---we prefer the easier
network administration of SSL/TLS, thank you---but does come with v4/v6
NAPT-PT, hence is viable to adopt even in otherwise IPv4-only networks.

These decisions are all based on the personal taste of the technical
people doing the work.  "smoky back rooms" are not our style.

Eric

Re: [9fans] on TCP vs IL

[George Michaelson]

> It's not radically different.  Think TCP without worrying about
> congestion in any way, shape, or form.  For RPC over an ethernet
> that isn't overused, the claim is that these are unnecessary
> because RPCs are inherently flow controlled.

That reads like a claim which is worth betting against in deployment.

Like, deploy Plan9 in a dealing room with millions of packets and suddenly
maybe the 'ethernet which isn't overused' is not so clear. Or, have to share
media with live 40Mbit HDTV steams.

Saying RPC are inherently flow controlled also implies inherently single-
threaded RPC models, no parallelism in the procedure call layer for a given
binding sounds like an awfully big assumption. Sure, that way lies madness
but multiplexing does happen.

re-assuring its essentially a TCPlike protocol. It would be interesting to
see if it had the same end-to-end performance with less cost for a reliable
transport.

cheers
	-George

(thanks for the docref btw)

--
George Michaelson       |  APNIC
Email: ggm@apnic.net    |  PO Box 2131 Milton QLD 4064
Phone: +61 7 3367 0490  |  Australia
  Fax: +61 7 3367 0482  |  http://www.apnic.net

Re: [9fans] on TCP vs IL

[Russ Cox]

ggm@apnic.net:
> In designing IL over IP, I suspect the network transport people face the
> same problems TCP does. To argue successfully for a *radically*
> different approach demands a bit of rigour. What is the core abstraction in
> IL which makes it so compelling? Whats its addressing schema in the packets.
> What does it offer routers in terms of knowledge of end-to-end flows, or
> in proving for the Clark end-to-end model irrespective of the attempts to
> make routers over-smart?

You could read the paper to answer your fancy questions.
hget http://plan9.bell-labs.com/sys/doc/il/il.pdf | page -w

It's not radically different.  Think TCP without worrying about
congestion in any way, shape, or form.  For RPC over an ethernet
that isn't overused, the claim is that these are unnecessary
because RPCs are inherently flow controlled.

cross@math.psu.edu:
> Yes, but isn't il a lot more efficient on the wire than TCP,
> particularly over mostly reliable local area networks?  TCP has a lot
> of baggage to deal with high loss, high latency, networks with moderate
> bandwidth at the expense of higher bandwidth, lower latency, low loss
> networks; in other words, it doesn't cope well with short networks.  :-)

TCP is usable over long and short networks.  IL is usable only over
short networks.  If I had to pick just one, guess which one I'd use?
Wouldn't you rather use the general solution than the specialized one?

TCP is probably only slightly less efficient on the wire than IL.
TCP has all that baggage, yes, but it won't get used on local
ethernets unless the net is in big trouble.  I have no numbers
to back up my ``only slightly less efficient'' assertion.  But then,
you haven't presented any numbers either.  Local networks are
fast enough that it just doesn't matter.

Russ

Re: [9fans] on TCP vs IL

[George Michaelson]

> >Not to
> >mention gorgeously huge address-space, which makes for consideration of
> >interesting mappings of persistant datastore into the network address space.
>
> You _could_ do that.  But some of us would Persistantly Object.
>
> Do you really want each byte to have its own IP address?
>

Um.. why not? I mean, in the reductionist world of theoretical wanking
of which I am an exemplar, isn't this precicely what persistant distributed
programming is maybe about?

There was a school of thought around this stuff from Glasgow a few years
back doing Persistant Pascal. I seem to recall 128-bit disk addressing being
on the table. This was an analogue, a corrollary of the 128bit VLIW model
of instruction wasn't it? Its not a long jump from disk address to network
address if you consider the namespaces ideas is it?

cheers
	-George
--
George Michaelson       |  APNIC
Email: ggm@apnic.net    |  PO Box 2131 Milton QLD 4064
Phone: +61 7 3367 0490  |  Australia
  Fax: +61 7 3367 0482  |  http://www.apnic.net

Re: [9fans] on TCP vs IL

[David Gordon Hogan]

> Not to
> mention gorgeously huge address-space, which makes for consideration of
> interesting mappings of persistant datastore into the network address space.

You _could_ do that.  But some of us would Persistantly Object.

Do you really want each byte to have its own IP address?