[comp.protocols.tcp-ip] Dial up access to Internet facilities

rick@ameristar (Rick Spanbauer) (05/25/90)

In article <9005240215.AA01426@psi.com> schoff@PSI.COM ("Martin Lee Schoffstall") writes:
>> Thus, I
>> applaud the efforts of CERFnet and UUNET to offer authenticated,
>> for-fee access to Internet as a whole.  I can guarantee that I'll
>> be interested in using their services whereas Marty's (if I understand
>> him correctly) just looks like an interesting service.
>
>You don't understand me correctly.  Essentially we've been waiting
>for the time that a prescedent is set, permission is granted, or
>a consensus may be achievable in the Internet community.  That time may
>be now, and the PSI blitzkreig may descend.

	The plight of many small technical businesses is that we just cannot 
	justify spending $30K+ for access into the Internet for the occasional 
	FTP/smtp transfer.  Were access fees brought inline with the level of 
	service offered, eg $2K-5K/yr for dialup SLIP is reasonable, surely PSI 
	and other regionals would see their business pick up substantially.  

	Note that it isn't small business alone that has a problem with
	the high connection costs to the Internet.  Ameristar sells IP/TCP
	network products and every once in a while I ask some of our larger 
	customers ($20M & up) why they are not on the Internet.  The answer is 
	usually that the perceived value of the connection is not in line with 
	the yearly access fee.  In such cases, a low cost dialup SLIP service 
	would go a long way in giving people a chance to experiment with 
	Internet access to evaluate its usefullness to their organization.  
	Dialup SLIP is also a safe way for the regionals to toy with their 
	price/volume curve without having to add infastructure (ie additional 
	or higher capacity links) at the outset of the experiment.  

	One other suggestion I have is that the regionals ought to survey 
	potential customers about the sort of connectivity and services they 
	would purchase as a function of cost.  Good starting sample data sets 
	might be the lists of technical companies that local business 
	organizations or government maintains, or even UUCP maps.

>I'll of course let you know in the least crass commercial manner that
>I can, if it is of interest.....

	Please do make an announcement of any new services PSI introduces.  I 
	for one would like to hear what PSI is doing to moderate access fees 
	without having to ping your sales organization every few months.  

>Marty

					Rick Spanbauer
					Ameristar Technology

Usual disclaimers: my opinions are my own, etc.

sl@van-bc.UUCP (Stuart Lynne) (05/26/90)

In article <1990May25.163528.14300@ameristar> rick@ameristar (Rick Spanbauer) writes:
>In article <9005240215.AA01426@psi.com> schoff@PSI.COM ("Martin Lee Schoffstall") writes:
}	The plight of many small technical businesses is that we just cannot 
}	justify spending $30K+ for access into the Internet for the occasional 
}	FTP/smtp transfer.  Were access fees brought inline with the level of 
}	service offered, eg $2K-5K/yr for dialup SLIP is reasonable, surely PSI 
}	and other regionals would see their business pick up substantially.  

van-bc has a dialup SLIP link (9600 bps) into BCNet and it works quite well. 
It's low cost, but effective for an NNTP news feed, mail and the occasion FTP.

