|
Grex > Coop10 > #24: Bandwidth usage policies on a faster connection | |
|
| Author |
Message |
janc
|
|
Bandwidth usage policies on a faster connection
| 
Aug 4 13:37 UTC 1997 |
How should Grex usage policies respond to having a faster internet connection?
Currently we do things like discourage sending big E-mail messages, ftping
huge files, and running mailing lists on Grex. We usual send E-mail to
people saying things like "Grex has only a tiny 28.8K connection to the
internet that must be shared among all its users" and asking them please to
not abuse it.
Once the internet connection is faster, these policies naturally come under
question. We could just edit the standard messages we send out to say "Grex
has only a tiny 128K connection to the internet" but it doesn't have quite
the same impact any more.
There are lots of options. We could loosen up a while and not start clamping
down again until it seems to be turning into a problem. We could try to hold
the line and aim to support more users instead of just more usage. We could
hold the line for now, and maybe slowly loosen up as we see how things go.
What do people think? How should staff approach this?
|
| 26 responses total. |
valerie
|
|
response 1 of 26:
|
Aug 4 13:41 UTC 1997 |
This response has been erased.
|
steve
|
|
response 2 of 26:
|
Aug 4 15:48 UTC 1997 |
Absolutely. A 128K connection is better than what Grex has had
in the past, but thats *still* a ludicrous amount of bandwidth for
an enterprise such as ours. Thats still 1/11th of a T1, which is
the standard speed for any commercial operation that does things.
Now, we aren't a commercial operation, but we do as much as many
do, and I still get looks of disbelief when I talk to people about
Grex and they find out we aren't on a T1.
We're going to have an increase of users FTPing things in once
we're on the ISDN line because uploads won't take geologic time any
more. If anything, we're going to find ourselves in the position
of having to be even more strict.
|
scott
|
|
response 3 of 26:
|
Aug 4 16:06 UTC 1997 |
I think we should open more telnet slots (this may require the 670 also) so
we can better serve our existing user base. Keep current policies in place
until (if) we find we can relax those.
|
richard
|
|
response 4 of 26:
|
Aug 4 16:30 UTC 1997 |
With a faster connection, consider losing the countdown cue...reasons for
having it in the first place should be reduced with a faster connection.
The countdown was put in experimentally a year ago and has never been brought
up again
for re-consideration or re-affirmation. This is time to do so.
|
steve
|
|
response 5 of 26:
|
Aug 4 18:26 UTC 1997 |
Richard, if we don't have the telnet queue, we'll be opening
ourselves to telnet attacks, where the telnet daemon (that master
entity that accepts connections) will have to fend off all these
requests when there aren't enough resources to handle them all.
There *will* be a queue to Grex: we can manage it ourselves,
save CPU time and even let people know where they are in said
queue, or we can make it open and let telnet sessions come in
on a first come first served basis and waste resources dealing
with telnet attacks.
I know what I want to see for grex.
There is also a "fairness" factor here: if we don't have
a queue system, then those people who have the knowledge to
write telnet attack scripts have a definite advantage over
those who don't. Not only is that unfair, but very much
selects for those more technical types to get to grex.
|
davel
|
|
response 6 of 26:
|
Aug 4 21:05 UTC 1997 |
What STeve just said.
|
mary
|
|
response 7 of 26:
|
Aug 4 22:40 UTC 1997 |
I'd really like to see Grex avoid membership perks. I've said this so
often folks know I'm going to say it before I read the item. But I don't
often go into why I feel this way. I will this once. ;-)
Grex inadvertently filters for a special type of member. We don't have a
grand plan to plan to do this, mostly it just happens. At present we are
filtering for folks who like the idea of an open system which seeks to
give all users as much access as possible. We are filtering for folks who
are patient and don't expect much from our overworked volunteer staff. We
filter for folks who are more into giving than getting.
If we start offering perks, like members-only Usenet access, we will most
certainly attract users who need cheap access to such services. I'm quite
sure we'd gain members and have a healthier bank account and that all
sounds wonderful, right? But all those new "donors" who are here for the
perks would now be voting members. Voting members who would be quite
likely to vote to extend more membership perks as such issues arose.
If I had to choose I'd much rather we be meager and smallish, struggling
to find enough generous donations, than evolve into a budget ISP, with
tiered access, and have-and-have-not users.
|
steve
|
|
response 8 of 26:
|
Aug 4 23:17 UTC 1997 |
Thats a very interesting thought Mary, that we'd start selecting
for members who aren't opposed to member-only benefits, beyond
what we have now. I'm not sure thats the case, but I can't say it
wouldn't turn out that way either.
|
mdw
|
|
response 9 of 26:
|
Aug 5 00:15 UTC 1997 |
I don't think it's so inadvertent that we "filter for a special type of
member". I'd like to think that we're making some effort to filter for
people who will like it here, and that we will enjoy having here.
|
mta
|
|
response 10 of 26:
|
Aug 5 00:51 UTC 1997 |
Thank you, Mary. Very succinctly put.
I concur completely. (I agree with Marcus, though, that to some extent
our selection process has been semi-intentional.)
|
rcurl
|
|
response 11 of 26:
|
Aug 5 05:54 UTC 1997 |
There is a difference between doing something just to create a member "perq"
and doing something for other reasons that happens to result in a member
"perq". The question can be asked, what modification could result in
significantly increased support for grex at the price of only a *little*
member perq? For example, if e-mail were just given a lower priority for
non-members than members - delayed by a day, for example. Or put into
a non-member outgoing mail queue, which results in members having a slight
advantage in mail handling. I'm sure others can think of marginal "perqs"
that might have dramatic consequences.
|
dpc
|
|
response 12 of 26:
|
Aug 6 00:34 UTC 1997 |
I support what valerie, steve, and scott said. We don't know what will
happen with the new connection; let's hold the line for a while.
|
janc
|
|
response 13 of 26:
|
Aug 11 15:38 UTC 1997 |
I really strongly approve of Mary's response #7 -- but I don't know why it
is in this item. I didn't think anyone had proposed any member perks here.
I think it belongs in Dave's E-mail restricting item, and I wouldn't mind a
bit if it were copied over there so that people reading that item from the
agora conference would see it.
I guess we have some general philosophical agreement about how to administer
a faster connection. Keep most of the restrictions, and loosening some like
the number of ptys up slowly, as we try to figure out what the traffic will
bear.
We don't have a lot of control over how people use the added bandwidth, but
we seem to be more interested in more telnet than in ftp and mail.
|
dpc
|
|
response 14 of 26:
|
Aug 11 15:42 UTC 1997 |
Righto to your #13, janc!
|
mary
|
|
response 15 of 26:
|
Aug 11 22:16 UTC 1997 |
Ack! Jan is right and response #7 here should have been
entered in item #23 on Usenet News. I'm surprised nobody
corrected me earlier. I shouldn't conference drunk. ;-)
|
tsty
|
|
response 16 of 26:
|
Aug 13 05:49 UTC 1997 |
...ahve you had THAT much cyberspace today????? tsktsktsktsk <g>
|
tsty
|
|
response 17 of 26:
|
Sep 1 08:06 UTC 1997 |
This response has been erased.
|
tsty
|
|
response 18 of 26:
|
Sep 1 08:14 UTC 1997 |
as far as filtering is concerned, " I'd like to think that we're making
some effort to filter for people who will like it here, and that we
will enjoy having here" seems strange with ~100 members and ~14,000
logins.
and how many are conferencing? those are the logins who best fit
the "enjoy having here." ppl who 'like it here' ... who are they if
not conferencers?
same reality applies to filtering, " for folks who are patient and
don't expect much from our overworked volunteer staff. We
filter for folks who are more into giving than getting."
if that is true, as i wish it were, then the filter is a seive
and need the element replaced.
in fact, it is my opinion that we are filtering for the REVERSE, those
who are more into getting than giving.
>p
|
tao
|
|
response 19 of 26:
|
Sep 16 15:04 UTC 1997 |
re 18: Nope. This is Grex, not MNet. :*
|
albaugh
|
|
response 20 of 26:
|
Sep 16 18:13 UTC 1997 |
I'm not in favor of increasing the "concurrent telnet sessions" count right
off the bat. I don't think anyone has evidence that the CPU with faster net
connections won't be the bottleneck to acceptable system performance for
connected users. I second the notion of putting in the ISDN with no other
changes, and seeing what happens.
|
arthurp
|
|
response 21 of 26:
|
Sep 16 20:18 UTC 1997 |
RAM is the bottleneck right now. We can't support the processes we're
currently running on less than 128M. We've got to solve that problem
before we let more in. My data, ping times under 200ms, but 6.x minutes
to load mail. Mail is a nothing program. If it can't load then there
are too many jobs competing for time. Please don't up the number of
people yet.
|
senna
|
|
response 22 of 26:
|
Sep 17 04:10 UTC 1997 |
And, it seems to me, things gravitate back to the idea of a mail machine to
ease the load.
|
srw
|
|
response 23 of 26:
|
Sep 19 00:23 UTC 1997 |
Load and memory problems both will be solved by the 670.
The advantage of a separate mail machine is that the bandwidth of mail
on the link can be throttled. I like this idea, but I don't see things
gravitating back to it especially.
|
senna
|
|
response 24 of 26:
|
Sep 19 00:37 UTC 1997 |
Bad choice of words on my part
|