response 26 of 121:

Nov 24 19:27 UTC 1996

grease?

response 28 of 121:

Nov 24 21:03 UTC 1996

(My suggestion of the name "edna" was 75% a joke.  I have no terribly
 bright ideas on this and certainly have no attachment to "edna".  Calling
 it "mail.cyberspace.org" would make a compelling amount of sense, perhaps
 too much to be really Grexian.)

(I don't know how the going-to-another-machine-to-read-mail thing could be
 made transparent.  Maybe there is some way.  Certainly it is possible, but
 one of the goals of this plan is to come up with something that can be
 implemented with existing parts and doesn't require really dramatic new
 software.  We might well be able to evolve toward that.)

Membership perks:  If we allowed all users to telnet from Grex to Edna, 
then many would telnet into Grex then from there to Edna to read their mail.
This would me (1) mail users consuming Grex's incoming telnet ports, and
(2) mail being sent over Grex's link as people read their mail.  This this
would violate the idea of resource separation between Grex's mail and other
activities.

As currently configured, this would not be a major problem because ordinary
users can't telnet anywhere.  However, as currently configured, members would
be able to telnet from Grex to Edna.  This is a perk, but a fairly small one.
We could certainly configure the system so even members can't do this.  But
Let's look at the alternatives:

  (a)  Allow Grex->Edna telnet to all users.  This pretty seriously undermines
       the whole idea of the partition.  It's a big problem.
  (b)  Allow Grex->Edna telnet to members only.  Minimal impact on the
       partition, a noticable, but not huge benefit to members.
  (c)  Allow no Grex->Edna telnet to anyone.

The problem is that alternative (a) is the one that is a big problem.  It goes
a good way toward overturning the whole scheme.  Either (b) or (c) is
technically OK.  So why should we prefer (c)?  We'd have to write new patches
to the kernal to specifically to deny members the access to Edna (while
allowing them to telnet to any other machine on the internet).  It seems
strange to bend over backwards to deny priveleges to members just for the
philosophy of it.  Yes, I think we should prefer giving priveleges to all
users over giving them to just members, but I think it is OK to give
perks to just members when they don't cost us much of anything and the
alternative is to give them to nobody at all.

Still, if people prefer (c), that's fine.  It's certainly do-able and
compatible with the rest of the scheme.

The question with POP-clients is similar.  Right now, I think members and
only members can run POP-clients on Grex.  Nobody does, and there aren't any
installed, but anyone could install one (I think).  If we had a separate
mail machine, interest in such things would step up.  We have the same
three alternatives, with the same costs.  Telnetting someplace and running
a mail program isn't really much different in terms of resource usage than
using a POP-client to connect to a POP-server on that machine.  Within the
constraints of the partition plan, the viable alternatives would be either
to allow it only to members or allow it to nobody.

response 30 of 121:

Nov 24 22:37 UTC 1996

(I like the name gridlock too.)

response 32 of 121:

Nov 25 02:24 UTC 1996