We have configured the modems (T2500's in V.32 mode) to auto-dial our private 
phone number on DTR. Every ten minutes we run a script which tests if the link 
is alive. If not we turn it off and on again. This drops the line and redials 
it. 

Works fairly reliably, and the cost is low. Now that we have it we couldn't
do without it.

-- 
Stuart.Lynne@wimsey.bc.ca ubc-cs!van-bc!sl 604-937-7532(voice) 604-939-4768(fax)

schoff@PSI.COM ("Martin Lee Schoffstall") (05/27/90)

Rick,

Someday I hope to meet you.....  5 years of private and public email
and our paths haven't crossed yet, just swords....    :-)

 	The plight of many small technical businesses is that we just cannot 
 	justify spending $30K+ for access into the Internet for the occasional 
 	FTP/smtp transfer.  Were access fees brought inline with the level of 
 	service offered, eg $2K-5K/yr for dialup SLIP is reasonable, surely PSI
 	and other regionals would see their business pick up substantially.  

Aside for PSI/PSINet not being a regional, (think about th N word), I think most
of us have recognized an entry level market. There must be half a dozen
providers who have something that looks like ~$10K with dedicated facilities.
One of the issues on the dialup front is that a major cost is hidden, the
message units that all businesses have to pay.  In many LATA's a 4wire
unconditioned analog circuit costs $100/mo, the cross over point where
the message units are more expensive is probably not too many of the
3 hour periods described below.

Somehow dialup Internet access and SMTP don't go hand and hand in my mind,
my estimate is that your going to have keep a connection open for about 3 hours
every day to have some probablity of synchronizing with all the SMTP
agents pushing mail out of their queues for the site.  Realistically you'll
be running uucp/tcp to a site like UUPSI who is MX'ing for your domain.

 	Note that it isn't small business alone that has a problem with
 	the high connection costs to the Internet.  Ameristar sells IP/TCP
 	network products and every once in a while I ask some of our larger 
 	customers ($20M & up) why they are not on the Internet.  The answer is 
 	usually that the perceived value of the connection is not in line with 
 	the yearly access fee.  In such cases, a low cost dialup SLIP service 
 	would go a long way in giving people a chance to experiment with 
 	Internet access to evaluate its usefullness to their organization.  
 	Dialup SLIP is also a safe way for the regionals to toy with their 
 	price/volume curve without having to add infastructure (ie additional 
 	or higher capacity links) at the outset of the experiment.  

At least you could talk them into getting a good quality UUCP connection
so they can do email.  I'm frightened by the lack of participation of
many vertical industries in communicating with their customers, suppliers,
except through phones. (Have you ever entered voice mail grid lock, where
neither party ever gets through due to synchronization problems, and
the use of voice mail systems as filtering devices.  Someday the only
time you'll ever get an answer is by dialing 1-900.lovenow).

 	One other suggestion I have is that the regionals ought to survey 
 	potential customers about the sort of connectivity and services they 
 	would purchase as a function of cost.  Good starting sample data sets 
 	might be the lists of technical companies that local business 
 	organizations or government maintains, or even UUCP maps.

This has been done, but your sampling focus is a good suggestion.

 	Please do make an announcement of any new services PSI introduces.  I 
 	for one would like to hear what PSI is doing to moderate access fees 
 	without having to ping your sales organization every few months.  

Maybe Kent England will radio you in reports from "The Front", rumored
to have been named "Operation Fortress Beantown", BarHarborAirlines has
guaranteed that they can airlift as many cisco's as they will need to
sustain the battle.  :-)

Marty

wbe@bbn.com (Winston Edmond) (05/28/90)

In article <90121@uunet.UU.NET> rick@uunet.UU.NET (Rick Adams) writes:
>UUNET plans to offer access to any Internet site from any Compuserve Dialup
>in the continental US.

>All access will require an individual login/password for accountability and
>authorization to use the Internet will be verified before the account is
>established.

>We plan to charge $5 per connect hour (in increments of 1 minute).

   Would UUNET be a CompuServe service provider, charging a $5/hr. surcharge,
or are you talking about using the CompuServe network and somehow bypassing
logging in to CompuServe itself?  Is the individual login/password the usual
CompuServe user number and password, or a UUNET login?

>We could start tomorrow if I could figure out how to bill for it.
>Its not worth sending out invoices for only $5.

   There are a number of CompuServe service providers that collect surcharges
directly from CompuServe -- the user gets a single bill, and CompuServe's
billing system keeps track of the surcharges in case the user has questions
about his bill.  This allows a service provider to charge small amounts, like
the $.02 stock quote charge, or the $.90 car profile charge, and still be
able to make money -- you don't have to bill the customer yourself.
 -WBE

mckimg@bronze.ucs.indiana.edu (geoffrey mckim) (05/29/90)

>In article <NELSON.90May21230840@image.clarkson.edu>,
>nelson@sun.soe.clarkson.edu (Russ Nelson) says:
>>That's too bad, because when I've gone travelling in the past, I've called
>>the local university, asked for their terminal server's phone number, and
>>telnetted back to Clarkson to check my mail.  It's a shame that that kind
>>of service has to go away...
>
>Actually, you can still check your mail, but for the price of a toll call
>back to your own terminal server.
>
>Maybe this is the price we have to pay for added security?
>
>/Pete
>--
>Peter M. Weiss   


I don't mean to flame but... Obviously one of the primary benefits of something
like the Internet is fast, efficient connections around the world.  Sure, 
if we wanted to, we could all just have cheapo 1200 baud modems on our desks
and dial up whatever machine we want to directly.  But that sort of defeats
the purpose of a high-speed network.

In other words, the easiest way to improve security is to simply disconnect 
all the machines on the network from all others.  But then we've got no 
network eh?  I'm afraid that knee-jerk reactions have long been the hallmark
of those in charge of computer security.  I realize that it will always be 
difficult to balance functionality and security, but I also hope that people
realize that the reason for the network's existence is FUNCTIONALITY.  I for 
one will certainly work to fight the elimination of dial-up terminal servers
connected to the internet.  Let's make our hosts more secure and not 
intentionally cripple the internet.


Geoffrey McKim				*** Standard disclaimers apply ***
Indiana University

J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft) (05/29/90)

 >I think that "fast connections around the world" does not mean that we
 >have to allow anyone with a modem and terminal to telnet/rlogin into any
 >host at will on the Internet.  Doesn't compute.

dont agree - we have just been checking how fast you can clock a line
based on the copper used for UK phones, and managed 200kbps without
much trouble - i.e. multiple basic rate ISDNs (without even needing
much tcp header compression) will make a X and NFS to 20 million UK homes
feasible before the year 2000 - if anyone thought building such a
wacky service ... if they do, security on my VCR is gonna be
ultra-tight (i dont want some hacker making me miss my favourite
show)...

jon {p.s. this is not entirely serious:-}

kwe@bu-it.bu.edu (Kent England) (05/30/90)

