HANK@BARILVM.BITNET.UUCP (03/29/87)
All the calculations about the bandwidth of a station wagon got me thinking. Why was Tcp/Ip not designed as a store and forward network (in addition to the protocols it does support)? Let me explain why I am asking this. In Bitnet, you might have as many as 20 9.6Kb lines separating you from the place you wish to send a file to. The probably that all 20 lines are working and that all 20 intermediate machines are up (yup - no IMPs) simaltaneously becomes quite small. (Imagine if the probability of any machine being up and working is 98% and that the probablility that any leased phone line is working is 99.5% - after 10 machines - 77.7% successful connection). Well you can say alternate paths and better reliability make the connection rate closer to 95%. I would perhaps doubt that when the two nodes are separated by a number of physical links and that the data has to pass thru a couple of hardware boxes that will not work if there is a power outage in the building or other "things" that can cause a hardware box to not respond. So, a S&F network would alleviate much of the problem. Try to get the data as close to the destination node and then spool it. Instead SMTP makes a valiant attempt to emulate S&F by spooling the mail locally and occassionally trying to establish a connection to the destination. After 'n' of days SMTP gives up and sends mail to the sender. I think it would have been nicer that SMTP try to get it as close to the down node as possible and then let that node try polling the down node for 'n' number of days. But FTP is even worse. FTP is basically an interactive process. You want a file you gotta establish a connection and suck it off or slap it into place. Transferring files should really be a batch orientated feat - you say what file you want to store or retrieve and you type in all the necessary options and parameters and you don't hear about it until it completes (with appropriate return codes of course). Bitnet uses BSMTP (Batch SMTP). Is there such a thing as BFTP (Batch FTP)? Is there a very strong technical reason why S&F was not part of the design of Tcp/Ip?? I have a lot of questions but very few answers. Hank
bzs@BU-CS.BU.EDU.UUCP (03/30/87)
Hank, Your questions mostly focus on design trade-offs. Trying to get the data as close to to the destination node and then spooling might not be defineable in many cases. What does closer mean when routing can be changed? The very notion implies that a route calculated at transmission time remains static (perhaps for days) as the file moves from host to host through the network. This is not always a reasonable assumption. I do think a Batch FTP is a fine idea, many people accomplish this anyhow by backgrounding transfer jobs, others by sending files through the mail networks. One major issue, of course is security. FTP is designed to demand a password before a file transfer begins. Not sure how this is accomplished in batch mode without sending passwords around the net (store and forward exacerbates this problem as passwords may lie on intermediate hosts for long periods of time.) Bitnet basically takes the attitude that it is similar to mail and files are simply put on a spool for a target user, no password to send a file is required. How *does* a user fetch a file within the Bitnet sendfile paradigm? Other than specialized servers for certain files, of course. Another problem with S&F networks at the higher (that is file or mail message) level are the failure modes presented. Clogging of hosts' disks receiving these as intermediaries becomes a problem (I believe WISCVM fell as much as 3 weeks behind in file transfers recently due to this type of clogging? correct me if I'm wrong, I mean no malice.) Packets are much more ephemeral things. There, of course, is also the problem of getting an error or success back to the originator from an intermediate node who decides the file's fate has been sealed. For another extreme, try MAIL-11 on VMS in a DECNET network. You can't send a message unless it is immediately deliverable, very annoying to me to end a message (typically a reply) and have it immediately rejected because the host happens to be down at the moment. This is a place where some kind of store and forward seems essential, I hate "busy signals" in mail networks. I think my conclusion is that it would probably be interesting to see someone propose and design a store and forward file transfer protocol and get it accepted by the community. There are several design problems but I don't think the concept is flawed, why have a human sit and wait on a slow link? Or not be able to initiate a transfer just because a host is down at the moment? I don't think, however, Bitnet is a great model for this at all layers if for no other reason than the fact that the routing is so well defined in Bitnet for where to store and where to forward while in the Internet things get a bit more nebulous. But, hey, that's what the designer will have to solve. -Barry Shein, Boston University
narten@PURDUE.EDU.UUCP (03/30/87)
One big problem with S&F networks is the lack of end-to-end acks. Once you drop a "transaction" (e.g. batch ftp or piece of mail) in the queue of one of the intermediate nodes, it is out of your hands. You don't know where it is, and you can't find out. How many times have you sent mail into a black hole? It happens much more often in store and forward networks than in the TCP world. Based on my experience, when I send mail over TCP to a user, I feel very confident that it gets to them. If the mail gets lost, its almost always because the mail subsystem at the receiving site is messed up. Sending mail through mail lists (which puts in an extra S&F hop) is also pretty reliably, though not as much. On the other hand, when mailing via one of the S&F networks, my confidence falls rapidly as the number of hops increases. You might argue that the reliability of S&F networks could be improved. No matter how reliable you make them, you will still be left with a system where everything you drop in disappears, and there is no way of finding out where it is until it comes out at the other end (if it does). Not too good when you just sent an important message. Thomas
karn@KA9Q.BELLCORE.COM.UUCP (03/30/87)
Actually, I thought the Internet WAS a store-and-forward network. Gateways store up packets as they are received and forward them after a queueing delay. I think you really meant "message switching" as opposed to "packet switching". But even this distinction is rather artificial. One of the most popular message switching networks is UUCP. Like the Internet, each UUCP node also stores up a block of information, makes a routing decision (sometimes specified in a source route) and sends it on its way. The only real differences are quantitative, i.e., the maximum allowable message size and the typical end-to-end delivery delay, although admittedly they heavily influence the way end-user nodes make use of the service. You *could* run TCP on top of UUCP (encapsulating one segment per message) as long as it is prepared to deal with RTTs of several days. On the other hand UDP query-response applications use the Internet as though it were a message switching network, since messages fit neatly into Internet datagrams. Perhaps the only real qualitative distinction is whether the network is useful for "real time" communications, however you define them. Nobody runs SMTP/TCP/IP on UUCP because few are willing to wait several days for a TCP 3-way handshake to complete. Instead UUCP mail consists of single, large, self-contained "datagrams" with no end-to-end protocol other than the implicit human-to-human one. Of course this means you have no real guarantee that the message will get there, so everyone puts in lots of low-level reliability enhancing mechanisms. I prefer SMTP across the Internet over UUCP whenever available, not only because it's usually faster, but because I *want* that end-to-end reliability provided by TCP. Assuming a fully connected Internet, I can feel pretty confident that if my mail disappears from the spool then it has safely reached its destination and isn't stuck in some unknown place halfway across the path. I think the distinction between message and packet switching will blur further as very high speed transmission facilities become available and RAMs get even cheaper. You can allow very large packets on a high speed fiber link without sacrificing "real time" performance. Chopping up a data stream into tiny packets will no longer be necessary or even desirable: the packet rate would get completely out of hand. For example, if each packet could hold an entire NTSC video frame, real time packet video would only be 30 packets per second, well within the capability of even a Z-80 as long as data paths are kept separate. An interesting project would be to see just how applications might make use of "megapackets". Interactive timesharing probably can't make use of much more than a few K (a screenful of text) but clearly file transfers could use much more. (Think of an entire magtape occupying a single packet. At gigabit rates it would still only take a second or so to transmit). Phil
HANK@BARILVM.BITNET.UUCP (03/30/87)
Barry, Which brings me to something I would like to get created: FTP to spool so that no pswds need to make their way around the network. If Bitnet can transfer files to/from Unix, VMS, VM, MVS, CDC, etc machines - WITHOUT passwords then Tcp/Ip should be able to send files around to local spool systems so that the entire concept of FTP pswds can be eliminated. Hank
mckee@MITRE.ARPA.UUCP (03/30/87)
You were concerned about the reliability of S&F. There are a variety of
tradeoffs to consider. The DoD has an ancient but vigorous system
called AUTODIN. It has the following characteristics:
- It is a message switching system; messages are limited to 40,000
characters; each message may have as many as 500 addresses.
- The "switching" part of the system is fairly small; there are 8
AUTODIN Switching Centers in the US, and a few more in Europe and the
Far East.
- AUTODIN is EXTREMELY reliable; however, duplicate messages may
occur during recovery from a failure. The AUTODIN design philosophy is
that it is better to send several messages twice than to drop any
message once.
- Also, during failure recovery, delivery transposition may occur;
i.e., an older message will be delivered before a newer message.bzs@BU-CS.BU.EDU.UUCP (03/30/87)
>Barry, > >Which brings me to something I would like to get created: FTP to spool so that >no pswds need to make their way around the network. If Bitnet can transfer >files to/from Unix, VMS, VM, MVS, CDC, etc machines - WITHOUT passwords >then Tcp/Ip should be able to send files around to local spool systems so >that the entire concept of FTP pswds can be eliminated. >Hank I'm not sure there's much difference between bitnet's SENDFILE and just sending a file via mail. Most of the differences between SENDFILE and Bitnet/Mail (and, actually, SMTP) are simply to accommodate spool record length restrictions within IBM's filing system. This is not particularly a problem when an heterogeneous environment is accounted for and files have to be in some "reasonable" ASCII text format anyhow. Even record length restrictions and binary images can be transferred in more generic ways (eg. UUENCODE/UUDECODE which I've ported to my 3090) than DISKDUMP formats which appear to be limited in function and very much designed with IBM's filing system in mind. I suppose VMS's jnet (bitnet) product accommodates this, but I assume only by being subservient to IBM file formats (and a very, very limited subset at that, as far as I know there is still no way to send, eg, a PDS between even two IBM systems via Bitnet without some user hackery.) The other half of the difference would be accomplished by adopting some convention that files are sent to, say, user-fxfr@host so it appears in a different spool or just marking the header so mail user agents could pluck out "file transfers" from the mail when they start up. I think this is a minor need, the Subject: line can get you 98% of the way there without changing anything. The "entire concept" of FTP passwords is useful in that it allows a user to get at files either destructively (in a positive sense) or past normal security (that is, files not publicly readable.) I don't think getting rid of this feature is a step forward. There are already passwordless protocols in use (eg. TFTP in the internet world and transferring via uucppublic in the UUCP world.) For obvious reasons they seem to have limited acceptance when FTP is available. They're mostly a security botch, especially when fetching of files is needed. -Barry Shein, Boston University
geof@imagen.UUCP.UUCP (03/30/87)
> Which brings me to something I would like to get created: FTP to spool so that > no pswds need to make their way around the network. [sorry for not answering directly, I don't have a reliable path from USENET to bitnet -- my packets always go into a black hole :-] I think that you are arguing for new conventions, not new protocols. Queuing of FTP requests is something you can program on your local machine. As pointed out, in the internet, a host has no concept of "closer", so it is impossible for a store and forward FTP to do anything other than what SMTP does now. Unless you do manual routing. Augh. Similarly, who says that Arpanet mail has end-to-end ACKs? It just depends on where you put the "end." I put it at the user, and I want to see explicit acks from users, too (well, I flame so much that it actually doesn't matter to me if some of my typed jewels drop on the floor -- but when I care, I ask for an explicit response). For example, I recently looked over the shoulder of another user, and discovered that he didn't realize that MM would only show him the messages as "NEW" once -- after that they were only marked UNSEEN. About three weeks before he had been cut off by a bad phone connection, and thus missed reading 2 important messages for three weeks - until I showed him that MM still had those messages marked UNSEEN (he didn't know what the U was for). So what good was Arpanet's ~100% reliable delivery there! On USENET it is normal to keep a copy of a sent message until you receive an ACK for it, manually sent by the recipient. It is reasonable etiquette to ACK a message when you receive it (unless you want to be able to claim that you didn't receive it :-)) with a small message that says "I got your message" or even just "ack". My opinion is that mail reading software should encourage this behavior by suggesting such a reply and having an automatic way of generating it. - Geof
gds@SPAM.ISTC.SRI.COM.UUCP (03/31/87)
Which brings me to something I would like to get created: FTP to
spool so that no pswds need to make their way around the network.
If Bitnet can transfer files to/from Unix, VMS, VM, MVS, CDC, etc
machines - WITHOUT passwords then Tcp/Ip should be able to send
files around to local spool systems so that the entire concept of
FTP pswds can be eliminated.
Hank
I would like to know what sorts of access controls are used in Bitnet to
allow or deny a user access to
* a remote file they own
* a remote file they don't own, but is not protected
* a remote file they don't own, but is protected
and how such users are prevented from sabotaging remote disks ...jon@CS.UCL.AC.UK.UUCP (03/31/87)
Actually, I thought the Internet WAS a store-and-forward network. Gateways store up packets as they are received and forward them after a queueing delay. I think you really meant "message switching" as opposed to "packet switching". Yep. In the UK we use a spooled FTP system called NIFTP (Network independant file transfer protocol). This works over anything and we have it on 11/44s on Cambridge rings, vaxen and pyramid, TCP/IP over ethernet. The spec says you can checkpoint files, so it will work over junk networks without having to break large files down yourself. It also does binary etc, and it does some sorts of run-length encoding, for people with 30bps packet radio nets! It also has sensible authentication, unlike ftp which seems happy to send LOGIN passwords around on networks without encryption (try and sell that to a commercial company with ethernet). The spec may be got from the Joint Network Team in the UK. Implementations for ?NIXs exist. Why reinvent the wheel, when you can get a halftrack for free - or you could wait for FTAM. jon
narten@PURDUE.EDU.UUCP (03/31/87)
Geof, >Similarly, who says that Arpanet mail has end-to-end ACKs? It just depends >on where you put the "end." I put it at the user, and I want to see explicit >acks from users, too True, there will never be real end-to-end ACKs if you take things far enough. An ack for a mail message to some would mean "mail has been received and READ (and understood :-))". A reasonable compromise would be a confirmation that the message has been placed in the recipients mailbox. Presumably, as domain names get extended, we will be able to do that. Any mail you send to a user can go directly to the machine where the his/her mailbox resides. No forwarding at the site would be needed. >On USENET it is normal to keep a copy of a sent message until you receive >an ACK for it, manually sent by the recipient. It is reasonable etiquette >to ACK a message when you receive it I don't find that acceptable as a *general* way of doing business. This puts the burden on reliable delivery on the sender and the recipient. That works for some cases, but requires voluntary compliance of all users (some who know nothing about mail and networks). Each user has to think about things such as "Is it time to send the mail again? I don't have an ACK yet." It is unworkable when mailing to lists (for which mail needs to be just as reliable), when the receiver is out of town, etc. etc. It is especially a burden for those that send and receive large quantities of mail. >My opinion is that mail reading software should encourage this >behavior by suggesting such a reply and having an automatic way of >generating it. This just confirms that most people want reliable mail delivery. Hence, the burden should be shifted from the user to the software used for the delivery of mail. It is much easier to do this with a transport level protocol that connects directly with the destination machine than over an S&F message switching system. Thomas
honey@CITI.UMICH.EDU.UUCP (04/01/87)
a man after my own heart -- reinventing uucp. i'm with you, bro'. peter
gds@SPAM.ISTC.SRI.COM.UUCP (04/01/87)
A reasonable compromise would be a confirmation that the message
has been placed in the recipients mailbox.
If you'll allow that the message has been placed in the user's maildrop
(/usr/spool/mail/user), sendmail has a feature such that if it receives
mail with the header Return-Receipt-To:, it will generate an ack to the
address listed there. (The address must be replyable from the
receiver's context, so it must contain a full reverse path for a
reliable ack.) You are pretty much guaranteed that the mail has been
committed to stable storage (if not the maildrop, the sendmail spool).
Presumably, as domain names get extended, we will be able to
do that. Any mail you send to a user can go directly to the machine
where the his/her mailbox resides. No forwarding at the site would be
needed.
I'm not sure what you mean by this. In the ARPA Internet, mail goes
directly from the sender's site to the recipient's site unless
forwarding is specified. UUCP requires forwarding at intermediate
nodes. Even if the UUCP namespace were entirely mapped out, you
couldn't have mail going directly from sender machine to recipient
machine unless everyone called everyone else, which will never happen.
I think we're mixing concepts here a bit. "reliable delivery" to
gds@spam.istc.sri.com is accomplished when something has been delivered
to a process on spam.istc.sri.com which will leave the mail where "gds"
can access it. "reliable delivery" to the human Greg Skinner requires
that he read it. I think it would be asking too much to modify mail
software to require acks, not to mention a problem for sites which don't
have source.
--gregboCERF@A.ISI.EDU.UUCP (04/02/87)
Hank, we didn't do it because I think we didn't think it was necessary but that's because we started with just one network and tried to extend the earlier services to the Internet. The mail forwarders are really store/forward when you think about it. Also, you need all the mechanisms for error reporting that the mail system has in it to recover from failures. Vint
narten@PURDUE.EDU.UUCP (04/03/87)
> Presumably, as domain names get extended, we will be able to > do that. Any mail you send to a user can go directly to the machine > where the his/her mailbox resides. No forwarding at the site would be > needed. There is still a hole with current TCP mailers in that often mail really travels an extra hop. That is, mail for janedoe@somewhere.edu gets sent to the machine at "somewhere.edu", which after accepting the mail, turns around and forwards it the machine the user reads mail on. I would prefer an acknowledgement that mail has actually been placed in the users mailbox, rather than just handing the mail to a "reliable" delivering agent at the site. Domain names were designed to handle lots more than just machine name to IP address mappings. At some point, it will (hopefully) be possible to register mailboxes in the system. That way, mail sent to janedoe@somewhere.edu will not necessarily mean sending the mail to "somewhere.edu". Rather, sendmail will find the real agent via nameserver queries about "janedoe@somewhere.edu". Now mail gets sent directly to the machine where the user's mailbox resides, and now when the mail is no longer in the sender's local queue, it really is in the correct mailbox, and not still in transit somewhere. Thomas
gds@SPAM.ISTC.SRI.COM.UUCP (04/03/87)
There is still a hole with current TCP mailers in that often mail
really travels an extra hop. That is, mail for janedoe@somewhere.edu
gets sent to the machine at "somewhere.edu", which after accepting the
mail, turns around and forwards it the machine the user reads mail on.
I would prefer an acknowledgement that mail has actually been placed
in the users mailbox, rather than just handing the mail to a
"reliable" delivering agent at the site.
Like the gentleman from rice said, you don't always know when mail is
placed in the user's mailbox. It may be a post-office type system,
where mail is read from a mail server, but composed from the mail
client. Everything is done without forwarding. When do you decide that
the mail is in the mailbox?
Domain names were designed to handle lots more than just machine name
to IP address mappings. At some point, it will (hopefully) be possible
to register mailboxes in the system. That way, mail sent to
janedoe@somewhere.edu will not necessarily mean sending the mail to
"somewhere.edu". Rather, sendmail will find the real agent via
nameserver queries about "janedoe@somewhere.edu". Now mail gets sent
directly to the machine where the user's mailbox resides, and now when
the mail is no longer in the sender's local queue, it really is in the
correct mailbox, and not still in transit somewhere.
It still might be in transit somewhere -- the mailbox entries may point
to non-Internet sites which will require at least an extra hop at a mail
bridge.
Does this "ack" scheme imply retransmission of a mail message until a
retransmission timeout? I would hate to see those old "Message queued
for 3 days -- will try again for another 12 days" messages from mailers
coming to my mailbox again.
--gregboRudy.Nedved@H.CS.CMU.EDU.UUCP (04/05/87)
The concept of distributing internal configuration information to everyone in the world is too prone to failures from too much information. Assuming that people will extensively use the domain system to publish current routing information for mailboxes and dealing with cacheing and all the other problems is expecting too much. The idea is a nice one alas a very flawed one (from too much data). The trick at this pont is to just get a reasonable mail relaying mechansim up and to get rid of the host table. The MX records solve in a not so great way the problem of mail relaying for hosts not on the connected network alas a better algorithm has not been thought up that did not get shot down (heck, we can not even get packet routing right...how do you expect to get mail routing right?) Also many places are still using the host table mechanism and are starting to suffer because of the size problems....alas they have received temporary relief in the form of a 10% smaller NIC table. Let us keep an eye toward the future but make that first couple of steps instead of just dreaming about the future.... -Rudy