From: Bill Stewart (email@example.com)
Date: Fri Mar 03 2000 - 11:46:41 PST
At 09:56 AM 03/02/2000 -0500, Steven M. Bellovin wrote:
>It is worth noting that some bans on running servers are based on
>not the business model of the provider. In IP over cable systems, there is
>much less bandwidth available upstream than downstream, and it's much more
>expensive to add more upstream bandwidth than it is to add downstream
>bandwidth. If you run a server, you're chewing up a lot of capacity, and
>affecting your neighbors.
Excite@Home's ban isn't really based on technology -
it's using a policy against things that are easy to detect because
they didn't have good bandwidth-limiting or bandwidth-measurement technology
and would rather limit their users than resolve individual conflicts.
USWest apparently has a similar policy for consumer-priced DSL.
Obviously they need to limit upstream volume (and the newer cable modems
or head-ends are giving them more tools for that),
but this not only limits the high-volume porn/warez/mp3 servers,
and high-volume small-business email servers shipping Powerpoints,
it also limits web servers with pictures of your kids and cats
that will only ever be downloaded by your relatives,
and it limits people who use SMTP email instead of POP3,
or want to use SSH (or telnet) to log into their home machine from work.
They don't limit MS file-sharing servers - they recommend turning them off
because they're terribly insecure, but they assume they'll be low volume.
But they don't limit RealAudio or CU-SeeMe, which are real bandwidth hogs.
It's a terribly counter-productive policy - the way to get 50 million users
is for somebody to develop the killer app that makes always-on more useful.
The way to do that is to let the current million users play around and find it
(and just hope it isn't Napster :-), which means allowing light-weight
The killer app may be a free thing, or a business, or a freeware that
sells out to MSAOL for big bucks; the cable ISP should welcome all of them.
The related technology issue is "so how much upstream load *do* they
and "what tools does the system have for scalability and load limiting?".
Julf's anon.penet.fi ran on a 64kbps line, but web service can be
a much heavier load, especially if the system forwards pictures.
I used to run a Crowds server when I had DSL, and it got very little load,
but if Freenet catches on, it'll have more load, at least unless there
are lots more users
And David Honig wrote:
>How many servers can dance on the head of a pin?
>How many cable modem operators are pin heads?
Yow! @Home has delayed cable modem service in my town yet another month :-)
>What is the definition of 'server' in these contracts? In the law?
None - it's whatever the sysadmin thinks it might be.
>Restricting the use of the media should not be legal if the supplier has a
>government-granted monopoly (as cable ISPs do, and DSL will if the CO isn't
Cable ISPs haven't had granted monopolies in most places for a few years;
there are FCC rules requiring towns to open access to the streets for
competitive cable providers. In practice, they're usually monopolies,
though overbuild carriers like RCN are starting to add competiting cable
>Better to act and ask forgiveness then to ask permission first...
Steve Shear also posted that cable ISPs don't enforce aggressively;
they mainly respond to complaints. But unless they become universal
(e.g. include an anonymizer with every copy of Apache),
remailers, rewebbers and eternity servers are *guaranteed* to generate
They'll obviously be abused by the usual spammers, harassers, and pranksters,
but there are people who don't like anonymity and will do the
Gary B*rn0re act of anonymously slandering themselves and complaining
to the ISP to get the remailer shut down.
Steve Shear also replied that security and firewalls may be more important
than the server-vs-client issue. I disagree, at least for cable modem users;
getting cracked is annoying, but getting shut down hard means that
you can't run the service\\\\\\\listener.
Bill Stewart, firstname.lastname@example.org
PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
This archive was generated by hypermail 2b29 : Fri Mar 03 2000 - 19:27:05 PST