In article <9005270423.AA19852@psi.com>, schoff@PSI.COM ("Martin Lee
Schoffstall") writes:
 ...
> At least you could talk them into getting a good quality UUCP connection
> so they can do email.  I'm frightened by the lack of participation of
> many vertical industries in communicating with their customers, suppliers,
> except through phones. (Have you ever entered voice mail grid lock, where
> neither party ever gets through due to synchronization problems, and
> the use of voice mail systems as filtering devices.  Someday the only
> time you'll ever get an answer is by dialing 1-900.lovenow).
> 
 ...
>  	Please do make an announcement of any new services PSI introduces.  I 
>  	for one would like to hear what PSI is doing to moderate access fees 
>  	without having to ping your sales organization every few months.  
> 
> Maybe Kent England will radio you in reports from "The Front", rumored
> to have been named "Operation Fortress Beantown", BarHarborAirlines has
> guaranteed that they can airlift as many cisco's as they will need to
> sustain the battle.  :-)
> 
> Marty

	Glad to!  [BTW, it's not "Operation Fortress Beantown".  Only
folks from elsewhere and local sportswriters call Boston Beantown.  :-]

	We got the three inches of water pumped out of the main bunker
and the dehumidifier is fixed now, so it's bearable down here.  I have
a pretty good view of the harbor and Logan airport.  PSI has been airlifting
in dial-up servers, but we shot down most of them, since the visibility
was pretty poor and PSI didn't pay for good IFR gear.  Better luck next
time, Marty.  :-)

	Seriously, though, I share Marty's concern about a lack of interest
in commercial enterprises in supporting business using modern internetworks.
It would seem obvious to me what the benefits are, so perhaps we just need
to be more aggressive in touting the capabilities of the technology we know
and love.  Marty will see to that, as far as he can, since his livelihood
depends on it.  I see a definite interest on the part of commercial
organizations
wishing to join the research and education (R&E) Internet, but I see much
less interest from them in joining a purely commercial internet service-
they don't seem to understand who they would be able to talk to on a purely
commercial internet.  Come to think of it, neither do I.  But certainly
there is a lot of interest from commercial outfits in becoming a part of
our R&E Internet and in exploiting that technology to talk to the existing
base of constituents.

	NEARnet has had a phenomenal response from commercial organizations
joining NEARnet and the Internet.  There are a lot of research labs in the
Boston area, and they are very eager to be a part of the R&E Internet.
Perhaps it is just that they are able to move more quickly allocating budget
to the NEARnet connection, and are therefore able to connect more quickly
than some of our colleagues in the academic field in New England.  We'll see.

	Like the PSI folk, NEARnet is aware of an untapped potential base
for lower cost access to the Internet, from both the commercial organizations
and from academic organizations.  As might be expected, this is due mostly
to a scale pyramid=  there are simply more small sites than large.

	NEARnet is committed to broadening its base of support to include
smaller sites at lower cost.  We are chafing against technical issues in
being able to offer high quality service at lower costs, since we balance
hardware and people costs, and people costs are not really that bandwidth
sensitive.  We also have strict standards on quality of service, and we
do not wish to compromise these standards in offering less costly access,
since we know that later on our customers would regret the compromise as
much as we.  Then there is the issue of just what is part-time access;
is it terminal dial-ups, SLIP/PPP (host or router?), uucp, what?  We have
to keep in mind what services we provide and we have to make sure that
our clients understand what they can and can't do with new service offerings.

	All in all, though we have been able to keep costs quite
reasonable, so far as we can tell in comparing costs with our neighbors.

	As far as keeping up with new service offerings, you should
keep an eye on comp.newprod.  PSI always posts announcements of new service
offerings there, and NEARnet will as well.

	Must get back to work; we have air raid drills scheduled for 2pm
this afternoon and my anti-aircraft gun needs greasing.  I'll radio in 
future reports so long as my lines to Princeton aren't cut.

	--Kent England, Boston University

morgan@jessica.stanford.edu (RL "Bob" Morgan) (05/30/90)

> Somehow dialup Internet access and SMTP don't go hand and hand in my
> mind, my estimate is that your going to have keep a connection open
> for about 3 hours every day to have some probablity of synchronizing
> with all the SMTP agents pushing mail out of their queues for the
> site.  Realistically you'll be running uucp/tcp to a site like UUPSI
> who is MX'ing for your domain.

Indeed, SMTP's assumption that everybody's connected all the time
doesn't work well with occasionally-connected hosts.  It would seem
that the time is ripe for some sort of extension to SMTP to do
receiver-initiated transfers to meet this need.  Of course you'll
still need the MXing host to hold your mail for you.  Presumably
getting away from uucp is one of the points of all this.

Note that POP doesn't make it for the small-business customer.  I want
my address to be "morgan@mybusiness.com" not "morgan@barrnet.net".  I
also want to manage my own accounts on my own multi-user system, not
ask my provider every time I need a new one.

 - RL "Bob" Morgan
   Networking Systems
   Stanford

barmar@think.com (Barry Margolin) (05/30/90)

In article <1990May29.191125.9800@portia.Stanford.EDU> morgan@jessica.stanford.edu (RL "Bob" Morgan) writes:
>Indeed, SMTP's assumption that everybody's connected all the time
>doesn't work well with occasionally-connected hosts.  It would seem
>that the time is ripe for some sort of extension to SMTP to do
>receiver-initiated transfers to meet this need.

No extension is needed: see the TURN command.  However, most SMTP
implementation don't enable this command for security reasons.  To make it
secure you need a way of authenticating the calling SMTP.  One possibility
would be to allow it only in cases where the name given in the HELO command
corresponds to the address being used by the transport layer; however, not
all transport layers make this available (what do you do if SMTP is being
done over dialup lines?).

