CIGALE is designed to handle message transfer between computers at the best possible speed. Messages are handled independently, as letters in the mail. There are no end-to-end functions, but any higher level protocol may be used to control message flows. Hosts may be connected through several lines, and there can be several hosts on a line. The host address space is independent from the topology. Regions make up a 2nd level addressing and routing. They can be viewed as local networks. Also, hosts can be networks. A network name is a 3rd level intended for inter-network traffic. Various services may be added for some classes of users and terminals may be connected through concentrators, or a packet interface. Congestion control and routing are associated to control the message flow. A simple message interface is all that is needed to interconnect networks. Complicated interfaces make networks incompatible. The best value is transparency.
1. INTRODUCTION
CYCLADES [1] a general purpose computer network being installed in France under government sponsorship (Fig. 1). Its goals are to foster experiment and develop know-how in computer-to-computer communications, data transmission techniques, and distributed data bases. CYCLADES is also to be an operational tool for the French Administration. The project started on the beginning of 1972. Various demonstrations of distributed activities have been presented in November 1973, including 4 host computers and a packet switch. The complete network of 16 computers, linked by a 5-node packet switching network, is to be on the air by mid-1974. Additional hosts and nodes may be connected later on.
The communications network within CYCLADES is called CIGALE [2, 3]. It is a store-and-forword packet switching network similar to the one included in Arpanet [4]. A brief summary of the CIGALE description will be given here. More details may be found in the referenced papers.
2. THE CIGALE NETWORK
Nodes are MITRA-15 minicomputers, with 16 K words (16 bits). Except for a teletype, no other peripheral is necessary. Communication lines are point-to-point PTT leased tines ranging from 4.8 Kbs to 48 Kbs. All host computers are connected via telephone lines and V24 interfaces, typically using 19.2 Kbs base-band modulation on voice grade circuits (Fig. 2). Transmission procedures between hosts and nodes are those of the various computer manufacturers, in transparent binary synchronous mode.
Specific components within CIGALE provide for some basic services, such as : echoing, statistics recording, debugging aids, node configuration, artificial traffic, clock. Other services may be requested with regard to a particular packet : priority, tracing, routing. Switching is implemented on a very simple manner by asynchronous processes feeding each other through queues.
A control center receives various reports and helps in locating failing components. Every node can be reloaded individually from this center by sending its program in packets.
3. DESIGN OPTIONS
The remainder of this paper will concentrate on the choices made at the design stage, and discuss the rationale behind. Indeed, a distinctive character of CIGALE is not its gadgetry, but its basic simplicity. The result is an unusual flexibility in handling all sorts of protocols and connections. It will be a trivial task to connect CIGALE with other packet switching networks, as long as they do just that.
3.1. Computer-to-computer traffic :
No statistics are yet available. Consequently, only prospective assumptions can be made. A set of frequently mentioned characteristics are following :
a) Bursty traffic, ranging from sparse short messages to a file transfer steady flow.
b) Very short delay, ideally nil. Actually, a few milliseconds or seconds may be acceptable, depending on the environment.
c) Error rate less than 10-10 bit.
d) If an initial set up time is required, it should be small as compared to transmission time.
e) Transmission availability at least 98 % of the time.
f) Throughput as high as suitable for an I-O channel (several Mbs).
g) Traffic between host and network multiplexed on a small number of I-O ports, typically 2 for reliability.
h) Standard communication interface where applicable.
i) Host computers are heterogeneous.
Data to be carried unaltered, in a transparent mode.
3.2. Packet switching :
Direct circuits between computers would not meet conditions e and g. If circuits are switched, conditions d and f would not be met. Other media could be considered [5, 6, 7] (radio, satellite, coaxial cables), but equipment and infrastructures are not available. Packet switching on mini-computers has been introduced recently, but its validity is now well established. It can be implemented with existing hardware at a small cost. All constraints above can be reasonably met, within the speed limits of presently available transmission lines, (typically 48 Kbs). When PCM links are installed, they will provide for higher throughput and shorter delay.
3.3. Transit delay :
Conventional message switching systems, using secondary storage, take a few seconds, or a few hours, to carry a message through, depending on priority[8]. On the other hand, in the range of 100 ms, Arpanet is the only known network of large geographical extension. CIGALE is aiming at this domain of performance.
Very distinct architectures result from these two different ranges of objectives. CIGALE is not designed to cater for traffic with deferred delivery and long term storage. However nothing prevents a conventional message switching system from using CIGALE as a communication tool between centers. As CIGALE basic service is fast transit delay, this objective carries a major weight in the choice of other characteristics of the network.
3.4. Added services :
This objective of fast transit delay suggests eliminating some mechanisms, which certain kinds of users might find desirable in a data communications system, e.g. for terminal handling[9]. But various services may be added on, as custom-tailored devices, for certain classes of users. E. g. asynchronous character terminals, data conversion, hot circuits, restricted traffic, multiple addresses, etc... This can be implemented as pluggable pieces of hardware/software. It may also entail some additional delay or restricted throughput in carrying messages.
This approach, which is classical in properly designed systems, insulates basic functions from market oriented services [10], Indeed, the former must be kept very stable and customer independent if it has to be reliable, while the latter may be introduced on demand for changing needs. Customers who rely on an interface providing only basic facilities are guaranteed to protect their investment against modifications likely to occur in more specialized services. Furthermore, they are not penalised in being forced to use functions that they do not need.
Computer-to-computer traffic is predictably going to be the most demanding data transmission consumer in terms of throughput and transit delay. Furthermore, computers do not require any help in managing their own data transfer. Therefore, the communications system they need should offer the simplest possible functions and the highest possible throughput.
Along these lines, CIGALE afters a basic service, message transfer, and allows grafting additional functions through more specialized interfaces. The development of micro-components with a parallel decrease in cost will gradually make these devices appear as trivial hardware integrated in user equipment. For example, character oriented devices will soon be equipped with a message interface, so that they be linked directly to a network. They will look like simple computers. This is one of the reasons not to consider terminal handling in a packet switching network, since present terminal interfaces will fade out.
3.5. Packet size :
The term packet refers here to bit strings exchanged between CIGALE nodes. Various studies might be mode to evaluate an optimum size depending on a number of parameters. Practically, as long as efficiency and delay stay within an acceptable range, it seems that its main virtue is to be stable. This allows an adequate optimization of customer software and hardware.
Furthermore, it will be necessary to interconnect different packet switching networks. A generally agreed maximum size for a packet would be highly desirable in order to simplify interface mechanisms. A proposal has been mode to set 255 octets as the maximum text size [11]. This is long enough to accept packets from existing networks, and it suits nicely present computer hardware. This choice has been made for the British Post-Office network presently being implemented [12]. So it is for CIGALE.
3.6. Packet header :
It contains the following items :
| - Header format | 4 bits |
| - Header length | 4 bits |
| - Text length | 8 bits |
| - Packet identification | 16 bits |
| - Facilities, accounting | 16 bits |
| - Destination network | 8 bits |
| - Source network | 8 bits |
| - Destination host | 16 bits |
| - Source host | 16 bits |
The header length is 96 bits, a multiple of 6, 8, 12, 16, 24, 32. This facilitates formatting on most types of computers. The format field anticipates future adjustments in connection with other networks. CIGALE may have to handle various packet formats in a mixed traffic. They will be segregated easily.
The identification field is left for the user to identify his packets. It is not processed nor altered by CIGALE, but it is used to report about anomalies, or when special services are invoked. An obvious use is to contain all or part of a tag for multiplexing internal users within a host along with some serial number. But this belongs to host level protocols, and CIGALE does not require any specific scheme, since it is transparent to any outer protocol.
A 3-bit time-out field will be introduced in a future version, so that older packets be exterminated rather than roam about the network for any reason. It will not appear at the host interface.
3.7. Host interface :
The term host refers here to any computer connected to CIGALE. A host is assumed to be located at some distance away from a CIGALE node, and must use PTT lines. Indeed, putting a node on host premises carries several drawbacks :
- it increases the network cost and places an additional transit delay.
- it reduces reliability, since the node is under user's control.
- it is a security risk, as it can be tapped and tampered with.
A single line between a host and CIGALE would be somewhat unreliable. Two lines in parallel would not help in case of node failure. Therefore, it is possible to run several lines between a host and several CIGALE nodes. The traffic can be dispatched arbitrarily over all lines, according to speed and load. It is. also a way to increase the maximum throughput when lines cannot be speeded up.
In order to avoid any predicament usually associated with special hardware, the electrical interface is typically CCITT V24 up to 19.2 Kbs. At higher speeds, V35 is required.
Also, it was found undesirable to introduce a special transmission procedure between a host and CIGALE. Current manufacturer procedures are accepted, even though they are generally not very efficient. Hence no modifications to operating systems are necessary, as long as a transparent binary synchronous procedure is available, which happens in most cases. A consequence is that host-to-host protocols may be implemented at user level without modification to operating systems. This is of course immaterial in CIGALE, but it makes quite a difference for users who want to keep their system under manufacturer's responsibility.
A 16-bit cyclical checksum is a common feature of synchronous transmission. Any polynomial is acceptable, but the ISO standard x16 + x12 + x5 + 1 is recommended to maintain the error rate below 10-10 per bit.
3.8. Message size
In some networks the quantum of information exchanged between nodes is different from the one exchanged between host and node [l3, 14]. It is called a message, in order to prevent confusion. This need arises when message sizes adapted to user traffic are too different from on adequate packet size. But computers can exchange messages of many different sizes :
- a few characters for control messages
- a few dozens of characters for transactions
- a few hundreds of characters for file records
- millions of characters for complete files.
Since we lack statistics it would not make sense to pick an ideal size. Furthermore, packetizing costs overhead. Since a host is to fragment his data anyway, the advantages of putting an additional level of fragmentation do not appear to compensate for its inconvenience [15]. Consequently, a host message is simply a packet.
A possible objection is that too short host messages increase I-O overhead. Let us remark that this is mainly traceable to a clumsy design of communications software in some operating systems. I-O would be better handled by direct memory access. On the other hand, if this turns out to be a critical factor, some blocking scheme might be installed, to wrap several unrelated packets into a single I-O burst.
3.9. Name space :
Existing networks consider message addresses as meaning some physical component : a node, a line. As a result, there is a solid coupling between host addresses and network topology. CIGALE implements an abstract name space independent from the physical components. Consequently there is no constraint in naming hosts.
Furthermore, messages may be delivered to a single host address from several distinct nodes. Also, several host addresses may be reached over the same line. The first case is intended for reliability, as said before-hand. The second case allows several logical hosts to be connected on the same line. This is particularly convenient for having several distinct host protocols within the same host (as in CYCLADES), or to have several virtual hosts (as in IBM CP67), or to reach several hosts through a front end computer, or to have a set of hosts making up a private network. Actually, the exact nature of a host is immaterial in CIGALE ; it is a name capable of sending and receiving messages over one or several lines.
Part of the CIGALE name space is reserved for its internal components, such as software modules providing special services for network control and diagnostics aids. This saves the overhead and complexity associated with specially formatted packets. As for as switching is concerned, CIGALE handles only one packet format. But an internal component may be a real host, considered as part of CIGALE. This is a handy way to plug in any desirable function without making any technical modification to the CIGALE software, except putting a name in tables. This would be quite a hang-up if network services were designated with special bits in special fields of special packets. Some variations in the address format allow the location of an internal component within a particular node, some nodes, or all the nodes. On this way network services may be distributed according to traffic patterns, and even relocated dynamically, should the need arise.
A brute application of the previous principles would result in every node containing the list of all possible addresses (internal components and external hosts). This is perfectly acceptable for small networks, but not large ones, as lists would be too bulky. Therefore, the CIGALE name space is divided up into regions, and host names are prefixed with a region name, like telephone numbers. Thus, only local hosts and other regions need be listed in any node. Addressing and routing is based on host name within a region, and on region name across regions. In this respect, CIGALE is an aggregate of local CIGALE's (Fig. 3).
A region can contain one or several nodes, or none at all. This allows implementing an addressing plan without necessarily immediately installing as many nodes as regions. In addition, a host can be linked to nodes of different regions, even though its name belongs to one. This is deliberately restricted to hosts which cannot avoid straddling regions due to their geographical location. Or else address tables could become too large.
This name space is only a first step towards a general network interconnection scheme. In a multi-network context, the total name space is to be tree-structured at several levels [16]. Local networks (or regions) are to carry local traffic using shorter addresses, and long distance traffic using longer addresses. A common addressing plan is a prerequisite to network interconnection.
3.10. Circuits :
This term means a point-to-point logical connection established between two network users, be they hosts, or some entities within hosts. This can be simulated on both ends within the network [17], or even implemented physically as a fixed path through specific resources allocated within intermediate nodes (buffers, names, slots) [14]. Another common terminology is call set up [12]
Circuits can be predefined, and their use requires some allocation scheme [4]. Or they must be established on demand [12, 14]. In both cases an initial phase is mandatory before message transfer can take place.
Circuits may be useful for simple terminals which carry on a conversation with a single correspondent for a certain period of time. This is typical of time-sharing and remote batch users. On the other hand terminals may switch rapidly between various correspondents, when they participate in distributed activities, such as data base inquiries, monitoring. They may even have to handle several conversations in parallel, i.e. several circuits.
The host software is necessarily designed to manage a variety of parallel and independent activities, including logical connections with other hosts over a network. This is precisely the core of host-host protocols, which should be completely insulated from packet network characteristics [10]. Setting up network circuits is an additional constraint without any useful counterpart. Presumably, it is also an additional trouble-maker, since circuits will have jinxes of their own requiring special recovery procedures. Moreover circuit shortage or overhead can create congestion without any real traffic. One also looses the reliability of multiple links between host and network.
Since circuits present for more undesirable aspects than useful ones, they do not exist in CIGALE. However, they may be implemented on various ways as added services, as long as some users request it.
Fixed or switched circuits may be custom-tailored through private interfaces [17].
Actually packet switching networks with virtual circuits are a completely different approach to data communications. Instead of offering a message transfer service, like a mail system, they simulate a circuit switch. But the nature of the circuits do not allow transmitting bits at any time, like on a couple of wires. That sort of circuits can only transmit packets of bits, in some predefined manner, which is imposed by the network. In other words, a specific transmission procedure is required. Packet switching is carried out inside the network, but this is no longer a service. As far as the user is concerned, he only gets a circuit with a transmission procedure, which is not too unfamiliar.
3.11. Sequencing :
This is a usual corollary of circuits, i.e. the property of delivering packets in the same order as they have been sent over a particular circuit.
Bit transmission should be independent from applications, but data transmission is not. Indeed, data are bits plus structure plus semantics. So far semantics is transferred through human channels. Structure is application dependent and is taken care of by specific user protocols. Some of them are sequential, some are not. Transactions, labelled records, statistics, are usually independent pieces of data and can be delivered in any order.
Since there are no circuits in CIGALE, there is no sequencing.
3.12. Error control :
In CIGALE packets are checked and acknowledged between nodes. However node and line failures coupled with adaptive routing may result in packets being lost or duplicated. Consequently, some control mechanism is necessary to catch this type of error. It can only be done as part of a transmission procedure between a pair of correspondents. There is none in CIGALE, for several reasons :
- due to multiple links between host and CIGALE, there is no correspondent pair at network level,
- user protocols require end-to-end error control, since host mechanisms and host-node lines may also fail.
Consequently, end-to-end error control within CIGALE would not be sufficient, would not easily fit multiple links, and would introduce additional overhead [15].
As a general rule, protocols using CIGALE should include message error control. This is done in CYCLADES [18, 19]. Actually these mechanisms are an intrinsic part of host-to-host protocols.
3.13. Flow control :
This term covers usually mechanisms intended to keep a sender process from overrunning a receiver. Again this implies end-to-end control between a pair of correspondents. Only transmission lines are controlled in CIGALE. On the other hand, error and flow controls can be identical mechanisms, as they are no more than producer-consumer relationships [10]. They should normally be part of host-to-host protocols. This is done in CYCLADES.
End-to-end flow control has sometimes been considered as a mechanism for controlling traffic congestion within a network. E.g. this idea was behind the link mechanism in Arpanet, which is a variety of circuit [4]. Since then, it has been shown that congestion could still develop, while throughput on links is restricted [20, 27]. Actually they are two different classes of problems.
3.14. Congestion :
This term means a state within which network throughput drops to nil, or almost, due to saturation of network resources, such as buffers, line bandwidth, processor time, etc... It is a ubiquitous problem in resource sharing systems, where supply is constant, while demand is at random [21].
Congestion may be local if it is only limited to a few nodes, e.g. when a receiver stops working, but not senders. Total congestion may also develop if the network gets so crammed with packets that they can hardly move. This phenomenon is somewhat elusive an real networks, as most of them are too small to allow for significant experiments. Actually most investigations are based on models and simulation [21, 22, 23].
Research pursued in Arpanet and NPL indicates that global network control should he obtained by using simple queue disciplines and storage allocation [24, 27]. Although CIGALE is small enough to dispense with sophisticated control techniques, it appeared worthwhile to experiment with some variation of congestion control. Modelling studies have been undertaken, but no results were available at the time of the preparation of this paper. The basic idea is to couple routing and buffer allocation as two related facets of a global resource sharing exercise over the network [25].
Similarly to Arpanet [26], routing information propagates continuously throughout CIGALE. In addition to an estimation of transit delay, an estimation of available buffers is given per destination. Due to the hierarchical name space of CIGALE, a destination is actually a region, or a local host in a region. Again, this 2-level structure saves considerable overhead in handling routing tables. When solicited for entering packets, a node allows in only a limited number, based on buffer availability towards the requested direction.
At this point, it is clear that various traffic classes might be accommodated, e.g. a shortest delay class, within the limits of a few packets per destination, and a highest throughput class using most of the buffer supply on alternate routes towards the some destination. This scheme is expected to prevent local congestion instead of curing it once an increase in delay shows that it is developing.
Furthermore, each node may evaluate the total available capacity in the network, by adding up the supply for each destination. By convention, each node may be allowed to accept no more than a certain fraction of this total supply, until it gets fresh reports. Assuming that all nodes are solicited for on upsurge of entering traffic^ the network might fill up to its maximum allowed capacity, but no more, so that traffic keep flowing. On the other hand, it is statistically predictable that only a few nodes will have to choke excess traffic at any given time. In this case, the propagation of the available network capacity results in a gradual absorption of the transient, following roughly a logarithmic law.
Thus, both local and total congestion are expected to be in control. Actually, this scheme is akin to the isarithmic technique [21], at least for controlling total congestion. A significant difference is that buffer supply is reevaluated constantly, instead of being assumed fixed. Indeed, a weakness of the isarithmic technique is that no error is supposed to occur. If a node smuggles permits in or out, the whole network gets out of hand. Also, network partitioning may throw traffic off balance. Such accidents should be corrected automatically in CIGALE.
As a safeguard, old pockets will be destroyed, so that solid hang-up be excluded. But this is only a way to recover from a pathological condition, not a normal management policy. Actually, eliminating old pockets is mainly intended to reduce the deviation of transit delays, so that host protocols can be tuned for quick reaction on lost packets.
3.15. Routing :
Routing has already been discussed previously in connection with congestion control. A slight difference with Arpanet is that packets never flow backwards. In case no other way can be found, they are just dropped.
3.16. Accounting :
There is no specific mechanism in CIGALE for traffic accounting. On the other hand, various statistics are collected within nodes, and shipped to a network control center, for further analysis and reduction. The research environment presiding over most network development is admittedly not too obsessed with accounting problems. Some exposure to a more commercial approach would certainly be beneficial.
4. NETWORK INTER-CONNECTION
CIGALE has been thought out keeping in mind inter-connection problems. So far its design has been discussed mainly with regard to its function within CYCLADES, i.e. a communication tool between computers. Occasionally, it has been mentioned that a host could be a private network, and that regions in CIGALE could be viewed as local networks. These are just examples of a more general capability (Fig. 4).
As long as a network carries messages as in a mail system, putting several networks together does not alter the picture, so that :
<network> : : = <network> <network> ... <network>
Passing a message between networks reduces to a local border problem, i.e. a mutually agreed transmission procedure.
Routing a message is a distributed activity. A common naming scheme is necessary at network level so that each network know in which direction it should send a message to the network containing the final destination. Routing to the local user is only taken care of within the end network. As far as addressing and routing are concerned, interconnected networks behave like nodes of a super-network.
This means that one might apply recursively the some approach to design a network, or a network of networks. Actually, there are real life differences which put some restrictions. Nodes of a network are homogeneous, and abide by the same rules. Networks tend to belong to different organizations, which do not necessarily wish to be homogeneous. However, they may agree that they are willing to carry one another's messages under minimum constraints.
In that context a network interface like CIGALE is likely to be the least constraining. A few common agreements would be required among all networks [16]:
- an addressing plan to designate networks
- a basic header format
- a maximum pocket size
- a plain packet delivery service, without additional function
- a set of accounting practices.
Other necessary agreements are just neighbour problems.
In view of inter-connection experiments with other networks, e.g. NPL, the CIGALE header contains source and destination network names, according to the CATENET proposal [16]. Linking with Arpanet would not raise any particular difficulty, as long as message length is restricted to one packet. On the other hand, experience now acquired tends to support the desirability of redesigning Arpanet protocols along simpler principles, such as in CYCLADES-CIGALE [28]. But there remain unsolved issues with EPSS-like systems [12].
It is clear that the CIGALE transparency is its major trump to provide a communication service between existing systems. Any additional well-wishing function tied with the external world is likely to be incompatible and detrimental to a good service. In particular, communications networks studded with all sorts of bells and chimes will end up as one of a kind networks, unable to communicate, unless an ad hoc kludge be interposed so that they at last exchange packets.
5. CONCLUSIONS
CIGALE has been developed as the communications tool of a computer network. However, it is designed so that it can be inserted as a component of larger systems to carry any data traffic in a transparent mode. Except for timing parameters, CIGALE does not impose any particular protocol. Furthermore, it may include custom-tailored components to implement specific services.
ACKNOWLEDGEMENTS
The CIGALE development has been a joint effort by the Delegation a l'lnformotique, the French PTT, and IRIA. Many dedicated people have put some contribution at various stages of the construction. Among individuals who created major parts of the software are A. DANET, J.L. GRANGE, D.PREVOST and S. SEDILLOT. Packets would not have travelled very far without F. DENJEAN's interfacing skill. D. WALDEN (BBN) suggested many good ideas.
REFERENCES
[1] L. Pouzin, Presentation and major design aspects of the Cyclades computer network. 3rd Data Comm. Symp. Tampa (Nov. 73), pp 80-87.
[2] J.L. Grangé, L. Pouzin, Cigale, la machine de commutation de paquets du reseau Cyclades, Congres AFCET, Rennes (Nov. 73), pp 249-263.
[3] L. Pouzin, Les choix de Cigale, Congres AFCET, Rennes (Nov. 73), pp 265-274.
[4] F.E. Heart et al. The interface message processor for the ARPA computer network. SJCC (1970), pp 551-567.
[5] L. Roberts, Extensions of packet communication technology to a hand-held personal terminal. SJCC (1972). pp 295-298.
[6] L. Roberts, Dynamic allocation of satellite capacity through packet reservation, AFIPS National Computer Conf. NEw York, (June 1973), pp 711-716.
[7] I. Switzer, The cable television system as a computer communication network. Symp on Computer Communication Network and teletraffic. New York (Apr. 1972); pp 339-346.
[8] G.J. Brandt, G.J. Chretien, Methods to control and operate a message switching network, Symp. on computer communication network and teletraffic. New York (Apr. 1972), pp 263-276.
[9] S.M. Ornstein et al. The terminal IMP for the ARPA computer network. SJCC 1972, pp 243-254.
[10] L. Pouzin, Network Architectures and Components, 1st European workshop on computer networks, Aries (Apr. 1973), pp 227-265. IRIA édit
[11] D.L.A. Barber, Hierarchical control of a communications channel, Nat. Phys. Lab. (Nov. 1972), 10 p.
[12] Experimental packet switched service, British Post Office Telecommunications (Nov. 1972), 50 p.
[13] BBN report no 1822, Specifications for the interconnection of a host and an IMP (1973), 120 p.
[14] L. Tymes, Tymnet, a terminal oriented communications network. SJCC 1971, pp 211-216.
[15] L. Pouzin, Network protocols, NATO Advanced Study Institute oncomputer communication networks, Brighton (Sept. 1973), 25 p.
[16] L. Pouzin, A proposal for interconnecting packet switching networks, EUROCOMP, (May 1974), 13 p.
[17] L. Pouzin, Use of a packet switching network as circuit switching, Réseau CYCLADES, TRA 507 (April 1973), 5 p. Also IFIP-TC6.1, doc. 31, NIC 16735.
[18] M. Elie, H. Zimmermann et al. Spécifications fonctionnelles des stations de transport du réseau CYCLADES, SCH 502 (Nov. 1972), 105 p.
[19] M. Elie, H. Zirnmermann, Vers une approche systématique des protocoles sur un réseau d'ordinateurs, Congrès AFCET, Rennes (Nov. 1973), pp 277-291.
[20] L. Kleinrock, Performance models and Measurement of the ARPA computer network. Sémin. AFCET, Paris (May 1972), 37 p. Also in Proc. Int. Symp. Design and Application of Interactive Computer Systems, Brunel University. Uxbridge, England, May 1972.
[21] D.W. Davies, The control of congestion in packet switching networks, 2nd Symposium on problems in the optim. of data comm. Sys. (Oct. 1971), pp 46-49.
[22] H. Frank, R.E. Kohn, L. Kleinrock, Computer communication network design. Experience with theory and practice. SJCC Vol 40, 1972, pp 255-270, (in Advances in Computer Commun., Chu, W. W., (Ed.), (1974), 254--269).
[23] W.L. Price, Survey of NPL simulation studies of data networks, pp 1968-72, NPL report Com. 60 (Nov. 1972), 27 p.
[24] W.L. Price, Simulation of packet switching networks controlled on isarithmic principlés. 3rd Data Comm. Symp. Tampa (Nov. 1973), pp 44-49.
[25] L. Pouzin, Another idea for congestion control in pocket switching networks, Reseau CYCLADES, SCH 504 (Jan. 1973), 6 p. Also IFIP-TC6.1, doc. 21, NIC 14498.
[26] G.L. Fultz, L. Kleinrock, Adaptative routing techniques for store-and-forward computer-communication networks. Internal. Conf. On communications. Montréal (1971), pp 39.1 - 39.8.
[27] R.E. Kahn, Flow control in a resource sharing computer network, 2nd Symp. on problems in the optim. of data comm. sys. (Oct. 1971), pp 108-116.
[28] V. Cerf, An assessment of ARPANET protocols (published as ARPANET RFC 635), 20 p. Also Network Systems and Software Infotech State of the Art Report 24, 5/1975, pp 461-478.