Paul Bryant's Networking Correspondence
There were about 40 people present representing most of the American and European networks, countries and network centers. Most of the participants were well known and respected experts. This was a real workshop in that attempts were made to plan and initiate work.
The principle subject was how we should attempt to interconnect the academic networks with particular reference to mail.
Discussions were extremely interesting, lively and fruitful. This was probably because, even though many people had not met before, they had all met on many occasions via the many electronic mail systems, in particular Swedish Com. This was a real demonstration of how electronic conferences can prepare a lot of the ground for a face to face meeting. I came away feeling more convinced than ever of the value of electronic mail and conferencing.
This was devoted to very short presentations from the major networks to bring people up to date. In fact one felt that most people were up to date and that perhaps the time could have been better spent in discussion.
Many of the talks dwelt on the protocol issues and the development of gateways. The principle application discussed was mail, other applications had very little consideration. This was not surprising since Jacob Palm had produced a paper defining the objectives of the meeting which were firmly based on CBMS interconnection and most participants based their presentations on addressing this problem to a greater or lesser extent.
I have a large batch of quite interesting papers from many of the networks which are available for study.
Day One had thrown up a number of very interesting points:-
Following these observations a number of working parties have been set up to study the problem area. These being:-
Gateways Tariffs Conferencing Name servers PTT Problems.
I am the chairman of the gateway group. The groups will meet via COM at QZ so the next face to face meeting will not be for a year and moreover the chairman job will probable be only to write a report or proposal when decisions have been made.
This was one of the most fruitful workshops I have attended in that real results are likely. Moreover we all felt that action was urgent and timely.
The next meeting will be in Jerusalem in 1985.
Dear ...,
At the recent EARN Board of Directors meeting I was asked to undertake the technical coordination of EARN.
As yet I am uncertain of the existing or planned products and documentation as well as the longer term requirements for our network. I am therefore proposing to collect, catalogue and disseminate documents and information coming from the EARN sites and possibly BITNET ones.
Attached are the first few documents which have come my way. The first document (EarnTech/1/84) is a list of the names and addresses of the Board of Directors and their IBM colleagues. Please could you check the details and give me any corrections.
Also attached is a questionnaire aimed at finding out EARN specific products and documents which are in existence or planned. When I have received your replies I will produce an analysis. I hope this will lead to the avoidance of duplication of effort and cooperation between the members. I am very happy to receive any existing technical material and will undertake to duplicate and circulate 'modest sized' documents. If you would like to distribute documents yourself may I ask you to get a document number from me (or my secretary Sue) so that I can keep the records up to date.
Finally can I urge you to complete the questionnaire as soon as possible and preferable before the end of July.
Best Wishes
Paul Bryant.
Please correct your name and address:-
I have produced the following documents (please enclose for distribution if possible):- ....................................................................... ....................................................................... ....................................................................... ....................................................................... I am producing documents on the following topics:- ....................................................................... ....................................................................... ....................................................................... ....................................................................... I have produced the following EARN specific software:- ....................................................................... ....................................................................... ....................................................................... ....................................................................... I am producing the following EARN specific software:- ....................................................................... ....................................................................... ....................................................................... ....................................................................... I believe the following software is required:- ....................................................................... ....................................................................... ....................................................................... ....................................................................... Any other comments:- ....................................................................... ....................................................................... ....................................................................... ....................................................................... Thank you for completing the questionnaire. Please return it to:- Dr. P Bryant Computing Division Rutherford Appleton Laboratory Chilton, Didcot Oxon OX11 0QZ
Present:- P Bryant Rutherford
P Girard Rutherford
R Cooper Joint Network Team
C Setford IBM
A Proudman IBM
E Hedger IBM
There were no corrections.
P Bryant has written to BT asking for clarification of some points and the reply has been circulated. It appears that Israel is a non European country for tariff purposes. The rest of the clarifications are probably now irrelevant in the light of CEPT negotiations.
Negotiations for the acquisition of a suitable multiplexer for Rutherford laboratory continue and are discussed below.
More details of the mail system to be used have been obtained from Ira Fouch but more are required.
Support for the production of gateway code is discussed below.
It is understood unofficially that Dennis Jennings and possible Herb Budd met M. Toutan of CEPT and it was agreed that the international lines could be used prior to an agreement on tariffs which should be obtained in September 1984.
As soon as written confirmation is obtained Chris Hobson of the DTI Regulatory Affairs Department will be asked to sanction the use of the lines from Rutherford.
ACTION: P Bryant
It was agreed that any publicity should await final confirmation of permission to proceed as well as preliminary testing of connections. This would avoid embarrassment.
A document would be prepared for inclusion in Network News, FORUM (Rutherford's computer information journal) and the IUCC bulletin. A draft will be produced for comment.
ACTION: P Bryant
It was agreed that a press release was desirable but that this should be done in conjunction with the BOD. Dennis Jennings will be asked to put it on the next meetings agenda. P Bryant will talk to Herb Budd at Davos next week. A draft will be produced.
ACTION: P Bryant
Only file transfer will be available initially. This will not preclude the use of mail but the users will have to be given a temporary account on the Rutherford machines to achieve this. This possibility will be investigated with Rutherford management.
ACTION: P Bryant
Documents for file transfer exist but will need revision when more is known about how EARN will be organized technically.
It was noted that users would first go to their local computer centers advice center who would know about EARN. The center would ether be able to help directly or would seek help from Rutherford. It was not expected that Rutherford would be the primary source of help but only the place of last resort.
Rutherford is prepared to sign a document of understanding on the lines of the draft prepared by Colin Setford. The draft has been returned with a few minor corrections. It may take some time for IBM administration to prepare a final document. In the mean time IBM agree to meet any line costs up the end of 1984.
This connection has political difficulties in that traffic of a commercial nature must be prevented. It was noted that Alvey was not allowed to have direct connection to JANET. It was considered that Alvey was commercial whereas the traffic between VNET and JANET would only be for academic purposes. Ideally such traffic should be 'sanitized' by passing over a public network but this is not currently technically possible.
Further discussions will be held with Peter Linnington and Mike Wells of the Joint Network Team.
ACTION: R Cooper
Further technical information has been requested from Ira Fouchs and this is required before any definitive proposal can be made. The job is still expected to be between 3 and 6 months of effort. Rutherford has no staff available to undertake the task due to complement problems. If finance were available then effort could be found internally or possible externally. Ideally it is advantageous to undertake the work at Rutherford so that expertise in EARN can be built up. IBM agreed to consider a request for finance to support up to five months of staff effort. This would be costed at Rutherford's internal rate of about 22000 pounds per year or pro rata. P Bryant will write to C Setford requesting support.
ACTION: P Bryant
The line to CERN was installed and disconnected pending the CEPT agreement.
The two modems will be shipped to P Bryant at Rutherford as soon as possible.
ACTION: C Setford
In order to guarantee EARN service and allow Rutherford freedom to reorganize there computing equipment Rutherford are requesting the provision of a small communications multiplexer. P Bryant will write to C Setford requesting support.
ACTION: P Bryant
IBM kindly agreed to provide RSCS support should this be required.
3 October 1984 (after the BOD meeting)
M3.3 Ask permission to use lines. P Bryant
M3.4 Prepare draft document for newsletters. P Bryant
M3.4 Talk to H Budd about press release and
prepare draft. P Bryant
M3.5 Investigate use of Rutherford for mail
pending the gateway code. P Bryant
M3.7 Initiate discussions on VNET connection. R Cooper
M3.8 Request support from IBM for staff. P Bryant
M3.9 Ship Modems to Rutherford. C Setford
M3.9 Request multiplexer from IBM. P Bryant
Most of the traffic to other countries over X25 networks is interactive and use the so called Triple X protocols. At Rutherford Laboratory there has been considerable use of foreign machines as well as use of Rutherford machines from abroad. Much of the traffic has been generated by the High Energy Physicist but the Library has also been a heavy user due to the growth of library data bases.
Green Book makes the basic assumption that we live in a well ordered network world. We all follow Green Book carefully and so interconnection is easy. Whether this is true or not for JANET I will leave to your judgment. That it is untrue for international connections is very apparent. Foreign sites in general have never hear of Green Book and even if they had would not want to follow it. Indeed, these sites may often not have the resources to do anything about the kit they have purchased from manufacturers.
Triple X allows some parameters and some parameter settings to be optional. Green Book uses optional parameters as they are available on PSS. Most networks do not use the optional features so even conforming equipment may have difficulties communicating.
It seems that the majority of overseas implementations of triple X are poor. Many of them do not follow the rules of the protocol. For example, PADs may not respond to a read parameter command or may reply un truthfully. On the host side implementations may not set parameters and thus leave the PAD in ignorance of the parameter settings required for successful communications.
In the early days of international traffic it was the exception rather than the rule to get satisfactory communication. The effects were strange. Double spacing was a popular fault. No spacing at all has been known. Often on attempting a 'break' a PAD may turn delivery of data off and the host may never turn it on again and the user is left with a seemingly dead terminal.
As a result of these problems we set about attempting to see if implementations could be written to cope with these problems. This work was under taken on a GEC 4000 machine.
It turned out that it was possible to construct both PAD and host software to deal with the vast majority of overseas sites. The approach taken was to produce implementations which tried to automatically learn what the other end was up to. For example, if a PAD does not follow a carriage return with a line feed then it is a fair bet that parameter 13 has not been dealt with correctly and so the host should set it to 0.
The details of how to produce good implementations have been published in the addendum to the Green Book recently produced by CTIG. The reader is invited to seek details from that document which also has a lot more useful information.
As far as I know there have been no other attempts at producing intelligent PAD and host implementations of triple X. This is a pity since experience shows that they are not very difficult to produce and give the user a very good interface where, in general, he does not have to bother to meddle with parameters. It is well known, or should I say painfully obvious, that so far there are no good PAD user interfaces that allow a user to sort out his problems and so automatic means are vastly superior. This does not mean that the automatic means should not be overridable in extreme situations.
It is a disappointment that there are so many poor implementations overseas and it is also a disappointment that so few intelligent implementations have been produced. It is hoped that this article will encourage more.
Dear Lassi,
It was a real privilege to attend the IBM European Institute on Trends in University Computing. Rarely have I experience such a pleasant and fruitful week. I certainly went away with many new friends and many new ideas that will keep me busy for a long time.
May I thank you and your excellent helpers as well as the hotel staff for making this such a memorable experience.
I hope I will have the opportunity of taking part in the suggested meeting on computer conferencing next year which is a topic of great interest to Rutherford.
Yours sincerely
Paul Bryant.
Dear Colin,
Further to our 'phone conversation I list the various things that have come up.
The IBM Institute at Davos was extremely pleasant and profitable. There was a lot of discussion on EARN both formal and informal. A few of the B of D were there as well as Ira. I met Peter Hilton from Hursley and we had some very long discussions. I was interested to learn that the RSCS that you run is as hacked about as ours is.
With best wishes
Yours sincerely
Paul Bryant
The week was split into two. The first two days were an Executive Program when the 40 or so delegates were joined by 40 or so heads of Universities and like organizations as well as 20 or so press. The last three days were much more informal.
The event was clearly designed to show how IBM were supporting Universities. Most of the talks were describing various large scale projects supported by the company. There were a few talks from academics describing other activities. I felt Rutherford should attempt to obtain more academic support from IBM.
There were 2 main themes which also carried over into the rest of the week. These were the personal work station and networking. Major projects at Carnegie-Mellon, Waterloo and Ryerson were presented, all these sites had had substantial support from IBM. These projects were very different and very expensive and were clearly pilot projects before the main invasion of work stations takes place.
At the Executive meetings networking talks included EARN, ESPRIT, work at Karlsruhe and EDUCOM. Certainly no X25 or ISO, this came in the second part with presentations from Stockholm and myself.
The first two days were rather 'stuffed shirt' and the 'lads' were invited to dress accordingly. Questions were not welcome and the presence of the press was a little dampening. The organization was immaculate. None the less the talks were very instructive.
Prof. Elliott, chairman of the Computer Board, described computing in the UK. He described the proposed University work station which looked pretty poor when the US projects were described which out performed the Computer Board proposals now.
It is clear that several major sites believe that the age of the personal work station is almost with us and that pilot projects were needed to lead the way. It is sad that no comparable projects exist in the UK. Most of the projects had installed fairly massive numbers of devices linked in networks.
The MIT Athena project is a five year project in using computers in the curriculum. $50M of hardware had been obtained from IBM and DEC represented by 2600 work stations and a network. The aim was to encourage but not demand the use of computers in all discipline by making equipment very available. Means of providing teaching material, sharing of information and access to special facilities are provided.
Brown University has a Scholar's Workstation Project. A broad band network had been put in to support the stations and servers of many kinds. They expected the scholars to purchase the low end work stations and had made appropriate arrangements. They expected to buy $2M of Apple machines over the next 3 years. Incidentally I understand that Yale insists on students obtaining their own computers.
Ryerson (Toronto) had received $5M out of $30 donated by IBM Canada. Here the project was more traditional being based on terminals to large mainframes.
At Stanford IBM PCs had been introduced into the humanities with all staff members having them to help with their work. Courses had been run with the aid of the computer center. The results had been very encouraging in that the speed with which research results and papers had been produced was spectacular. From a technology point of view is was not ambitious in that only well tried products were used such as Word Star.
EARN had its airing as did BITNET but this is well know ground.
The IBM internal network, VNET was presented by Peter Hilton of Hursley. He gave a warts and all presentation. It turns out that the Hursley communications software is hacked left right and center to make it work sensibly. They have the difficulty of getting the production side of IBM to take their fixes and changes. I get the strong impression that anyone who expects to run large systems without significant changes to the software provided is unlikely to succeed. Interestingly VNET started informally as did SERCnet. As with SERCnet the trouble started when management noticed it and started to try and control it.
CSNET was presented. This is not so much a network but an assembly of bits and pieces of other networks to provide services to computer scientists. It is quite impressive that such a network can be put together and made to work with all the gateways involved. In fact, I am a well known user of the network which I use to get in touch with Larry Landweber who runs CSNET and is a mail expert.
Birgetta Carlsson described Sunet, the Swedish network entry, this is built on the same lines as Janet but based on the public network. They face the same problems as we do- how do we get to ISO. Birgetta was persuaded to give a presentation of KOM which was very lively. We almost got IBM to support it. We think we have persuaded them to support a conference on conferencing next year. It is clear that conferencing is becoming a very important topic and that KOM is the most likely system to succeed.
My own talk on JANET was received with the usual standing ovation.
I feel that the day when we all have a work station on our desk is now close. What it will be is in question and also the infrastructure round it. The views are very different. Mackintosh, Apollo and the IBM PC seem the front runners with UNIX following on. The problem with UNIX seems to be the user interface which is not too good for the man in the street. I got little feeling for what network would be used. Everyone had tried something different. I was impressed by the Sytec broadband network at Brown which seemed to have a lot of potential as a backbone.
On the network front mail and conferencing are the important topics. I believe we should be putting a lot more effort into this area as I believe that communication between the scientists is important and also economic. The enthusiasm for ISO protocols was not very apparent which was not surprising considering the make up of the delegates.
In all this was a most useful gathering and I had some very interesting discussions into the late night and made many new contacts both within and outside IBM.
A very lively and useful meeting. Topics included the TELEX gateway, PRESTEL gateway, X29 over ISO session, transition to harmonized standards, Ethernet, and CCITT 1988.
There were strong complaints that BT was ignoring the technical objections CTIG have to certain aspects of the protocol. We now intend to bypass BT, who failed to respond to an action to explain their attitude, and will be complaining to DTI.
The lamentable absence of international TELEX is a separate but more important issue and I agreed to find someone influential in BT sales to exert pressure.
We considered the PRESTEL X25 gateway. We did not have strong feelings but considered that the current method of connection via a reverse PAD should be improved.
The proposal by DTI was unanimously rejected. We considered that the inclusion of session layer added nothing and that the current scheme of X29 over transport should be used for ISO as it is for Yellow Book. We were also unhappy with the idea that eventually X29 could be run over presentation. We felt the incremental inclusion of protocol layers would be disruptive and added no functionality. We also concluded that X29 should be changed as little as possible in being defined to run over transport. In particular we were not happy that unsolicited indications of parameter settings should be encouraged.
Regretfully nothing has happened. We wanted some test implementations.
Just a nice chat.
We agreed to formulate a set of proposals.
The first area is to attempt to make all parameters and their settings mandatory. In addition a few illegal parameter settings should become legal. I will be writing a paper.
The second area is to investigate block mode working. Here a paper is expected from BT.
The third area is to extend the X28 user interface to be more user friendly. Here CAMTEC will provide a paper. Incidentally, CAMTEC intend to support X28 as an alternative user interface- I've won at last.
Dear Chris,
There have now been some useful developments in the efforts to get the EARN network operational.
The chairman of the EARN Board of Directors, Dennis Jennings, has now had a meeting with M. Toutan of CEPT and has reached an interim agreement on the EARN international connections.
I attach a memorandum from M. Auroux together with a letter to Dennis Jennings. The documents suggest that we can now proceed with the development of the network and work out the tariff details before September. May I therefore ask you to authorize the commissioning of the lines to Dublin and CERN as soon as possible? Could you let me know if there are any further problems preventing connection as I have been asked to report progress back to the Board of Directors.
I am happy with the requirements placed on us by CEPT to move towards the use of ISO protocols and the use of public networks. In fact at the recent Board of Directors meeting all the members were happy to make such a transition as soon as possible particularly as the ISO protocols will provide added features such as interactive facilities. We are already exploring various ways in which we can achieve a fast transition. Possible means include the interim use of the UK Colored Book Protocols or perhaps use of the RSCS protocols over X25. We are also pressing IBM to provide the necessary systems which is, of course, the ideal solution.
I am still worried over the tariff levels. The problem is that IBM is unhappy with a scheme which involves them with an open ended commitment. In addition the tariffs listed in your letter seemed to me to be rather high. I would be very pleased if you could use your good offices to try to negotiate a lower and fixed tariff. I understand that a number of countries will be levying a zero volume tariff.
In requiring us to eventually use the public X25 networks doubts have been raised as to whether the current international connections can cope with the traffic. We think that these connections are only one or two 9.6K connections in the case of UK to Switzerland and therefore may be strained with the addition of a further 9.6Ks worth of traffic. I would value your comments on this point. It would be useful if you could provide details of the capacity of the international connections and how this capacity is expected to grow.
I guess that with the changes in BT I have now got your title wrong, my apologies. I hope you will still be dealing with EARN though.
Thank you for your help with this project.
Yours sincerely
Paul Bryant.
To:David Baugh R1 Cc:Jed Brown David Rawlinson
You asked for comments on the Logica VTS 'the Kennet' and 'PC Exchange' and whether they could be Lab standards.
The documents you sent me were a masterpiece of non information in keeping with much of the information from suppliers.
First the PC Exchange.
It is impossible to tell from the document what technology is being used. Is it Cambridge Ring, Ethernet, Token Ring or whatever? What speed does it use? What installation requirements in terms of cable is used? The only clue is that it seems to use modems which need BABT approval. This indicates that it uses good old RS232 which puts it in the class of steam age technology. If this is the case then we are already very well supplied with such communications products such as our X25 network and various other odds and sods. I would be very opposed to anymore of this technology WHICH DOES NOT FOLLOW THE CURRENT STANDARDS. I very much doubt if this does follow our standards. Thus I am not enthusiastic without a lot more information on the nature of the beast.
The information on the Kennet is not quite so vague. This looks to be a PC look alike. Thus it suffers the advantages and disadvantages of the PC. BUT BEWARE all PC look-alikes are not alike. Some are not very compatible with the real PC and can thus only use a subset of the software and other PC products. I would not buy one before I had seen a report on it as regards its compatibility in the magazines. If you want a PC look alike there are about 20 or thirty to choose from including a few British. This product must be compared with the genuine PC on price, speed, compatibility and whether it fits in with the decor. Incidentally I am having a demo of IBM's Display Writer code for the PC on the 31st of this month in the Atlas Building at 10.30. How good it is will be interesting to see.
The documents lay claim to 3270 capabilities. The IBM PC can imitate a 3270 with an IRMA card for use over coaxial connections or with a very cheap card using the X25 network (just like a full screen Cifer but a lot better). Thus the PC in transport CAN BE USED AS A PROFS TERMINAL with the expenditure of a few pounds for a card and a communications line of some sort- all very easy. Thus Exchange is not needed for this task.
My recommendation- don't touch the Logica Kit with a barge pole until it is well proven to be PC compatible. Also don't touch their network stuff until proven to be compatible with the rest of our network.
This is the fourth meeting. The first meeting was at HMI where it was suggested ESONI should be interested in local area networks, attendance 200. The second was in Brussels to consider what to do, confusion reigned, attendance 50. The third was also in Brussels, it was decided to support the CERN connectionless initiative and prepare a proposal, attendance 12. The fourth dealt with the planning of an open meeting in October in CERN to launch a plan, attendance 8.
The meetings have become quite useful despite (or because of?) the falling attendance.
Prior to the meeting Ted Owen had prepared a paper outlining a program of work. Paul Kummer had produced a paper on the need for connectionless services. I had produced a paper on the protocols needed above network layer. Half the meeting was taken up with considering and refining the papers.
These papers will form the basis of the meeting in CERN. A good audience is assured as it will be part of an ECFA meeting. The aim of the meeting will be to attempt to popularize the CERN initiative and try to include many more sites in the work.
The work, I hope, will form the basis of the protocols needed for the IBM/SNS and IBM/Bubble Chamber links. It is sensible to attempt to follow the CERN work which itself follows ISO and we may be able to cut costs and also help other sites by all going the same way.
As we will do the SNS and Bubble Chamber links anyway the only extra cost is the liaison with other sites. Thus travel and meetings will be involved. Hopefully we save on any future implementations although we and unlikely to save much on this one.
The relevant ISO documents and the papers for the meeting can be obtained form me.
Dear Sir,
A colleague of mine, R S Baxter of the British Embassy, recently 'won' a copy of TALIOS from you at the 'Computer Showcase Expo'. Having no IBM PC he gave to copy to me for evaluation and use. From the documentation it looks to be a very useful product that I could well find very useful. Unfortunately I find that the disc is empty. I would be most pleased if you could replace the disc. The product was under your invoice #84081 of May 30, 1984.
In your advertising literature you state that the package has KERMIT and XMODEM file transfer capability. Both these are of interest to me yet I have found no mention of them in the manual. Could you tell me how to use these features?
I look forward to receiving the software. Thank you for your attention.
Yours sincerely
Paul Bryant.
(Head of Development and Network Group)
At the ESONE LAN meeting in Brussels it was agreed to support the use of the ISO Connection less Network Service DP 8473 (1). This paper examines some of the options available over this service. Comment and suggestions are invited.
Use of the ISO connection less network service is discussed in a paper from CERN (2).
An addendum to the ISO 7 Layer Model, ISO 7498 (3), is DP 8524(4) and this extends the ISO model to cover connection less-mode transmission. DP 8524 makes the following important statements:-
The implications of these statements is that connection less services operate in a closed environment although higher layers may enhance the service to be open. Thus peer entities must be aware of each others characteristics and the characteristics of the underlying layers. For example, an entity must find out or be told the transit delay, whether packets can be reordered and so on, outside of the protocol if these features are important or are to be taken advantage of.
A connection less-mode service may be converted into a connection-mode service or a connection-mode to a connection less-mode. This may only be done in the network layer (this seems at variance with the use of ISO Transport class 4 for providing a connection service over a connection less service as advocated by some experts). Note that below data link layer there is no concept of a connection and that the data link layer offers a connection or connection less service.
Segmentation may take place in the network or transport layers but it is recommended that it only take place in the network layer.
The connection less network service provides:-
The network layer to be used is DP 8473.
The transport layer for connection less mode is defined in ISO working paper 1703 (5) and 1705 (6). The transport layer provides protocol for the transfer of a 'source transport service access point address' and 'destination Transport Service Access Point address'. There is an optional checksum. Thus the layer is very simple.
Currently there is no connection less mode for session or presentation layers. The author is unaware of any current work items in this area.
It is assumed that the session and presentation layers will not enhance the connection less service above being an unreliable data gram service. There is a need for further protocol to provide higher quality services of several types.
It is likely that connection less session, presentation and applications protocols will eventually be produced by ISO. Thus any developments for early services must be interim. There is considerable discussion on how connection less services above transport fit into the ISO model, so far with no clear views emerging. This discussion has been mainly on how existing protocols fit in with the model.
There are number of documents which are worthy of study.
The Spector paper (7) is an analysis of the various types of protocol possible. It does not define a protocol but is important reading. The paper concentrates on the type of protocol in which a 'master' sends a data gram to a 'slave' and expects to receive a reply, this is not unlike a remote procedure call mechanism. Three types of use are defined. The first is the 'maybe' class in which a data gram from a master may or may not arrive and the reply may or may not be sent or received. The second is the 'at least once' in which a message from the master is guaranteed to arrive at least once and the reply received by the master at least once. The third is the 'only once' in which a message is received once and the reply received once. The three types are in increasing cost order. For example, the third type requires mechanisms for discarding duplicate packets and for re transmission is it is suspected a message has not been received. Spector's paper is aimed at interconnecting processors over a local area network. He assumes a session level connection but this assumption does not effect the value of the ideas for use over connection less services although this will effect the range of applications.
Xerox has defined the 'Courier' protocols (8). This protocol uses remote procedure calls over a connection service. It defines data types and thus has elements of a session layer. A complete set of protocols are defined. This protocol does not seem strictly relevant but does provide useful ideas.
The Newcastle connection (9) is designed specifically for connections between UNIX systems. It defines a remote procedure call mechanism. The mechanisms used for ensuring reliability are not clear although there are a number of papers on the subject which suggest how the protocol works. Any presentation information is implicit in that the calling process knows the characteristics of the procedure being called. As the protocol is UNIX specific it is unsuitable for wider use without re definition to ensure wider applicability.
The 'Carnegie Mellon Inter process Communications Facility' (10) is designed to be processor and operating system independent. The protocol has the concept of a connection in that 'ports' can be set up and destroyed across the network. Messages may be dispatched from the user with a priority, which may cause queue jumping, it may specify that the order of reception is unimportant, it may specify that guaranteed delivery is not required and a message may be marked as being discardable after a certain time. The protocol has presentation facilities allowing items such as integers, reals and strings to be defined.
Cambridge Computer Science Department use light weight protocols over their Cambridge Ring. These are specific to the Ring and how it is organized.
Since ISO is likely to develop protocols at some time it seems sensible to provide an interim protocol at the applications level and to leave the session and presentation layers null. If possible an existing protocol should be used but unfortunately none appears to be immediately usable without some adaptation.
It may be possible for any protocol work to form the basis of ISO standards. If this is the case then considerable effort will be required to undertake the work and ensure that it meets the needs of a wider community.
From the available documents it appears that their are two types of protocol. The first is the remote procedure call mechanisms which are to be found in Spector and Newcastle connection. The second is the message passing scheme found in the Carnegie Mellon protocol. The message massing scheme is more primitive and perhaps a remote procedure call protocol could exist above the message passing scheme. One could envisage that the session layer provides a message passing layer, the presentation layer provide data typing facilities and the applications layer the remote procedure mechanisms. It is far for clear that this is a correct split.
The laboratory activities include applications such as:-
The characteristics of the data transfer in each case include one or more of the following characteristics:-
Characteristic (a) is a function of the underlying layers and the application can only demand that a packet is not delivered after a certain time has elapsed. The underlying layers may provide a means for reordering the order of transmission of packets to attempt to meet some requirements . This is an area for further study and it is assumed that such a facility would be provided by means of a quality of service parameter.
Characteristic (b) may be a feature of the underlying network in which case the application may take advantage of it. If this is not the case then packets will require serializing. The application layer protocol is responsible for reordering the packets or taking other suitable action is the packet order is important.
Characteristic (c) requires the sender to repeated send a packet until an acknowledgment is received or some error procedure is invoked. If more than one packet is in transit between the transmitter and receiver then some means of associating the packet with the acknowledgment is required.
Characteristic (d) requires that a packet contains a unique identification so that duplicate packets may be discarded.
There a number of outstanding questions which must be answered before a scheme can be proposed.
(1) 'Addendum to the Transport Service Definition covering Connectionless mode Transmission', ISO DP 8473.
(2) 'Interim Report of the Data gram Definition Group', C Piney 29 Feb 1984, CERN
(3) 'Information Processing System - Open Systems Interconnection - Basic Reference Model', ISO DIS 7498 Oct 1983.
(4) 'Addendum to ISO 7498 Covering Connection less - mode Transmission', ISO DP 8524 Dec 1983.
(5) 'Addendum to the Transport Service Definition Covering Connection less mode Transmission', ISO working paper TC97/SC16 N1703.
(6) 'Protocol for Providing the Connection less mode Transport Service Utilizing the Connection less mode Network Service or the Connection orientated Network Service', ISO working Paper TC97/SC16 N1705.
(7) 'Multi processing Architecture for Local Computer Networks', H Z Spector, Department of Computer Science, Stanford University, Report No. STAN-CS-81-874, Aug 1981.
(8) 'Courier - The Remote Procedure Call Protocol' XSIS038112 Dec1981.
(9) 'Newcastle Connection Remote Procedure Call Protocol Release 1-0 (Draft)', J P Black F Panzieri and L F Marchall, Computing Laboratory, University of Newcastle-Upon Tyne.
(10) 'An Inter Process Facility for UNIX', R F Rashid, Local Networks for Computer Communications.
Nick Newman has asked me to comment. Since I received the papers very late he has asked me not to spend much time on it. Therefore many of the comments I make may be ill founded and often later sections may reveal the answers to my questions. I have spent the best part of a day on this terrible document. as a result of reading it I have been encouraged to outline the project I would have liked to have seen.
I am disappointed. I believe that the philosophy behind the project is very wrong.
My interpretation is that the project is aimed at networking UNIX machines and providing all the resources for this work from within the project (at least to a first approximation). It aims at the large job of providing all possible services without putting much thought into the priorities and needs of the users. It seems to ignore work going on elsewhere. The diagram on page 4 is very revealing in showing UNIX as the center of the world and everything else an adjunct. While I do not think that the diagram was drawn with this in mind it does reveal the underlying thought of the authors.
I believe the philosophy should have been that there exists a public data network. each site should have a local area network connected to this public one, preferably ISO. Attempts should be made to connect all interesting machines to the LANs. ISO protocols should be used wherever possible. Where possible, products existing or under development should be used to reduce costs. there should be very close liaison with other bodies to ensure interconnection, for example, Zander group, DFN, JANET and so on.
I see very little of the thinking in the above paragraph in the proposal.
I am unhappy with the blanket approach to the provision of services. It is now becoming clear that some services are much more important than others. The two most important ones are mail and interactive services in that order. The other services such as job transfer, file transfer, name servers are well down the popularity or urgency scale as they can be obtained via mail or interactive means, albeit less conveniently.
We now know of several projects to produce ISO products. For example, British Columbia University are alleged to provide MHS over X25 on VAX VMS and UNIX. There is the York front end X25 system (this does get a passing obscure mention). we believe that Berkeley 5.2(?) will have X25 provided as standard. It is likely that all standard UNIX systems will provide X25 at some time. Why is the EIES project ignoring these activities? Why isn't there cooperation and liaison with these places to reduce the burden of implementation and decrease lead times? The project appeared to be an ab initio one to produce everything and is thus vast and expensive.
The project, as far as LANs is concerned, aims to use transport class 4. To my mind, it is not at all clear that this is the best way to go. The two approaches are the use of Class 4 and the use of X25 1984. ECMA favors the first but the academics and PTTs appear to favor the second. Surely this issue should be resolved before the project proceeds with class 4. It would be a great pity if we ended up with two approaches. Clearly since the contractors are ECMA members they have favored the Class 4 approach.
There seems to be no section on the commercial exploitation of the products they are producing. I would have thought that ESPRIT could have got some of its money back from sales.
EIES is aimed at providing services to the ESPRIT community based on ISO protocols and on the computers used by the community.
Where possible the versions of the protocols used will follow the Zander Harmonization activity.
Where possible use will be made of existing and on going work from other organizations.
The work will be aimed at providing the more popular services of mail and interactive services first. It may be that some services may never be provided on some machines if there is no demand.
Protocols and services which are not defined in current ISO standards will only be provided as a last resort and then the protocols and services will ether be defined with a view to submitting them as standards or in a way so that they can be easily be replaced in the future as standards advance.
The EIES will be based on the use of the X25 PDNs. Each site will be expected to have a local area network conforming to an ISO standard which will be connected to the PDN via a gateway.
EIES will not be concerned with connections to other networks as a major activity. it will be expected that the networks to which EIES needs communication will also provide the same ISO protocols. In a few cases there may be a need to provide some temporary gateway. Hopefully such gateways should be provided by others.
Below is a diagram of the protocols to be used showing which protocols interact with which. (Here is the usual set of building blocks in a diagrammatic form).
The list of operating systems and machines is:- VAX UNIX, VAX VMS, PERQ UNIX and so on.
The table below shows which manufacturers (or outside organizations) will supply which components). This will be a large table.
The tables below show the time scales and costs of each of the components. Another very large table.
The scheme will take some time to implement and in the mean time some interim arrangements will have to be supported on a temporary basis at minimum cost. These are cu, uucp- possible over X25 and so on.
The above is the sort of proposal I would have been far happier with.
I ran a project to provide all the colored book protocols on a GEC 4000 machine. This started in 1977 and ended in 1983. It was done slowly with between 1 and 3 people working on it at ant time. My estimate is that it cost about 10 man years. Translating this to EIES terms- the ISO protocols are larger and more complex so add 3 man years. Many of the products are partly existing so subtract 4 man years. The products have to ported in some cases so add 2 man years per port.
These figures are off the top of my head but comparisons are interesting.
Below I give a few detailed comments but these are fairly minor compared with my criticism of the concepts of the project.
First an overall comment is that I had great difficulty getting an overall view of the project. The document is a large list of bits and pieces which it is quite difficult to fit together into the overall picture. It is difficult to follow a complete theme through the document such as how XXX is expected to develop- it pops up is lots of places.
Page 2 1.1. What teleconferencing? COM or something on UNIX? If COM how does that fit into the proposal which is based on UNIX? What News system- I guess they refer to a UNIX product? Is naming and addressing a service? Sounds more like a scheme?
Page 2 1.2. UNIX is mentioned as a 'starter operating system'. In fact no other systems are mentioned. At the end of the project we still only have UNIX systems running. I guess others will develop the products for other operating systems. Preservation of cu and uucp do not get my vote. I thought cu was just a terminal emulation program so what is wrong with XXX?
Page 3. Why is session service developed? I would have thought that transport would have been a better target. To my mind the break between the upper and lower level protocols come at transport. Thus session presentation and applications would have come as a bundle and one would not try to put applications over session or play musical levels- it just leads to terrible interconnection problems. I would not like to see EIES spend money on gateways to non ISO networks,
Page 4. This is the diagram I dislike with UNIX as the center of the world. Why are non UNIX ISO systems shown as getting to public networks via UNIX? There are going to be legal difficulties to producing gateways to other networks as we have found in the JANET/EARN case.
Page 5. Cannot understand the diagram- what are the two lines marked Year 0 and UNIX OSI meant for? Why are transport class 2/3 used when Harmonization recommends class 0 and 2. What is supposed to run over ISO session? If uucp how do you organize the transition from uucp over transport to uucp over session?
Page 6. The protocols should follow Harmonization- not be derived from the ISO-osi model. I prefer version 2 of the alternatives. I cannot see how you connect a class 2 to a class 4 transport service back to back- they do not match too well. What do you do with features present in one but not in the other? The project seems very concerned with ECMA! More ECMA than ISO!
Page 7. What is this rubbish about public networks? For all practical purposes they have no option but to regard the PDNs as a single network (not sub network). I do object to all the padding in this document. The authors had verbal diarrhoea. I should add - for meaningless comments- for there is certainly a lack of technical detail. I just cannot understand the last paragraph of section 2.2.1.
Page 7 section 2.2.2. Good bold words I endorse. They will have trouble with that approach. Others have tries and failed. Good luck. The UNIX KERNEL is not nice for this sort of work.
A general point. This section (and several others) is in the past tense. I assume they are anticipating the end of the period. It does make one confused. I suspect it is due to non native English speakers writing parts of it.
Page 8. Why are they talking about LAP? LAP is as good as dead with LAPB being the way to go.
Page 9. They have no option but to use X121 if they use PDNs- more padding. Why are they using ECMA 80/81/82 and not the ISO equivalents? Again why not follow harmonized transport?
Page 10. How do they intend to 'open the UNIX world to communications with other operating systems'? I hope distributed mail means MHS and file transfer FTAM.
Page 11. What collaboration with the projects for gateways? What gateways? What is the result of this collaboration?
Page 12. What is MIS? Is it MHS? what is the connection between teleconferencing, news and mail? I see no project for this?
Page 13. I don't like the idea of 'an enhanced UNIX mail interface'. I thought MHS defined a user interface which if true should be followed. What has FTAM got to do with MHS?
Page 14. Glad to see them implementing X28. Keep up the good work. Glad to see transport class 0 coming in. I would have thought putting in class 0 while doing class 2/3/4 would have been trivial rather than making a separate issue of it. Do applications use session? If so what is presentation for? What are these applications?
Page 17. I guess validation is just letting user loose on the products to see what happens. They are right that a lot off effort will be needed to debug it all.
Page 18. Integration is a buzz word. Could mean nothing at all. How do you enhance x25? You ether implement it or you do not. There are clearly problems in matching the local PTT X25 standards (regretfully). So what are these enhancements and why do GEC need to do none? How do you enhance uucp? I thought it was a well developed and proven product (even though it needs killing by ISO replacements). Enhancement is another of those buzz words which mean- we will probably make a balls up of it so need a little sub project to sort out the mess.
Page 20. Looks good!
Page 21. I wish I understood the EIES driver. Does he drive a Rolls? It sounds good but is there any detail ? If not how can we asses the time scales? What is a 'global' IPC mechanism. More buzz words. I cannot see how an IPC mechanism of a portable sort can make use of (or not as the case may be) another IPC mechanism which is what seems to be implied from other sections. (Its getting late and I am now tired).
Page 22. I thought we already had teletypes connected via PSDN to the system.
Page 23. I thought that X25 had just been developed to run in the UNIX Kernel yet I now see the 'York front end' popping out. I am confused!
Page 24. I fail to understand the variations in manpower for the companies. (Here or in many other places).
Page 25. We use XXX on UNIX systems with the York front end already, so what needs doing? What is this UNIX friendly interface? I thought they were going to use X28 and that's a standard so you cannot change it. True the name stuff will be useful if not essential. I hope they read CCITT 1984 carefully before proceeding!
Page 26. Why not use York software?
Page 27. This is a topic for standards bodies not EIES. Harmonization should have a view.
Page 30. What is an 'EIES gateway system'? I do not see a project to provide it.
Page 31. What are the interactive applications to run over session? I know of no standards here.
Page 32 I think FTAM needs a presentation layer.
Page 35 missing on my copy.
Page 36. What is COSAC? Page 35 probably tells me. Hope it is yet another name for MHS. But British Columbia University has X400 over X25 for VAX VMS and UNIX. Why not use it as it exists now (I am told it is not very good but no doubt could be improved)? Would save 2 man years.
Page 38. Motherhood. All projects must have this phase to patch up the cock ups. I doubt if serious enhancements can be expected.
Page 40. Name servers are not essential. Just highly desirable. We can get by with numbers and paper directories. Should be done though.
Page 41. What is the PCTE project?
Page 43. I am not going to waste my time trying to understand this section. The terms used are obscure to me. Security by obscurity! Ha ha. I see this product (and the following ones) cost nothing to port.
Page 46. I understand that X25 will be available on Berkeley 5.? If so what will happen to the EIES version?
From here on things seem to get woolly. What is GRASPIN and PCTS.
Page 56. Shouldn't the PCTS project pay for this?
Page 58. 13 man months to mount a demonstration! If the products are as expected it should take as long as it takes to walk up to the nearest terminal and type! Outrageous!
Page 59. What are these gateways? Surely is DFN and OSRIDE are PSDN and ISO protocols no gateways are needed. Clearly if DFN sites connect to DFN via a gateway then that is their problem not EIES. I am confused. I fail to understand. CSNET is another thing since it is not currently ISO. I suspect it will provide ISO exits at some time quite independent of EIES. Really- other networks have to work out their own salvation and EIES should not stick their snouts in other peoples networks. Incidentally JANET never gets a mention anywhere- why is this? Remember we have the interesting job of a transition to ISO. Also it is a large important network.
Page 61. This is not needed if DFN and EIES follow Harmonization standards. What do these gateways do.?
Page 62. O no! If Harmonization succeeds this is rubbish.
Page 65. keep up the good work Dennis. Hang on- what has ICL got to do with this?
The rest of the document is not technically interesting so I will not comment.
Dear Herb,
Thank you for your reply to my circular.
As a long standing and active member of the Swedish COM, which Birgitta presented at Davos, I fully agree that an open conferencing system for the European academics would be of great value, All the current systems are semi closed in that they only provide services to a select band of people- in general these tend to be 'locals' plus network hackers. Perhaps I am being a bit hard in that I think with maturity the conferences are tending to move away from network topics which is good. The advantage of an EARN system is clearly that it would be open to a far wider range of people.
In discussions with Lassi Hyvarinen we thought it would be a good idea to run a small conference or workshop on the topic next year. I have a feeling that that is a bit late and that we should try and do something earlier.
We do have a number of problems to overcome which I outline below.
Look forward to seeing you in Rome. I am trying to persuade my wife to come over as we have not 'done' Rome yet.
Yours sincerely
Paul Bryant.
I blame the Italians - yes - the Italians. They 'blew it'. Caesar had it made. He had a European Community the best part of 2000 years ago. He was not the only one who 'blew it'. William the Conqueror had it made but seemed to forget about the rest of Europe. Queen Victoria had it made. An empire the sun never set on. Now it is the empire the sun rarely rises on - apart from this hot summer and a temporary carbuncle called Gibraltar. She had it made - treated the natives like dirt - and that was that. think what Europe could have done if all our illustrious fore fathers had not 'blown it'. It will be interesting to see if ESPRIT 'blows it' or, at least as far as I am concerned, the IES part of ESPRIT.
One thing the English didn't blow - they decided, quite out of character, that they had a standard called the English Language and they resolutely refuse to speak any other. One of our few successful exports. It is a pity we cannot charge you for the privilege of speaking it! Clearly the English have something in common with some computer manufacturers who resolutely refuse to believe that there are other manufacturers and standards - in this case we are charged for the privilege of speaking their language.
Now I belong to an ad hoc panel on IES - the ESPRIT Information Exchange Scheme. I am not an expert - experts get paid. This has advantages and disadvantages. The disadvantage is that I, or my poor employer, has to finance my ESPRIT activities which little chance of any return. Being government employed I do not think we can bid for contracts and even if we could our rates of pay are so low that we could not get staff to do any projects. The advantage is that I can say what I want without any fears of loss of projects or dismissal.
I have been working in communications for umpteen years - trying to put together the UK academic network JANET. There is an attempt at getting a heterogeneous set of machines into some sort of network with almost zero help from manufacturers - especially from those who believe that they are the only manufacturer. In addition with almost zero finance. The aims of IES are somewhat similar. IES has the advantage of money and manufacturer support.
Now IES is primarily for helping the ESPRIT partners to exchange information of one sort or another. It is rather more than that, or at least it could be more than that. There are two ways IES could proceed. The first is to use whatever means happen to be around and to make use of them - carrier pigeon, smoke signals or whatever. The second is to decide that IES is to do with communications and communications must follow standards. Whether those standards are good bad or just plain daft is a secondary consideration. Thus IES, whatever else it is, is a supporter of standards. The two approaches lead to very different activities and different time scales and results.
Standards are funny things. I remember a company - a well known company - came to sell me a high speed local area network of 50Mbits per second or so. The salesman said, on learning I was an ISOFILE - now there's a word to conjure with - an ISOFILE is a person who eats, sleeps, breaths ISO and ISO protocols. The salesman said 'you are going to like our product' 'O yes' I said, 'Yes our protocols follow the ISO model'. He then proceeded to show how he had this level and that level. This level was null and this level was split into sub levels and so on - I call this 'the cork screw approach to ISO', if I bent my lawn mover enough I guess it could conform to the ISO model. So why didn't they follow the ISO protocols- well they were thinking about it. So how did they expect to inter work with JANET (I leave aside the unpalatable fact that JANET is only ISO below transport). He replied that did I really want to, after all you only want to get data across this network for a special purpose. So I cast then out into utter darkness - and my management, against my advice, bought it. It is now stuck on a shelf collecting dust as the rental on the software is to high and because of its protocols it is not worth the money.
A colleague, an IBMFILE (a man who speaks, sleeps and breaths IBM), claims that we should forget ISO and all adopt SNA as IBM was bigger than anyone else and to follow IBM and SNA was a sure fire way to succeed. I dare say that my DECFILE friend would say the same about DECNET. He was right - as long as we all buy IBM or 'look alike IBM' and pressure all other manufacturers to follow SNA then we will all get on fine. What happens when IBM decide to change SNA? What happens about the rest of the world who would prefer to follow non proprietary methods. One IBM salesman said IBM was converging on ISO - I have yet to see any official confirmation of this. In fact the salesman said IBM was moving as fast as possible towards ISO but he did not think there would be enough of ISO around before 1988 to bother about. In any case they were going to all the ISO meetings - some say with ensuring the 1988 date. Anyway - what happens when we want new protocols that SNA does not provide - do we have to wait for IBM- an interesting question. Another interesting question is whether the American government can call SNA a strategic product and ban its export to the East.
So should we stand and fight against SNA, DECNET, ad hoc-ery and any other non ISO protocols for IES (or anything else) or give way to pragmatism to speed the provision of services. In fact is ESPRIT, as far as IES is concerned, going to 'blow it'. If we 'blow it' then we shall loose an opportunity of providing a demonstration of ISO protocols in action in a very public way. We will loose the opportunity of giving a public statement of confidence that ISO protocols are viable and important and are to the common good.
I guess it is still a matter of conjecture as to whether ISO is to the common good. As an ISOFILE I have no doubts. But let us look at the situation as dispassionately as an ISOFILE can.
First what are the objectives. The objectives of Open Systems Interconnection is, without doubt, for information to be passed freely between machines. It should be a matter for management decision whether data is allowed to be passed and not whether the manufacturers in his wisdom will supply the protocols. Clearly to obtain such a situation many bits and pieces are necessary but one overriding requirement is that all the protocols should - in fact must - fit into a common framework with common service definitions at various useful places so that protocols can be mixed and matched to provide the facilities management and the users need.
These requirements exist at most of the levels. At the low level we need the slow X25 style of working - the higher speeds of CSMA/CD and token ring. It would be a pity if things stopped there. I see protocols being developed indefinitely as need arises and certainly at the low level one expects much faster speeds of 100 M bits/sec having standards defined as well as standards for satellites and whatever else comes along.
There is no less variety at the higher levels. Certainly the more obvious standards are well defined or almost so, these include file transfer, message handling, teletex and interactive protocols. We still await a virtual terminal protocol, file access and job transfer. No doubt there are many other applications which will be 'brewed up'.
There are another very interesting set of protocols which are as yet undeveloped for use in distributed systems and like activities. These are loosely termed 'light weight protocols' which depend on connection less techniques. These are seen as being mainly used over local area networks.
Now any of the proprietary offerings can meet some of the demands but not all. In fact experience suggests that many of the proprietary offerings fall down quite badly on meeting the fairly basic requirements. Most of the proprietary offerings are aimed at closed networks rather than open systems. Let me do a brief hatchet job with no apologies and if I destroy some of the credibility of the proprietary offerings I will rejoice, I only wish I had time to go through every one and destroy then one by one. In addition, I have no desire to know too much about proprietary protocols lest I be polluted by their seductive nature.
Let me start with DECNET. A protocol that works well after its fashion. Last time I looked it was struggling to work over public networks without costing you an arm and a leg. In a DECNET network nodes 'know' about the topology of the network - what is connected to what- and expect permanent circuits between themselves and other nodes. Thus DECNET over X25 requires permanent or semi permanent connections between nodes and unless you want data to make several hops between nodes then each node must know how to get at every other one. OK if you know where every other node is but if someone else comes along then the whole network needs to be re jigged. Now lets go upstairs. DECNET relies heavily on file access so that a file transfer consists of opening a file on a distant machine and reading it across bit by bit. And, of course, the way it does this is dependent on DECs file store structure in that if you want to stick a PRIME in such a network then you have some interesting problems. Of course, with such a scheme spooling of file transfers will not work. For interactive work life gets complicated with the dreaded echo pipeline markers which are designed to cope with the character by character methods of working so beloved by DEC.
SNA has similar troubles in that computers like to know about the topology of the network. SNA also contains many very IBM like sub bits and pieces. In fact SNA is a amalgam of everything, almost everything, that IBM likes to call communications. Even 3270 is a facet of SNA.
The smaller companies have far worse offerings. Far worse in that they aim at a smaller corner of the market to make a killing before disappearing in a puff of blue smoke. The favorite area just now is coupling IBM PCs together. The networks tend to 'solve all your problems of getting 1000 IBM PCs accessing some common disc and, of course, cope with all your office automation needs. It is often difficult to find out how these object work as the companies consider such details as their secret property that someone might want to copy. Some make great play of 'being IEEE 802 compatible' but then go and put up their own protocols over it. So why boast that it follows these standards when they go to lengths to stop you indulging in the delights of interconnecting it with other products - it might as well be any old technology. Following standards only makes sense as a way of interconnecting products from a number of suppliers.
The worst advertising is from companies which claim their systems follow the seven layer model. Nothing about the ISO protocols themselves mind you, but they do follow the model. If they do not follow the protocols then as far as I am concerned they might as well follow a number 9 bus. Advertising in this way is getting down right deceitful. The glossies from the companies are misleading. I find it very difficult to understand them, they seem to go to great lengths to conceal the technical details of their products.
I propose a 'Network Advertising Standards Truthfulness Association'.
At least the UNIX CV and UUCP as well as the Newcastle connection have no pretensions to follow the model although some noble efforts have been made to push and prod the definitions into some sort of ISO layers. A bit of a waste of time to my way of thinking.
Let me make a strong point. I believe it is counter productive to push and prod everything in sight to fit the model. If we do this we will end up with anything anybody wants to use having some spurious standards stamp of approval. There are two principles I would put before you.
The first is - does a proposed protocol foster open systems interconnection? If not then it should not be supported. CU or UUCP, after some suitable elevation over some layers of ISO protocol, still seem unlikely to be adopted by other systems with enthusiasm so fail the test.
The second principle is a more interesting one - it is the principle of minimal protocol. Rather like Occams principle - that the correct description of a phenomena is the simplest - the principle of minimal protocol is that we should have the minimal number and amount of protocol to achieve our open systems interconnection. Thus we should not have 101 varieties of file transfer but just one and that one should have the minimum facilities to meet the needs of the majority of users. One feels that the protocols designers have tended to stuff in rather more options, facilities and negotiation than a poor implementor like myself can cope with. Complex systems seem to be an invitation to produce non interconnecting products.
So how should IES proceed? The question rephrased is - is IES an end in itself and does that end justify the means. Is the object to get as many ESPRIT participants connected in some way by whatever means, or should IES be a rigorous supporter of ISO protocols and be a pressure for encouraging, forcing, cajoling, sponsoring the production of ISO protocol products?
The first approach is to observe that the most popular operating system is UNIX - a full 21%. Thus in this approach effort must concentrate on seeing what can be done with whatever UNIX provides which currently is CU and UUCP. Hopefully we might even be able to encourage these protocols to operate over some of the ISO ones. We might be able to get the other less popular or should I say less populous systems to adopt these protocols. This will end up with an alternative set of protocols to ISO.
The alternative is the vigorous support of ISO and the active suppression of anything else. In this case the current UNIX products or any other non ISO products is irrelevant. All systems have the same task of supporting a common set of protocols.
Do we have to wait until 1988 for sufficiency of protocols to be firm, as an IBM colleague of mine suggested, or can we expect action to be more rapid?
A few years ago the scene was bleak. Over the last year or so there have been many encouraging activities. This has, in my view, been as a result of users realizing that the proprietary network solutions have limited applicability and their belief that there must be a better way. The popularity of the public X25 networks, or network as it effectively is, has played a strong part as users find that this network has allowed a measure of connectivity and is technically and economically attractive. The use has been limited by the lack of higher level protocols. The important protocols now reasonably well defined. In particular the Message Handling System one needed for that ever popular activity - mail. Of course, interactive ones with the triple X has been with us for a long time and provided very useful services. There are massive gaps still - such as file transfer, job transfer as well as products for screen mode working. Some of these are now in an advanced state.
A serious problem with the protocols has been that, as with any committee job, everyone has had to get their particular bit put in. This has led to protocols stuffed full of options, negotiations and complexities. To my mind this has been excessive and mitigates against the swift production of protocols and also reliable inter working ones. It is regretfully true that it is all too easy to produce conforming but non communicating implementations. This is a great pity and I would have for preferred it to be difficult if not impossible to produce such implementations.
Now the Germans are putting together DFN, a German Academic Network. The Italians are doing likewise. So Professor Zandar managed to persuade the EEC to support a study to make sure that the two networks used compatible realizations of the ISO protocols that both networks wished to use. So this became Europe wide and the interest became a lot wider than the academic community. So here we see some sense being made of the ISO protocols. We see the options and negotiations being restricted in the interests of defining a minimum set of features for inter working. Whilst one would have liked these things to have been thought of when the protocols were being defined it is now an essential activity to get the implementations problems of the protocols sorted out so that the army of implementors can get to work with the confidence that their products will work. Eventually one hopes to see some means of certifying these products. And finally and also hopefully one would hope it happens rapidly.
The start has been poor. It gives me constant amazement that the European PTTs could not come to some agreement on the X25 standards to be used in Europe. I would recommend to you an excellent publication of ECMA which defines the differences between the X25 standards in the various countries. It is a document that should never have needed to have been written. I hope no such document will be needed on the higher levels.
By now you must be in no doubt where my sympathies lie. It is my hope that ESPRIT and IES in particular will be a strong supporter of the ISO protocols. I do not believe ESPRIT should foot the bill for the developments required as I believe that companies should be providing the implementations just as they supply a FORTRAN compiler. Clearly developments are in an early stage and some funds may be needed to encourage early implementation. I believe that once we have a kernel of implementations then there will be a lot of incentive for others to follow. This was the experience in the UK academic network with the colored Books.
Dear Dr. Budd,
The European Academic Research Network (EARN) is an international network which is generously supported by IBM. It connects a number of university and similar sites in a computer network. It is based on the use of leased telephone lines and the IBM RSCS protocols. Problems have arisen with the PTTs which require IBMs help in solving.
The network contravenes the 'third party traffic' regulations of some of the PTTs and thus requires a license from each of them before it can operate. CEPT, the advisory body for the European PTTs, has no objections to the granting of the licenses under certain conditions. Although the PTTs are not bound by CEPT it is highly likely that they will all follow its recommendations. The conditions include the following requirements:-
1. The network must evolve to the use of the protocols described in CCITT or ISO recommendations. In particular X21, X25 and X28. If these protocols cannot be used immediately then other protocols may be used but an evolution plan towards the use of CCITT standardized protocols must be submitted to CEPT.
It is desirable that there should be an evolution towards the use of the protocols described in CCITT recommendations X224, X225, T61, T62, F200 and X400. These are the TELETEX and MHS protocols.
2. The use of public data networks for the EARN project should be aimed at as far as possible.
In section 1 I believe the protocols mentioned are in error in that they should include X3 and X29. However the intention is clear that EARN must use protocols compatible with the public networks.
EARN will be used, at least initially, for two classes of traffic. The first is mail and the second file transfer. The X400 or MHS protocols are suitable for mail but CEPT suggests no file transfer protocol. The ISO file transfer protocol FTAM would probably be suitable when it is finally defined.
The X3, X28 and X29 protocols give interactive service and there is no real equivalent on EARN. The participants would certainly find such a service useful.
The TELETEX protocols, which no doubt could be made use of, are certainly not an immediate requirement.
Considering that CEPT is insisting that EARN develop plans to move towards CCITT and ISO protocols in the next four years, the EARN Board of directors have actioned me to ask IBM what products exist or are planned to meet the needs of EARN and the demands of CEPT. I hope that any information and help you can give us can be used in the next few months for planning the required transition.
I am sorry that we have to call on your help and generosity to solve our problems and look forward to a satisfactory outcome.
Yours sincerely
Dr. P Bryant. EARN Technical Coordinator.
EARN is a network of machines connected using the IBM RSCS protocols. The machines are located in many European countries. There is a connection to BITNET in the USA.
The lines and some equipment are financed by IBM for the next 4 years.
The use of the network is free to participants. There are no regulations apart from a bar on commercial traffic. For the purposes of EARN management JANET is regarded as part of EARN since Rutherford will be the only connection in the UK to EARN.
Rutherford will be connected to Dublin and CERN.
Due to CEPT pressure the network will convert to using ISO protocols and public networks in the next 4 years.
The technical objectives are:-
1.1 Connect Rutherford Laboratory IBM computer to the European Academic Research Network.
1.2 Provide file transfer gateway between JANET and EARN.
1.3 Provide mail gateway between JANET and EARN.
1.4 Participate in management of EARN.
Internal pending agreements with IBM and BT when it will become external.
3.1 Management of EARN. Attendance at quarterly EARN Board of Directors meetings. Ad hoc meetings with IBM UK. On going at one month per year. P Bryant.
3.2 Rutherford's representative is the Technical coordinator of EARN. On going two weeks per year. P Bryant.
3.3 Obtain permission from BT to order and install lines to Dublin and CERN. P Bryant.
3.4 Sign memorandum of agreement with IBM. P Bryant.
3.5 Sign EARN charter. P Bryant.
3.6 Obtain modems from IBM. P Bryant.
3.7 Obtain 3727 from IBM. P Bryant.
3.8 Commission line to Dublin. One day Peter Gill, Peter Girard.
3.9 Commission line to CERN. One day Peter Gill, Peter Girard.
3.10 Produce publicity document for Network News. P Bryant.
3.11 Produce documentation for file transfer. P Girard.
3.12 Obtain technical details of mail gateway and attempt to obtain code from elsewhere. P Bryant.
3.13 Obtain finance to develop mail gateway. P Bryant.
3.14 Write gateway code or modify existing code. A Burraston. 5 months.
3.15 Document gateway code and produce user documentation. A Burraston.
3.16 Plan transition to ISO and public networks. P Bryant. Unknown effort.
3.17 User support. A Goldfinch. Manpower depends on use.
The project is a cooperative one with many other European sites. Decisions taken by the EARN BOD could effect the project.
Decisions of IBM, BT and CEPT could stop the project or make it uneconomic.
The Network Executive and JNT may wish to take active interest in the project.
IBM are likely to withdraw support at the end of 4 years and if the network is to continue finance will have to found possibly from JNT or by charging for use.
If a poor service is provided Rutherford will be criticized. If a good one we may be praised.
Exact dates are difficult to give due to dependence on other organizations.
6.1 Obtain license to operate. End August.
6.2 Installation of lines and modems plus testing. Mid September.
6.3 Provision of file transfer service. End September.
6.4 Provision of mail gateway. End December.
6.5 Installation of IBM 3705. No date obtainable.
5 months A Burraston.
6 weeks per year P Bryant.
Few days P Girard and P Gill plus longterm equipment maintenance.
User support A Goldfinch. Depends on usage.
Capital for some wiring.
Maintenance of IBM 3705.
Travel and subsistence for EARN Board of Directors Meetings.
Service, User Interface Group, Network Development, internal and external users. Network Executive and JNT.
It is expected that EARN will move to ISO protocols and use of public networks. Rutherford will be expected to participate in this.
Exact dates are difficult to give due to dependence on other organizations.
Items 3.1/2 on going Item 3.3 action with BT answer expected by end August. Item 3.4 action with IBM to produce document. Item 3.5 action with EARN BOD to produce document. Item 3.6 complete. Item 3.7 request with IBM. Item 3.8 await action 3.3. Expect completion end August. Item 3.9 await action 3.4. Expect completion end August. Item 3.10 action with P Bryant. Expect completion end August. Item 3.11 not started but will be based on existing document. Item 3.12 action continuing. Item 3.13 request with IBM. Item 3.14 awaits action 3.12 Item 3.15 awaits action 3.13 Item 3.16 not started. Item 3.17 not started.
In the past Rutherford played an important part in the development of JANET. The developments were never directly funded but were under taken as part of the support of the various computers. Coordination of the work was under taken by means of the regular meetings between Daresbury, Rutherford, NERC and a few other useful representatives. This meeting had no official status but none the less was highly successful in putting together the network.
During the last two years the methods of working have undergone a radical change. Formal committees were set up to look after the network there being 4 in all. These committees were only partly successful. SNMC, the parent body, attempted to control the policy of the network but found that its activities were blighted by the imminent take over of the network by the academic community. This staved the network of finance for equipment and also prevented any long term planning. The development committee continued to coordinate development progress but became less effective as manpower resources were withdrawn. The network operation committee had a chequered existence in that meetings were fairly irregular and little notice seemed to be taken of its decisions. The local area network committee was spectacularly unsuccessful due to the diversity of views and lack of standards to coordinate around. The Ring problems did not help.
The take over of the network and the pressure of other projects let to the reduction in manpower devoted to networking until there is now the situation where Rutherford must be regarded as a fairly weak site whereas it had been one of the strongest.
After the disbanding of SNMC there was enthusiasm to set up an SERC network coordination meeting. It appears that the Computing Coordinator has agreed to the meeting being set up but as yet the late chairman of SNMC has been unable to do so. There is a view that it may be more fruitful to form close cooperation links with CERN.
Rutherford now needs to decide whether it wishes to attempt to regain expertise in networking or to take a passive role and merely attempt to adopt network products as they become available.
A large part of Rutherford's work load comes via networks and this trend is likely to continue. In the past the performance of network products from other sites including manufacturers has been very disappointing, if indeed they ever appeared. This has shown up in the expertise needed to mount and use the products. It has been found that products need developing to meet Rutherford's requirements.
Rutherford has often developed its own products in response to user demands. This has led to the site having considerable expertise which has been put to very good use in ensuring that the various network committees provide standards suitable for Rutherford use.
This paper takes the view that Rutherford should attempt to regain a strong network group and defines a number of projects which are required. The projects are grouped under 'urgent', 'essential', 'desirable' and 'speculative'. In addition to development Rutherford should dedicate some time to the various groups defining both JANET and other standards.
The work items below are beyond the capabilities of the current manpower levels and some selection of projects is needed. The purpose of the paper is to try and decide which topics should be followed.
HDLC for IBM. This is essential to allow the current SERC exchange software to be phased out. Whether the Auscom box or IBM 3705 (or look alike) should be used is still under debate. The 3705 with Com-Pro software currently looks attractive. (NG or PMG).
CMS PAD. This product needs considerable improvement for parameter handling, better user interface. (AWB).
VNET. Still requires heavy maintenance effort. Half a man continuous (AWB).
NIFTP. Although operational for two years there are many enhancements requested. These include scheduling of output to printers according to better algorithms. 3 or 4 man months needed (PMG)
Exchange support. This is a short term need to ensure that exchange problems are rectified. Even when GEC software and/or CAMTEC switches are adopted expertise will be required to look after them.
MVS/TSO. Required by October for MVS service. Needs VMNCP under MVS, mapping X29/TS29 via VTAM into TSO. Deadline may not be met. (PMG).
TELEX. Administration is determined to have a better TELEX service ideally operating directly into Grey Book mail. If effort is not put into this it is likely that a poor solution will be found. (PEB).
GIFT. It is likely that this project will be enhanced to encompass ISO protocols to help the transition to ISO protocols. Rutherford has an opportunity to play a lead part in the this development. (SWL)
Full Screen Cifer. The product requires some maintenance. It is important that the concepts behind the scheme are supported with a view to getting it widely adopted elsewhere. It would be unfortunate and expensive if only Rutherford supports it.
Administrative computing. The network needs of the administrators are important and must be met. At the same time it is important to attempt to get them to use standard protocols it at all possible. The use of other standards will undermine the adoption of standards, reduce the effort put into standards, prevent open systems interconnection, and prevent equipment being used for many purposes.
Coordination. The networking on the Rutherford site must be better coordinated to conserve effort and ensure interconnection. Any coordination group must have some power to impose standards.
GEC PAD print server. Further effort is still required.
JTMP. It is certain that there will be pressure for JTMP into the computers and to other sites. It is important that all machines which want to submit jobs elsewhere provide it. In the early days quite a lot of protocol proving will be required to ensure products can provide services. For the IBM an MVS JTMP for heavy job traffic with status modify and a Q-end FTP plus a VM JTMP to give a user CMS user interface are needed. The Salford code does not look attractive. It will be a full time job providing the protocol but Amdahl may be interested in cooperating.
EARN mail gateway. It is likely that the major use of EARN will be for mail and a gateway is essential. The details of EARN are still not settled and it may be that the gateway will be in CERN rather than Rutherford.
Provision of high speed local area network for the Bubble Chamber Group. The most attractive solution now appears to be Ethernet. This project should be seen as part of a much larger project to develop Ethernet for other activities. It is currently proposed that the ISO connectionless protocols should be used. CERN are adopting this approach.
Provision of backbone fibre optic or broadband network. This would provide a large data capacity which would be taken up as required.
NRS. Not a major task and not urgent until NRS becomes more of a reality.
YBTS. Support for non fast select. Quite difficult but important as many networks cannot support fast select.
Documentation of NIFTP and VMNCP. Needed to disseminate product to other sites. 6 weeks (PMG).
MAIL. Improved user interface and facilities in CMS and PROFs.
Completion of adoption of GEC network code. When the GEC work ceased the work to move to GEC network products was half complete leaving a messy situation which prevents some services, such as outgoing interactive calls over the Ring. This development would allow easy adoption of GEC Ethernet products.
Production of CR82 IBM interface. This would allow Ring PADs to be employed which would give better performance for full screen Cifers and allow economies in cabling.
Development or purchase of various IBM PC products. These include X25, CR82, Ethernet and various high level protocols. Quite a bit of progress has been made here.
It is desirable to support the many network committees. This helps to retain expertise, prevents decisions being taken to Rutherford's detriment, maintains contacts and is for the good of the community. With the current staff levels this work is not as active as would be desired.
Development or acquisition of Ethernet products with 'approved' protocols on several machines. This is dependent on decisions taken elsewhere and on the popularity of Ethernets in the community.
Provision of network bulletin board(s) for announcing planned down time, configuration changes and other ephemeral but important information.
MHS (message handling protocols). These protocols will be the standard protocols for mail and early experience in them is desirable. There are some free implementations available for VAX VMS and VAX UNIX from British Columbia. These should be evaluated and perhaps Rutherford can be a lead site for helping the transition to MHS.
TELETEX. The acceptance of teletex has been slower than expected but it is still likely to be important especially as ESPRIT is backing it heavily. IBM PC implementations should soon be available and these should be obtained for experimentation and evaluation. This may lead to the need to implement TELETEX on a central machine.
Standards support. The various bodies setting standards should be supported particularly if their deliberations effect Rutherford. Of particular importance are the harmonization activities and implementors groups. Attendance at these meetings also allow staff to gain valuable information from their colleges elsewhere.
Introduction of a conferencing system. Probably PORTACOM as a VM version should soon be available.
Network monitoring. Although always regarded as vital has proved to be a very difficult job. The analysis of the information is as difficult and important as the collection of data.
Dear Ms. Mattes,
Thank you for your prompt and efficient response to my complaint. Also thank you for supplying the latest copy of your product. The initial use we have made of it is very encouraging. I enclose the completed registration card.
Your interest in communications prompts me to outline a project we have which may be capable of commercial exploitation. I have tried to interest a few companies here but with no success.
First I have to explain our situation. We run a number of large IBM and Amdahl machines. These are connected to the UK Academic Network which is a large private X25 network connecting to over 200 assorted machines. Most of these machines contain a Packet Assembler Disassembler (PAD) which allows terminals on that machine to access any other machine. There are also a small number of (50 or 60) terminals connected directly to the IBM machines. Recently we have put in a number of IBM 3270 terminals as these are becoming the popular way of accessing VM/CMS, CICS and like IBM systems. These are on local coax connections.
Our problems are- The 3270s cannot access other computers easily. The 3270 connections are expensive and we are reluctant to re cable the site with coax. We would like to have 3270 access to our machines from remote sites using the existing X25 network.
We have overcome these problems with an interesting and effective development. We have got a friendly terminal manufacturer (Cifer) to modify their terminal so that as well as being a scroll mode asynchronous device it has a second mode which allows it to emulate a 3270 over an asynchronous connection. To allow this we have defined a suitable protocol. This defines a means of 'framing' the 3270 data and provides facilities for the host to switch the terminal to and from the 3270 mode. To complement the terminal we have developed two IBM programs. The first to allow directly connected terminals to provide 3270 emulation and one for terminals connected via PADs and the X25 network.
To the user a terminal initially acts as a scroll terminal. Eventually the IBM switches it into 3270 mode. On logging out the IBM switches it back again. The terminals normally operate at 4.8K bits per second. This is far slower than a 3270 over a coax connection but is none the less adequate for many applications.
Recently we have produced code for the IBM PC which provides the same protocols. This has proved very effective. We are now including file transfer facilities based on the IBM XEDIT.
As I mentioned- I have had no interest in this idea from UK companies. Perhaps it is something you may like to follow up.
I enclose a description of the protocol.
Yours sincerely
Paul Bryant.