"Alain FONTAINE (Postmaster - NAD)" <af@SEI.UCL.AC.BE> (02/27/90)
WARNING : this message should probably be classified as 'philosophy' (and even rotten philosophy, if you want). Skipping it will not alter your understanding of the facts. Reading it, while less dangerous than smoking, may still be a threat to your health. While NJE-IP is certainly an easy (well, for those willing to use it, I don't want to imply that it was easy to develop) way to offer the traditional NJE services (for those who were out of town for the last three years, sender-initiated password-free file transfer and interactive messages) on top of an IP infrastructure, I do have some questions. I do think that those 'traditional NJE' services should be available in any network worth considering as ones only external connection, but I don't feel NJE-IP as a correct way to do it in the long term. The logical way to add services in the TCP/IP environment is one service = one client and one server on one port. It would be perfectly possible to devise a proper, lets say 'SFTP' protocol to be used on a TCP port, and then a, uhhhh, IMTP protocol to be used on some UDP port. NJE in itself is a pre-layering monster, were everything is mixed : you throw files and messages at one end, and see bits riding on a (sometimes virtual) wire at the other end. Multiplexing of application flows (messages and files), flow control, multiplexing of the bandwith (multiple data streams), routing, everything is done in the black box. This leads to some stupid things. An example : messages and files are handled by the same monolith, so, unless there are things I am not aware of, messages follow the same routes as files. While a multiple hop S&F strategy is fine for files, it does not make any sense for messages, to which it only adds delay and processing overhead while gaining nothing, since a message is dropped at the first down link encountered..... I am also wondering (but have no definitive idea) if it is wise to try to multiplex several data streams on a single TCP connection. The tradition seems to go in the opposite direction (99% of the FTP sessions involve at least two connections between a pair of hosts, for example), for the benefit of simplicity in the application protocols if for no other reason. Before I get flamed for what I did no say, let me restate what I said in the beginning : I am considering the *long* term, and I do understand that NJE-IP was needed to rapidly fix some real congestion problems. So this is not a critique for the developpers of NJE-IP, who of course were not the developpers of NJE, who in turn are probably not to be condemned given the time when work started on it. You are of course welcome to flame me on anything else.... /AF
Hank Nussbacher <HANK@BARILVM.bitnet> (02/27/90)
>Why is this a dilemma? Since NJE is an inferior protocol to TCP/IP >and Bitnet will serve no function not served by the (soon-to-be- >more-than-merely-logical) Edunet, what is there to mourn in "the >fall of Bitnet"? > >Rick Kirkham In addition to the comments people made to the benefits of NJE: the Internet does not provide any store and forward capability. The physical topology fo the network is transparent to you but to the designers it is not. A host at one end wishing to communicate (telnet, FTP, SMTP) to a host at the other end must sometimes transverse dozens of telecommunications lines. Yes, IP handles alternate routing via IGRP or RIP but the farther one has to go the higher the probability you will not succeed in getting through. That is where NJE comes. Since NJE is a store and forward network, it is imprevious to "down" links. The files/mail just keep moving along - getting closer and closer until they get to their destination. To say that "NJE is an inferior protocol to TCP/IP" is like saying that oranges are a better fruit than apples. Each has its place and in my opinion, one compliments the other. I wouldn't be suprised that one day NJE-IP will be a standard IP protocol right up there with NFS, Telnet and FTP. Hank Nussbacher Israel
"Michael R. Gettes" <GETTES@PUCC.bitnet> (02/27/90)
On Tue, 27 Feb 90 16:06:56 +0100 Alain FONTAINE (Postmaster - NAD) said: >Before I get flamed for what I did no say, let me restate what I said in >the beginning : I am considering the *long* term, and I do understand >that NJE-IP was needed to rapidly fix some real congestion problems. So >this is not a critique for the developpers of NJE-IP, who of course were >not the developpers of NJE, who in turn are probably not to be condemned >given the time when work started on it. You are of course welcome to >flame me on anything else.... /AF Alain, I see nothing in your mail that deserves flaming. I find your line of thought quite correct. My personal opinion is that the important services provided by NJE style services should be ported to the Internet. I personally believe that, in the very long term, NJE as a protocol for internetworking will not be needed. I believe these services will be incorporated into TCP/OSI applications and the world will eventually speak the same language (swahili). /mrg
"Richard A. Schafer" <SCHAFER@RICEVM1.RICE.EDU> (02/27/90)
On Tue, 27 Feb 90 11:57:35 EST Michael R. Gettes said: >... My personal opinion is that the important >services provided by NJE style services should be ported to the >Internet. I personally believe that, in the very long term, NJE as >a protocol for internetworking will not be needed. I believe these >services will be incorporated into TCP/OSI applications and >the world will eventually speak the same language (swahili). Actually, my current belief is that rather than trying to improve the TCP/IP suite with new services, effort should be put into increasing the range of ISO/OSI functions. This may, of course mean moving OSI/ISO (I never am sure which order of the letters I should use at which time :-) functions into an Internet currently based on TCP/IP services, in the long run, as the Internet migrates in the OSI direction. Besides, everyone knows that the *true* international language will be Esperanto. :-) Richard
"John F. Chandler" <PEPMNT@CFAAMP.bitnet> (02/27/90)
> Actually, my current belief is that rather than trying to improve the > TCP/IP suite with new services, effort should be put into increasing the > range of ISO/OSI functions. It seems to me we're always faced with migrating to something new. The question may be whether the OSI suite gets adopted before it's superseded by something else entirely. > This may, of course mean moving OSI/ISO (I never > am sure which order of the letters I should use at which time :-) Rule of thumb: "ISO OSI" is always correct usage in English -- ISO is the sponsoring organization, and OSI is the architecture itself. > Besides, everyone knows that the *true* international language will > be Esperanto. :-) Seriously, I would say that Swahili has a far better chance than Esperanto. It has far more speakers. Despite the fact that BITNET has an Esperanto discussion group but none on Swahili, Esperanto doesn't have much of a constituency -- and that is already better served by English. For that matter, there's still Latin... John
Valdis Kletnieks <VALDIS@VTVM1.CC.VT.EDU> (02/27/90)
On Tue, 27 Feb 90 11:42:19 CST Richard A. Schafer said: >Actually, my current belief is that rather than trying to improve the >TCP/IP suite with new services, effort should be put into increasing the >range of ISO/OSI functions. This may, of course mean moving OSI/ISO (I never >am sure which order of the letters I should use at which time :-) >functions into an Internet currently based on TCP/IP services, in the >long run, as the Internet migrates in the OSI direction. See the ISODE 6.0 package, available on nic.nyser.net and other sites. One of the things being done is an Internet-wide OSI-based X.500 directory service, to replace the old WHOIS service based at sri-nic.arpa. I beleive the White Pages project already has over 100K users listed in it. Valdis Kletnieks Virginia Tech
Roger Fajman <RAF@NIHCU.bitnet> (02/28/90)
> Alain, I see nothing in your mail that deserves flaming. I find your > line of thought quite correct. My personal opinion is that the important > services provided by NJE style services should be ported to the > Internet. I personally believe that, in the very long term, NJE as > a protocol for internetworking will not be needed. I believe these > services will be incorporated into TCP/OSI applications and > the world will eventually speak the same language (swahili). > > /mrg I also agree with this line of reasoning. Convincing the powers that be in the Internet that they can learn anything from BITNET could be a difficult task though. Roger (I agreed with Michael AGAIN???? Better check this out -- seems about as likely as the Berlin Wall coming down. :-)
"Michael R. Gettes" <GETTES@PUCC.bitnet> (02/28/90)
On Tue, 27 Feb 90 20:00:07 EST Roger Fajman said: > >Roger > >(I agreed with Michael AGAIN???? Better check this out -- seems about >as likely as the Berlin Wall coming down. :-) I too have been trying to figure this out. I did get a hair cut the other day -- but I doubt this is the reason. I can only guess that Roger has been working at the NIH too long and has caught something. Roger, I wish you all the best in your recovery. Where shall I send flowers? /mrg
John C Klensin <KLENSIN@INFOODS.MIT.EDU> (02/28/90)
Ignoring the question for the moment of what we presumed-Internet-bigots can learn from BITNET, I've seen one assumption go by that may be worth questioning as people propose migrating services. To a considerable extent, the absence of a sender-initiated file transfer mechanism on the Internet was a rather deliberate design decision, not an accident. Sure, there are some operating system issues, but there are also ways to get around most of them. The theory was that you should have my explicit permission before transmitting a large file into my disk space. This was important in the early days of the ARPANET when "big" computers had fairly small (by today's standards) disk capacity. But it is perhaps equally relevant today, when the modal "Internet machine" in many places is increasing tending to be a fairly "small" workstation, again with limited disk capacity and, perhaps, the "ability" for its other work to be brought to a complete halt while receiving a large file. The last time I looked, there was no sender-only file transfer mechanism in ISO OSI FTAM, either, possibly for similar reasons as well as (possibly) a protocol concern in much of the ISO and CCITT OSI work that has not significantly influenced Internet or BITNET protocol development: making sure someone can be found to pay whatever bills the "administrations" feel like rendering. Back in the early days of the ARPANET, there was a project to build a central archival data store--a "datacomputer"--and, because that device was conceived as using rather slow archival media, the question of a server initiating a file transfer without being a user on the remote machine was addressed (this is the issue referred to in an earlier transaction as the requirement for this type of file transfer in order to permit things like LISTSERV to work). If I recall (it's been 16 or 17 years), there were notions about attaching to a datacomputer server, specifying the retrieval request, and then leaving some sort of one-use-only authorization chit such that, when it was ready, the datacomputer server could initiate a file transfer to your machine using that authorization. That kind of capability would provide all of the capability that BITNET's sender-only transfers do, with none of the dangers, and, with today's technology for, e.g., public key encryption, it should be more feasible than it was a few decades ago. However, when I made some inquiries a few years ago, I could not discover *any* current research in the area of making a connection to a remote server, depositing a request, breaking the connection, and having the response to the request delivered through a secure/with permission/ authenticated mechanism. The proposed OSI RDA protocols were no help the last time I looked, and an inquiry to the relevant working group produced one of those "my this is an interesting problem, no one is thinking about it" responses. Now, ignoring the problem and deciding that the sender should be able to send off anything to anyone, as in BITNET, is certainly a possible solution. But it may not be extremely attractive when people have to pay for lines, packets, and incoming messages and files. And BITNET folks, before advocating it as a general solution, should perhaps contemplate the robustness of their systems and networks, in the presence of an attack based on the unsolicited receipt of a lot of large files. john klensin Klensin@INFOODS.MIT.EDU -------
Dan Lynch <LYNCH@A.ISI.EDU> (02/28/90)
Roger, I hope your comment about "convincing the powers that be in the Internet..." is wrong. (Being a member of the IAB, I can at least speak for one of those folks.) BITNET solved/solves a certain class of problems. So does Internet. (So does SNA, Netware, DECNet, etc...) Internet was based upon a set of assumptions about connectivity, cost and community of interest. BITNET dealt with the same set of considerations. Each came up with different solutions. It appeears that the Internet sytel of networking is taking hold in a whole lot of places. As it "expands" it will run into "subcommunities" that more closely resemble the BITNET category and it is our mutual responsibility to ensure that the services provided to the users are actually useful. I may be a bit off base here, but I'll venture an "opinion/observation" to hopefully help the readers understand my leading remarks about "assumptions". BITNET has two services that are not present in the Internet. THose are : Store and Forward Anonymous file transfer and Interactive messaging. Well, BITNET wins hands down on item one, but not on item two. The Internet has had "chat" and "talk" (I.e., realtime "terminal-to-terminal" interaction) for almost 20 years. It's just that it is not highly used (and therefor not widely known or even implemented) because (this is my own "because") its mail protocl is "realtime". That is, one can send mail and expect that the recipient will get it in a few minutes.This obviates the need for having a "realtime interactive messaging service". I'm not trying to point out "deficiencies". (Money is wonderful stuff...) I'm just trying to point out that good services are good because they meet a real need. All of the BITNET services need to be accomodated in the evolving Internet; maybe not in the identical manner, but definitely in function,for an agreed upon "price". Dan -------
"A. Harry Williams" <HARRY@MARIST.bitnet> (02/28/90)
On Tue, 27 Feb 90 20:00:07 EST Roger Fajman said: > >I also agree with this line of reasoning. Convincing the powers that >be in the Internet that they can learn anything from BITNET could be a >difficult task though. After searching through all this, I'm finding myself also in agreement with Roger and Michael. I also agree that the Internet never seems to believe that any of Bitnet services are worthwhile, and yet seems to be growing number of USERS on the Internet that want connections to Bitnet. (Heaven forbid servicing the users). I find more and more subscribers from the internet that are subscribing to lists on Bitnet listservs that are simply redistributions of internet lists. When I've asked some of them in the past, it was because they found it easier and more accurate. Several also commented on the two big items mentioned here in the past, interactive messages and sender initiated file transfer. I'm also getting a little tired of the internet biased people just drop Bitnet and go to internet without discussing these other issues. The NJE bashing is not appropriate, and I have found less productive than the VM-MVS wars that occasionally get started. At least with that, I usually learn something from Leonard that I can apply to my job. > >Roger Harry > >(I agreed with Michael AGAIN???? Better check this out -- seems about >as likely as the Berlin Wall coming down. :-) Well, we all have our bad days.
"Steven N. Goldstein--Ph 202-357-9717" <sgoldste@CISE.NSF.GOV> (02/28/90)
Interesting dialogs going on here . . . Can you imagine a networking community in which system operators cooperate and share networking resources among DECNET, TCP/IP, NJE, and plain-old X.25, being pragmatic in the interests of their user communities? Would you believe that the leader/spokesman for the IP-group is the HEPnet manager (HEPnet in the States being a closed DECNET community)? Where is this place? Western Europe! Ip-ers, EARN-folk, HEPnet-ers and X.400 afficionados team up to make things work. Protocol wars? "Harumph, no!" they claim--though the bete noir is the subsidized OSI community that is seen pushing solutions that the operational folk do not want down their throats with the force of the subsidies strengthening the hands of the pushers. But, even that "antagonism" seems to be yielding to the diplomacy of the combined communities. Pragmatism is spreading! Concentrations of dogmatism are becoming isolated islands. It is a truly exciting scene. So, keep the faith. Do not give up hope. Protocol bigotry may yield to pragmatism here in the States, too. One small item...I note that nobody seems to have mentioned anonymous File Transfer Protocol in which one "puts" a file into the host of the recipient. Granted, it is a jury-rig compared to the BITNET capability (for instance, the target machine has to permit anonymous FTP, and the recipient has to know that there is a file there to be fetched--requires aonther "go fetch" message by e-mail, phone, etc.--AND the sender has to know the identity of the CORRECT target machine, since the machines on which people actually do their work are often hidden behind a higher level corporate/campus domain name in their e-mail addresses). jBut, I think that the factious fallout of the "Which is better?" debates fly in the face of pragmatic solutions. May I repeat an earlier sentiment sent to the list: my normal mode of communicating is vie [Internet] e-mail...hours per day. But, I am not above sending a FAX when that is the best way to do business, nor FEDEX, nor even a phone call if needed to do the job. Similar diversity in the computer communications world, e.g., Internet, BITNETs of the world, DECnets of the world, and commercial e-mail systems makes it possible for me to reach a wider community of correspondents, and I hope that that scope is never diminished. The protocols, gateway traversals, etc., are of less interest to me than the impact on my ability to communicate. Thanks--this turned out to be 3 x longer than I had intended. Steve G.
"Robert R. Blackmun" <ACC00RRB@UNCCVM.bitnet> (02/28/90)
AMEN to Steven Goldstein's call for diplomacy and pragmatism. Bitnet exists because a small number of poeple originally had that attitude, and grew very rapidly because others apparently adopted the same attitude. One thing that I *would* like to emphasize from Steven's note -- he used the word "subsidy" and "subsidize" twice. We must all realize that the current NSFNet/NREN effort is just that, and like all subsidies, the intent is to encourage decisions in a particular direction. We must make decisions in light of such subsidies, but should have all of the facts, including future costs and benefits when the subsidies disappear (as they must) available. Bitnet, of course, has been "subsidized" by a number of major institutions which pay for backbone links that benefit all members (as well as by an IBM grant the established Bitnic). In looking at any restructuring proposal, one of the issues will certainly have to be how the implicit existing subsidies are resolved.
John Wagner <MAINTCMS@PUCC.bitnet> (02/28/90)
On Tue, 27 Feb 90 23:20:21 EST Dan Lynch said: > BITNET has two services that are not present in the >Internet. THose are : Store and Forward Anonymous file transfer and >Interactive messaging. >Well, BITNET wins hands down on item one, but not on item two. The Internet >has had "chat" and "talk" (I.e., realtime "terminal-to-terminal" >interaction) for almost 20 years. It's just that it is not highly used >(and therefor not widely known or even implemented) because (this is >my own "because") its mail protocl is "realtime". That is, one can >send mail and expect that the recipient will get it in a few minutes.This > obviates the need for having a "realtime interactive messaging service". As I understand this, there is one major difference between the internet implementation and the BITNET implementation. Messages in NJE are given priority over files. I don't expect my message to get there in minutes, I expect it to get there in seconds (which it did to the fellow I was messaging with in Turkey yesterday). It seems to me that the fundamental notion of "more important" is missing in the internet approach. This is not surprising when one expects the connection to be (effectively) machine to machine, but it has always ignored the delays inherent in getting the messge out the socket on the senders machine and from the socket onto the recipients screen. Had the BITNET type of messge processing been seen as useful when the protocols were defined, I suspect there would have been a network wide service for this already (just as there is for FTP). It was not seen as important by the folks who were architecting the internet so it isn't there. That makes neither approach better, just different.
Doron Shikmoni <P85025@BARILAN.bitnet> (02/28/90)
Alan Fontaine writes: > This leads to some stupid things. An example : messages and files are > handled by the same monolith, so, unless there are things I am not aware > of, messages follow the same routes as files. While a multiple hop S&F > strategy is fine for files, it does not make any sense for messages, to > which it only adds delay and processing overhead while gaining nothing, > since a message is dropped at the first down link encountered..... Indeed messages are following the same routes as files, but they are not "Stored", in the sense of putting them to disk or something. In this sense, they are simply handed over by the communication software, as "esoteric packets" - if you think of it, it makes sense to do it. > I am > also wondering (but have no definitive idea) if it is wise to try to > multiplex several data streams on a single TCP connection. The tradition > seems to go in the opposite direction (99% of the FTP sessions involve > at least two connections between a pair of hosts, for example), for the > benefit of simplicity in the application protocols if for no other > reason. It is definitely unwise to go into trouble multiplexing streams over a virtual link that is already multipexed. Of course. Had NJE-like service been developed over a TCP-like protocol, it would most likely have used several TCP streams. I think most people agree that NJE over TCP (why, BTW, is it refered to as NJE over IP?) is not an optimized solution in any way, just an intermediate ad-hoc bridge between two very different network services. All in all, I do agree that NJE over TCP is not a way to go, in the *long* run. Definitely, NJE-like services *can* be developed in the TCP/IP suite. The thing is, that they are currently missing (I do not consider TALK to be similar to the NJE unsolicited-message/command service - and this is not to say any of them is superior. They are just not similar services). Doron
Edward Vielmetti <emv@MATH.LSA.UMICH.EDU> (02/28/90)
(interactive messaging vs. Internet services to do same)
It's my understanding that BITNET uses a type-of-service (TOS)
queueing approach to speed "interactive" messages along
their way while ordinary mail traffic gets a slower
store-and-forward approach.
There is a TOS queuing facility that discriminates between interactive
traffic (telnet, rlogin) and bulk traffic (NNTP, SMTP, FTP data) in
Van Jacobsen's "compressed SLIP" package for running IP links over
slow dial-up type lines on the order of 9600 bits/second -- it
improves perceived performance considerably for normal use. Any site
that's converting over to IP that uses data links in this range should
specify the availability of such priority queueing to make sure that
they can cope sensibly with a mix of bulk and interactive traffic.
I'm not sure what the state-of-the-art type of service
markings are, but here's an indication of how they
are specified in IP (RFC 791) as an example of the
sorts of factors to be balanced.
Type of Service: 8 bits
The Type of Service provides an indication of the abstract
parameters of the quality of service desired. These parameters are
to be used to guide the selection of the actual service parameters
when transmitting a datagram through a particular network. Several
networks offer service precedence, which somehow treats high
precedence traffic as more important than other traffic (generally
by accepting only traffic above a certain precedence at time of high
load). The major choice is a three way tradeoff between low-delay,
high-reliability, and high-throughput.
Bits 0-2: Precedence.
Bit 3: 0 = Normal Delay, 1 = Low Delay.
Bits 4: 0 = Normal Throughput, 1 = High Throughput.
Bits 5: 0 = Normal Relibility, 1 = High Relibility.
Bit 6-7: Reserved for Future Use.
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| | | | | | |
| PRECEDENCE | D | T | R | 0 | 0 |
| | | | | | |
+-----+-----+-----+-----+-----+-----+-----+-----+
Precedence
111 - Network Control
110 - Internetwork Control
101 - CRITIC/ECP
100 - Flash Override
011 - Flash
010 - Immediate
001 - Priority
000 - Routine
The use of the Delay, Throughput, and Reliability indications may
increase the cost (in some sense) of the service. In many networks
better performance for one of these parameters is coupled with worse
performance on another. Except for very unusual cases at most two
of these three indications should be set.
Type of Service
The type of service (TOS) is for internet service quality selection.
The type of service is specified along the abstract parameters
precedence, delay, throughput, and reliability. These abstract
parameters are to be mapped into the actual service parameters of
the particular networks the datagram traverses.
Precedence. An independent measure of the importance of this
datagram.
Delay. Prompt delivery is important for datagrams with this
indication.
Throughput. High data rate is important for datagrams with this
indication.
Reliability. A higher level of effort to ensure delivery is
important for datagrams with this indication.