>Note that POP doesn't make it for the small-business customer.  I want
>my address to be "morgan@mybusiness.com" not "morgan@barrnet.net".  I
>also want to manage my own accounts on my own multi-user system, not
>ask my provider every time I need a new one.

MX records solve the first problem.

However, I'm not sure why you need any of this.  What's wrong with the
MX'ing host periodically trying to connect to the occasionally-connected
hosts?  Much of the time it will just time out, but when it succeeds it can
forward all the accumulated mail.  This is the default behavior, so no
extensions are necessary.
--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar

amanda@mermaid.intercon.com (Amanda Walker) (05/30/90)

In article <57875@bu.edu.bu.edu>, kwe@bu-it.bu.edu (Kent England) writes:
> I see a definite interest on the part of commercial organizations
> wishing to join the research and education (R&E) Internet, but I see much
> less interest from them in joining a purely commercial internet service-
> they don't seem to understand who they would be able to talk to on a purely
> commercial internet.  Come to think of it, neither do I.

In our case, at least, one of the reasons that a connection to what you call
the R&E Internet would/will be so valuable is that a lot of the people that
we want to communicate with are already there.  I suspect that the companies
that are currently most interested in the Internet fall into one of two
categories:

 1. Companies whose customer base is largely already on the Internet.
    TCP/IP vendors, supercomputer vendors, and so on.  We fall into this
    category, for example.

 2. Companies that want to reap the benefits of wide-area networking
    without having to develop their own infrastructure.  Some bicoastal
    computer corporations fall into this category, for example.

As the number of companies in category 2 increase, the perceived value
of a purely commercial internet will also increase.  At some point, also,
commercial service providers may increase its value by allowing it to
mediate services that the R&E Internet cannot or by policy will not support.

--
Amanda Walker
--
This posting is cursed.  As you read it you will be confuset by ther
printeb wertz.  Yer intelijen will vabni ..... XRT! XRT!

craig@bbn.com (Craig Partridge) (05/30/90)

In article <1990May29.191125.9800@portia.Stanford.EDU> morgan@jessica.stanford.edu (RL "Bob" Morgan) writes:
>
>Indeed, SMTP's assumption that everybody's connected all the time
>doesn't work well with occasionally-connected hosts.  It would seem
>that the time is ripe for some sort of extension to SMTP to do
>receiver-initiated transfers to meet this need.  Of course you'll
>still need the MXing host to hold your mail for you.  Presumably
>getting away from uucp is one of the points of all this.

CSNET did this some time ago with MMDF2b.  Some of the dial-up sites run
a script every night which brings up the dial-up line, and then opens
a connection to a port on relay.cs.net and tells it to start delivering
mail to the site.  The application at that connection starts up the
appropriate MMDF channel (mmdf can have multiple SMTP delivery channels,
where a channel typically has messages destined for a particular site),
which delivers the mail to the site.  [Note there's no security problem
here -- anyone can start up the channel, but the channel will only deliver
to the proper remote system(s)]

Craig

kwe@bu-it.bu.edu (Kent England) (05/31/90)

In article <118@ultrix.uhasun.hartford.edu>, jbloom@uhasun.hartford.edu
(Jon Bloom) writes:
> In article <57875@bu.edu.bu.edu>, kwe@bu-it.bu.edu (Kent England) writes:
> > We also have strict standards on quality of service, and we
> > do not wish to compromise these standards in offering less costly access,
...
> >
> Speaking as one who is trying to figure out how to convince management that
> $10k/yr would be well spent, I would be willing to accept service limitations
> for a lower-cost net access.  If the service truly is as useful to the
> organization as I believe it would be, the demonstration of that usefulness
> might just break loose the dollars for a higher quality ($10K)
connection.  So
> providing low-cost, restricted service connections may well have the effect
> of enhancing the number of sites getting full-service connections eventually.
> 
	We hear you.

	Let me elaborate on some of the costs hidden in a NEARnet service fee.
Consider these representative of a mid-level network service provider.  I
certainly don't mean this as an advertisement, but as explanation of the costs
of internetworking.  It might be helpful for someone starting from a UUCP or
BITnet point of view.

	Cost of the router on your end.  NEARnet requires that the demarcation
point be on the local LAN and not somewhere on the leased line.  In
other words,
NEARnet has to own and control the router at your site.  You have to pay for
that.  But this has proved critical to achieving service objectives.

	Cost of the router on our end.  It takes a lot of hardware to make
the NEARnet core work and provide access to NSFnet and other services.

	Leased line charges.  Leased lines are expensive and difficult to
move and change.  Fractional T1 is helping that a little, but still, we are
in large part unable to provide distance-insensitive fees, and some of our
clients pay large fees because of geography.

	Depreciation.  What does your service provider do for you when your
router is obsolete and can no longer function in an Internet?  Do they make
you pay for a new one?  NEARnet builds depreciation into its fee schedules,
so you pay for the cost of hardware and software continually, and not in a
lump sum, or worse, never.  Depreciation is critically important to a
network service provider being able to keep up with the technology.

	People costs.  It is very expensive in man-hours to run a mid-level
network, but we have found that it does not pay to scrimp on people.  I
think new network management tools will help, particularly as we gain control
of the wide area network, but it is still an expense that we feel is justified
to provide a sufficiently high level of service.  NOCs should be 24 hours
a day, seven days a week, and that will never be cheap.

	User services.  We have found it absolutely critical to be able to
