Paul Bryant's Networking Correspondence
The full executive:- David Lord, Stephano Trumpy, Jean-Claude Ipollito, Birgitta Carlson, Michael Hebgen, Paul Bryant. In addition Herb Budd and Alain Auroux of IBM. Commission and CEPT observers were unable to attend.
These were not considered as the meeting was dedicated to the EARN conference.
Date is Monday October 27 to Wednesday October 29 in Berlin. It will be for 300 delegates and quotas have been given to each country from 100 for Germany through 30 for UK and 2 for Greece. The numbers are based on requests from Board members. All costs apart from travel will be met. Speakers costs will be fully met. It was felt inappropriate to pay speakers. IBM has donated 150,000 Dollars. Requests for places should be made by 15 September after which un-taken places will be re-allocated. Final list will be on 10 October when the preliminary programme will be sent to participants. Brochures will be produced but no posters.
The conference will be mainly concerned with networking at a high-ish and philosophical level. And considerable thought was given to the 'shape' of the conference. The three key speakers will give an EARN, a US, and a European view of academic networking followed by discussion. A second topic will be a view of the future from the PTTs. It looks like it will be enjoyable. The rough unconfirmed tentative program is:-
Monday - start mid day. Welcome from Mayor of Berlin. European Communications - Prof. Karl Zander (HMI Berlin) European Success in Space - Prof. H Curian (ESA) European Scientific Co operations - Schopper (CERN) Interactive Television and European Education - Dr. G Hubbard (IC UK) Current and future telecommunication environment - Dr. Schwarzschilling (Bundespost Minister) There will probably be some evening entertainment laid on. Tuesday Inter working of European academic networks - Dr. Peter Linington (JNT UK) Evolution of academic networking in the USA - Dr. Gordon Bell Telecommunications future technology - ? (Italy) The users challenge to European telecommunications - Prof. R Nordhagen Lunch European competitivity - Le Viscompte Davignon (The Commission) Round table. Mediator - Dr. Dennis Jennings (UCD Dublin & NSF USA) After dinner speech - ? Wednesday Research networking in Japan - ? WUNET - Dr. Herb Budd (IBM Academic support Paris) Finish with buffet lunch.
The meeting will be followed by meetings of the EARN Board of Directors and the EARN Technical Group.
David Lord's term as director ends at the new year and the EARN statutes bar him from re-election. It is unclear who will take his place.
A meeting has been scheduled with CEPT for 20th attended by Hultch and Hebgen.
IBM may finance a man and secretary for EARN. It should be hosted by an existing site. The only candidate so far is Jean-Luc Delahey from Montpelier. It is up for grabs.
A final document expected.
A good meeting with a lot of progress.
The observations by DL are correct and are confirmed by my own observations in a paper to NDM (NDM/P47/85).
The performance of Async 3270 and SSMP are broadly similar as they are restricted by the same technological considerations. It is likely, but not confirmed, that Async 3270 will have a slightly better performance and be a more accurate emulation of the 3270 as it is specifically designed for the task rather than being flexible and more general purpose. Regretfully, due to the incredible bureaucratic gymnastics of Harwell contracts it has not yet been possible to evaluate SSMP.
The performance of async 3270 is restricted by:-
The performance of the IBM can sometimes produce quite long delays of the order of a few seconds and occasional, so called, poor Async 3270 performance is due to this.
The performance of the network is variable as the imposed load is variable. The performance of the Memorex multiplexers has contributed to this variability. With the success of the 4705 and the introduction of Kilostream links to other sites this should become a less serious effect unless or until the load rises to saturate the faster lines. It would be possible to dedicate parts of the network to reduce the interference of 3270 traffic by other traffic - for example - one of the 4705 ports and perhaps direct kilostream links to a switch. Experiments so far under taken suggest that such reorganization only has a marginal effect except at exceptional times.
Most asynchronous connections are limited to 9.6K but it is expected that PAD ports at 19.2K will soon be available. Higher speed connections are not impossible but are unlikely on widely available equipment.
The code in the Cifer or the IBM PC is limited by the processing power available. In the case of the Cifer this gives an effective display rate of 2.4K regardless of the line speed. Note that 'effective display rate' is the speed with which characters received can be displayed and does not mean that characters cannot be received at a higher rate since buffering can absorb the excess. The new version of the Cifer is likely to improve this performance but it is not yet known by how much (a Cifer with the new code is expected in the middle of June 1986). It would be surprising if it could rise to an effective 19.2K. The PC code gives an effective display rate of 9.6K. As the author of this code I estimate that the code could be improved to have an effective rate of 19.2K with about 2 months work although this work is not scheduled as 19.2K connections are not widely available. The PC 3270 code sits in a multi tasking operating system and the removal of this would increase performance by a similar amount to between 30 and 40K but would take a month of effort.
Experiments with the IBM PC for the refresh of a full screen were found to be:- (time in seconds)
Speed Best time Average time Worst time Theoretical best 9600 2.6 2.6 2.8 1.45 4800 3.9 4.1 4.4 2.90 2400 7.1 7.2 9.4 5.80
The performance of the current Cifer, which only operates at 4800, is:-
Speed Best time Average time Worst time Theoretical best 4800 7.7 7.9 9.5 2.90
Considering the extra switching equipment that calls from DL traverse this agrees accurately with DL observations. Remember that their measurements were with the current 9.6K links and not the expected 64K ones (I believe).
The estimate is that the response of an IBM PC using a 19.2K connection could be improved to a little under 2 seconds. I would think that these performances could be obtained at DL with the higher band widths now being installed by JANET - but these are still a long way from the observed response of a 3270 on a coaxial connection of 0.2 seconds.
The observations by DL that the improved band width between RL and DL will only make marginal improvements are therefore correct. The main effect will be to remove the X.25 network delays which are undoubtedly responsible for occasional poor performance. The secondary effect will be a small improvement in best response due to the reduced packet flight times as long as the connections are at 64K rather than several 9.6K lines.
For comparison the response on a 3270 on a 9.6K bi-sync line with no contention was:-
Speed Best time Average time Worst time 9600 1.63 2.15 4.25
These figures suggest that the use of IBM bi-sync connections are only a marginal improvement over async 3270. The relatively high average time is thought to be due to the performance of the IBM giving occasional very long responses illustrated by the high worst time.
A minor correction to the DL paper is that the maximum asynchronous data rate of the IBM PC is a PAD limitation and not the PC interface. In fact the IBM PC can in theory operate at about 100K but IBM do not recommend speeds higher than 9.6K as V24 recommendations suggest that they may be unreliable.
A further minor correction is the use of SSMP. This protocol is available on the IBM computer and on the IBM PC and allows 3270 emulation. But as has been stated this is unlikely to have a superior performance to async 3270. I agree that the concept of a 'new' user full screen interface including a new screen editor would be a foolish move with respect to access to the IBM for CRAY access until it has been proved within the community. However the DL comments are based on some comments from another source which appear to be rather more concerned with the 'standardization' of full screen editors within the community than using SSMP for emulating 3270 as closely as possible.
We hope to evaluate SSMP 3270 PC emulation as soon as Harwell contracts can sort out an agreement with IBM.
Dl are right in identifying the CAMTEC PAD as a bottle neck. This can be alleviated to some extent (as is done at RL) by restricting the number of connections into a PAD or by mixing high and low usage terminals on the same PAD. Of course this will be to no avail if all the PADs eventually feed into a single 9.6K connection!
There are a number of alternative options of varying costs and with variable political acceptability:-
1* IBM controller connected to RL by leased kilostream using SNA. This is proposed by DL.
2* IBM controller connected to RL via JANET using SNA.
3* IBM controller connected to RL by leased line using bi-sync.
4* PIXNET channel extension to DL as proposed for Swindon.
5* Installation of small IBM 4300 connected to JANET by 64K line with 3270s connected to it.
6* Various enhancements to the IBM PC Async code
7* Development of an IBM PC X.25 PAD/3270.
In the DL SNA proposal the use of IDEACOMM 3270 connections in IBM PCs is not essential. The essential component of this or any of the first 5 proposals is to provide an IBM co-axial 3270 connections which can be used to interface to any 3270 compatible terminals (with some constraints which need not concern us here). The principle is, of course, to provide a terminal which can absorb and make use of a very high data rate. As an aside it has been found that the response for a 3270 is about 0.2 sec while the response for an IRMA 3270 (similar to IDEACOMM 3270) is 1.2 seconds. It is known that the IRMA product is a bit sluggish and I guess that the IDEACOMM falls between the two extremes.
The DL SNA proposal certainly has the advantage that it uses off the shelf hardware and also off the shelf software. It also insulates the user from all the effects JANET could inflict. The 'off the shelf' software does involve SNA and the estimates of Peter Girard are that the support of such software would take two extra staff although for this limited use of SNA this may be an overestimate. A peripheral consideration is that other sites wanting access to RL will want similar facilities and RL may be faced with the possibility of installing a substantial SNA star network. The cost of such a network could be reduced by including other university IBM computers in this network as SNA nodes. As DL point out, JNT may not be happy with such a development and there would certainly be no help from them of any sort. Thus RL would revert to being faced with a substantial private network which would require considerable staff resources.
It would be possible to operate SNA lines over X.25 and therefore over JANET. This would be less likely to have adverse JNT comment but may not have such a good performance as network congestions may reduce performance although I would not estimate this as important with the increased JANET band width. Having allowed DECNET over JANET and also allowed NERC to use SNA over JANET there is reason to suppose JNT would be in a weak position to oppose SNA. As a supporter of open systems I am opposed to both DECNET and SNA being used over JANET.
It is not necessary to operate such links with SNA and bi-sync links could be used although this could not be used over JANET and would be limited to 9.6K. This does not seem an attractive option although it would allow a further totally IBM solution. Alternative manufacturers produce kit that will work at 19.2K.
PIXNET has yet to be proved at RL. The principle is that the equipment can extend an IBM channel over a communications link. Thus in principle not only 3270 equipment can be connected but a wide range of IBM compatible equipment. The equipment is expensive. The provision of PIXNET at DL will encourage the request of similar equipment at other sites and thus RL may again be faced with running a private star network. The equipment has the principle advantage that it can utilize 2M megastream links. Again, JNT support is unlikely.
The installation of a small IBM 4300 is expensive but is rather flexible since it allows a certain amount of local processing compatible with the processing at RL. The connection would use JNT approved protocols with the exception of Async 3270 which is not really opposed by them. The performance should be more or less the same as the use of SNA over JANET as the same network band widths are employed and there seems no reason why async 3270 is any less efficient than SNA when used computer to computer. In fact the data compression in Async 3270 should make it more efficient.
The improvement of the IBM PC Async 3270 will always be limited to 9.6 or 19.2K unless PADs with higher speed async connections are provided. However, it is unclear what the minimum acceptable performance is. Hopefully the new Cifer product will match the IBM PC performance.
Recently an X.25 board has been bought and investigated for the IBM PC. This provides a 64K X.25 interface. Thus in principle it would be possible to mount the current Async 3270 code to utilize this board. Investigations of a rather shallow nature suggest that it is feasible and would take a few months to accomplish. Its performance is hard to estimate but the restriction on performance would be much the same as for the current Async 3270 giving a realistic performance between 30 and 40K. The solution would cost at least twice that of Async 3270 depending on the cost of 64K X.25 switch interfaces. The TELEFILE switch being evaluated at 3 sites and being investigated on paper at RL could provide suitable 64K X.25 ports at a lower cost than GEC switches. It is an interesting proposition. A further interesting possibility would be to make a PC with an X.25 card drive a number of other PCs via coaxial links but this idea is still only at the thinking stage.
A reasonable assumption is that JANET lines will be provided free and even enhanced free and that any private lines will be charged. It is also assumed that only kilostream lines are of interest although they may not be available at all sites and more expensive lines may be needed. The cost of terminals is omitted since there is a wide variety. All the costs are in pounds less VAT and are approximate and marginal.
Port on 4705 (one per line) 3500 Kilostream line 460 +5390 rental p.a. 3274/1C Cluster controller 9500 SNA 6000 rental p.a. or %age.
PORT on 4705 (one can support a number of connections) 3274/1C Cluster controller 9500 SNA 6000 rental p.a. SNA X.25 option 1000 rental p.a.
Port on 4705 2000 Kilostream link (overkill) 460 +5390 rental p.a. 3724 Cluster controller 8500
PIXNET 157000 Kilostream line 460 +5360 rental p.a. (Megastream not costed) 3274/1D Channel attached controller 10000
IBM 4360 100000+ I had difficulty getting a good cost - probably same as for PIXNET.
Manpower 2-4 man months Pad port 400 (nominal)
PC X.25 card 650 X.25 switch port 3000 (GEC) or 1000 (Telefile) Man power 2-4 man months
There is no ideal solution and to some extent the religion of 'open systems' complicated the issue.
As a supporter of open systems my preferences are:-
First:- enhance async 3270 and buy enhanced PADs and put up with performance.
Second:- X.25 PC - it is something interesting to do! It has potential for LAN and other interesting developments.
Third:- IBM 4380 but very expensive
Fourth:- SNA over JANET - it undermines open systems.
Fifth:- PIXNET - but expensive.
Sixth:- Direct SNA connections - the thin end of a very long wedge that I would want nothing to do with.
Dear Carol,
I enclose a map of how to get to Rutherford. If you drive- go down the M4 until it meets the A34 (for Oxford and Newbury). Go north on the A34 and the laboratory is on your left just after some single carriageway and some major road works. The site is in the middle of nowhere.
The other way to get here is by train and there is a good train service from London Paddington to Didcot and there is a bus to the site leaving the station at 10.15 which meets the appropriate London train.
From Heathrow life is difficult by public transport and you take a bus to Reading and then train to Didcot.
Let me know if you need any assistance with transport.
I enclose a couple of documents which will fill in a bit of background and hopefully make your visit better.
The team which runs the national academic network JANET is located at Rutherford as is the network control centre. We also operate a gateway to the public packet switched network and to EARN/BITNET.
I hope you will find your visit useful and I very much look forward to meeting you.
Yours sincerely
Paul Bryant.
Dear Peter,
Thank you for giving us the opportunity of talking to you about our future communications requirements. I hope that our discussions will lead to a full understanding of our problems with international data communications and that we will be able to start solving some of them. The academic community throughout Europe has been holding discussions and it is clear that our concerns are Europe wide.
James Hutton and myself will certainly be coming but I am not sure yet whether Peter Linington or Mike Wells of the Joint Network Team will be able to attend. Although we all work closely together we have different interests which all interact in complex ways. The interests are:-
We are united in our desire to support ISO protocols and would like to use public services if at all possible. However there are a number of problems such as the provision of systems from manufacturers, quality of services and tariffs, which make the future somewhat uncertain. It is some of this uncertainty that I hope our meeting will hopefully clarify.
The topics we would like to cover are:-
* Europe
Current academic services
Current academic planning
* Traffic
Traffic volumes expected
Type of traffic (bulk / interactive / graphics)
* Quality of service
Band width
Response
User information
* Tariff
Tariffs for various qualities of service
What the academics can afford
* Future liaison with BT International
I look forward to a mutually profitable meeting.
Yours sincerely
Paul Bryant.
Paul Bryant PSO
Peter Girard PSO
N Gunadhi HSO
Tony Burraston HSO
Graham Robinson SSO
Andy Jesset SO
Peter Tomlinson SO (probation)
Tim Kidd SO (at university)
Tony Wilson (student)
D B Gulley (trainee scientist)
S G Jones (trainee scientist)
SSO to help Peter Girard. He really needs to get rid of the maintenance of the coloured book code and concentrate on more farsighted projects (see below). If the post is provided I intend to try and poach Shirley Wood from informatics who is now working on the GEC computers. HSO/SSO to help Graham Robinson. I want the person to take over all the administration and user support activities and let Graham get on with development, particularly on the network aspects of PCs.
Finish off EARN gateway within 6 months. It currently works well but quite a few enhancements are needed to comply with standards. Several developments are needed to monitor the use of the gateway.
Get JTMP working within 6 months.
Get EARN X.400 project complete in 6 months.
Finish CEN/CENELEC activity and decide if we want to continue with the activity.
Ethernet link to HEP VAX in conjunction with James Hutton. An exploratory project to link the IBM to a VAX using ISO or coloured book protocols.
I would like to regain our former state as a centre of excellence for ISO/coloured book IBM activities. To do this I am fostering the X.400 project, encouraging the LAN project above, keeping a close eye on JNT/RARE/EARN activities. This is the area I want Peter Girard to move into.
Provision of a "sensible" LAN for the site. The Cambridge Ring was a complete failure as our suppliers (Acorn et al) have proved to be incompetent. I believe the future (next 5 years) is with ethernet and token ring using ISO protocols. I am reluctant to do more than experiments until we can see where the products are coming from. To this end we have ethernet on IBM, VAX and PC. We have problems in that Informatics are using TCP/IP and are well ahead due to product availability.
Continue our role as IBM PC experts. This should now encompass the RISC machine. I do not believe we should get involved with non IBM compatible workstations such as SUN/APOLLO/PERQ - leave these to Informatics.
The major problem is to sort out the exact role of the division network wise on the site. How far should we be invading other divisions and imposing network standards? How far should we go into restricting other activities on site? I have seen a lot of wasted effort in each division doing the same things and making the same mistakes. However, other divisions value their autonomy. A long hard look needs to be taken into how we provide services across the site.
The workshop is a problem. It was set up as a result of Peter Blanshard's activities and he also instigated an interesting project for the monitoring of X.25 lines which I was sceptical about but was an opportunity for him to prove his worth. He has now left and we are left with a project which I do not think is really worth pursuing. Do we need a workshop? The answer is probably yes. It is unclear how we can make it fly. We do not really have experts capable of undertaking complex projects and the flow of small projects is not all that interesting. I have suggested closing it down or restricting it but this has not been well received.
Dear Jan,
Herewith my 'write of' of the questions during the FTAM session of the RARE workshop for the proceedings. I agreed with Birgitta to produce them for you.
Yours sincerely
Paul Bryant.
Dear James,
I enclose the latest version of the functional standard for distribution. I have no agenda items apart from the revision of the document itself.
Thank you for your comments. I have tried to incorporate yours and all the other comments and I hope the document is now in better shape. I could not put in your suggestion to alter the section structure of the first few parts as this is dictated by ITAEGS.
I think that this meeting will have to spend most of its time on X.25 as there are a number of decisions needed. I have made a lot of fairly arbitrary decisions which need further study.
I CEPT issue is far from settled. I have been refused permission to attend the relevant meetings as an observer. This makes a nonsense of the 'good will and spirit of cooperation'. I do not believe we have moved very far on this issue but the acid test will come when CEPT have to agree the document.
In reality I do not believe that CEPT has done much at all.
Best wishes
Paul Bryant.
Dear Mr. Broomfield,
Dr. James Hutton and Dr. Peter Linington will be with me at our meeting.
James is the chairman of a network subcommittee which looks after international data communications on behalf of the high energy physics community. I am sure you are aware of Peter's position as head of the Joint Network Team.
We all have strong interests in the international services which will be offered by BT. I think my original letter to Peter Morley will give you an idea of the topics we would like to examine and I would suggest we take that as an agenda.
I looks forward to meeting you on Thursday.
Yours sincerely
Paul Bryant.
Dear Richard,
In sorting out the X.25 for Y/11 Y/12 I have had to study T31 (ITAEGS 304) and have a number of comments. I am not sure who these should go to so can I leave you to forward then to who you think appropriate?
Page 12 line 5
I would like the ignoring of facilities sent by the PSDNs that are not supported by the DTE to be mandatory rather than a recommendation.
I note that the functional standard refers from time to time to "PSDNs". Should PSDNs be referred to rather than just packet switched networks. For certification purposes the particular network used is surly irrelevant.
Page 13 end
The "called address extension" (and other facilities in ANNEX G of X.25) are not included. It is unclear from CCITT whether these facilities are mandatory in X.25 84 or not. However the provision of this facility is fairly fundamental and least there is doubt it should be included together with the other facilities in that ANNEX.
There is no rational as to why some facilities are mandatory and other not. Such a section would be useful.
The table is curious in that it seems rather pointless to include facilities which are to do with subscription time options since these have nothing to do with conformance. The ISO document DIS 8878 is rather better in not including irrelevant material.
Page 16 section 8.6
Is this relevant in a functional standard?
Page 17 9.2
Is the "recommendation" of a window size of 7 appropriate in the body of a functional standard rather than being put into an annex on hints to implementers?
The text on the value of T1 is unclear. Should T1 be installation settable or what? I think it would be a good idea to put in a complete set of values for all the "standard" speeds as the typical values are not very helpful.
Why is N2 recommended to be 10 (again should this be in an annex)? Should a mandatory value be chosen. Are there limits to the settings of N2? What are the implications for conformance testing?
The meaning of the text on N1 is unclear. Is it mandatory to provide N1 at 263 or greater? What is the relevance of the comment "depending on packet size used."? Does it mean that you can have N1 smaller if a smaller packet size is used?
Is it mandatory to have a value of T3 between 30 and 60 seconds or is the implementer free to choose other values?
Page 17 10.2
A list of supported data signalling rates are given. With synchronous data communications the data rate comes from the modem and so the DTE can only claim that a certain data rate is within the range of operation of the equipment. Thus - what is the relevance to DTE conformance. It is stated that certain speeds are not available on some networks. This has no relevance to conformance and so perhaps should be relegated to an annex.
I have pulled out a few random points. They mostly indicate that the functional standard is a mixture of conformance clause, useful information for implementers and gratuitous information about the public networks. It would be most helpful if these areas could be separated into distinct sections.
I hope these comments are of help.
I am sorry that pressure of work prevented me from attending the ITEAGS meeting. I did send an apology to Jan which may have been too late.
My letter to Jan again comments on the CEPT "problem". I spoke to Mike Brenton and asked if I could observe the relevant X.25/PAD harmonization meetings (not that I believe much is going on). The reply was a flat no. So much for the CEN/CENELEC CEPT cooperation! I am sorry to start sounding like a stuck needle but I think we should initiate a work item to produce a functional standard for the X.25 networks and see how it rides.
Best wishes
Paul Bryant.
David Lord, Paul Bryant, Jean-Claude Ippolito, Stephano Trumpy, Dennis Jennings, Michael Hebgen, Alain Auroux.
Minutes and actions from last meeting were not considered.
A letter had been received from CEPT (A Schwall) complaining that traffic figures were not being submitted. This appears true and the comment that CEPT had not been commenting on them and thus they did not seem worth submitting seemed a bit lame. M. Hebgen will contact him. We did not understand what his relation was to Hubner.
There was a long inconclusive discussion on accounting.
The application by DIN needs study. So far the only associate members are the Dutch PTT and UNHO.
No one had yet been found to run it. To my mind this is not surprising since the conditions are not all that clear. Some thought was put as to whether a consultant should be employed.
It was thought that a study to determine how EARN should be funded should be under taken. It was thought a consultant could do it and Hultch was suggested. It would take about 2-3 months and cost 25K Dollars. Traffic levels and other data was needed.
A rough guide is that management will be the same as the international least line costs.
There is a proposal for a satellite link for EARN to the States. It is suggested that this should go to Montpelier but there there other options. It will cost 40K FF / month plus 5K Dollars / month. It was unclear how RSCS could drive such a line. One and maybe both existing lines to the USE would be dropped is this went ahead.
I noted the other academic links to the states and suggested that it was time that Europe reviewed the situation to maximize the benefit of these expensive resources.
It was agreed to upgrade many lines to 14.2K (UK-CERN, GSI-CERN, CERN-Montpelier, CERN-Pisa, Montpelier-Pisa). The US link is to be relocated to Pisa.
I noted that for performance we appeared to be working towards a semi star network centred on where the satellite link came to. It may be wise to undertake a study to see how the network could be reconfigured to reduce hoppage and costs.
Progress was reviewed. The programme needed some minor rearrangement. The arrangements appeared to be going quite well.
Finance for the EARN lines from IBM terminates on 31st December 1987. There is a strong possibility that the network will need to continue in its current form since:-
The UK part of the cost of the lines for the three months are :-
CERN 1990 pounds Dublin 1139 pounds 10% contingency 312 pounds VAT 517 pounds Total 3958 pounds
It is possible that EARN will require a subscription from the UK or from each UK member site from 1st Jan 1988. The exact way this money is to be raised and the amount involved is under discussion but is likely to approximate to the cost of the least lines.
The costs could be recovered by a subscription from UK member sites or by a charge on traffic. Both these methods would be costly to administer compared with the money to be recovered. It is therefore proposed that SERC or some other benefactor meet the cost.
Thus the total cost is 7400 pounds which should be in the 1987/8 estimates.
The other costs are for staff and are:-
Software and system support 1/4 man year per year (A Burraston) Management 1/4 man year per year (P Bryant) User support 1 man year per year to be supplied by IBM.
Dear Brian,
I have a few minor changes that my administration have suggested, otherwise we can agree the contract.
1. Paragraph 1. Add to end of first sentence 'for non commercial purposes'.
2. Paragraph 2. Section 1. Add 'for submission to the EARN UK user group, the EARN board of directors, the JANET executive, or other appropriate bodies.
3. Paragraph 2. Section 4. Add to first sentence ' for a two year period'.
4. Paragraph 3. Change 50,000 to 57,600. This is the cost of employing a 'Higher Scientific Officer' which I think is the appropriate grade.
5. Paragraph 5.1. Add to end of first sentence 'regardless of whether such information or property is the result of this contract'.
I think we would not object to the original wordings if any of the above cause you problems.
I hope we can now proceed and I am grateful for your help.
Yours sincerely
Paul Bryant.
Dear Colleague,
The minutes of third EARN Technical Meeting are enclosed together with an action list.
The fourth meeting will be held directly after EARN'86, that is the afternoon of Wednesday 29th October. It will end at mid day on the 30th. I have made it relatively short as I expect you will also have attended EARN'86 and will want to return home as soon as possible. Regretfully this clashes with the EARN Board of Directors meeting.
As it will be a short meeting I think we should concentrate on a small number of topics and I suggest:-
Please let me have any comments on topics.
I look forward to meeting you in Berlin.
Yours sincerely
Paul Bryant.
The third EARN Technical Meeting was held in the IBM Scientific Centre, 36 Avenue Raymond Poincare, Paris on Monday and Tuesday, 21 and 22 April 1986.
The list of those present is appended.
Apologies were expressed on behalf of:
Steve Arnold, Joiner Associates
Arty Ecock, CUNY
Robert Boers, DEC
Peter Girard, RAL
Guenther Schmittner
Heidi Berghof RUNIT
Having welcomed the participants and thanked Dominique Pinse for making the arrangements for the meeting, Paul Bryant proposed the agenda, as follows:
1. Minutes of previous Meeting and Matters arising 2. Review of the State of EARN 3. Management of EARN 4. Migration to ISO Protocols 5. Mail 6. BITNET 7. Applications 8. Gateways 9. Operational Problems 10. Newsletter 11. Next Meeting
The Agenda was agreed. During the course of the meeting, the order of the items was re-arranged to suit the timetable, and some additional items were also discussed.
The minutes of the second EARN Technical Meeting were accepted.
A number of different systems for monitoring connections in the network were discussed. A task force consisting of Meyer, Martin, Ecock, and Pasch was set up to identify the appropriate one, and to report on its management.
It was decided that the use of the username INFO as a contact address for a node should be encouraged, and also that node administrators should be encouraged to maintain a NODEINFO file on NETSERV which would contain information about contact addresses, maintenance schedules, and other information thought useful.
It was noted that the address to use for the EARNTECH mailing list should be EARNTECH@CEARN, and that for the LINKFAIL list should be LINKFAIL@BITNIC. It was decided to request that LISTSERV be enhanced to provide peer-to-peer operation rather than the current hierarchical operation. General satisfaction with the EARNTECH and LINKFAIL lists was expressed.
It was noted that some sites in the U.S. are now running the GRAND conferencing system.
It is intended to invite representatives from other vendors again to the next meeting.
A representative from each country reported on the current state of the network in that country.
Portugal: Portugal is not yet connected; a line to Barcelona has been installed, but is not yet working reliably. It is proposed to have a single Portuguese node, with a gateway to the national academic network.
Switzerland: Nine sites are active, and one more is planned. A gateway to CHUNET is in place and one is planned to the Swiss Academic Network in 1988.
United Kingdom: The EARN/JANET gateway is now working. It was "not completely reliable" for mail, and better documentation is needed.
Finland: There are now seven nodes, and more are expected in the future. Most of the existing nodes are in Helsinki. X.400 would be the preferred method of networking for the Finns, but they are sceptical of whether the Heidelberg project will be fruitful soon enough; if not, then they will probably use jnet and urep to connect VMS and unix systems.
France: Twenty nodes are operational, and twenty more are due to be connected over the next two or three months. Discussions are under way with the PTT concerning volume charges on international lines. In December 1985, EARN France was inaugurated. CMS and TSO documentation has been produced, and also some publicity material, including a videotape. A user directory is in place. Montpelier is ready to run GRAND, and is participating in the X.400 project. A task force has been set up to examine security issues and to offer recommendations to node administrators.
Germany: The DEARN node has been upgraded to a 4361 processor, improving response times. There are now 128 EARN nodes in Germany, of which sixty-one run RSCS; eighteen, jnet; twenty-one, JES2. Traffic through DEARN is now at the rate of two gigabyte per month. Volume charges are levied on the basis of the number of "equivalent hours" of link utilization per month, and are charged only above the threshold of eighty equivalent hours per month. In view of this, it is important to take full advantage of high-speed links, and there is a need to modify the GENROUTS program to take this into account.
Some concern was expressed regarding the future of EARN, and its relation with DFN. It was noted that about half of the DFN sites are members of EARN.
Spain: Seven nodes are active, and five more are planned for connection as soon as the lines can be installed by the PTT.
Netherlands: Thirty nodes are already active, and ten more are planned in the near future. Most of the nodes are VAX/jnet nodes. Some problems have been encountered in discussions with the PTT concerning the international link to the DEARN node.
Italy: Twenty-six nodes are already active, and five are due to be connected soon. In italy, EARN includes VAX/VMS/jnet nodes, unix/urep nodes and some CDC nodes. A Sperry node is planned, which will use software from the University of Maryland. An ARPAnet connection is planned to the CNUCE in Pisa, but it has not yet been decided to offer a gateway service. Work is in progress in Italy to harmonize academic networking.
Iceland: No EARN connection has been made to Iceland, due to the cost of connection. It is not clear at present whether an X.25 dial up connection will be best.
Israel: Thirty-nine nodes at nine sites are active, but many are MAIL-only nodes. The international link is now no longer from the IBM Scientific Centre at Haifa, but from the University of Tel Aviv. There have been problems with the international link, exacerbated by the different observation of the weekend at either end of the link. In Israel as well as in France, there is concern about network security and abuse, and a group has been set up to address these issues. A document is being prepared which will describe minimal precautions which should be taken by node administrators.
Greece: The Grecian EARN connection was made in October 1985 and now two nodes are active, with four more planned, including one CDC node, at least one VAX/VMS node, one Prime node, and perhaps a unix node.
Belgium: The EARN connection to Belgium was made in February 1986 and there are now ten nodes distributed among six sites. Between five and ten further VAX nodes are planned, which will use free software from Argonne National Laboratories, rather than jnet. One Cyber node and one JES2 node are planned.
Turkey: The Turkish representative reported problems with both the local IBM enterprise, which is not yet ready to support EARN activity, and the PTT, whose tariff structure is not attractive. These problems have to be overcome before plans for connection can be made.
Norway: One node is already active, and another, at Bergen, is imminent.
Sweden: Seven nodes are already active, and ten more are planned. A distributed gateway to SUNET, which uses mainly DECnet, is planned, and will be the responsibility of SUNET. The gateway will be based on a number of jnet sites. NORDUNET is using Blue Book file transfer as an interim solution. An interface from EARN to COM is expected to be in operation in mid-1986, and will be based on RFC822 mail. QZ is participating in the X.400 project.
Denmark: There are eight EARN nodes in Denmark. There was nothing to report on Danish NORDUNET developments. The Danish PTT has taken a "wait-and-see" attitude to volume charges. There are many usenet/Eunet sites in Denmark, but no gateway to EARN. The Danish representative was concerned about the capacity of international X.25 links: there are only four 9600-baud X.25 connections between Denmark and the rest of the world.
CERN: New links to Rutherford Laboratories and Paris have been installed. Two additional VAX nodes have been connected, of which one is a micro-VAX. A link is planned to the U.N. in Geneva, who will become a class D member. Two million records are processed daily, and a total of fifty equivalent hours of traffic per day are carried on the three international links. Gateways are provided to the CERN and CHUNET addressing domains, to various X.400 networks using ean, and to DFN and the Italian research network based on DECnet. LISTSERV supports the LINKFAIL, EARNTECH, and NETSRV-L mailing lists. There is a RELAY server. NETMON (which requires GDDM release 4 and a 3279 graphics terminal) is in use to monitor the network connections. All users are registered in a directory.
Ireland: NETSERV is now running on IRLEARN at UCD. UCD is participating in the X.400 project. Some intermittent problems have been noticed on the link between DEARN and IRLEARN. The link between UCD and Rutherford is normally running X.25.
GULFNET: GULFNET is due for connection to EARN at Rome later this year. There already five nodes in Saudi Arabia, one in Kuwait; four more nodes in Saudi Arabia, one in OMAN, and another in Morocco are planned for the future.
It was pointed out that NETSERV will not run on VM/SP 4 unless certain APARS have been applied.
It was noted that node naming is now stable, with new countries using the 2-letter ISO standard codes. The question of whether to use ISO codes or car-plate codes for the country tag in the NODES files arose; it was decided to use both, subject to absence of ambiguities, and to recommend that the ISO code be preferred. Berthold Pasch is to check whether any ambiguities actually arise.
It was recognized that better liaison with BITNET at the technical level was necessary, and Paul Bryant and Gligor Tashkovich are to follow this up.
There was a discussion of NETSERV support for the North American BITNET community.
There was some discussion of the gathering of network statistics and the requirement of the Board of Directors for traffic figures. It was decided that the RSCSACCT program (available on NETSERV) should be run systematically on each national node by the country co-ordinator, and that the results be put on NETSERV. Udo Meyer intends to make some enhancements to this program, and has asked for feedback from its users. It was pointed out that MSG traffic was not accounted for, and suggested that for planning purposes this could be reckoned as between five and ten percent of total traffic. It was decided to put the item "Accounting" on the agenda for the next meeting.
In reply to a question on the possible introduction of charges on BITNET, David Lord said that he understood that the intention was to introduce a membership fee, not to impose volume-related charges. Peter Streibelt of IBM is to investigate whether the IBM-internal version of RSCS can be made available for the international nodes of EARN.
NETSERV: The UDS SEARCH function has been improved. Planned enhancements include an RFC822 interface, support for distribution of software packages, an APPEND mechanism for distribution. It was reported that BITNET has plans to replace BITSERVE with NETSERV, and NICSERVE with the IBM package TOOLS. It was decided that EARN would continue to use NETSERV.
Downtime - scheduled and unscheduled: The meeting recommended that scheduled downtime should be announced in the NODEINFO file of each node. In addition, national holidays should be announced in the NODEINFO files of the international nodes.
There was a discussion of the need for a link failure database, and it was decided that the present LINKFAIL mechanism and the proposed NODEINFO mechanism together would suffice.
JES2 Problems: A modification to JES2 to allow more than 1000 nodes to be defined is now available; this allows about 4000 nodes to be defined. JES2 performs poorly with a large network, as it uses a linear search algorithm. Another modification is available which allows dynamic network table reconfiguration.
Time Zone Management: Time zone management is not consistent over the network. Peter Hilton (IBM) explained some underlying principles of the software, viz:
- TOD clock zero is taken to be 1 January 1900
- RSCS GMT-offset must correspond to that in DMKSYS
- RSCS reckons daylight saving according to US standard
- RSCS has winter and summer values for the GMT-offset
and switches automatically according to the US standard
- On the network, timestamps used are GMT
- IBM recommends using two CP-nuclei
It was concludes that this problem would best be addressed by SEAS or SHARE, rather than EARN.
Paul Bryant circulated a report on this project, and summarized it. A course on the software to be used had been held; the participating sites were to install the hardware and software; specific evaluation tasks had been allocated to the participants; progress reports were due at three-weekly intervals; a "go/nogo" report is to be presented at the end of six months. The performance of the software when used over both the public X.25 network and leased lines will be evaluated. Other products will also be examined, such as the IBM OSNS products, and Rutherford software. A number of other issues were identified, such as the identification of a suitable product for MVS and CDC systems, compatibility of the Heidelberg software with DEC X.400 software, and the intentions of BITNET in relation to X.400.
It was noted that PROFS and SQL are components of the User Agent for the present Heidelberg software, and that one of the tasks identified for the Heidelberg project was the provision of an alternative User Agent.
It was noted that until FTAM products become available, NJE connections will remain probably necessary for file transfer.
It was noted that the cost of currently-available MVS X.400 products was prohibitively high.
UCLA-Mail: Peter Sylvester gave an illustrated presentation of the UCLA-Mail software. Copies of his material were distributed. It was noted with interest that this software provides RFC822 for JES-2.
After some discussion of insecure features of the networking software, the initiative of the French and Israeli EARN groups in setting up specific task forces to address problems of this nature was noted with enthusiasm, as was their current work of identifying the shortcomings of vendors' systems. It was decided to send a letter to all node administrators warning them of the risk of penetration and suggesting "obvious" precautions.
It was agreed to co-operate in this area.
It was decided to request the Board of Directors to consider this issue.
It was also proposed that the French and Israeli groups should present a report at the next meeting and that the other countries should report incidents to them in the meantime.
GRAND Conferencing System: Bob Flavin (IBM Yorktown) gave an illustrated presentation on the GRAND system which is now in use internally in IBM, and on field test at certain US universities. This software is a base on which networking applications, such as distributed conferences can be build. Copies of the material presented were distributed, and the meeting noted with interest that this software offered a possible mechanism for conferencing system for EARN.
So far, GRAND servers are in operation at CUNY, Cornell, Weizmann, and DEARN. In BITNET, it is planned to provide a distributed conferencing system based on up to twelve regional servers; this project will be co-ordinated by Henry Nussbacher.
Peter Streibelt (IBM Heidelberg) reported on the experience with the GRAND server at DEARN and pointed out a number of areas where development was necessary, including: documentation, MVS support, remote user interface, national language support, security, and support of users on other operating systems.
He indicated that IBM was preparing a licensing agreement which would allow a number of GRAND servers to be set up in Europe, as was being done in the US. He said that an experimental service would soon be available from DEARN, and that development work for the MVS environment would be tackled in a way which would allow a future VAX implementation to be simplified.
A progress report will be presented at the next meeting.
Network Name Server: Berthold Pasch (IBM Heidelberg) gave a brief report on the status of the name server, which is now running smoothly. He pointed out that there were still some shortcomings in the audit trail; for example, no notifications sent to the node administrator when a user changes his entry in the server. Every three months, users whose entry is older than one year are asked to confirm their entry. Node names are limited to eight characters in the present design. NETSERV (of which the Name Server is a component) will support an RFC-Mail interface in future; this interface is under development.
X400 over RSCS: After a somewhat meandering discussion, it was suggested that the evaluation of the Queen's X.400 implementation of X.400 over RSCS may be incorporated into the Heidelberg X.400 project.
A document from Joiner Associates (suppliers of jnet) was circulated, which contained a "statement of direction" and answers to certain specific questions. Gligor Tashkovich undertook to circulate this on the EARNTECH distribution list after the meeting.
Doron Shikmoni reported that RSCS v.2 support was being prepared and should soon be available in urep. The planned implementation would not support SNA. BITNET
BITNET Programmers' Meeting: Peter Sylvester reported on the BITNET Programmers' Meeting which he had attended. He mentioned specifically the discussions which had taken place on "Standard BITNET Environments", on "Quality of Servers" (during which discussion it had been recommended that the EARN tools, especially NETSERV, should be examined), and on "New Features in LISTSERV". He also mentioned the work of the BITNET Domain Task Force, whose report Gligor Tashkovich undertook to circulate after the meeting. It was understood at the BITNET meeting that vendors will not be able to offer software to support addressing domains. He stated that the work of the BITNET Task Force did not restrict the option of the EARN or NETNORTH networks to use a domain system or not.
It was noted that Europe also would have to cope with a confusion of domains for a time, and resolved that EARN should undertake discussions with other research networks.
BITNET Directions: Gligor Tashkovich mentioned the NSF-supported TCP/IP migration pilot project, stating that no clear direction had yet appeared.
It was decided to include an item in the agenda of the next meeting on "BITNET Directions".
BITNET Technical Report: Gligor Tashkovich reported from notes provided by Arty Ecock. BITNIC was now running the Queen's X.400 software, and a new version was expected soon. It is thought that this will be compatible with the Heidelberg software.
There is development project under way to implement the Queen's software over OTSS/OSNS; CNUCE (Pisa) are also involved in this. BITNIC and McGill University tested RSCS over an X.25 connection.
Active BITNET projects include network management software NETMON, NETSTATS, and BITMON, and the TCP/IP project mentioned above.
Migration of BITNET to RSCS v.2 is expected during the current year.
It was decided to hold the next EARN Technical Meeting in conjunction with the EARN Conference in Berlin at the end of October.
The following gateways, not already mentioned in the discussion of the state of EARN, are planned or already in existence.
A project involving Siemens and IBM to build a gateway between EARN and DFN is under consideration.
The MINT (Mail INTerchange) system at CERN provides a gateway to CHUNET, and unofficial gateways to certain other networks.
Funding has been allocated within the Swedish SUNET for a MINTlike project based on mmdf and urep.
In Finland, two gateways to UUCP are working, and gateways are planned to FUNET and CSNET.
A gateway to IBM's VNET is planned in German.
It was pointed out that transfers to the ARPAnet using CROSSNET would not work if line sequence numbers were present, and that a new version of CROSSNET which eliminates this problem was available.
It was stated that the transatlantic link to CUNY would be moved to a different (as yet undecided) site in Italy.
Since VM cannot support more than 9999 spool files, these files are now purged at CERN after two weeks. It is reckoned that console log files are the worst cause of problems.
The EDUCOM magazine "Networking", and the CSNET "Newsletter" were exhibited to the meeting as examples, and it was suggested that there could be an insert from EARN in the former.
Gligor Tashkovich is to investigate this possibility, and Paul Bryant is to contribute an article.
Peter Streibelt mentioned that the German EARN community has a newsletter "Neueste Netznachrichten" and that a new edition of the EARN reference card would be available towards the end of May. He pointed out that despite his offer at the Abingdon meeting to edit a newsletter, no-one had contributed any material.
It was recommended that network servers should support command sequences sent as RFC-822 mail messages.
Paul Bryant gave a description of RARE, mentioning the association's objectives of fostering ISO networking among the European academic community, of fostering migration to ISO standards and development of gateways within this community. He stated that certain priority areas had been identified and working groups had been set up to address these, for example: MHS/X.400, FTAM, administration of the association, documentation of networking activities, use of X.25, Virtual Terminal definitions, network operation, and liaison with CEPT. The members of the association are formally the national academic networks. A RARE conference was planned for the end of May in Copenhagen.
He emphasized that RARE was not trying to establish or run a network, but rather to foster co-operation.
The meeting concluded with an expression of thanks by acclaim to Dominique Pinse (IBM Paris) for her work in organizing the meeting.
Advise on monitoring Meyer/Martin/
Ecock/Pasch
Encourage provision of INFO and NODEINFO on sites All
Invite other vendors to next meeting P Bryant
Report on security France/Israel
Report on any problems in use of ISO and car
registration country codes B Pasch
Liaison with BITNET Bryant/Tashkovich
Running RSCSACCT on sites All
Discuss accounting at next meeting P Bryant
Put scheduled downtime and holidays in NODEINFO All
Produce letter on security for node administrators ?
Circulate note from Joiners associates G Tashkovich
Discuss BITNET direction at next meeting P Bryant
Provide article for EDUCOM or CSNET newsletter P Bryant
This meeting was set up to explore problems of mutual interest with respect to the use of IPSS now and in the future. The idea was to exchange views and start some sort of dialogue to continue the process.
The meeting was attended by P Bryant (EARN), J Hutton (HEP), and P Linington (JANET). Chris Broomfield (Data Services Product Manager) and two others came from BTI.
The meeting started with each of us giving a summary of what we were doing internationally, the problems we saw, and how we saw things developing in the future.
Some countries have identifiable gateways to other countries and others integrate the service into their national switches. Both methods have strengths and weaknesses and the way a country goes is more a political matter than a technical one.
About 30% of the international lines now go to the new gateway and the rest will follow in a couple of weeks. The fate of the old gateway is undecided. The new one can deal with 500 data packets a second minimum and this will be extended. It can deal with at least 17 call requests a second.
The speed of international lines are progressively being raised to 48 or 64K. Germany, Luxembourg, Switzerland, and Belgium are already connected.
There are direct connections to most European countries and multiple links to many. An out of date diagram is appended.
There are about 6 48K lines into PSS to various switches. 3 to London, and one each to Cambridge, Manchester, and Birmingham.
The gateway has a lot of parameters which have to be 'tweaked' for each network. The principle problem is what to do when things go wrong.
Connections to the States are complex and use several carriers. The exact route depends on the destination, political considerations, and traffic loading. Most circuits are surface and a small number are by satellite. The gateway gives local packet acknowledgement to avoid the delay problem.
There is no rerouting on failure particularly if rerouting would involve passage through another country. It turns out that agreements for services are hard to arrange and rerouting would be an additional complication. Some countries are more difficult to deal with than others, for example, Italy who have a very complex political communications set up.
Apparently there is a China Italy link which could possibly give UK access if needed. It seemed that BTI were not familiar with all the possibilities and where new connections are needed one may well do well to do some 'ferreting'.
East Europe is a bit of a mystery as little exists but things are happening. Yugoslavia is almost up, there are some moves in Poland, and there is a rudimentary service to Hungary. For reasons we can only guess at East Europe access seems to be centered in Austria with a hint of action in Finland.
The new gateway should be capable of dealing with X.25 84 apart from 'transit delay'.
There are Euro-PTT discussions on plans and time scales and the first meeting will be 1st September 1986. Roth's group has done some preliminary work which we have seen.
It seems Germany is going for a second network and are going to tender to purchase two systems for demonstration. Germany is one of the networks without a separate gateway which may cause problems in transition. France does have a gateway.
It would be helpful (and possibly save us money) if the Janet gateway were to fail calls which would be failed by the BTI gateway or remote network. For example if the remote network did not support fast select we should not initiate such calls to that network. It seems they could supply us with information on this. (To by mind it would be useful to study how BTI deal with this problem).
There are facilities of less importance and our view was that international closed user groups and reverse charging are not a lot of use for academics.
It seems that IPSS and PSS are only marginally profitable and this is broadly true in other countries. None the less there is recognized to be tariff problems for academics. Such matters have to be sorted out with CEPT for international traffic.
We put our views on the nature of academic traffic and on the funding problems. It is clear that our views are understood.
Discussions covered ISDN and satellites both of which were interesting but nothing of immediate importance.
The meeting was very helpful to both sides. It was a rare event for BTI to have such talks with knowledgeable customers with particular interests which could influence and help them. Also we had lacked such close contact since JANET decided to set up a private network.
It was agreed to set up another meeting for 6th January 1987 and to also involve PSS.
Dear Neil,
We now have a copy of SSMP but as we suspected we will need the source to adapt it for our 'network control program'. I spoke to Pat Moran and he is happy to release the source but will need a letter from you so to do. May I there ask you to progress this.
I phoned you but you were on holiday so write to avoid forgetting about it. I hope you had a good holiday
Yours sincerely
Paul Bryant.
Dear Sir,
Further to our telephone conversation and my previous letter I define below the keytop changes needed to make the keyboard conform to the IBM UK one:-
# 3 to 3 " ' to @ ' @ 8 to " 8 \ _ to # _
I guess similar changes are needed for the 'yellow' key \ _.
Yours sincerely
Paul Bryant.
After a brief investigation it turns out that there are several communications lines to the UK in various stages of installation and planning which will be financed(?) by NASA and used for their projects. Several of these lines are to universities or SERC and others to industry. Some lines are of high bandwidth. It is proposed, in a number of cases (Rutherford and Oxford), that onward connections are provided to other sites.
It situation gives some cause for concern as:-
Some details of ISAMS and SPAN are known. There is also a known and urgent requirement for the link from Madrid to Aston to be replaced.
I have had a brief discussion with Mr. Blank from ESA who appeared to be happy for the low speed Aston traffic to go via ESA and Stevenage. I understand that the Stevenage line (to British Aerospace) is likely to be rerouted to Rutherford and then onward linked to other sites. How data would get to Aston is not clear.
It appears to me that it would be valuable to convene a meeting between the users of these lines to find out exactly what is going on with a view to making the best use of the connections, minimizing costs, and making the best use of the current infrastructure. Having made the suggestion I do not have the information to set up such an event although I should be delighted to attend.
The EARN executive has decided to recommend the installation of a 56K satellite link between Europe and the USE. In addition they recommend that many of the international links should be upgraded to 14.4K by installing new modems. It is expected that one of the existing lines should be removed as soon as possible after the satellite link becomes active. The other terrestrial link may be removed depending on circumstances and finance.
This meeting is to decide how best this should be achieved.
The initial proposal is for the link to terminate at Montpelier although other sites may be more appropriate on the grounds of:-
It is unclear how RSCS can utilize a satellite link on account of the acknowledgment mechanism. IBM will advise on how this is achieved within VNET and whether the same technology can be used within EARN.
It is unclear whether Montpelier is the cheapest terminal point for the connection in Europe. It is believed that costs across Europe do not differ significantly between countries but this needs study. Even if it is the cheapest then when the costs of lines from the site are considered the economies may change.
A recent study has found that the maximum number of hops across EARN/BITNET/NETNORTH is 23 and the average is 8. This indicates that a large amount of bandwidth is wasted when compared with a star network which would always take two hops. Of course such a topology is not possible on a world scale and exceedingly difficult of a European basis. None the less some study is appropriate to reduce 'hoppage' particularly where the international lines are concerned and where lines are expensive. It may well be that EARN should centralize lines to a greater extent than now on a small number of large switching sites to which all the other countries should connect. Clearly the site(s) which link to the states are prime candidates for this role. Thus lines may well have to be re-routed to Montpelier from other countries. The cost of the lines of such a reconfigured network requires study as do the benefits in the increased capacity thus released. It should be noted in passing that if EARN decides and is allowed to migrate to a private X.25 network such a topology would be more appropriate and X.25 switches could be located in this (these) central sites.
To make sensible recommendations the following facts are needed:-
It is hopped that this meeting will progress the above items. It is unlikely that with the limited information currently available final decisions can be taken. It may well be that working parties will have to be convened to study certain aspects on the project.
As an aid to the study I am hoping (if some student labor can be found) to instigate a survey to find the line costs and traffic figures on which to base studies. EARN directors are asked to cooperate with this study.
I regret that due to an unavoidable commitment I will not be able to attend the meeting and it will be chaired by .
It is hoped to produce minutes of this meeting to be circulated as soon as possible.
I look forward to an exciting second expansion phase for EARN.
Dear Pierre,
I enclose two IBM floppy discs. NRS1 is the names and addresses of the Name Registration coordinators of all the UK (and some other) sites. NRS2 is a list of all the entities registered. Project is the content of the Joint Network Team's data base which is not kept very well up to date. NRS3, on the second disc, is the NRS names and the addresses associated with them and is very large.
I also enclose a list of JNT projects which should be up to date.
I hope that the information is useful and will be happy to help further as time permits.
Yours sincerely
Paul Bryant.
Dear Manos,
I attach a revised version of the article. It is unfortunately a bit longer. I have tried to take into account the comments but there is the danger in trying to cover too much ground that article becomes too long and detailed and misses being light reading.
The last comment (Nick's?) on 'disagreeing that the way EARN went was the only way' is the most worrying since it takes a lot of words to explain. But he does answer the point himself in saying that countries may well have objected to UK coloured books. My arguments in full are:-
I have wound if a few of these arguments but I worry that this sort of detail detracts from the articles readability.
With my tongue in by cheek I could ask why, if you are so worried about EARN, didn't you put your money where your mouth is and finance a Coloured Book network to rival and sink without trace EARN? Don't answer that - I know the reasons!
The last point - that EARN has reduced pressure and diverted resources for ISO - is debatable. One could say that without the spur and threat of EARN RARE would never have got going. EARN snapping at the heels of RARE should keep up their momentum and help you to give RARE the cash! However, these are un-provable points for late night sessions.
I am reluctant to drag up the EIN/EURONET saga which is all very true but requires a lot of text to explain what they were. However I have introduced comment directed to the PTTs which provides a similar message on the problems of tariffs but I do not think the topic is one of EARN vs RARE but one where we have a high measure of agreement.
It is not the place of the article to be either pro or anti either organization or to rake over the past - it is a plea for them to work together for the common end (which is not ISO - that's a means) of services to the customer.
I hope the changes improve the article.
With best wishes
Paul Bryant.
EARN VERSUS RARE - IS THERE AN ISSUE?
(revised 25 July 1986)
issued by
P Bryant
24 April 1986
Well, is there a battle? If so who will win? If not, what is all the fuss about? In any case what are these organizations, who are their pay masters and what are they out to achieve?
After such a build up you must be 'hooked' so read on and find the truth.
First, what is EARN- the European Academic Research Network? It is a network provider, it runs a network, it gives a network service to academics in Europe. It does not indulge in research and development to any extent. It is not primarily interested in the technology used. Its primary interest is service to the user.
Second, what is RARE- the Rese'aux Associe's pour la Recherche Europe'enne. It is dedicated to the three objectives of- encouraging ISO networking within the academic and research community, encouraging the interconnection of current networks, and the encouraging of the migration of existing networks to use ISO protocols.
So on the face of it the two organizations are complementary as EARN is interested in the pragmatic end of providing services now and RARE is dedicated to ensuring Europe moves to a single set of network standards in the future. EARN has only a secondary interest in RARE's primary purpose of full interconnectivity in the community. RARE has only a secondary interest is the provision of a physical network.
But life is never simple! Earn is a very large network of 350 or so computers from various manufacturers, it carries a large amount of traffic, it is cheap for the customer, it is international, it is growing, but it is certainly not using ISO protocols. On the other hand there is currently little ISO networking going on, or likely to in the near future, and so to the user RARE appears to be achieving little. The worry is that the popularity of EARN will continue and expand. It may well delay the installation of ISO network methods by this popularity. It may well divert resources. The reverse argument is that networks are for users and not users for networks and so if EARN provides a good service why not encourage it and why provide an alternative based on ISO? Why must the user wait?
The principle argument of RARE is that high quality services for all types of computers can only be provided by the use of ISO. If you were to select IBM or DEC protocols, say, then these may well provide a good service for some users but most certainly would not provide a good service, if any, for others. But the birth pangs of ISO are plain for all to see.
EARN started in about 1983. It uses the IBM 'Network Job Entry' protocol which is relatively simple but can be used for moving files between a large number of interconnected computers. There had been a similar network in the USA for some time called BITNET and IBM decided to encourage a similar one in Europe by financing the international connections, some equipment, and some organizational effort. IBM financed EARN as part of their support of academic endeavor in EUROPE as they felt that many European countries had little or no such services and usually lacked international services. In particular, services to the USA were poor and so two lines were provided between the two continents.
IBM protocols are used not only because IBM is involved but because the hardware and software was already in place on most IBM installations and all that was required was the provision of some leased lines and modems. Hardware and software was also readily and cheaply available for VAX and a few other computer types. The network was capable of growth in a piecemeal way. This is not strictly true since when it became more than 100 or so sites it needed some firmer management to keep the various routing tables in order, to ensure new lines were optimally places, and to ensure key sites provided 24 hour service. Other technologies would have been unlikely to have provided a fast start up, to matched the cost, or to have been available for the popular computers (IBM and DEC). A network based on the public X.25 services would have been an order of magnitude more expensive than leased lines because of the high tariff. A network based on a private X.25 network would have taken a lot of new equipment, such as switches, and required a lot of management. It would have been unlikely to have provided services at an early date. Even if X.25 had been selected there are only a few parochial high level protocols that could have been used, such as the UK 'Coloured Book' ones. If Coloured Books had been selected then each IBM computer would have to have been provided with a Series One front end (about 200 machines) and Coloured Book code which at the time was only just released. A difficult and expensive proposition.
It is worth noting that PPT tariffs are an area where EARN and RARE have cause for concern. If the EARN traffic were to be put onto the public X.25 networks there is no way that the current traffic could be financed. If RARE is successful in using public networks and EARN also migrates to use them then one can expect the resultant potential traffic (ten times the current EARN traffic?) to be severely restricted by the tariffs. Currently the X.25 tariffs are geared to low volume transaction traffic and not the high volume bulk traffic that research generates. On the other hand, the PTTs find that their X.25 services are not very profitable. So there we have a dilemma. It would be tragic in these days of struggling for cooperation and understanding across Europe if costs prevent communication.
The result of IBM's initiative was different in each country. In Germany it was greeted with enthusiasm and 120 or so connections made. In the UK the 'welcome mat' was less apparent as there was already a very well developed academic network called JANET. However, it was decided to build a gateway between the two networks to enable UK academics to gain most of the benefits and not to undermine the UK network. All other countries accepted EARN to a greater or lesser extent.
EARN is run by a 'Board Of Directors' there being one from each country who is, in principal, elected by the users. EARN is an association set up under French law and was given some initial finance for administration by IBM. Although IBM provides considerable technical and administrative help as well as advice the network is not run by them nor do they dictate how the network should develop. In fact the Board Of Directors would welcome interest and support from other manufacturers and organizations.
Since EARN uses leased lines a license had to be obtained from each PTT. CEPT eventually became interested in the activity and recommended that licenses could be issued until the end of 1987. By that time it would expect EARN to have migrated to use public networks and ISO protocols. In addition they recommended that the PTTs impose a volume tariff on traffic.
In order to migrate to ISO protocols EARN has set up a project to decide how this should be done. Their first activity is to undertake an experiment between eight international EARN centres using an X.400 (the international mail standard) system from the IBM European Network Center in Heidelberg. The results of this work are expected towards the end of the year. It will hopefully show that the system is suitable and will define some further developments. Already there are plans to add the ISO file transfer protocol FTAM and the CCITT interactive protocols known as 'triple X'. Initial thoughts are that it will not be possible to migrate by the end of 1987 since the ISO protocols are still young and immature and it may take a further year before the objective can be achieved. It must be remembered that EARN contains computers from many manufacturers and the experiment is so far only dealing with IBM computers running the VM operating system. It is hoped to test against other products such as the one expected from DEC and the EAN one from Canada in due course.
The use of public X.25 networks needs careful study. It is very difficult to get figures from the PTTs on the capacity of the public networks and the capacity of the international lines. Some 'leaks' suggests that there are currently only one or at most two 9.6K lines between countries and on any connection one can expect no more than 2K bits/sec. In fact experiments suggest that 1K is more typical at peak periods. 'Leaks' also suggest that some 48 or 64K lines are now being installed. EARN is currently composed of 9.6K leased lines and these are becoming saturated and so the use of 48K ones is likely in the future. It is very difficult to see how the public networks can absorb the current traffic let alone the traffic if the band widths are increased. This may mean that EARN will try to continue to use leased lines even after it has migrated to use ISO protocols.
EARN is strictly for non commercial use. In some cases the research arms of companies may join as 'associate' members but they may not communicate with other associate members and the use must be strictly non commercial.
EARN is connected to many other networks. In particular it is connected to BITNET in the USA which in turn gives access to the many academic networks there such as ARPA, CSNET and so on. In Europe gateways exist or are planned to many national networks such as JANET, DFN, and SUNET.
RARE has very different origins although some would have it that EARN frightened RARE into existence! The first attempt at academic cooperation in networking was the 'Zandar' initiative supported by the European Commission which attempted to harmonize some of the standards. This was in 1983. This work was taken up by the manufacturers but the academic interest more or less ceased with the funds. In late 1984 there was a further initiative which led to a closed conference in Luxembourg in may 1985. The aim was to ask the question 'what do we do next?'. This was attended by academic delegates from most European countries as well as by representatives from the European Commission and CEPT. The result was a decision to set up an association with the three aims mentioned above. It was also decided to set up working parties in eight priority areas these being:-
To set up the association. Liaison with CEPT. Message handling. File transfer. Virtual terminals. X.25. Network operation. Documentation and directories.
During 1986 work has progressed steadily. There is now a secretariat that has been provided by the generosity of the Dutch which looks after the organization. A council of administration meets from time to time to direct the association. A further conference took place in May 1986 in Copenhagen. At this event it was clear that substantial progress had been made in most of the areas. Most striking was the encouragement from all the countries for RARE to continue and the certainty that most, if not all, European countries would become members. CEPT has shown interest in cooperation with RARE. Less encouraging is the slowness of the appearance of products and an awareness of the many problems and challenges ISO poses.
Lately there have been discussions with the European Commission concerning a number of RARE project aimed at defining how an ISO network infrastructure could be provided. These should enable finance to be available for far closer co operations between the countries and also to have a number of useful ventures to pursue. There is little doubt that a number of such projects helps to maintain momentum and increase contact between people.
The aims of RARE are long term and will therefore take time to achieve. The principle objective of encouraging an ISO network infrastructure across Europe is hampered by the immaturity of many of the protocols and the lack of products from the manufacturers. On the more positive side the creation of RARE at this early stage does give it the opportunity to influence the manufacturers as well as network providers to produce products which will inter work and which are suitable for the academic community. Thus, much of the RARE activity is concerned with the communications standards which need augmenting with 'functional standards' to ensure that products inter work. Indications are that this will be successful.
It must be emphasized that RARE has no intention of setting up or operating a new overlay network. Their belief is that this is the task of the PTTs. RARE does have the job of persuading the PTTs to provide networks of the quality needed and at a cost that the community can afford. This is why liaison with CEPT is a priority activity.
It is of interest to note that a number of the EARN Board Of Directors are also on the RARE Council of Administration and thus there is considerable informal liaison between the two organizations. It is, however still true that there is some uneasiness in RARE that EARN will divert resources from ISO activities. In addition there is the worry that EARN will continue to grow and prosper and that it will be far harder than expected to migrate it to ISO protocols.
From the EARN side the network is undoubtedly providing a valuable service to the community. This could not have been provided in any other way considering the lack of ISO products, the finance available and the time scale. It must be remembered that it would be wrong to deny much needed serviced to academics if they can be provided by whatever means. The users will not accept a delay of the provision of a service on the grounds of having to have it provided with some specific protocols. It is up to the network experts to define a path which does provide early services yet is forward looking in defining migrations towards better methods, these aims are difficult to reconcile.
The conclusion that the author draws, who is one of those with a foot in each organization, is that EARN and RARE are complimentary. Whilst EARN provides a service, RARE plans the future. It is essential that the two work closely together and there is every indication that this will be the case. Thus, there is no battle.
P Bryant (EARN, IBM PC)
P Girard (IBM Coloured Book communications)
A Burraston (RSCS, EARN JANET gateway)
N Gunadhi (IBM Auscom interface, Ethernet, X.400)
G W Robinson (IBM PC, Workshop)
T Kidd (X.25 monitor, at university)
A Jessett (X.25 monitor, other hardware projects)
P Tomlinson (X.25 monitor, software)
P Shingler (1 day a week- X.25 monitor)
Two trainee scientists
Student
School boy (1/2 day a week)
EARN has been welcomed by the community and enhanced the prestige of the division. The far higher than expected traffic levels has shown the need for international connections. The connection has not appeared to have an adverse effect on the operation of the IBM computer but the connection has absorbed more manpower than expected particularly in management.
The disjoint nature of the site and the lack of local area network products 'off the shelf' indicates that the current cautious approach should be continued with a small number of low cost experimental projects to maintain expertise and provide services in special circumstances.
The IBM PC project has been successful and the users are pleased with the level and type of support provided although this level cannot be maintained with current staff levels if the number of PCs rises much further.
The PRIAM project has not progressed due to lack of staff and also lack of interest in SERC. Some soundings were made and the response was poor.
P Bryant has been involved with the CEN/CENELEC functional standards work and is the chairman of the Y11/Y12 working group on the triple X interactive protocols. This has also involved representing BSI on one of the CEN/CENELEC committees and attending many BSI meetings.
Gunadhi has attended the JNT ethernet working group.
P Bryant has taken part in the JNT transition group working party defining how JANET should migrate to ISO protocols.
The three major projects of the IBM communications, EARN and PC support are in very good shape with no real problems on the horizon. These projects are to a great extent support tasks.
The amount of effort it has been found possible to put into development is disappointing. PC experiments have all but ceased due to the importance placed on providing a service. The local area network development has been very slow for reasons outside the control of the division none the less some modest progress is being made.
Dear James,
I enclose in record time the updated version of the functional standard for distribution.
I propose on the cover sheet that it should go out for final comment with a deadline of 1st October prior to distribution for the voting meeting. How do you feel about that?
I have put in a couple of minor additions to do with conformance and some advice on timers in annex A. I have also had a good go through the text to get the terminology and layout consistent as well as a few aesthetic changes to improve presentation - such as recasting the conformance requirements as a list rather than a long winded sentence. You will see that after some thought I have followed your advice and removed all underlining. It turned out to be difficult to underline all CCITT terms without underlining 99% of the text. Also this word processor will not deal with bold or italic. I have noted on the cover sheet that the inclusion of some form identification of terms may be needed. I have also added in the text under definitions that CCITT definitions have in the main not been included. Our basic problem in including CCITT terms is that there are a lot and that CCITT themselves seem to have taken pride in not producing anything we could copy. I still incline to the use of italics but to be honest I don't care as long as I don't have to produce a list of definitions. It may well be sensible to remove the CCITT definitions we have put in and only define terms we have invented.
It may be a good idea if you gave it a going over to see if their are any changes or improvements worth making.
Although I am fairly happy with the result I have a nagging feeling that there are topics we should have included. For example, we have said little about the start-stop mode DTE - should we have commented on the provision of XON/XOFF say? I was hoping that our audience would have picked up these points but they seem is the main to be more interested structure rather than content (unfortunately).
Anyway- here is what I hope is more or less the final draft.
Best wishes
Paul Bryant.
Dear Dr. Catteral,
South Africa has applied to join the European Academic Research Network (EARN). As the UK is a member of EARN they have been asked for an opinion. This affects SERC as the Rutherford Laboratory has the only UK direct connection to EARN and operates a gateway between EARN and the UK academic network JANET. A Rutherford employee is a member of the EARN Board of Directors that manage the network. Advice is sought as to the attitude that the UK should take. This is a sensitive issue as the UK position may well become known and attract comment which may be prejudicial to the UK academic community and Rutherford in particular.
Some details of the network are appended. The network, together with its companions BITNET (USA), NETNORTH (Canada), and GULFNET (Middle East), forms a world wide network of over 1000 computers and is dedicated to academic and non-commercial traffic. Countries have up till now joined freely as long as they accept the EARN Charter (attached). EARN has attempted not to discriminate on the grounds of the counties political status and have accepted applications from Israel, Arab countries, African states, and East Europe.
In the South African case a number of points should be considered:-
SERC has a number of options:-
The EARN chairman is seeking guidance from all countries connected to EARN and would like a reply by the 16 September. Paul Brant (Rutherford 5267) will be happy to supply any further information you may require.
Considering the sensitive nature of South African relations I would appreciate guidance.
Yours sincerely
B J Davies.
Present:
B Davies (Chairman) J Hutton HEP W Turner Admin T Daniels CCD W Pulford SNS Bryant (Secretary) Apologies: M Johnson Neutron Division J Sherman S&A Division
The date of the last meeting was 28 January nor 23 October.
M2.4.4 A new network strategy paper had not been produced. It had been intended to produce this paper as a result of a CCD planning meeting but this had been postponed. A paper produced in 1984 had been circulated as P22 as a guide for discussion.
M3.3.2 An exchange of views meeting has been held between IPSS, P Bryant, J Hutton, and P Linington. The meeting covered the current state of the international connections, the future plans, and security. The meeting was informal and confidential. Notes of the meeting may be obtained from P Bryant. The meeting was very useful and a further one will be held in January.
M4.2.2 The document describing the network facilities on site is issued as P19.
M5.2.1 See M2.4.4.
M5.4.1 NDM is now open for all divisions to attend and minutes of the meeting are sent to division heads not supplying a member.
M5.4.2 No PAD guide has been produced but the guide produced by Daresbury will be examined with a view to its adoption. Action: T Daniels
CCD had attempted to have all PADs with the same tables in the interests of maintenance. There was a limit to the number of NRS entries in the PAD tables and an attempt had been made to put in the more popular names. However there are difficulties in accessing machines offering ASYNC 3270 if their names were not in the tables. P Bryant saw no reason why all these machines should not be put in the tables as they were small in number and he would ensure it was done. Action: P Bryant
It was noted that CCD was intending to put more effort into the maintenance of PADs.
M5.5.1 Action to produce an 'NRS site responsibility paper continues. Action: P Linington
M5.10.1 Security is being dealt with.
B Day was given a vote of thanks for his excellent paper P19.
After a wide ranging discussions it was decided that P22 was not a suitable starting point for a document as it was too detailed and contained a measure of tactical detail not needed in a 'policy' document. It was agreed:-
It was established that no service yet existed for the SYSTEL telex system although there was some pilot usage. It was also established that Administration Division was responsible for the service although this was subcontracted to CCD. Operator documentation is required by CCD Operations Group before a service can be launched. Further discussions are needed between Administration Division and CCD. Action: T Daniels, W Turner
Disappointment was expressed that as yet there was no automatic service between the Grey Book mail systems and the SYSTEL system. Although SYSTEL were asked to look into such a service, this was not part of the contract and it appears that no progress has yet taken place. CCD agreed to progress this. Action: T Daniels
The quality of service from PADs into VAX and possibly NORD computers was reported to be of a poorer quality than that of directly connected terminals. This is as a result of the systems in those machines rather than the PADs themselves. This is resulting in pressure for directly connected terminals.
It was understood that pressure was being put on suppliers but it was felt that this could well be better coordinated.
J Hutton was concerned that SERC and Rutherford in particular did not have a good record with respect to the implementation of the NRS.
P Bryant stated that the move to NRS was very complex but nearing completion. It had been hampered by lack of effort on various computers and by peripheral problems such as the building in of old style names into PROFs. In general the move had been fairly smooth for the users and at about the same rate as the rest of the community.
J Hutton will provide a paper on the state of NRS on various computers. (Appended as RCCC/P23/86).
J Hutton was concerned that from a mail point of view PROFS was regarded as a separate world by some users. For example a recent circular concerning Coseners House has requested bookings to be to a PROFS mail id which would not be understood by Grey Book users or those outside PROFS. The meeting agreed that every effort should be made to quote Grey Book mail identifiers in preference to PROFS identifiers whenever possible. Action: All
24 October 1986
The minutes of the JANET South East regional meeting were noted.
M5.5.1 Provide 'NRS site responsibility' paper P Linington
M6.2.1 Examine Daresbury PAD guide with a view to
adoption T Daniels
M6.2.2 Get all ASYNC 3270 services in the NRS PAD
tables P Bryant
M6.3.1 Produce policy document CCD
M6.4.1 Discuss launch of telex service with T Daniels
SYSTEL system W Turner
M6.4.2 Progress provision of Grey Book interface
to telex via SYSTEL system T Daniels
M6.7.1 Use Grey Book mail addresses whenever
possible All