🚀 go-pugleaf

In article <11240001@hpfclp.HP.COM>,
diamant@hpfclp.HP.COM (John Diamant) writes:
> Yes, but why have they moved to implementing OSI protocols?  Is
> it because these protocols are significantly better than TCP/IP and
> ARPA standards, or is it simply European market pressure?  If market
> pressure, why is that happening?  Again, is it because the protocols
> are better, or just because they weren't developed by the Americans?

I have a few uninformed opinions...

First, OSI isn't new, I don't have precise details of the dates of either
TCP or OSI, but I wouldn't be surprised to learn that OSI (the concept,
and model) predates TCP (nb: I said TCP, not IP).

When comparing TCP/IP and OSI you have to remember to look at them in
all their aspects.  If you're simply wanting to move bytes, and don't
care much about anything else, then probably both will work.

But there's one major feature that TCP lacks, and that's any rational
manner of coping with networks where you actually have to pay for
usage.  I'm not concerned with the mechanics of accounting (billing
procedures, etc), or of packet (or byte, and time) counting, I have
no doubt that that could be added to IP without any great degree of
difficulty.  The problem is TCP's overall philosophy, which has been
praised again and again recently on this list.  That is, that the
levels below TCP should not retransmit damaged packets, TCP should
do that.

Now clearly accounting belongs at the IP level (or perhaps even below it,
if you can't see why, then just contemplate alternative protocols above
IP for a while).  Now if TCP is retransmitting when packets are damaged,
retransmitted packets get charged twice.  I don't know about you, but I
really don't think I'd be all that happy paying to use a network service
that was permitted to discard packets at will, yet charge me for sending
them.  Even if the network service didn't do this, I wouldn't be too
thrilled at having packets transmitted through the network, correctly
routed to the local LAN at the destination site, and then lost there, for
me to have to retransmit them, and pay again (which the network would
clearly have to do, or I would simply claim that all my packets after
the first were retransmissions).

Of course, none of this matters if you're working in an environment
where you don't pay for each packet that you send, or each second
that you're connected, so its easy to see how the Internet Protocols
evolved like they did, but that simply doesn't work well in other
environments, and apart from local LAN's, the Internet environment
just doesn't exist much in other parts of the world (BITNET and its
associates are similar).

Its also true that when you're actually being charged for each byte
you want to minimise the number you send, so you want packet headers
of minimal size (down at least to the level where you're being changed,
below that matters less).  This is actually less important than it
might seem, as the resources used by the network are likely to end up
being much the same whether you have a connection oriented network link
(small packets, but state information along the way) or connectionless
(larger packets, but less to remember in subnet nodes).  It might also
be true that what appears on the outside to be one is actually the other
underneath.  In any case, the charge per byte can be adjusted to take this
into account, a net that gave a connectionless interface, with larger
headers, could just charge a little less for each byte, than a connection
oriented net charged, overall things would probably even out.

Given a basically totally reliable network level, which is needed
for charging, the functions of the transport level can be altered
quite a lot, it no longer need do much error checking for most
uses (the most critical might request additional checksums, but that's
probably going to be rare), making for a much simpler transport
layer than TCP (of coursem the network layer is much more complex
than IP).  NB: it IS NOT necessary for the transport level to do all
the checking/retransmit again, any more than it is necessary for
applications in the TCP/IP world to do it, once you have reached
a level that you define to be "reliable" users of that level are
entitled to assume reliablity, just as STMP assumes that TCP will either
deliver data accurately, or break the connection and signal an
error to SMTP, ISO transport is entitled to assume that CONS
(connection oriented network) will deliver the data reliably, or
break the connection and signal an error.

I doubt that there's really much anti-American bias in this,
after all, ISO does include all the unreliable protocols as
well, largely because the American's pushed for them to be included.
Those protocols are very similar to TCP/IP, though they have the
benefit of hindsight, a lot of the minor problems with TCP/IP
can be corrected (eg: its clear (now) that 32 bits simply isn't
enough for an address intended to encompass the entire world).

There are a whole bunch of other charging related issues that TCP/IP
has trouble dealing with, including how to accurately charge the
right person for data transferred, which means that charging for an
FTP fetch of a file needs to be sent to the requestor, which means
that (somehow) the charging needs to look inside the IP packets
and discover their true nature.  That might not be too difficult,
though its certainly not clean, but can you say the same about a
TFTP transfer?

The only way arund this problem would seem to be avoiding charging.
While the US DoD, DoE, NSF, etc continue to be willing to fund
networking for (essentially) all and sundry in the US, its easy to
justify ignoring ISO, and connection oriented protocols.

In Australia (that's here) we don't have that luxury, there's no way
the Aust Govt is about to fund anything like the arpanet or nsfnet,
and so far we haven't had much luck convincing the US Govt agenices
that we really are the 52nd (after Canada) state...

The alternative of running a bitnet like net, with institutions
paying fixed fees (for line rentals, or other similar purposes)
might be workable, but its very difficult to come up with a scheme
for charging the fees that's fair (so that sites that really
make little use don't pay all that much .. ignoring this encourages
wastage of resources, where people use the service just because it
has been paid for).

I have posed a similar question to the following before, which was
met with total silence, but would someone like to explain a reasonable,
implementable, and fair charging scheme that will work with TCP/IP ?

Finally, you actually asked why people are "implementing", rather
than "inventing", OSI now.  This raises a different issue.  I hope
I've shown why OSI (or something similar to it) is wanted by many
people, and why simply standardising on TCP wouldn't work.  That
hasn't explained why there aren't more implementations of ISO out
in the world already though.  Here we get into the "should standards
bodies invent new things, or just bless existing products" debate.

To me, there look to be too quite different types of standards.
First there are standards for things like CD's, telephones, UNIX, ...
where someone invented something new, previously un-thought of,
and made it available to the rest of the world, who could then
say "this is great, lets make one of those".  In that area,
standardising an existing product is clearly the right thing to
do.  The other area is where there's a clear need for some
product, that doesn't yet exist, which almost anyone can see
if they think about it (consider home video several years ago,
where commercial systems existed, far too expensive for home
use, and all that was needed was some inexpensive format).

Here there's a real danger of several independant inventions with
little to choose between them, standardising one of those inventions
and ignoring the others clearly gives the lucky inventor a
big advantage over the others, and will either cause them big
losses (all that wasted effort) or to ignore the standard and
continue with their previous product, effectively destroying
the standard if they succeed.  Given that environment, in cases
where it can easily be seen that this situation is likely to
arise, many potential inventors are likely to simply neglect
to invent at all, and just wait for someone else to do it.

I believe that networking fits into the latter of those two
classes, everyone could see that it was needed, only a few
were brave enough to actually try it on their own.  Enter
ISO, faced with either chosing an existing net from one of the
few (and don't kid yourself that TCP would have stood much chance
of being "the one", it would more likely have been SNA, or DECNET,
or something similar), and I suspect quite rightly deciding to do
something a little different from anything on offer, equally
disadvantaging everyone.

Given that scenario, and the fact that several of the OSI protocols
have only recently become really firm enough to implement (and release,
even if the vendors were implementing the intermediate draft standards),
its not too surprising that the OSI protocols are just being implemented
(and released) now.

kre