merlin@hqda-ai.UUCP (David S. Hayes) (05/10/87)
In article <16608@amdcad.AMD.COM>, bandy@amdcad.AMD.COM (Andy Beals) writes: > I don't know about you, but the last time I dialed-up a > computer, I got line-noise. Interactive smtp is nice but you > need to have an error-free datastream between them. So, anyone > for writing a point-to-point dialup tcp/ip? This discussion seems headed to the general possibility of doing TCP/IP over a dialup phone line, so I'm moving it to comp.protocols.tcp. Ideally, we'd like to be able to write a daemon that can listen for non-local IP requests, check against a list of dial-up machines and their addresses, dial the phone, and then act as a pass-through. All this should be done without any kernel modifications. I don't know if this can be done with current 4.x BSD kernels. Used to be that all BSD sites had source, but with the rise of the workstation vendors, that's not true anymore. Perhaps raw sockets would provide a means to do this, but it's been quite a while since I did anything with raw sockets. Anyone else have any ideas? -- David S. Hayes, The Merlin of Avalon PhoneNet: (202) 694-6900 UUCP: *!seismo!sundc!hqda-ai!merlin ARPA: merlin%hqda-ai.uucp@brl.arpa
kent@DECWRL.DEC.COM (05/11/87)
This topic seems to come up every year or so. I have some old messages (from 83) where a few of us discussed this topic. The raw sockets sort of approach seems good, as far as it goes. The real problem seems to be that the IP protocol family (especially TCP) believe in short packet lifetimes (30-60 seconds for TCP open timeout, ~255 seconds total packet lifetime), and this is hard to achieve in a dialnet environment, where it can take 30 seconds to convince a dialer to dial a number and connect the call, much less get logged in, switch the dial port to be an IP link, etc. On top of that, protocols like SMTP count on being able to reach the destination host directly; there's no concept of uucp-ish store and forward in the protocols. This makes opens take even longer; several hosts in succession may have to dial and open connections, depending on the diameter of the net. There are even desirable configurations where it is impossible to have everyone connected at the same time -- say neither hosts A nor B have dialers, but are both periodically polled by C. A and B can never be connected at the same time, thus can't exchange IP packets. That seems to be where the idea of dialup is incompatible with the IP networking model... Cheers, chris
CERF@A.ISI.EDU.UUCP (05/11/87)
Chris, How about running full TCP/IP on the dial-up link to deal with the problem of store/forward - this limits the application of IP to pt-pt applications such as mail, where the store/forward is outside the context of the initial TCP connection. Vint
kent@DECWRL.DEC.COM (05/11/87)
Vint, That was the plan -- to run all the protocols intact. The original impetus for the idea was to punt explicit store-and-forward mail systems (like uucp). I'm not in favor of introducing any new mechanisms into the Internet that require explicit routing by the user. We already have people doing dial-up IP from home machines, and Dave Mills has had fuzzies doing it for much longer than that (I booted my first fuzzball long distance at 1200 baud in 1983, and it was old hat then). The problem seems to be making multi-hop configurations work with existing TCP/SMTP implementations. chris
minshall@OPAL.BERKELEY.EDU (05/11/87)
How I would do TCP/IP from a micro over a phone line:
1. The user dials up their favorite IP host (TIP?).
2. The user logs in.
3. The user invokes, simultaneously on both sides, programs
which place a remote procedure call interface over the
wire, with reliability. The program on the IP host is,
basically, just a user application.
4. Then, the remote procedure call interface "gives" the
user programs on his micro, the ability to access the
hosts standard TCP/IP services.
Ttalking to a 4.2 system, if after establishing the dial-up
logon, I have a program which says:
{
...
s = socket(....);
if (s == -1) {
...
}
if (connect(s, ...) == -1) {
...
}
if (recv(s, ...) == -1) {
...
}
}
all of the calls "socket", "connect", "recv", etc., would be performed via
remote procedure call to the IP host.
(Better, possibly, would be to implement a standard set of TCP-over-dial
remote calls (like LU6.2 verbs) that everyone would recognize once
the system dependent call setup/login/invocation was performed.)
Note that in this way, we get out of having to assign a new IP
address to the client machine, and the user gets to move his/her
TCP/whatever programs down to his/her micro.CERF@A.ISI.EDU.UUCP (05/11/87)
Chris, If TCP is configured to be pretty persistent, and if there is only the one dial-up, low speed, circuit switched hop, I would think one can get the IP to work - assuming you can avoid dial-up for each packet! On the other hand, to introduce dial-up links virtually anywhere in the topology of the Internet, and low speed, to boot, without a reliable link protocol [forcing recovery to be via TCP] seems pretty hard to achieve. Vint
dms@HERMES.AI.MIT.EDU (David M. Siegel) (05/12/87)
Speaking of dial-up IP... I am looking into hooking up a home Sun-3 to IP via a modem. I was planning on using Serial Line IP (slip) for this purpose, but came up with a few problems: 1) The SLIP package doesn't support logging in to the IP connection, so anyone could dial up to the modem and connect to the network. 2) The SLIP host that's on the Ethernet end needs to know the IP address of the dialup host, so if different hosts can dialup to the IP connection, something must be done to handshake down the dialup host's Ethernet address. Question: has anyone done something like this, and is SLIP the right way to go? -Dave
minshall@OPAL.BERKELEY.EDU (05/12/87)
Chris, Yes, there are two issues here. Circuit-switched IP is one. The other is, for me, how does one extend IP service to a large number of micros, many of which are sitting in someone's home, and connected via a dial-up phone line. My bias is that these do not need to have IP addresses assigned, and so can piggy-back off some existing host. Still, I think these machines need various TCP/IP *client* services (FTP, telnet, SMTP maybe), and I think the remote procedure call is valuable there. Yes, it needs a reliable data link layer, flow control, in-sequence delivery, etc. The user sitting at home would like to move files back and forth between the home system and hosts on the IP network, share file systems with other hosts, login over the network, etc. The RPC mechanism seems, to me, an interesting way of accomplishing that. Greg Minshall
minshall@OPAL.BERKELEY.EDU (05/12/87)
Chris, Currently, a user logged in to one of our IP hosts can now run any/all of the client protocols they would like. When they do this, they run the protocol using the IP host's CPU cycles, and things they do that reference files (ftp, "screen capture" on telnet) they reference files located on the IP host system. What I would like is for any user with an account on any of our IP hosts to be able to dial in (from home), or otherwise connect, and run those same clients from their micro (thus affecting the files in the micro, and using, mostly, CPU cycles from the micro). One of the advantages here is that the user need not submit a "request for an IP address" form to the local administration. Nor do they need to know what IP address they are talking from. I am the first to admit that the RPC mechanism solves only the problem I am posing. Still, I think it is an interesting problem. As to your point about validation schemes, I tend to differ. I agree that the .rhosts scheme has limited usability (and can be something of a security hole). However, I think that the most interesting schemes will be those relying on authentication, keys, etc. (and NOT on knowledge of the remote host name). Again, my purpose is to allow micros to become clients. This is also my bias. Not to prompt any heated discussion, but I am dubious of the desirability of running SMTP servers on large numbers of micros. Here I think the POP-like protocols are more interesting. In those (relatively fewer) cases where it is necessary to run a machine with servers, then a separate IP address (and separate protocols) would be the way to go. I should make clear that I am not even seriously proposing any work in this area at this time. It is just an idea I've been kicking around for a while, and the recent discussion was enough to finally prod me into airing it a bit. Greg
kent@DECWRL.DEC.COM (05/13/87)
Greg, Every time this issue comes up, I wonder why people don't want to assign addresses to micros. Is it just a problem of scale? I realize that most of the micros won't be hooked up at the same time. But, if you're going to have server SMTP service on the micro, that probably means that each micro needs a unique name. If you don't assign it a permanent number, then you have a real headache at startup, interacting with the nameserver database, etc. If you're just talking about having client services on the micros, then you can get away with random names/numbers. But home micros are getting powerful enough that people might want to have server SMTP sitting there. Another authorization problem arises for home micros that want to be remote file system clients. It seems very difficult to use the flexible protection/authentication mechanisms that are appearing if you don't know exactly which host is the client -- the 4.2 .rhosts mechanism breaks down pretty quickly. The contents of .rhosts either becomes all possible dialup hostnames, or is essentially useless. chris
kent@DECWRL.DEC.COM (05/13/87)
The question isn't really how to do TCP on a phone line to allow a micro in, but rather how to build something like a circuit-switched IP network. As evidenced by the mail on the list, lots of people have had user-initiated dialup IP for some time. Most implementations just run IP over the wire (with something like SLIP or compressed SLIP as the data link layer), with acceptable performance. The remote procedure interface is interesting, but you need to build some sort of reliably data link layer under it ... I wonder if it really buys you anything in performance? chris
kent@DECWRL.DEC.COM (05/13/87)
We use SLIP (with some header compression) for dialups from some home machines. Basically, the user logs in and then runs a shell script that does ifconfig and slipconf on the dialup line, and does a similar thing on their home machine. This supplies the IP address and avoids the problem of having an IP port hanging out for anyone to dial into. chris
CERF@A.ISI.EDU.UUCP (05/13/87)
Chris, One problem with assigning numbers or names to micros is that they don't bind to any telephone or other addresses - since in principle a micro is mobile. So you need some kind of authentication to assure that the caller is who he says he is. This isn't insurmountable, but it is like the X.32 (dial-up X.25 ) problem. Vint
Mills@UDEL.EDU.UUCP (05/13/87)
Greg (?), You are making assumptions that a willing 4.x is available to front the application and that a front-end protocol will be designed for it (them). I prefer not to need that horsepower and use IP directly over the micro-IMP (or whatever) link, even if encapsulated in SLIP, hello or other suitable envelope. Address management and authentication is an interesting issue - see for example the schemes used by the fuzzballs (RFC-891) and (a different one) the MIT PC/IP gateway. For authentication I offer a variant of the Needham-Schroeder scheme (e.g. RFC-1004). My point is that we shouldn't have to climb all the way up the protocol stack to connect a PC to the Internet. Dave
Mills@UDEL.EDU.UUCP (05/13/87)
Vint, I can't resist observing that, in the nine years or so I have been running dial-up 1200-bps IP links (mostly over metropolitan areas), the incidence of packets lost to transmission errors has been much less than those due to the circuit simply going on-hook. The nice thing about TCP and the latter is that you can redial during the user-timeout interval, while TCP is retransmitting, and things just go on as before. Now consider the amateur TCP/IP packet-radio experiments being conducted by Phill Karn and several others (including myself), where the packet loss can be as high as one in three on the radio channel. I would agree from experience that the channel protocol needs to be reworked entirely before expecting TCP retransmissions to save the day. Obviously, Phill and friends are leapfrogging the dial-in issue. You want ubiquitous access? Look ma, no telephones or wires even. Dave
montnaro@sprite.UUCP (05/15/87)
I'm sure this is naive of me, but what's a fuzzie (or fuzzball) as referred
to recently in the dial-up SMTP discussion? Replies by mail please.
--
Skip| ARPA: montanaro@ge-crd.arpa
Montanaro| UUCP: montanaro@desdemona.steinmetz.ge.com
(518)387-7312| GE DECnet: advax::"montanaro@desdemona.steinmetz.ge.com"glee@cognos.uucp (Godfrey Lee) (05/19/87)
In article <8705121532.AA19034@armagnac.DEC.COM> "Christopher A. Kent" <kent@sonora.dec.com> writes: >We use SLIP Is SLIP available publicly? -- ----------------------------------------------------------------------------- Godfrey Lee, Cognos Incorporated, 3755 Riverside Drive, Ottawa, Ontario, CANADA K1G 3N3 (613) 738-1440 decvax!utzoo!dciem!nrcaer!cognos!glee