offer some minimal user services to our members.  This is extremely important
to some of our clients.  Some of these services are things like name servers
for their domains and help with registration and connected-status.  But it
also includes a committment from NEARnet to take responsibility for tracking
down, identifying, and, to the extent possible, fixing users' connectivity
problems, no matter where in the Internet the problem is lurking.  This is
a service available to anyone, anywhere.  Finger @nic.near.net for details.
It also includes Dan Long's time and effort in the IETF in the User 
Connectivity Problems Working Group to try to spread this capability and 
commitment throughout the Internet.

	All this adds up to quite a chunk of change.  Makes UUCP look pretty
good, eh?      :-)

	I understand, though, that money is money and it still costs too much.
I believe the NSF is sympathetic, as they are still considering proposals for
grants to connect qualified sites to the Internet.  You may be able to turn to
the NSF for grant aid.

	It's all part of the Internet growing up, running like a business,
going private, etc.  And NEARnet is not the only mid-level network
service provider
working these issues.  More and more operational people are getting into the
IETF and there is the Federation of American Research Networks which is
populated
by the mid-level networks, among others, and is working on these sorts
of issues.

	--Kent England

schoff@PSI.COM ("Martin Lee Schoffstall") (05/31/90)

Jon,

I think the counter argument is that if it doesn't work reliably/well
especially in the beginning then people won't rely on it to provide
communications for their everyday needs.  If they don't use it
everyday then it is luxury suitable for axing at the appropriate
belt-tightening time.

Marty
---------------
> Speaking as one who is trying to figure out how to convince management that
> $10k/yr would be well spent, I would be willing to accept service limitations
> for a lower-cost net access.  If the service truly is as useful to the
> organization as I believe it would be, the demonstration of that usefulness
> might just break loose the dollars for a higher quality ($10K) connection.  So
> providing low-cost, restricted service connections may well have the effect
> of enhancing the number of sites getting full-service connections eventually.

jb.loom@uhasun.UUCP (05/31/90)

In article <57875@bu.edu.bu.edu>, kwe@bu-it.bu.edu (Kent England) writes:
> 
> 	NEARnet is committed to broadening its base of support to include
> smaller sites at lower cost.  We are chafing against technical issues in
> being able to offer high quality service at lower costs, since we balance
> hardware and people costs, and people costs are not really that bandwidth
> sensitive.  We also have strict standards on quality of service, and we
> do not wish to compromise these standards in offering less costly access,
> since we know that later on our customers would regret the compromise as
> much as we.  Then there is the issue of just what is part-time access;
> is it terminal dial-ups, SLIP/PPP (host or router?), uucp, what?  We have
> to keep in mind what services we provide and we have to make sure that
> our clients understand what they can and can't do with new service offerings.
>
Speaking as one who is trying to figure out how to convince management that
$10k/yr would be well spent, I would be willing to accept service limitations
for a lower-cost net access.  If the service truly is as useful to the
organization as I believe it would be, the demonstration of that usefulness
might just break loose the dollars for a higher quality ($10K) connection.  So
providing low-cost, restricted service connections may well have the effect
of enhancing the number of sites getting full-service connections eventually.

Jon
 
--
Jon Bloom, KE3Z -- jbloom@uhasun.hartford.edu

smb@ulysses.att.com (Steven Bellovin) (05/31/90)

There's no reason, of course, why the dial-up hub can't call out.  As
long as the time to complete the call (including login) is less than
30 seconds or so, most TCPs won't care (too much).

henry@utzoo.uucp (Henry Spencer) (06/01/90)

In article <9005302148.AA02245@psi.com> schoff@PSI.COM ("Martin Lee Schoffstall") writes:
>I think the counter argument is that if it doesn't work reliably/well
>especially in the beginning then people won't rely on it to provide
>communications for their everyday needs...

True in general, but one must beware of thinking of "reliably" and "well"
as Booleans.  Uucp mail is unreliable and ungodly slow by Internet
standards, but vast numbers of sites found it reliable *enough* and
workable *enough* to come to rely on it very extensively.

The reason why a zoology department (!) was a major networking hub
at U of T for some years was that everybody else was so obsessed with
Internet (or better) performance that they wouldn't even look at silly
ideas like networking via low-speed modems.  We set up our phone links
and started shipping mail and news, and pretty soon half the campus
had uucp links to us.  Half a loaf is much more nutritious than none.
-- 
As a user I'll take speed over|     Henry Spencer at U of Toronto Zoology
features any day. -A.Tanenbaum| uunet!attcan!utzoo!henry henry@zoo.toronto.edu

meissner@osf.org (Michael Meissner) (06/01/90)

In article <9005301640.6.142@cup.portal.com> jb.loom@uhasun.UUCP
writes:

