[11115] in Commercialization & Privatization of the Internet
Options (was Re: What is an "Internet reseller"?)
daemon@ATHENA.MIT.EDU (Bruce Gingery)
Tue Mar 22 05:12:41 1994
Date: Mon, 21 Mar 1994 19:47:26 -0700 (MST)
From: Bruce Gingery <lcbginge@antelope.wcc.edu>
Reply-To: Bruce Gingery <lcbginge@antelope.wcc.edu>
To: Matthew Kaufman <matthew@echo.com>
Cc: fair@apple.com, karl@mcs.com, com-priv@psi.com
In-Reply-To: <199403190727.XAA22208@echo.com>
On Fri, 18 Mar 1994, Matthew Kaufman wrote:
> If I send 1MB of email from a Unix account I buy from some provider,
> or 1MB of email by forwarding stuff via UUCP up to a service provider,
> or 1MB of email by opening the SMTP connection myself, if its going
> to some other CIX-connected host it uses EXACTLY THE SAME AMOUNT OF
> RESOURCES.
Actually, as I see it, that's not REALLY the case.
1. If you have direct IP, you may or may not move more data
but what you DO use will use less resources of the
various providers (or the same in some cases).
2. If you use a UUCP connection, your provider can probably be
a bit freer with scheduling OUTGOING data, but incoming
targeted at you, whether ftp via net mailserver, list
mail (or the list echo of a newsgroup, or even binnews
packets), will not only have to be stored until you
poll (unless bi-directional polling is furnished, which
is NOT common).
3. If you have a "login" as opposed to UUCP or direct IP (SLIP/PPP)
again, you MIGHT move less traffic, or you may utilize
the MOST resources. Your value is likely decreased
over BOTH of the above, but the resources used by the
provider are likely the highest of the three compared options.
All of this presumes full network connectivity limited only by the
type of service provided. Perhaps the best of all the worlds is..
1. uucp (via TCP) for incoming mail
2. pass-through straight IP for everything else.
FOR THE PROVIDER
Though this eliminates some of the enhancements available in various
UUCP implementations such as Z-modem based transfers, efficient bi-directional
serial protocols, and the like. The IP connectivity eliminates much of
the "user maintenance" requirements from the provider, at least as
compared to "login" with home directory, much of the "auth" and "limits"
setups, and the like. All of this is transferred to the consumer. Use of
uucp TCP connects eliminates the need for multi-shell logins for most
lines, and any term sets, shells (and special menued shells.) Much on-
system storage. IF local newsgroup service is provided, it can be
provided via simple INN and/or NNTP setups... no maintenance of rn and its
successors. Storage requirements are limited to that required for any
uucp store-and-forward system, but no maintenance of hand-keyed (hence
betimes forgot) passwords, home directories, and NO need for support of
novice users for on-system (rtfm) utilities.
Connect times are apt to be longer than simple uucp, but shorter than
logins, hence it hits a mid-point for serial resource use. With the
problems some providers have had maintaining decent 'g' protocol
transfers for simple uucp clients, the connect times may actually
decrease, and the complaints certainly decrease.
CONs are all compared to simple serial IP connectivity without the uucp.
Added storage for the incoming traffic, second "login" for the uucp
connectivity with a uucp shell in addition to the serial-IP connection.
Yet to provide sometimes service some provision has to be made for
incoming mail.
FOR THE CONSUMER
Again, loss of Z- or bi-directional serial protocols for massive data
movements will likely increase (depending on the alternative 'g'
responsiveness) transfer times for E-mail, hence increase connect time
somewhat. On the other hand, while connected, the link is not limited to
JUST transfer of mail. Gopher, WWW, telnet to a handy Archie server (or
use of a local Archie client), and pass-thru SMTP transfers can co-exist
with the uucp connection. Advanced ftp clients (NEXTSTEP Yftp, ncftp,
etc) can simplify and speed the access to remote files with a straight-
through "download" as opposed to ftp to a login, then download with kermit
or other facilities.
LEVEL OF SERVICE
The provider needs to maintain standard interfaces for UUCP and SLIP
and/or PPP. Troubleshooting the consumer's end of such connections should
NOT be part of the basic service, which seems to be the primary problem
addressed in this and other discussion groups. If the provider is
supplying "plug and play" connectivity, then that's their own option, but
why make that part of the basic package? ANYTHING else would be extras.
Even newsgroups repository and NNTP/INN service.
Auto-starts for provider-stored to client mail transfers come via the
"login", and such a "login" COULD even be provided to a roming client over
the net. Everyone seems to have become so focused on SMTP that it is
forgotten that there are other options.
> "IP is Special" is a MYTH. Except for some arbitrary, unfounded beliefs of
> some people who, now that they have spent their $10k, want to pretend
> otherwise, there is NO REASON to differentiate between "user who occasionally
> calls a Unix host", "user who occasionally sends out stuff via UUCP" and
> "user who occasionally dials in and uses SLIP"
My own two cents is that "IP is Special" is far from a myth. It's more
bang for the buck (if provided at comparable connect rates) for BOTH the
provider and the consumer. For the provider, it is more efficient use of
resources. For the consumer it is potentially FAR more bang for the buck.
The actual data volume is apt to be no more, or not MUCH more, and the
local administrative problems are less.
> They can all generate and receive bits which travel across the CIX router,
> and as long as the connection is getting paid for, WHY SHOULD YOU CARE?
> Once the CIX router and its support is paid for, the extra $10k per
> "reseller" simply goes into Bill Washburn's pocket, as far as I can tell.
> And simply MAKING UP reasons why more people ought to be required to
> pay the $10k doesn't go any farther towards convincing me that its going
> to a good cause.
>
> -matthew
Bruce Gingery lcbginge@antelope.wcc.edu