I think I see.  My original proposal  looked like this:

 +----------+    conferencing link                     ___________
 |  GREX    | --------------------------------------- (           )
 +----------+                                        __)         (__
      |                                             (      The      )
      | local network link                           )   Internet  (
      |                                             (__           __)
 +----------+                                          )         (
 |  EDNA    | --------------------------------------- (___________)
 +----------+   mail link

(Actually there are some routers in here, that I didn't draw in.)  Here the
mail link might get jammed with traffic, but the link to the conferencing
system remains uneffected.  But if we open up general access to the local
link connecting the two systems we create an additional fast path to the
mail machine, so mail load (at least as far as reading is concerned) starts
to creap onto the other link.


What Steve Gibbard suggested looks kind of like this:

 +----------+          +--------+   internet link       ___________
 |  GREX    | -------- | ROUTER | -------------------- (           )
 +----------+          +--------+                     __)         (__
                           |                         (      The      )
                           | mail link (slow)         )   Internet  ( 
                           |                         (__           __)
                      +----------+                      )         (
                      | GRIDLOCK |                     (___________)
                      +----------+

Here packets destined for the mail machine have to go through the artificially
slow mail link.  Because of this bottleneck, mail can't consume more of the
internet link than the capacity of the mail link, so the rest of the
internet link bandwidth is effectively reserved for the conferencing machine.
This has lots of advantages, I think.  We only need one connection to the
net, so we look more normal to the outside world and it probably costs less.
We can more simply adjust the speed of the mail link, giving us more control.
We can let all users telnet to the mail machine, because their usage would
still be limited by the same slow mail link.  Allowing POP clients might
still be an issue if we don't want the CPU load from them on GREX, but that
may be less of an issue than network bandwidth.


Steve's plan does seem like a better plan, if it is technically feasible.

response 34 of 121:

Nov 25 05:25 UTC 1996

Ok, I tried reading slowly and carefully, and I still can't figure out the
>answer.  Here's the question:
>What impact, if any, does partitioning, reducing ptys (whatever they are),
>and all the other techie stuff have on us *very* simple users who are on
>antique equipment (Mac plus, 1200 baud modem), can only use dialin because
>we have no other access to computers, love conferencing, and use a moderate
>amount of email, again because Grex is the only internet access that we have?
>  
This is the same question I had in 144, but I'd like to know the impact of
these two schemes in a frame of reference that I can understand.  

response 36 of 121:

Nov 25 06:37 UTC 1996

I was thinking grind.cyberspace.org.  That's what it would do.  I'm so far
behind all the time.  :(

response 38 of 121:

Nov 25 09:41 UTC 1996

  Re 37, one way they may do it is to use NFS or something to make
remote drives appear like local drives, another is to run a POP or
IMAP server that certain mail clients can access.  Those options
have been discussed on Grex before.  I'm about to enter a separate
item to discuss using an IMAP server.
 
  Re 32, in the second diagram, if people typically log into Grex and
telnet to the mail host to read mail, the network bandwidth usage is
about the same as if they'd telnetted to the mail host directly.
However, they'll be consuming a pty on grex, which uses some of its
limited CPU/memory resources.  Running telnet uses less than running
pine, but it would still use CPU resources, so letting everyone telnet
from the grex to the mail host would not be as clean a "partition" as
making people telnet directly to the mail machine.
 
  The shared line idea is what I described in #10; one drawback mentioned
there is that it's easy to set a maximum speed for the net->mail or
net->grex link from the router, but not as easy to set a minimum speed,
unless you limit the speed of both connections from the router, which
leads to inefficient network utilization.  So in the example in the
second diagram, if grex is using a huge amount of bandwidth, gridlock's
share would be less than what the "mail link (slow)" connection allows.
 
  Also, if we get an ISDN router like the Ascend P50, which uses an
Ethernet interface, we'd probably need a separate router (like gryps)
to limit the bandwidth usage of the mail host.  The second router
isn't reflected in the second diagram in #32.

response 40 of 121:

Nov 25 12:56 UTC 1996

1)  I dial in to grex exclusively; if telnet from grex to edna is not
    allowed, how will I read my mail?  I am a member, but local non-
    members may share my concern.
    
2)  Is it possible to partition ptys so that some are not open to
    telnetters but may be used for screen or other local purposes?

response 42 of 121:

Nov 25 18:10 UTC 1996

"Gridlock" is too impersonal.  The new computer needs an identity.  It 
needs a name.  Why not call it "Valerie" in honor of Popcorn and all the 
other Valeries who have used grex:

"Valerie.Cyberspace.org"   Has a nice sound to it! :)

response 44 of 121:

Nov 25 18:38 UTC 1996

.. fron grep to egrep ... from grex to egrex ... the egress for email.
  
and when it is realllllly fassssssssst .... fgrex  

response 46 of 121:

Nov 25 20:05 UTC 1996

As a grex member, I would be seriously annoyed if I couldn't telnet from grex
to the mail machine.  I want to be able to do a variety of things with
"one-stop shopping", such as being able to !mail from within picospan.  If
I had to !telnet from within picospan, then mail, that would be OK,  But if
I had to exit picospan, logoff grex, login to mail-machine, etc., *that*
would be lousy...

response 48 of 121:

Nov 25 21:17 UTC 1996

I would guess that home directories would be in common on both machines, sort
of like the UM.  In that vein, UM uses IMAP clients, which would defeat the
purpose of the seperation, because the CPU/memory hog of the mailer (Pine is
the primary IMAP mailer) would still be on grex, and the link flood of mail
going over the link would still go through the grex link.  Question:  Would
it be possible to have the router send information to the origional off site
source of the login, rather than through grex if someone is telnetted from
grex?  This would get rid of some of the link drain on grex.  You would still
have the CPU and link drain, tho.

This item is linked to coop 9