| In article <57875@bu.edu.bu.edu>, kwe@bu-it.bu.edu (Kent England) writes:
| > 
| > 	NEARnet is committed to broadening its base of support to include
| > smaller sites at lower cost.  We are chafing against technical issues in
| > being able to offer high quality service at lower costs, since we balance
| > hardware and people costs, and people costs are not really that bandwidth
| > sensitive.  We also have strict standards on quality of service, and we
| > do not wish to compromise these standards in offering less costly access,
| > since we know that later on our customers would regret the compromise as
| > much as we.  Then there is the issue of just what is part-time access;
| > is it terminal dial-ups, SLIP/PPP (host or router?), uucp, what?  We have
| > to keep in mind what services we provide and we have to make sure that
| > our clients understand what they can and can't do with new service offerings.
| >
| Speaking as one who is trying to figure out how to convince management that
| $10k/yr would be well spent, I would be willing to accept service limitations
| for a lower-cost net access.  If the service truly is as useful to the
| organization as I believe it would be, the demonstration of that usefulness
| might just break loose the dollars for a higher quality ($10K) connection.  So
| providing low-cost, restricted service connections may well have the effect
| of enhancing the number of sites getting full-service connections eventually.

If all you currently want is SMTP and FTP initially, then uunet may be
a way to start.  They obviously will do mail, but another service they
offer to paying customers is to do anonymous FTP's on request, and
UUCP it to your machine.  When I was at Data General, and the internet
connection was extremely flakey (it did get better before I left), I
begged, pleaded, and such to management to establish such a UUNET
connection and buy the Telebit Trailblazer modem.  I was able to get
GCC releases and prereleases in a timely manner (though there was the
time when I couldn't keep an internet connection or modem connection
open long enough, thanks to the lousy GTE phone service in the RTP
area of North Carolina or the lousy internal DG phone service).

The last time I looked, the uunet charges where $35/month, $2/hour if
you called their local number (using company WATTS lines if you have
them), or $16/hour if you used their 800 number.  A Telebit T2500
modem sells in the range of $1000.  Obviously this is subject to
change, as is their willingness to do anonymous FTP's for you (though
they have most of the stuff people want directly on uunet).
--
Michael Meissner	email: meissner@osf.org		phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA

Catproof is an oxymoron, Childproof is nearly so

ddl@husc6.harvard.edu (Dan Lanciani) (06/01/90)

In article <57952@bu.edu.bu.edu>, kwe@bu-it.bu.edu (Kent England) writes:
> In article <118@ultrix.uhasun.hartford.edu>, jbloom@uhasun.hartford.edu
> (Jon Bloom) writes:
> > In article <57875@bu.edu.bu.edu>, kwe@bu-it.bu.edu (Kent England) writes:
> > > We also have strict standards on quality of service, and we
> > > do not wish to compromise these standards in offering less costly access,
> ...
> 	All this adds up to quite a chunk of change.  Makes UUCP look pretty
> good, eh?      :-)

	One of the reasons that UUCP does indeed look good in this comparison
is that the current structure of UUCP networks (last I looked!) still allows
a site to join the network at as low a cost and with as poor service as it
can tolerate.  In many cases, e.g., a local phone call, that service can
be pretty good and pretty cheap.
	Many regional internet service providers forbid "third party"
connections and nets-behind-nets because they see such access as depriving
them of the revenue they would obtain from a directly-connected customer.
While this may be a valid business concern, and while it has the side effect
of allowing the regional to enforce a certain quality of service, it can
preclude some interesting and potentially cost-effective (at least for the
customers) structures.
	A more standard and quantitative method of charging for internet
service, e.g., per-packet accounting (sigh), might allow the existence of
low-end sub-service providers without threatening the income of the regionals.
That is, a regional need not worry whether two customers pay for 100
packets each or one subcontractor pays for 200.  Competition could then
drive the price of service down to a point where even an individule can
afford a connection...

				Dan Lanciani
				ddl@harvard.*

sl@van-bc.UUCP (Stuart Lynne) (06/01/90)

In article <3103@husc6.harvard.edu> ddl@husc6.harvard.edu (Dan Lanciani) writes:
>While this may be a valid business concern, and while it has the side effect
>of allowing the regional to enforce a certain quality of service, it can
>preclude some interesting and potentially cost-effective (at least for the
>customers) structures.
>	A more standard and quantitative method of charging for internet
>service, e.g., per-packet accounting (sigh), might allow the existence of
>low-end sub-service providers without threatening the income of the regionals.

It also provides a way for people to try things out. A sys admin can hook
into van-bc for example simply by agreeing to attempt to make some donations
to help us run things. So he can hook up, usually with existing resources
and then after a few months demonstrate to management that it's a good
thing. And then get authorization to do it and make some donations.

We also see people using the uucp service for a while and then deciding to
move up into SLIP service directly into the regional network. Again if they
hadn't had the opportunity to demonstrate the usefullness of the endeavour
they might not have been able to get management approval for the more
expensive regional network connection. 

-- 
Stuart.Lynne@wimsey.bc.ca ubc-cs!van-bc!sl 604-937-7532(voice) 604-939-4768(fax)

medin@NSIPO.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office) (06/01/90)

	 
	 .
	 .
	 .
	 I think the counter argument is that if it doesn't work reliably/well
	 especially in the beginning then people won't rely on it to provide
	 communications for their everyday needs.  If they don't use it
	 everyday then it is luxury suitable for axing at the appropriate
	 belt-tightening time.
	 
	 Marty


Marty, I think John was trying to espouse the "crack dealer's" approach
to Internetting.  First, you give them a little something either free or
very low in cost.  Then, once they are hooked, you stick it to them with
high cost, high performance solutions, and by this time, they are screaming
for more and can't do without.  They will pay and and pay at this point.

