Paul Bryant's Networking Correspondence
The latest recruitment campaign has been an experiment in that candidates have been given an opportunity of an informal visit to the site. An additional 'experiment' has been that the exercise has been protracted due to the Christmas holiday and lack of board members being available.
I make the following observations which are my own:-
Approximately 230 applications were received. The majority cited 'Current Vacancies' as the source followed by 'The Guardian'. 'New Scientist' and 'Computer Weekly' turned in few applicants.
Short listing was arbitrarily restricted to selecting 40 candidates. 30 of these attended the open day. Candidates from distant parts were not invited on cost grounds.
21 candidates were noted at the open day as 'of interest'.
The response to attending the board was:-
Date Invited Attended Withdrawn No Show 5 Dec 7 5 ? ? 11 Dec 7 7 0 0 13 Dec 7 4 2 1 3 Jan 6 3 ? ? 4 Jan 5 4 0 1 7 Jan 4 2 1 1 8 Jan 4 2 0 2
Thus 27 candidates were seen and 13 jobs were offered.
The correlation between the staff 'spotted' at the informal visit and those liked by the board was quite good. This suggests that there may be merit is short listing at the time of the informal visit. With a response of 230 candidates it is unclear how this could be achieved except by an initial course selection followed by a fine selection after a visit.
The organization of the visits, although hurried, turned out to be quite good. (I would like to put on record the hard work put in by Dennis Williams, Jacky Hutchinson and Jed Brown). Jacky has written a paper on the subject. The main observations were that in future only one staff member should talk to a candidate as with multiple staff it became more like a formal board. In addition it was evident that many candidates did not have a chance to see staff working in areas that interested them. It may be a good idea for greater care being taken with the literature given to the candidates which could indicate which booths there will be and even the names of the staff manning them.
Jed Brown's introduction was excellent and restricting the talking to one person is good in that it avoids confusion. A procession of dignitaries would achieve nothing and in fact I suspect that the raw candidate would be unable to differentiate between Geoff Manning and Jed Brown.
I feel very strongly on this. The time between the advert and the offer must be minimized. Recruiting over any holiday period is likely to increase this time. I feel that recruitments are 'unplanned'. Unplanned in the sense that each stage is planned as needed. Thus short listing is not organized before applications have been received. Boards are not organized before short listing is finished. Board composition is a real problem if you want consistency and as diaries are booked months in advance consistency causes unacceptable delays.
My feeling is that the following procedure should be adopted for recruitment for junior staff for non specific vacancies.
All dates for the complete exercise should be laid down before any advert is placed. Clearly this will mean that specific staff may not be available for certain phases of the work. I do not regard this as a problem as I would expect any competent SSO/PSO to be able to do a bit of short listing to some arbitrary standard. In addition for recruitment boards for junior staff the opinions of board members appear to be quite consistent and leads me to believe that as long as the board is competent there is no problem. For the informal visit we should ensure that we have at least a couple of people capable of organizing or talking at the event.
In the main the candidates were rubbish. Even fairly elementary questions on general topics received poor responses. I felt that the candidates having taken some course or other felt that that should be sufficient to get a job. Few had read around their subject or had taken their studies further in their own time during their protracted periods of unemployment. I felt that any 230 arbitrary people off the streets would have had the quality of the candidates we saw.
The candidates all had poor degrees. It was very clear that we were scrapping the barrel and seeing the rubbish which had failed to get jobs since graduating. Clearly for attracting good junior staff Christmas is not a good time. We must concentrate on the summer when the good graduates are job hunting. This may, of course, be no more successful with the salary levels we now have.
The idea of turning a non computing graduate into a computing one with a one year course seems unsuccessful. The courses seem very shallow. The candidates seem to have merely learned a programming language or two and had almost zero depth of knowledge. Questions such as 'compare Fortran and Pascal' rarely brought out the real differences but only rather shallow comments such as 'Pascal is more modern' or 'I don't like having to declare variables'. The TOPS course is only 15 weeks in which the student learns a bit of COBOL and BASIC have little time to instil much knowledge but I did feel that they taught useful things but did not bring students up to a standard of interest to us. It could be that such a course could get a person in as a trainee ASO, say.
Dear David,
Thank you for your 'phone call, I am sorry I was not about.
Please feel free to come to all or part of the meeting. You would certainly help to give us a good start. I am fairly keen that the main participants should be technical people and not board members. If we had a predominance of board members then I think we might end up with a mini board meeting and discuss political matters. I certainly hope to steer the meeting well away from such things.
The replies are now coming in and I think that the majority of the participants will be arriving early and late evening so I do not expect any serious discussion that evening but just to get a few ales back to oil the wheels. I am very unclear as to what will be the major topics but I think the provision of added value such as mail will be high on the list. I have been talking to Roland Wolf from Hargan's empire and he seems very keen to play a role in the meeting and has been making valuable suggestions. I am co opting him to chair some of the sessions to give me a break. He suggests I give a talk on ISO protocols on the second day to bring up the level of understanding - seems a good idea. One tends to forget that not everyone is as steeped in the topic as I am. I am intending to push round my ISO Migration paper to the meeting as a starting point for the discussion. I think I would like to delegate various members to go away and explore a particular option as if it was the winner and for them to come back and present a case for that option. In that way we may be able to ease the problem of understanding it all and get some progress.
A major objective will be to sort out the mail problem to ensure that at least the technical people can talk to each other. I think it would be better to try and concentrate on using EARN itself rather than KOM to show some confidence in what we are doing.
I have the feeling it will all go well. Incidentally, something else which is going well is my negotiations with DTI. I am having almost daily phone calls with my man Mike Wright on the fine points of the license. He hopes to send me the draft by the end of the week. But - I have been optimistic before!
I would be grateful if you could let me know if you want to come and if you need accommodation by the 28 Jan. The problem is that after that date the numbers at Coseners have to be frozen and although I could book speculative places this would make me liable to cancellation charges.
I have just received the new EARN headed paper and the leaflet. It looks very nice but I see we have the IBM PC on the front of it.
Hope you enjoyed your break.
Best wishes
Paul Bryant.
Present:- B Butscher Germany
M G N Hine CERN
W Jensen Norway
P F Linington United Kingdom
B Mahon CEC
E Valente Italy
P Bryant and J Hutton Secretariat
Apologies:- J-L Grange France
Recent discussions have led to a proposal to run an academic network workshop in the spring of 1985. Some initial planning has taken place but it was stated that this was subject to endorsement by the Organizing committee.
The object of the workshop is to foster cooperation and coordination between the European academic network providers with a view to enhancing the quality of service to the end users, encouraging the use of standards to enable international traffic, and to reduce costs. It was not intended to support network research or computer science objectives at the workshop. It was not intended that the event should be a platform for manufacturers, PTTs or government bodies although representatives may be invited to observe or provide specific information. The workshop would consider any relevant topics such as protocols both high and low, PTT tariffs, migration to ISO standards, and performance/fault reporting.
It is envisaged that this may be the first of a series of annual workshops. It would, hopefully, initiate some on going activities on international cooperating which would be reported and reviewed at subsequent meetings.
The event is a natural successor to such activities at Prof. Zander's Harmonization initiative. It should concentrate on the fairly immediate objectives of sorting out and exploiting the current generation of medium speed networks such as the X25 ones offered by the PTTs. None the less some consideration should be given to emerging higher speed networks provided by satellite and local area network technology.
The meeting welcomed the initiative and agreed the objectives.
Sponsorship for the workshop is being sought from the CEC, ECFA and COST 11. A sponsors committee is being set up to keep them informed. This committee will operate by correspondence.
The proposed date is 13/14/15 May 1985.
The proposed location is a CEC meeting room in Luxembourg. This will hold between 60 and 70 people depending on whether translation facilities are demanded.
It was thought that the greater number would be preferred to translation facilities.
Thanks are due to the CEC for providing the rooms free of charge. However delegates would have to pay for meals and hotel accommodation. B Mahon would provide a list of hotels to delegates who would be responsible for booking their own accommodation.
Should the CEC room be unacceptable then M Hine offered to host the meeting at CERN.
It was originally envisaged that the meeting would be limited to 100 but the size of the room and the desire to make the event a workshop rather than a conference suggests that the size should be 70.
The delegates would be selected by national representatives who are themselves selected by the Organizing Committee. However, speakers would come out of a country's quota. Delegates should be people who have influence in their countries and are in a position to effect network developments.
The numbers of delegates from each country and the country representative are:-
Country Total no. Speakers/ Not yet National
Delegates Organizer allocated representative
Austria 2 0 2 Prof. Kernel
Belgium 2 0 2 P Van Binst
Denmark 2 0 2 J Richter
Finland 2 0 2 J Ekberg
France 6 3 3 J-L Grange
Germany 7 5 2 B Butscher
Greece 1 0 1 ?
Ireland 2 0 2 J Scanlen
Israel 1 0 1 A Cohen
Italy 6 3 3 E Valente
Luxembourg 1 0 1 B Mahon
Netherlands 3 0 3 R Blokzijl
Norway 2 3 0 W Jensen
Portugal 1 0 1 ?
Spain 3 0 3 G Thomas
Sweden 3 1 2 B Carlson
Switzerland 2 0 2 J Harms
Turkey 1 0 1 ?
UK 7 4 3 P Linington
Yugoslavia 2 0 2 T Kalin
CEC 3 2 1 B Mahon
CERN 4 3 1 M Hine
PTTs 2 1 1 B Mahon
It is expected that the numbers will be adjusted as some countries will not meet their quota and others may require to send extras.
Invitation 'packs' would be put together by Rutherford and B Mahon and sent by RAL to representatives who would then invite the delegates. Forms would be returned to B Mahon. There would be no registration charges and delegates must be encouraged not to drop out without notice, it may be sensible to allow a little over booking.
The countries involved are the COST ones plus Israel.
It was agreed that a workshop atmosphere should be encouraged. Presentations should be by invitation and plenty of time left for discussion. Where possible rapporteurs would be used to summarize the European situation, rather than having short papers with overlapping contents. Written papers would be requested and proceedings published.
Monday 13 May.
Lunch
Session 1. Chairman J-L Grange. Introduction and survey of networks.
14.30 Introduction and welcome.
14.45 Background to European Academic Harmonization. Prof. Zander.
15.15 Rapporteur session on national academic networks. P Linington
16.00
Tea
Session 2. Chairman M Hine. Survey of networks continued.
16.30 Discussion and stop press news on national academic networks.
16.45 Rapporteur session on international networks. B Carlson.
17.15 Rapporteur session on ESPRIT, RACE and COST 11. H Hunka
or Prof. Helms.
17.45 General discussion.
18.00
Tuesday 14 May
Session 3 Chairman P Bryant. Low level protocols.
9.00 X25 84, PTT transition plans and time scales. PTT person to be
suggested by B Mahon.
9.30 LAN WAN gateways. Lenzini.
10.00 Terminal access; XXX and VPT. U Beyschlag.
10.30
Coffee
Session 4 Chairman J Hutton. Applications and high level protocols.
11.00 File transfer. Protocol review and GIFT. F Fluckiger.
11.45 Mail, MHS and TELETEX. A Hansen or K Bringsrud.
12.30 Rest of world report. P Kirstein.
12.45
Lunch
Session 5 Chairman B Butscher. Network management.
14.30 Directories and name management. Santo.
15.00 Performance and failure reporting. B Mahon.
15.30 Tariffs and charges. J Hutton.
16.00
Tea
Session 6 Chairman E Valente. Transition plans for current networks.
16.30 ISO overview and CEN/CENELEC activities. H Zimmermann.
16.50 JANET transition. P Linington.
17.00 DFN Transition. Ullmann.
17.10 EARN transition. P Bryant.
17.20 French transition. Salzedo.
17.30 Italian transition. Valente will provide.
17.40 Nordic transition. Jensen will provide.
17.50 Discussion.
18.00
Wednesday 15 May
Session 7 Chairman B Mahon. Future services.
9.00 Future telecom requirements and possibilities. M Hine.
9.45 Future applications and user requirements. CAD CAM, Graphics.
Encarnacao.
10.30
Coffee
Session 8 Chairman Prof. Zander. Conclusions and future activities.
11.00 Summary of sessions. Chairman panel.
11.45 Discussion and recommendations.
12.30 Closing session
12.45
Lunch.
It is not intended to hold a further meeting of the organizing committee but it is intended to use Swedish KOM for sorting out any further details.
Secretaries note:- Members of the organizing committee are asked to return any comments on the proposals as soon as possible so that the distribution of the packages can be completed. We would hope to circulate the information packs to national representatives by mid February. Please let us know as soon as possible when the speakers you are contacting have agreed.
B Mahon Check size and availability of room.
Provide hotel/travel information for information pack and
contact point for return of booking.
P Linington Produce technical program, cover letter etc.
Assemble and dispatch information packs to national reps.
B Mahon Propose national representatives for Greece, Portugal and
Turkey.
All Contact potential speakers as follows:-
Butcher for Zander, Santo, Ullmann, Encarnacao.
Hine for Beyschlag, Fluckiger.
Mahon for Hunka or Helms.
Hutton for Carlson
Jensen for Hansen or Bringsrud and transition statement.
Linington for Kirstein.
Valente for Lenzini and transition statement.
Grange for Zimmermann, Salzedo.
The meeting was aimed at informing one and all on how remote observing was getting on. You may recall that I took part in some early experiments to UKIRT over PSS some time ago. There is also a report of this meeting in New Scientist which gives a different picture. I gave a talk on 'Communications Options and Standards'.
My impression was that although there had been a lot of progress the whole subject was in some confusion as each group was 'doing its own thing'.
One wants to indulge in remote observing so that astronomers do not have to visit the telescopes and in order to use telescopes more effectively. Remote observing is one of three options. The others being 'service observing' and 'hands on' observing. Service observing is for well defined observations which can be carried out by the staff at the telescope - for example - a systematic survey of some area of the sky. Hands on observing is for those who derive some pleasure from climbing mountains and spending a cold night at the sharp end of a telescope. Conversations reveal that these people are a dying breed who, in any case, have little idea of what they are up to. They tend to produce instruments on their kitchen tables which are rough and unreliable as well as needing constant attention from their masters (or is it their slaves.
Remote observing has been carried out in a variety of ways. The UKIRT work is over PSS and is achieved via interactive calls using PADs and reverse PADs. ROE has had a PSS connection put in for the purpose due to the 'dubious' reliability of the JANET gateway at Rutherford. It has never ceased to amaze me how a problem like our gateway can turn people off and incur expenditure the size of which could sort out the problem to everyone's benefit. At Kitt Peak users have a 'kit' consisting of a terminal, a squawk box and a slow scan video. This all runs over three dial up lines. The kit goes from place to place.
Of particular note is the use of a reverse PAD to get into a VAX because the VAX PAD code is too slow on a VAX 11/730. What an indictment. Perhaps another aside is in order. I see an increasing move towards the way Americans use X25 via PADs reverse PADs and a move away from the original UK idea that network code should be reasonably intimate with the computer. One can cite the use of reverse Ring PADs at Oxford and the Ungerman Bass kit at Daresbury as well as the astronomers.
Quite a lot of work is going into making instruments more reliable. I believe work should also go into standardizing the interfaces for the instruments and there are indications that things are going that way. One man stood up and said that astronomy was traditionally done on the cheap and on home brew instruments which needed careful attention. This gent, I learned latter, was a well known astronomical Wally.
At RGO they are linking computers and instruments over an ethernet. I had an interesting talk to someone (its a good job I cannot remember who) who told about the standards they were going to use and how they intended to elevate them over the ISO standards as these became available. It was clear that he was totally ignorant about what the rest of the world was up to and I told him in no uncertain terms that he was on to a loser but I made no impression.
Another gent tried to convince me that astronomers somehow needed different facilities to others in terms of speed and reliability. This seems to be an excuse for taking some short cuts and to do their own thing. Basically I can see no real difference between their needs and many other in the laboratory automation field and I feel that they would be well advised to look and see what is happening elsewhere and save themselves some time and money.
I left with the impression that the standards issue had not been appreciated and we shall see a further generation of 'roll your own'. However I did feel that several people were starting to appreciate that there was something to be gained from standards, automation and reliability so I was not all that downhearted - in truth the very fact that the meeting was held and well attended was encouraging.
I have been asked whether staff members can purchase IBM PCs via the Laboratory for private use. Could you please find out whether this is possible. We currently get 20% discount from IBM and we are treated as an IBM PC dealer and I suspect IBM will have no objection to this activity although I will check on this point should Rutherford have no objections.
Many companies allow employees to take advantage of purchase agreements arrived at. Shops, more often than not, give their staff such facilities and I know of many industrial organizations which do the same. It does not seen unreasonable for Rutherford to help its staff in this way particularly in this case where the equipment may well be used for some of its life to Rutherford's benefit.
The aim of the NRS is to allow sites to register the names of services they provide in a central data base and to allow this data base to be used by other sites for updating their name servers. It is considered that names of services should be used in preference to numeric addresses in the interests of user friendliness and to allow the underlying networks to change without changing the user interface. It is thought advantageous for the name of a particular service to be common across the community as the alternative would be that each site would name everyone else's services and this would be very confusing particularly to the itinerant users.
The details of the NRS were developed by a JNT group who were heavily influenced (or dominated) by Salford University. In my view the result is over complex. However we are now stuck with it and it would be counter productive to argue for changes to the scheme.
Salford have been given the job of setting up a data base and providing a means of accessing it across the networks. This is reaching some level of usefulness. It is regretfully written in FORTRAN rather than Salford adopting a well proven data base package. In my view, since it is a large new data base package, one can expect it to have many faults and shortcomings which will make any reliance on it inadvisable for some time to come.
Salford provide facilities for sites to access the data base for updating or retrieval on a service by service basis or the whole data base may be file transferred. Some test have been run from Rutherford with a measure of success.
Salford also provide Fortran code which is portable and can be put in a host on a site to help a site maintain its name tables. Judging by the quality of the code provided by other Salford packages one would be ill advised to rely on this code at an early date.
It is not possible to estimate the effort required or when that effort will be required for the second two phases until further experience and knowledge is to hand.
NDM has been considering NRS for some time and progress has been made. In consultation with HEP and Informatics names have been chosen. The attitude taken has been to make the new names as similar to the old ones as possible although complete identity is not possible. Some decisions have been taken as to the subsets of names to be put in various machines. We hope to take advantage of code being produced by ULCC for the IBM machines. Although the PRIMEs are not our responsibility it is believed that there are no problems. There are minor problems with VMS VAX systems but these will be cured by UWIST. That leaves the GEC.
All the GEC code is geared to using 4 characters and it would be difficult to change this. There are a number of alternatives which are:-
The adoption of NRS is going at about the right speed, that is keeping pace with other sites. Thus there is no real cause for alarm.
My view is that we must follow NRS or be seen as not supporting the national academic networking effort which would reduce our credibility and be counter productive in influencing our lords and masters.
It is highly likely that there will be a lot of anomalies on various sites for some time to come and so a perfect transition to NRS is unlikely and unnecessary if the price is high.
The effort which we can afford to put into the GEC depends on how long we expect them to survive and whether funding for the work can come from else where. The GEC still plays quite an important part in our activities particularly in networking where NRS is important.
Dear EARN Technocrat,
I now have a final (I hope) list of the participants for the EARN Technical meeting to be held at The Cosener's House in Abingdon on 18/19/20 February. I am sending this letter to the EARN BOD members and participants just to make sure no one is left out. I have learned the hard way that the postal services are a bit poor in some countries. If anyone does decide to turn up at the last moment it should not be difficult to find accommodation in a local hotel.
The first table is the list of participants. Some of the names were taken over the 'phone and I apologise if the spelling is wrong. The important columns are 'Arrival' and 'Trans' which is your arrival time and whether I will arrange transport from Heathrow. My driver will be holding a card marked 'Rutherford Appleton Laboratory' and will meet you at the exit from customs. Since he may have to pick people up from other terminals you might have to wait a few minutes.
I attach a list of the names and addresses of the participants as well as a copy of the program.
On the 18 February I shall be at the Rutherford Laboratory until 17.00 and at Coseners House from 17.30. The telephone number of Coseners House is (0235) 23198. I look forward to meeting you.
If I have missed anyone it is probable the postal services and I would ask you to 'phone me or send a telex particularly if you need transport from Heathrow.
Yours sincerely
Paul Bryant.
Jean Louis Ambeosio CNUSC Paul Bryant Rutherford Appleton Laboratory Tony Burraston Rutherford Appleton Laboratory Mats Brunell QZ Stockholm University Oded Comay Tel Aviv University Arthur Ecock City University New York Per Arne Enstad Runit / Sintef Lello D'Erasmo CNUCE A Fusi IBM Italy Dipl. Jug Hans-Ulrich Giesc Universitair Pekencentrum Peter Girard Rutherford Appleton Laboratory Jurgen Harms Universite de Geneve Francoise D'Hautcourt Universite Libre de Bruxelles W J Karman URC Olivior Martin CERN Dominique Pinse IBM France M Pitteloud University of Zurich Ari Rikkila Finnish State Computer Centre Mauno Salomone CNUCE Colin Setford IBM UK Morten Hoegh Sorensen NEUCC Mauro Salome CNUCE Peter Streibelt IBM Germany Gusta Sunberg QZ Stockholm University Bertahol Tasch IBM Germany Michael E Walsh University College, Dublin Roland Wolf GSI Paola Zupa CNUCE
IMPORTANT- I intend to introduce each topic with informal short presentations from delegates. I would appreciate people being prepared to talk on topics they feel they can contribute to. These will be more valuable if written contributions can also be provided. I do not intend to keep to the times and these are just for guidance.
February 18.
Arrive. A buffet supper will be available and there will be an
opportunity to get to know each other.
February 19.
9.00 Introductions.
Review of state of EARN - Plans for the rest of the meeting.
Documentation.
How should the existence of documents be publicised? How
should they be circulated and maintained?
Centres of excellence.
It may be appropriate to designate certain people or sites as
'experts' on particular products and provide help to others.
10.30 Software Distribution
Mechanisms for software distribution, software updates and for
maintaining catalogues.
Services.
NETSERVE is running at Darmstadt, CERN, Spain and Italy and
provides user information services and node management. What
problems are there and what further developments are needed
Name Registration
What naming standards should be followed? How should these
relate to names used in BITNET, JANET, DFN and other networks?
Directory services.
A directory service for users is needed. What product(s) are
needed, where should they be located and how should they be
maintained? How will this service relate to similar services
on BITNET and other networks?
Mail.
EARN requires a mail service and the MAILER is a possibility.
It is important that it will allow mail to pass through
gateways to other networks. Should we adopt RFS 822 or try
to develop along MHS lines?
14.00 Node management.
EARN needs to decide how routing tables are to be updated,
generated and distributed. How will EARN routing relate to
BITNET ones? Should there be a single master table or should
each country have a separate table?
Network problems.
Problems with RSCS, JES2, JES3, JNET and other products. What
problems exist, what problem or error reporting facilities
are needed?
Accounting and statistics.
Accounting and statistics facilities are needed to satisfy the
PTTs. Can a single program or set of programs be provided to
satisfy every countries requirements.
Management
Network management facilities are needed to ensure maximum
availability. What products exist, how should they be
developed and what new ones are needed?
15.00 Gateways to other networks.
What gateways are to be provided. What possibilities are
there for cooperation? What products need to be developed?
How should inter networking problems across Europe be tackled?
Conferencing.
EARN requires a conferencing system. What system should be
adopted?
February 20.
9.00 User applications.
What applications will be provided? How will these services
be advertised? Should there be an 'EARN Journal' for
advertising services and developments?
10.00 Migration to ISO protocols.
As a result of being allow to use leased lines EARN has
agreed to migrate to the use of ISO protocols. It will be a
job of the technical group to advise on how this should be
achieved. What route should be taken and what time scale
should be adopted?
Future meetings.
Should there be further meetings, if so when and where? How
should the work of the group be developed and monitored
between meetings?
14.00 Depart.
Dear EARN Board Member,
At a recent EARN BOD meeting I was asked to write to IBM asking them what plans they had for producing products that could help EARN migrate to ISO protocols and the use of public networks as requested by CEPT. I have now received a response which I attach.
My initial impression is that it is a very helpful and positive statement. I am particularly pleased that IBM will be putting in resources to address directly the needs of EARN and also that the time scales are well defined. The statement can do nothing but good in our negotiations with the various regulatory authorities. This is certainly true in my own case where discussions are still regretfully dragging on but none the less progressing.
There are a few minor points to be clarified. In particular it is unclear what part IBM would like us to take in the Task Force's work. I would like to give IBM as much help and advice as possible and would certainly be willing to participate as far as I am able. The work should be of direct benefit to JANET as it plans its own migration to ISO and I suspect that DFN and the other national academic networks will also benefit.
I am circulating the letter to the EARN technical group for consideration at the forthcoming meeting on the 18/19/20 February. The invitation to participate has had a good response and I am expecting 21 participants just now. I suspect the numbers will rise as I know that the various documents have met appalling postal delays. I attach a list of participants as it now stands and I will also put it in KOM. If there are names missing I would appreciate a TELEX or 'phone call to make sure I make suitable provision.
Yours sincerely
Paul Bryant.
Dear Herb,
The statement you made in your recent letter concerning ISO and the help IBM will give EARN was most welcome. I have forwarded it to the BOD members and I attach the covering letter.
In your letter is was unclear what part you intend the EARN members to take in the work. Personally I believe it would be useful if we could take part in various phases of the work in particular with respect to the end services provided, the priorities given to the provision of these services and in the provision of test environments in the community where we could prepare the products for service. I believe that the IBM Task Force will have a lot of relevance to the migration of JANET to ISO protocols and I would suggest that it could also be useful to involve JANET when relevant. I am most anxious to encourage and help the work in any way I can both from my EARN and JANET positions.
I can give you a modicum of good news on the licence front. According to Mike Wright of DTI all parties have now agreed except OFTEL. It is going via their committees just now but Mike will not disclose the content of the minutes but leads me to believe that there is no problem. He has given me a draft of the licence and I enclose a copy for your information. I would be grateful if you would treat it as confidential since it is only a draft, none the less I would welcome any comments which I will relay to Mike.
Perhaps I will see you on the 6th when we could discuss it further.
Yours sincerely
Paul Bryant.
Dear Colin,
I enclose the very positive statement on ISO that Herb Budd sent me. I have also sent it to the EARN BOD members but not the IBM EARN reps. I find it very encouraging and hope to talk to Herb on how EARN members and also the JANET community can assist the work.
Mike Wright has now decided to send me a draft of the license and I enclose a copy. I would be grateful if you would treat it as confidential until we have a final copy. I have sent a copy to Herb. Mike tells me that he expects to see quite a few changes. I would appreciate any comments you have which I will forward to Mike.
I have not given it extensive study yet but I have noted a few points:-
I would prefer not to question any of the sections unless we feel there is a real need or we just delay matters.
So far I have 22 people coming to the technical meeting and things are going well. I caught a bit of a cold because the postal services are so bad on the continent and the notices only reached some places in the last week. I suspect that there are a few replies still in the post.
Yours sincerely
Paul Bryant.
The secret of understanding the sort of equipment supplied by the 'bolt on specialists' is to realize that they more often than not copy an existing piece of IBM kit but do it cheaper or add on a bell or whistle. It is exceeding rare to find volume manufacturers stray from the straight and narrow and ITL is no exception.
IBM have a pieces of equipment that allows IBM 3270 and line by line terminals to be multiplexed down an SDLC link to an IBM machine, they are 3271, 3274 or 3276. It is part of their SNA product range. The ITL 3703 emulates this equipment. ITL have added the facility of allowing other non IBM terminals to be connected, in particular things like ordinary glass teletypes.
It is irrelevant to JANET or X25. I can see no way in which it can be used.
The equipment could be useful if we wish to build up an SNA network as it is from such equipment that an SNA network is built. The device could have its terminal lines connected to PACX and so allow current terminals to get SNA access to whatever the device was connected to.
You could say that the 3703 is to SNA what the JNT PAD is to JANET.
It appears to me that we are steadily building a separate network for the administrators which looks like it will be SNA. This equipment could certainly be useful. It worries me that we will have to provide expertise and effort to support this other network which will dilute the effort being put into JANET. I am no SNA expert but Peter Girard went to a seminar which suggests that looking after such a network requires at least two good experts to keep the software side in shape and there must be some cost in maintaining a separate set of lines with protocols that we currently do not understand or know how to maintain.
EXYLINK is another type of product which allows an IBM PC to emulate a 3278 or 3279 full screen terminal over a bi-sync line. It also allows a PC to act as a 3276 cluster controller or concentrator for up to 5 other PCs. There are many manufacturers selling such products. We have not considered them as they cannot operate over JANET and require a bi-sync port on the IBM or on a cluster controller and these developments have been suppressed in the interests of developing along the lines of the full screen CIFER. This sort of product has the advantage of having a better performance due to the IBM PC CIFER product having to go via the network and encounter certain delays which we are not allowed to call the PAD problem. An additional point is that we do not yet have a strong need for constructing clusters of PCs into the IBM and when we do I hope that our Ethernet project will be looking good.
The display phone is again an example of a device which is becoming common. Bob Hopgood had a similar device on trial. All it is is a glass teletype with a built in modem and telephone. The advantages are:-
The disadvantages are:-
My opinion - I would not have one as a gift. It would make a fine executive toy. Incidentally- I have rarely seen advertising blurb so uninformative. I had to work hard to find anything useful in the paper. The device can work over a special data set in the case of the SL-1 exchange. We have some of these data sets as an experiment and gave up because of the expense per terminal. Also they were delivered many many months late. Try asking David Rawlinson about SL-1 equipment. He says that it is taking 6 months or so to get further equipment for the PABX!
Note for $ read also all prices are ex VAT.
Investigations are now concentrating on a range of options centered on the 'CASE B LINE' and the 'BRAID' systems.
The CASE B LINE forms part of a series of products for setting up sophisticated networks. Thus, the device can be connected to a large variety of equipment including X25 and sophisticated proprietary switching systems. The CASE B LINE has an interface to TELEX and provides spooling, printing, authorization, interfaces to devices and many other bolt on 'goodies'. A box is available from SIPHER which will allow the B LINE to be connected to a variety of IBM terminal interfaces the most interesting of which is RSCS. This device can accept a file from the IBM via RSCS and then forward it to the CASE B LINE over an asynchronous interface, and vice versa.
An alternative possibility is to connect the CASE B LINE to the X25 network when it will look like an X29 server. X29 is a terminal protocol.
The cost is high at between $45,000 and $50,000 depending on configuration and including $6,000 for the SIPHER. X25 access would add $4,000 but if only X25 access were needed the SIPHER could be dropped at a saving of $6,000.
The BRAID equipment is a TELEX modem and code for an IBM PC. To connect it to the IBM or network, code would have to be added to the IBM PC to move data between the IBM PC and the rest of system. Corresponding code may be needed in the other systems the BRAID connects to. The system is cheap at $1,900 plus $200 for a software interface to the BRAID code. BRAID have produced a software package for a customer which provides an asynchronous interface to another system. This is probably not sophisticated enough for Rutherford as it lacks facilities such as returning the TELEX 'answer back' to the user but it could form the basis for development. It costs $1,500. A suitable minimal IBM PC would cost $2,000 but a better configuration with a hard disc $3,200.
There are two main possibilities for both CASE B LINE and BRAID:-
The various options are described below with a list of their characteristics.
_____ ______ ______ ____ ____ |TELEX|-A-|CASE |-B-|SIPHER|-C-|4705|-|3033| |MODEM| |B LINE| | | | | | | |_____| |______| |______| |____| |____| A = 50 bps async link B = Async connection with IATA protocol C = RSCS connection with IATA protocol
The IATA protocol is used by the airlines and is exceedingly simple. It delimits the start and end of a document and defines where certain address information resides. It contains very primitive checking, re transmission and security features.
The CASE B LINE can have multiple TELEX connections. It also has logging and printing facilities. The WELCOME FOUNDATION has developed a system in the IBM for surrounding a PROFs document in IATA protocol and putting it in an RSCS spool. The system informs the PROFS user when the CASE B LINE has accepted a document and when the remote TELEX machine has accepted it. TELEXes can be delivered as a PROFs document automatically if constructed according to 'rules' by the sender. In practice delivery of all TELEXes for non users of PROFs and arbitrary TELEXes would be done by human intervention on an IBM 3270. This is likely to be a very high proportion of TELEXes. Outgoing TELEXes for non PROFs users would be handled manually but could be entered on an IBM 3270.
Advantages:-
Disadvantages:-
_____ ______ ______ _______________
|TELEX|-A-|CASE |-D-|X25 |-D-|GEC TELEX SPOOL|
|MODEM| |B LINE| |SWITCH| |OR SOME OTHER |
|_____| |______| |______| |_______________|
|
D
__|__ ________
| PAD |-E-|TERMINAL|
|_____| |________|
A = Async 50 bps link
D = X25 and X29 link
E = Terminal connection
Two methods of working are possible. A terminal can access the CASE B LINE directly. Such a procedure would not allow the answer back to be returned to the user unless he remained connected to the CASE B LINE. The second method is to modify the existing TELEX spooler in the GEC (which was developed for TELEX over PSS) to drive the CASE B LINE. This is not difficult as the requirements of the CASE B LINE are similar to the requirements of TELEX over PSS. It would be possible to write a new spooler for some other machine but this would be a large job. The GEC spooler has the advantage that it has a very sophisticated system for attempting to deliver TELEXes by an analysis of the content of the TELEX. Methods exist for forwarding un deliverable TELEXes by human intervention on any machine offering GREY BOOK MAIL with forwarding facilities.
Advantages:-
Disadvantages:-
NOTE- The two schemes above can coexist.
_____ ______ ______ _______________
|TELEX|-A-|IBM PC|-D-|X25 |-D-|GEC TELEX SPOOL|
|MODEM| | | |Switch| |OR SOME OTHER |
|_____| |______| |______| |_______________|
|
D
__|__ ________
| PAD |-E-|TERMINAL|
|_____| |________|
A = Async 50 bps link
D = X25 connection
E = Terminal connection
The biggest difficulty with this solution is to obtain X25 code for the IBM PC and to interface this to the BRAID TELEX code. The attractions is that X25 code is required for other purposes. No changes, or only trivial changes, would be needed to the existing GEC TELEX code. In fact the work needed on the GEC is virtually identical to that required in the CASE B LINE - X25 system. It would be possible for terminals to connect directly to the BRAID across the network.
Advantages:-
Disadvantages:-
_____ ______ _________________ |TELEX|-A-|IBM PC|-F-|GEC TELEX SPOOLER| |MODEM| | | |OR SOME OTHER | |_____| |______| |_________________| A = Async 50 bps link F = Asynchronous connection
In this solution the GEC TELEX system is modified to drive an asynchronous connection rather than an X25 one. This is a modest size job. Code would have to written in the IBM PC to match the code in the GEC and this also is a modest size job.
Advantages:-
Disadvantage:-
_____ _________________ |TELEX|-A-|GEC TELEX SPOOLER| |MODEM| | | |_____| |_________________| A = Async 50 bps link
In solution 7 the IBM PC replicates what the TELEX spooler in the GEC is doing. Thus the IBM PC is not essential. It is only there because TELEX equipment has to have BT approval and the GEC has no such approval. The work required is less than in solution 6 in that no IBM PC code is needed.
Advantages:-
Disadvantages:-
_____ _____ ______ ____ ____ |TELEX|-A-|BRAID|-A-|SIPHER|-B-|4705|-C-|3033| |MODEM| | | | | | | | | |_____| |_____| |______| |____| |____| A = Async 50 bps link B = Async connection with IATA protocols C = RSCS connection with IATA protocols
This is a hybrid solution which makes the BRAID system imitate the interface provided by the CASE B LINE. Its main advantage is reduced cost.
Advantage:-
Disadvantages:-
The aim of the project is to automate the telex service. This should reduce staff costs and speed the delivery of TELEXes to users.
Solutions which interface TELEX to PROFS is deficient in not providing a service to GREY BOOK MAIL users which form the bulk of the scientific users and also the users with the most demanding requirements in terms of time constraints and sizes of TELEXes. This could be overcome by developments in the IBM to improve the PROFS to GREY BOOK MAIL system and this is desirable for other reasons.
The cost of the CASE B LINE is probably too high considering the benefits obtained.
Solutions based on the BRAID equipment need software effort and subsequent maintenance. The BRAID equipment has no facilities for authorization and these would have to be added preferably in the GEC spooler.
Accounting is present in the CASE B LINE and to a lesser extent in the BRAID. However both are deficient in not providing mechanisms for transferring this information into a large machine so that billing can be automatic. Ideally accounting should be ether in the IBM or GEC spooler depending on the solution chosen. As far as is known the WELCOME code has no mechanisms and so would need enhancement. Currently all traffic through the GEC spool is recorded in the GEC journal and to pick out the TELEX traffic is fairly straightforward but would require work on the GEC accounting suit. Some minor enhancements to the information going into the journal would be needed. Without a better understanding of the WELCOME code it is not possible to estimate the effort needed. In the GEC case the effort should be less than one month.
The ideal solution of using TELEX via PSS (which exists) is deficient in not allowing international traffic and carrying a high tariff which makes a TELEX approximately three times as expensive as a normal TELEX.
The second choice of a modem directly connected to the GEC and a modified TELEX spooler regretfully needs BT approval and the magnitude of this problem is not known but experience suggests that it may not be easy. It could be a solution to be pursued at leisure once some other scheme is in place.
The next most attractive solution is to use the BRAID equipment interfaced to the GEC via an asynchronous interface.
The CASE B LINE via X25 is next in line but suffers from very high cost.
Next comes CASE B LINE via the IBM which also suffers from high cost and also does not provide a service to GREY BOOK MAIL users.
BRAID connecting to the IBM via the SIPHER is getting a bit complicated and also does not provide a GREY BOOK MAIL service.
BRAID with an X25 interface must currently be discounted due to the lack of a suitable X25 package for the IBM PC. In the long term it might become attractive.
The recommendation is:-
This strategy has the approval of NDM.
Start Finish Activity
Month Month
0 1 Order IBM PC and Braid equipment (Admin budget)
0 1 Produce detailed design- one man week- PEB, GWR, SAW
1 2 Install PC, set up stand alone TELEX system- one man
week- PEB, GWR, AJ.
2 4 Produce GEC code- 2 man months- This work could
start earlier and may slip due to competing work
2 4 Produce IBM PC code- 2 man months- this work could
slip due to competing work
2 4 Study accounting and authorization requirements- one
man week- various people
2 ? Study problems of BT approval- PEB
4 ? Implement final accounting scheme- effort depends on
study
? ? Study an X25 connection to the IBM PC
? ? Improve IBM/PROFS GREY BOOK MAIL.
IMPORTANT- I intend to introduce each topic with informal short presentations from delegates. I would appreciate people being prepared to talk on topics they feel they can contribute to. These will be more valuable if written contributions can also be provided. I do not intend to keep to the times and these are just for guidance.
February 18.
Arrive. A buffet supper will be available and there will be an opportunity
to get to know each other.
February 19.
9.00 Introductions.
Review of state of EARN - Plans for the rest of the meeting.
Documentation.
How should the existence of documents be publicised? How
should they be circulated and maintained?
Centres of excellence.
It may be appropriate to designate certain people or sites as
'experts' on particular products and provide help to others.
10.30 Software Distribution
Mechanisms for software distribution, software updates and for
maintaining catalogues.
Services.
NETSERVE is running at Darmstadt, CERN, Spain and Italy and
provides user information services and node management. What
problems are there and what further developments are needed
Name Registration
What naming standards should be followed? How should these
relate to names used in BITNET, JANET, DFN and other networks?
Directory services.
A directory service for users is needed. What product(s) are
needed, where should they be located and how should they be
maintained? How will this service relate to similar services
on BITNET and other networks?
Mail.
EARN requires a mail service and the MAILER is a possibility.
It is important that it will allow mail to pass through
gateways to other networks. Should we adopt RFS 822 or try
to develop along MHS lines?
14.00 Node management.
EARN needs to decide how routing tables are to be updated,
generated and distributed. How will EARN routing relate to
BITNET ones? Should there be a single master table or should
each country have a separate table?
Network problems.
Problems with RSCS, JES2, JES3, JNET and other products. What
problems exist, what problem or error reporting facilities
are needed?
Accounting and statistics.
Accounting and statistics facilities are needed to satisfy the
PTTs. Can a single program or set of programs be provided to
satisfy every countries requirements.
Management
Network management facilities are needed to ensure maximum
availability. What products exist, how should they be
developed and what new ones are needed?
15.00 Gateways to other networks.
What gateways are to be provided. What possibilities are
there for cooperation? What products need to be developed?
How should inter networking problems across Europe be tackled?
Conferencing.
EARN requires a conferencing system. What system should be
adopted?
February 20.
9.00 User applications.
What applications will be provided? How will these services
be advertised? Should there be an 'EARN Journal' for
advertising services and developments?
10.00 Migration to ISO protocols.
As a result of being allow to use leased lines EARN has
agreed to migrate to the use of ISO protocols. It will be a
job of the technical group to advise on how this should be
achieved. What route should be taken and what time scale
should be adopted?
Future meetings.
Should there be further meetings, if so when and where? How
should the work of the group be developed and monitored
between meetings?
14.00 Depart.
The formal minutes of this meeting are being distributed and this note is an informal account of it.
The meeting was successful. Since it was the first such meeting it was inevitable that we had difficulty exploring topics in detail and that much of the meeting was taken up with education. However this was time well spent as was the time spent in the 'pub' where a lot of business was conducted in a very satisfactory way.
29 people attended but we managed to keep proceedings informal but with many more this would have been impossible. Most countries were represented and IBM supplied 6 experts. Inevitably the meeting tended to be dominated by the Germans who had done most developments and the English speakers who had an unfair advantage.
Naming produced some contention. Germany had proposed and followed a proposal made a long time ago. This defined the first character as a country code, the next two as a location, the next three as a machine name, the next one as the RSCS type and the last to remove ambiguity. Some members felt that the first two characters should be the two ISO country code characters as one character was to few and gave some counties rather meaningless codes. Also the scheme would break down when more countries joined. Some felt that the use of the remaining characters was not ideal and that the system in use should not be included as it would be disruptive if systems were changed. Since several countries had adopted the scheme is was difficult to move to a new one if it involved changing existing names. The decision was to let countries use whatever names they liked as long as they did not clash but to recommend that the first two characters would be the ISO country code. Unfortunately we could not agree to avoid using other peoples country codes. I found this disappointing.
NETSERV, which is being produced in Germany, was demonstrated and found favor. It looks like being important in managing EARN. It seemed a pity that we will not be using the same system as BITNET. There was a feeling that there should be some talks with the Americans to see if some convergence is possible between the products. The hierarchical nature of NETSERV was considered and it was unclear whether it was satisfactory but the opinion was that we should see how it works in practice.
The Germans described and demonstrated their statistics gathering and monitoring system. Again we found that BITNET was working on a similar system and again it was felt that it would be good if the systems could converge to adopt the best features of both. The topology of EARN makes comprehensive monitoring difficult and it is unclear how one gets an overall picture of the health of the network. It appears that there will have to be a number of monitoring points strategically placed.
The Germans described their statistics gathering system. This will also be used to supply accounting figures to the PTTs. We felt that we should take care to run exactly the same system in each country and to supply the PTTs with the raw data on which they should base their charges. It was important that the statistics seen from each end of a line were the same. We considered how we would like the PTTs to interpret the figures and thought we should establish some multiplying factor which would turn the raw figures into a measure of use in terms of bytes passed.
I gave a short presentation of ISO concepts and the options open to us under the CEPT agreement. It was clear that most members were not familiar with the topic and we did not progress with narrowing the options. There was curiously little enthusiasm for joining a working party to explore the topic in response to the letter from IBM. I felt that members were very busy and could not afford the time or did not have the finance to take part. However the UK, Sweden and Ireland are keen to contribute.
We agreed to publish an EARN Journal. We also agreed to achieve this by increasing the scope of the German one. We did this as no one had any resources. Thus material will be supplied to Germany and copies of the journal would be sent to each country representative for further distribution. The Journal would contain information with a low technical content on a large variety of topics related to EARN. It would be freely available and aimed at the general reader.
We agreed to meet again in September, probably in Zurich.
Everyone felt that the meeting had been useful and it was good to see the large amount of discussion taking place outside of the formal meetings. I believe that the major benefit of the meeting will be the personal contacts made which will help the understanding between the sites.
Networking seems to be a religious topic and the zealots support their causes in the utter belief that their cause is right. They pick up every possible argument whether supportable or not to further their cause. I am afraid that you and me fall into this class.
There is another aspect of networks that is important and that is finance. Any scheme can be made to be successful given resources and any scheme can fail if staved of them. This must be born in mind.
In your letter to James you comment on the poor performance of 3270 CIFERs. On the other hand you fail to appreciate many of the causes of that poor performance which are nothing to do with the concept but more to do with the equipment. You must be aware that all the X25 services into the IBM are via a single 48K line which is highly unreliable. Through this line goes ALL the full screen CIFERs and terminals which often number 70 as well as ALL the file transfers. In fact a high proportion of the total printing load of the IBM uses this route and then you wonder why response is bad. That is a criticism of unreliable equipment which should have been replaced years ago and of the number of lines and amount of network equipment employed. This is lack of resources. You also comment on the poor performance from CERN. In this case the X25 band width is only 4.8K so it is not surprising that performance is poor especially when traffic to the VAXes at CERN and to the work stations also use this channel.
You comment that you can get good response from a 3270 on a bi sync line at 9.6K and then go on to suggest that you could connect 32 such terminals to such a line and continue to get good response. I would have grave doubts. Unless the terminals are mainly idle I would imagine that you would get some erratic and bad performance.
The comments seem to imply that we would do a lot better to connect the CERN machine to the Rutherford one with RSCS and PASSTHROUGH. Such a procedure will no doubt give a good performance for those who need that service. It does mean that the band width to CERN will be permanently split and that one will not be able to get the full benefits of multiplexing. It is obvious that the better the multiplexing techniques used the better will be the utilization of the line and X25 multiplexing is very good in that it enables a large variety of traffic to be multiplexed effectively. I would invite you to try PASSTHROUGH after it has passed through a number of machines. The resultant performance makes a full screen CIFER look like lightening.
You seem to imply that we would do well to adopt SNA rather than JANET methods. I cannot see how that can be done. SNA is designed primarily for multiplexing terminals into central machines. There is no concept of having a network infrastructure, such as X25, which can provide sophisticated switching including, if required, multiple routes, load sharing and application independence. In SNAs case switching is in the central machines or in the front end multiplexers and is provided to switch terminals to other machines and is not aimed at computer to computer links although recent developments have plumbed in some facilities. Although SNA can be carried over an X25 network this is not as one might imagine. The X25 links merely replace a copper link and does not provide the switching facility needed and the hosts still provide this and if one is not careful links may well go over a number of X25 calls. A further problem is that SNA is not expected on VM machines until later this year and to contemplate a move to an as yet unavailable product does not strike me as sensible.
To say that IBM has had good well worked out networking techniques for many years is not exactly true. I would have said that they have been groping forward with a series of disasters. You may recall the origins of SNA and if you do not I would invite you to read the relevant IBM Journals of the early and mid 1970s. Here you will see that SNA was little more than what we used to call 'device independence' it allows a variety of terminals to attach to a variety of applications without the application having to know much about the terminal. It went on to define how such terminals could be cascaded into a central machine. It was certainly heavily based on how you connect terminals to single central machine and had no thoughts of distributed terminals getting to distributed machines. Further more it was dedicated to the 'closed network'.
As one reads on one sees how more bits and pieces have been stuck in to meet this need or that. One starts to see the possibilities of connecting front end together to allow terminals to attach to remote machines. However the whole system is still based on terminals getting at processors. When it comes to bulk transfers between machines, network mail and so on SNA seems to be lacking. I have spent some time trying to see how SNA copes with such problems and have failed. Peter Girard has also studies SNA and failed to see how it undertakes the types of task we see JANET undertaking. As far as we can see it can only support a file access mechanism.
You make comments on PC manufacturers supporting SNA. As far as I can see this is nothing more than emulating various terminals that SNA recognizes. The SNA support that larger machines provide seems only to mean that they support IBM SNA terminals and is little to do with networking. I cannot see a PC product that implements the file access facets of SNA on a PC. To be fair I cannot see any sensible X25 products which provide file access although FTAM can provide them.
You seem to imply that it would be wise if we gave up JANET type networking and install SNA. First I would comment that most machines in the Academic Community do not support SNA and cannot. Second SNA does not currently run over X25 and it is unclear how successful SNA over X25 would work. It is far from clear how file transfer works between IBM machines. It is even less clear how file transfer between other manufacturers machines would work as there are no products.
One may ask the question as to why IBMs corporate network uses RSCS and not SNA. The answer is that SNA cannot provide the mail and file transfer facilities and SNA is not suitable for networks with a large numbers of machines. One can also ask why BITNET and EARN have no current plans to use SNA. Again lack of suitable facilities and the high cost in terms of manpower prevents it.
You note the slowness of the definition of ISO protocols and even more their implementation. You are regretfully right. However, the ISO protocols are public, they are well thought out, they are attempting to address a wide range of problems. In the SNA case some parts of the protocols are secret. They are certainly not defined with a view to allowing other manufacturers to use them.
You further comment 'what happened to TELETEX'. I am happy to report that TELETEX is alive and well but not in the UK. The Germans and Scandinavians have been progressing the introduction of PTT services. You may be aware that ESPRIT is intent on basing its Committee Support Services on it. You will probably be unaware that the session and presentation layers of TELETEX are also in the X400 or Message Handling Protocols that CCITT has defined for interconnecting public mail boxes. There are already implementations of the protocol available on UNIX and VAX VMS. You will no doubt have heard of the COMICS project at CERN which proposes the use of MHS as a way of rationalizing MAIL services. The MAIL conference in PARIS last summer was unanimous is supporting MHS as the proper way to progress academic mail services in the future. The MHS implementations are already running at CERN and I am putting them onto our VAX for experimental reasons but will hope to introduce a service when the MHS product for VM becomes available from Waterloo university. In many ways MHS is a super set of TELETEX and introducing gateways between the two will be trivial. As BT will be providing gateways between TELETEX, MHS and TELEX I hope this will solve our TELEX problem in the long term.
Whilst I agree with you that ISO protocols have been slow to be defined and slow to be implemented at least they are well thought out and non-proprietary. They provide the only means of providing an open system. SNA has no hope of providing an open system since the underlying address mechanisms are 'closed' (that is every machine has to know about every machine, incidentally one of the curses of EARN). The protocols available on SNA do not meet the needs of the academic community for file transfer and mail. One should add that SNA is expensive in core cycles according to rumour and since traffic tends to go through each machine the congestion likely in a large network is likely to be far higher than with an X25 network where re routing, load sharing and fall back conditions on failure can be incorporated.
It is my belief that SNA is good for an organization with a small number of large IBM machines and a vast number of terminals mainly involved with transaction work.
The academic community, on the other hand, have a very wide variety of machines each with a clutch of terminals which have a lot of variety. The machines and terminals are constantly being rearranged without much notice. In these circumstances a closed network would be very difficult to manage.
I read with interest and some alarm your correspondence with James. I am also aware of a few of the things you are doing in the communications area. I am very alarmed that networking activities are taking place without my knowledge and without NDM's knowledge and without the consequences of the actions being considered. I am finding that the division is now speaking with two (at least) voices which must be somewhat confusing. This subject MUST be addressed and resolved and the division must have a single policy or we will fail in all directions. The current policy, as I understand it, is to support vigorously the policies of the JNT and considerable resources have been expended in that direction. It may well be that this policy is wrong in some or all of the areas we are concerned with and that we should formulate a new one. What I am totally opposed to is such changed happening without conscious decision.
Your correspondence paints a rosy picture of IBM network methods which I find is not shared by some people I talk to. I attach a paper Peter Girard wrote to Cliff some time ago, some comments on your note to James and some of my own religious thoughts on the subject.
Communications developments are now not only split between Divisions but between Groups in Computing Division. This has resulted in assembling a program of work for a particular group being difficult as work often involves effort from a number of sources. The loss of network staff from the Division and from the Laboratory has placed severe restrictions on the magnitude and quality of projects. A further difficulty is that the original network strategy was to follow JNT advice closely but now it seems that there is pressure to abandon this in part and follow a strategy of following IBM. If a policy of following both lines is taken then expertise in IBM products, which is now small, will have to be increased and the total effort in communications raised. If a policy of following only IBM is taken then there are some problems in deciding how to communicate with non IBM machines and with JANET. This matter needs urgent study.
The level of activity on the IBM PC has been low which is commensurate with the small number of machines installed. The main effort has been in administration, investigating products and considering how the machines ought to be networked. IBM PCs have been neither encouraged or discouraged and this has resulted in about 25 being installed. Recently the rate of purchase has been increasing to three per month and this indicates that increased effort may soon be needed to support them. There is a dilemma with IBM PCs as to whether they should be considered as part of the IBM setup and should use IBM network methods to attach to the IBM or whether they should be seen as needed to connect to an ISO network and only incidentally having access to the large IBMs. The group currently takes the latter view which is why IBM PC network methods are not being pursued.
The hardware group is now very well staffed. Currently it has a very large number of 'bit parts' each being of a modest size but combined they represent a lot of work. Projects range from building an X25 traffic measuring tool to investigating IBMs new cable system.
The objectives of the group are not well defined. The current projects are:-
a. Support of IBM X25 and Coloured Book products. b. Support of RSCS. c. Support of EARN. d. Development of Ethernet on the IBM e. Support and development of the IBM PC. f. Development of Ethernet on the IBM PC. g. Support of CIFER 3270 protocol. h. Various small scale hardware developments. i. Provision of technical assistance to Telecom group. j. A large number of small investigations
From time to time many other projects arise often at short notice which it is desirable to pursue.
The group attempts to support several of the networking groups set up by JNT and other bodies in the interests of influencing network standards and developments. The extent of this support has decreased considerably as the range of machines supported and the staff levels have reduced. In fact from being one of the strongest networking sites this is now a relatively weak one. Whether we are happy with this situation is a policy matter which needs resolution.
The group does not really have the resources to undertake its tasks and the result is that it cannot provide support and assistance in many cases. Of particular note is limited ability to investigate network performance, no activity on JTMP and lack of work on GEC network products. It is difficult to define a staff level without a clearer idea of our network strategy.
Little effort is going into supporting IBM network methods such as SNA which is in line with the network strategy but which should be reviewed.
The current group strength is 8 and the complement level is 9. The current recruitment activity may fill the vacancy. The 'current level' column is how staff are employed. The 'desirable level' represents the levels to carry out current and some desirable activities. There is no allowance made for undertaking any additional substantial activities.
Topic Description Current Desirable
level level
VMNCP/MVSNCP No development planned but it
requires maintenance and enhancements
are often needed such as the
support of NRS. It is highly
desirable that PMG should have some
back up. 0.1 PMG 0.1 ?
CMS-PAD Some enhancements pending. 0.1 AWB 0.1 AWB
VNET/RSCS Considerable maintenance effort and
effort to migrate to new releases
is needed. It is highly desirable
that AWB should have back up. 0.8 AWB 0.4 AWB
0.4 ?
NIFTP Requires enhancement and removal of
deficiencies. It is highly
desirable for PMG to have back up.
This work should be eventually be
under taken by someone else. 0.5 PMG 0.5 ?
JTMP No current effort. Considerable
effort required even if ULCC/
Salford product taken. Time scale
for the requirement is a bit vague. 0 1 ?
AMDAHL-4705 Considerable short term effort. 0.1 PMG 0.1 PMG
VM/SNA for X25 This product needs to be examined
shortly to see if it can be used
instead of COMM-PRO software. 0 0.1 PMG
EARN Effort setting up RSCS 0.1 AWB 0.1 AWB
EARN-Janet gateway (to be financed
by IBM) 0 0.5 ?
EARN management 0.2 PEB 0.2 PEB
If EARN is to be well supported
further effort is needed which
should be financed from elsewhere 0 0.5 ?
Ethernet Connection of IBM to HEP VAX
includes developments towards a
general purpose ethernet yet to be 0.9 NG 0.9 NG
defined. 0.2 AJ 0.2 AJ
Ethernet Looking after the cables and
management equipment on the CD and ID LANs 0.1 PB 0.1 PB
Memorex Difficult to estimate further
problem effort desirable. 0.1 PB 0.1 PB
Dial up Almost complete and should be
reorganization adopted by Telecoms. 0.1 PB 0.1 PB
Network Equipment is being designed and
monitoring constructed to monitor various 0.2 PB 0.2 PB
aspects of an X25 connection. 0.6 AJ 0.6 AJ
Terminal 'Box' to assist a teacher to
switch control students' terminals. 0.2 AJ 0.2 AJ
Fibre optic Design a general purpose fibre
infrastructure system for site communications 0.2 PB 0.2 PB
Design of This needs urgent study
backbone LAN 0 0.5 ?
Advice to Peter Blanshard spends a lot of
Telecoms time advising Telecoms 0.3 PB 0.3 PB
Supervision of The major tasks in sorting out the
workshop workshop are now complete. 0.1 PB 0.1 PB
IBM ISO It is desirable to attempt to take
an active part in the transition
of EARN and JANET to ISO protocols
as far as the IBM machines are
concerned. 0 0.3 PMG
IBM PC General developments and Ethernet 0.8 GWR 0.8 GWR
developments. 0.1 PEB 0.1 PEB
PC user Purchasing, evaluation and 0.2 GWR 0.2 GWR
support advice. 0.2 PEB 0.2 PEB
The increasing number of PCs
makes further effort desirable. 0 0.5 ?
PSS gateway This activity has been dropped
X25 switch due to loss of staff. Our lack of
maintenance knowledge and expertise is
embarrassing. 0 0.5 ?
TELEX Although the exact method of
automating TELEX traffic is unclear
most schemes result in effort 0 0.5 ?
Evaluation of This is the ISO mail protocol. It
X400 for VAX is in use at CERN and is likely to
be important in migration to ISO.
The product is from UBC. If a
success then the IBM version should
be tried. Steve Yip was going to
mount it. 0 0.2 ?
X25 switch There is some feeling that the GEC
replacement switches are not the best and other
suppliers should be investigated. 0 0.1 ?
Cambridge Further development is suspended
ring pending a better understanding of
the future of the product. 0 ?
CIFER-3270 There are requirements for
enhancements, for example entry
assist which need study. 0.1 PMG 0.1 PMG
IBM-3270 A project to provide colour 3270
across JANET is being considered
which would be financed by IBM 0 0.5 ?
Other Management meetings etc. 0.1 PMG 0.2 PMG
activities 0.1 NG 0.1 NG
0.5 PEB 0.5 PEB
TOTAL 7.0 12.3
The most important requirement is to give Peter Girard assistance so that he can start working in other areas and also to ensure that there is back up for the NIFTP and VNET/RSCS activities.
The above list includes items relating to GEC and VAX computers and we need to come to some decisions as to what extent we wish to support the network products on these machines.
From the recent recruitment activity we have obtained Tomlinson who is interested in hardware. He will initially work in the workshop and this will cause this area to be slightly over staffed but it is hoped that he will gain expertise in software areas and local area networking but it is too early to asses his potential. He has not been assigned tasks in the above table.
No effort has been included for the support of the several IBM proprietary network products which are now in use. It is important to decide how these products should be treated with respect to encouraging or discouraging their use and the level of support we should give how their use relates to our support of JNT activities.
A number of projects which may not be pursued have been included but on the other hand no allowance has been made for projects which may develop during the year.