Those of us who work in the government side of networking don't use this exact
tactic, but I know of many large organizations who were "hooked" this way...

					Thanks,
					    Milo
	 

schoff@PSI.COM ("Martin Lee Schoffstall") (06/01/90)

 	Many regional internet service providers forbid "third party"
 connections and nets-behind-nets because they see such access as depriving
 them of the revenue they would obtain from a directly-connected customer.
 While this may be a valid business concern, and while it has the side effect
 of allowing the regional to enforce a certain quality of service, it can
 preclude some interesting and potentially cost-effective (at least for the
 customers) structures.

Revenue is only one issue, there are considerations of performance,
debugging, responsability and market perception:

PERFORMANCE:
	There are cutomers who opt for 9.6-19.2 Internet connectivity,
	who don't understand why their link is unusable after they
	feed a couple fortune 500 companies with UUCP behind it, then
	potentially they want to offload their DNS to their service
	provider, which most regionals do, but why do we do it, for them or
	for the companies behind them which we have no relationship with.

DEBUGGING:
	So the MX record doesn't work, so their sendmail.cf is misconfigured
	in doing this, so the side behind them calls the service
	provider to ask questions, get help, whatever.  For the
	regionals working with each other all the time, the  RIGHT
	assumption is that everyone is carrying each other at some
	level, and that the people at the ends are paying for
	the service.  A terminus uucp connection (which is the
	norm for the problem sites), pays nothing.

RESPONSABILITY:
	Who is responsible for that uucp connection, especially when
	friend system administrator A and University B moves onto
	make some big money at Commercial company C.

MARKET PERCEPTION:
	Maybe this is the largest issue of all, without even trying
	the service quality perception of network Z can be drawn
	down by a dozen bad uucp connections who's users think
	they are on ZNet and they tell their friends about how
	it isn't reliable, doesn't work, poor performance etc...


Some organizations including PSI/PSINet throughout the US and
CERFNet throughout California have simply decided that the
real solution is to establish local dialups everywhere they
are, and provide CHEAP UUCP connections and deal with this
directly.

Marty

karn@ka9q.bellcore.com (Phil Karn) (06/03/90)

In article <1990May29.191125.9800@portia.Stanford.EDU> morgan@jessica.stanford.edu (RL "Bob" Morgan) writes:
>
>Indeed, SMTP's assumption that everybody's connected all the time
>>doesn't work well with occasionally-connected hosts.  [...]

I'm also very interested in making the Internet protocols work well over
non-full-time paths. 

Here's an idea that I put into my KA9Q TCP/IP package a while ago.  It has a
UDP-based server that handles "kick" requests. These force retransmissions
on any TCP connections to the specified IP address (which defaults to the
sender of the kick message) and they also cause the remote SMTP daemon to
start sending any pending traffic to the destination.

This has turned out to be a useful feature when dealing with dialup links or
the long network outages that are characteristic of some experimental
amateur packet radio links. When the path is up, the person expecting mail
sends a kick request to the site(s) from which he expects his traffic, e.g.,
a mail exchanger. If there's any traffic waiting, it immediately starts to
flow. Also, because my TCP connections never time out (they just back way
off) the kick command lets you pick up a partial transfer right where you
left off when the path broke without having to restart it from the
beginning.

Perhaps it's time for an "intermittent connectivity" working group in the
IETF?

Phil

henry@utzoo.uucp (Henry Spencer) (06/03/90)

In article <36901@think.Think.COM> barmar@nugodot.think.com (Barry Margolin) writes:
>>Indeed, SMTP's assumption that everybody's connected all the time
>>doesn't work well with occasionally-connected hosts.  It would seem
>>that the time is ripe for some sort of extension to SMTP...
>
>No extension is needed: see the TURN command.  However, most SMTP
>implementation don't enable this command for security reasons...

TURN is the wrong tool for the job.  What is needed is the equivalent of
UUCP's callback facility:  A connects to B, says "call me", and hangs up.
B then makes the call -- which eliminates the authentication issue -- and
transfers the traffic.

People interested in infrequently-connected hosts would do well to study
how UUCP software and administrators deal with the problems.  There is
a large body of relevant experience there.

>However, I'm not sure why you need any of this.  What's wrong with the
>MX'ing host periodically trying to connect to the occasionally-connected
>hosts? [which is the way it already works] ...

It has the standard problem of any polling scheme:  frequent attempts eat
resources, infrequent attempts can miss "hitting the window" for a site
which is only connected occasionally.  As with most polling, the real
answer is to have the other end *tell* you "now would be a good time".

SMTP's approach assumes hosts that are on the network more or less
continuously, with partitioning and/or downtime a relatively rare and
transient phenomenon that can be dealt with in simplistic ways.  When
the connection, as opposed to the absence thereof, is rare and transient,
more sophisticated tactics are needed.
-- 
As a user I'll take speed over|     Henry Spencer at U of Toronto Zoology
features any day. -A.Tanenbaum| uunet!attcan!utzoo!henry henry@zoo.toronto.edu

jc@minya.UUCP (John Chambers) (06/04/90)

> CSNET did this some time ago with MMDF2b.  Some of the dial-up sites run
> a script every night which brings up the dial-up line, and then opens
> a connection to a port on relay.cs.net and tells it to start delivering
> mail to the site.  The application at that connection starts up the
> appropriate MMDF channel (mmdf can have multiple SMTP delivery channels,
> where a channel typically has messages destined for a particular site),
> which delivers the mail to the site.  [Note there's no security problem
> here -- anyone can start up the channel, but the channel will only deliver
> to the proper remote system(s)]

How so?  What's to prevent me from running a script of the form:

	for h in foo bar bax glorph `hostname`
	do	hostname $h
		<<Connect to your machine and exchange mail>>
	done

Is there some mechanism for detecting such spoofing?  The only way I can 
think of is by noting info at the link level (Ethernet address, phone number, 
or some such) and comparing, but on most systems, this info isn't available 
to application-level processes.  For instance, how does a process started
from a modem login discover the caller's phone number?  UUCP uses callback 
(if you can figure out how to make it work ;-), but I didn't see any mention 
of that.  What am I missing?

(Yeah, I know I'll also have to run ifconfig for this to work across the
internet.  That's part of the <<code>; give me credit for some smarts! :-)

-- 
John Chambers ...!{harvard,ima,mit-eddie}!minya!jc
--
If you're not part of the solution, you're part of the precipitate.
[Kiel oni ^ci tiun diras esperante?]

wcs) (06/06/90)

In article <1990May31.211414.8140@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
]The reason why a zoology department (!) was a major networking hub
]at U of T for some years was that everybody else was so obsessed with
]Internet (or better) performance that they wouldn't even look at silly
]ideas like networking via low-speed modems.  

]-- 
]As a user I'll take speed over|     Henry Spencer at U of Toronto Zoology
]features any day. -A.Tanenbaum| uunet!attcan!utzoo!henry henry@zoo.toronto.edu

It's nice to see that Henry does have a balanced view of things,
regardless of what his .signature may imply :-)  (Tanenbaum, aside
from any OSI politics, is the author of Minix, which was designed to
provide features at the cost of some speed on a machine where speed
was in short supply already - a successful and nice project.)

I've always been surprised at how much you could accomplish with UUCP;
my main disagreement with the SMTP approach, other than the
appalling overcomplexity of sendmail, is that it wants to make a
connection NOW, and send traffic the whole way, rather than settling
for store-and-foreward on a message basis.  While uucp was always a
pain to maintain, the major cause of problems seemed to be
inadequate numbers of modem ports.
-- 
				Thanks;  Bill
# Bill Stewart AT&T Bell Labs 4M312 Holmdel NJ 201-949-0705 erebus.att.com!wcs
# Actually, it's *two* drummers, and we're not marching, we're *dancing*.
# But that's the general idea.

david@twg.com (David S. Herron) (06/06/90)

In article <9005270423.AA19852@psi.com> schoff@PSI.COM ("Martin Lee Schoffstall") writes:
> 	The plight of many small technical businesses is that we just cannot 
> 	justify spending $30K+...
> 	  Were access fees brought inline with the level of 
> 	service offered
>Somehow dialup Internet access and SMTP don't go hand and hand in my mind,
>my estimate is that your going to have keep a connection open for about 3 hours
>every day to have some probablity of synchronizing with all the SMTP
>agents pushing mail out of their queues for the site.  Realistically you'll
>be running uucp/tcp to a site like UUPSI who is MX'ing for your domain.

Hmm..  interesting discussion.

uucp/tcp isn't a good choice because the transition through rmail
loses information and bursts messages going to multiple recipients.
There's a bunch of CSNET like tricks that can be played to make this 
work out better.  For instance, a "relay" machine could be advertised
as a fairly low cost MX alternative for the true site causing mail to
be dropped at the relay.

Oh, but does sendmail choke a bit when it has lots of undeliverable
mail in its queue?  Sigh, such is life...  :-)


Count me in as a potential customer of low cost IP service.  It'd be
real nice, when travelling, to be able to reach my home site w/o problem.
For day-day work-at-home stuff I think I can manage to arrange something
local without too much expense, especially since my home line isn't charged
as a business line.  "On the road" is another matter entirely..  
-- 
<- David Herron, an MMDF weenie, <david@twg.com>
<- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu>
<-
<- Sign me up for one "I survived Jaka's Story" T-shirt!

wuu@DUMBO.JVNC.NET (Sze-ying Wuu) (06/12/90)

>	CSNET did this some time ago with MMDF2b.  Some of the dial-up sites run
>	a script every night which brings up the dial-up line, and then opens
>	a connection to a port on relay.cs.net and tells it to start delivering
>	mail to the site.  The application at that connection starts up the
>	appropriate MMDF channel (mmdf can have multiple SMTP delivery channels,
>	where a channel typically has messages destined for a particular site),
>	which delivers the mail to the site.  [Note there's no security problem
>	here -- anyone can start up the channel, but the channel will only deliver
>	to the proper remote system(s)]
>
>	Craig
>


Does CSNET uses Phonenet protocol for dial-up sites? 

We have 1986 version of MMDF, is there a newer version available from
pulic domain? I assume with MMDF, we still need MX RR for a host to
accumulate mail for all dial-up sites. Is there a limitation on the
number of channnels can be fired up? 

Sze-Ying Wuu
JvNCnet
wuu@nisc.jvnc.net