t , I X3S37-77-56 Source: U.S. Department of Defense Advanced Research Projects Agency and Defense Communications Agency Title: Datagram Interface Requirements for Packet Networks Date; July 22, 1977 Abstract: This paper discusses the motivation for augmenting the X.25 packet network interface standard to include a datagram mode of operation. Technical arguments based on forseeable commercial and military require- ments are offered. ----------------------------------------------------------- DATAGRAM INTERFACE REQUIREMENTS FOR PACKET NETWORKS Background Packet communication networks are either in operation or under con- struction in at least 20 countries, and, in some countries, more than one network is to be found. Commercial interest in these networks is increasing and both public and private networks have been developed. A natural consequence of the development of these networks is the desire to establish standards for interfacing to them. Such standards would permit computer equipment manufacturers to build and support compatible software and hardware and could also, potentially, ease the ultimate task of inter- connecting many of these networks to each other. Over the past 4 years, packet network interface standards have been the subject of many lively debates, both in the international commercial and government telecommunications world and also in academic circles. This paper discusses the motivation for augmenting the X.25 packet network interface standard to include a datagram mode of operation. The following conclusions are drawn: 1. X.2S cannot concurrently support transaction services involving arbitrarily large numbers of sources and destinations. 2. X.25 places terminal handling functions at the wrong protocol layer. 3. Dual-homing of hosts and gateways is make-shift at best under the virtual circuit strategy. 4. The X.25 network interconnection strategy does not accommodate non-sequencing or lossy nets. 5. Flexible network interconnection with dynamic alternate gateway routing is unsupported by X.2S. 6. End-to-end encryption services may fail if the X.2S interface arbitrarily recombines packets before delivery to a host. Packet fragmentation and reassembly under X.2S appears to lose important end-end boundary information. 7. Packet broadcasting is inefficient at best and impossible, at worst, if virtual circuits are used to achieve it. 8. Real-time applications requiring low delay but not requiring guaranteed or sequenced data delivery will be inefficient and possibly inoperable through X.2S virtual circuits. 9. Regardless of the use of virtual circuits or datagrams, host level protocols must provide sequencing, retransmission, duplicate detection, fragmentation, reassembly, and flow control techniques to assure reliable and controlled host-level intranet and internet communication. ----------------------------------------------------------- Many of these conclusions stem from military network requirements which are more general than those for public nets. A counter-intuitive conclusion is that the military requirements impose fewer restrictions on network operation them the X. 25 interface does, admitting a wider ½las of nets to the internetrina community. Network Models Most views of packet networks distinish between "datagram networks" and "virtual circuit" networks. In fact, this is a very mis]eading taxonomy. A more accurate picture can be obtained by separating the network interface characteristic5 from internal network operation. For example, the interface to the ARPANET is datagram-like. No "connection set-up" exchanges occur between subscriber and network to cause packets to flow from source to destination. The network has two modes of internal operation, however. Packets labeled "type O" are delivered in sequence to the destination. The mechanism to do this is hidden within the network and does not require know]edge of subscriber-level connections. Type 0 packets flowing between pairs of source and destination hosts are kept in sequence. The second mode of operation is pure datagram. "Type 3" packets are not sequenced and delivery is not guarmnteed. The user selects these services by packet labelling and not by connection set-up. This combination of interface and internal operation may be con:rested with the U.S. TELENET operation which requires an external connection set up request and acknowledgement before a subscriber can send data to a remote site.* In this mode of operation, the set up packet traverses the network and a record of the connection is made at the destination [but not at intermediate points). A return packet confirms the virtual circuit set-up. Subscribers typically assign a short identifier to the virtual circuit to avoid sending the entire source and destination address in each packet from DIE to DCE (i.e., subscriber to network). The internal operation of the Telenet subnet is otherwise similar to that of ARPT. Packets carry both source and destination addresses and are routed through the store and fo'ard network in an adaptive fashion. Re-sequencing occurs at the destination DCE, as in ARPT. A third example may be found in the TYUWVET where subscribers are assigned explicit fixed route5 through the network. The connection set-up is managed ,,centrally by a supervisory computer which sends specific routing information to each switching node in the path from source to destination. Each character of text (or group of characters) is associated with a source "line number" which identifies the source subscriber. A "Frame" of text is made up of groups of characters from one or more terminals. The groups are each separately routed from node to node, $o the frame, when it arrives, is check- summed and disassembled. New frames are constructed at each node based on routing tables. By virtue of the fixed routing and link control procedures, all data remains in equence from source to destination. 'This does not rule out efficiencies such as allowing the'connection set-up packet to carry data as well. ----------------------------------------------------------- Finally, we can consider the CYCLADES network built at the French Institute Recherche d'Informatique et d'Automatique (IRIA). In this net, no attempt is made to maintain the order of packet arrivals at the destination. No "circuit set-up" packets are needed. Instead, as in ARPANET, each subscriber packet contains a source and destination address which can be used to route the packet through the network. Autodin II has similar characteristics. A reasonable taxonomy for these nets is: 1. Datagram Interface, Virtual Circuit Operation (e.g., ARFANETtype 0 packets) 2. Virtual Circuit interface, Virtual Circuit operation (e.g., Telenet; EPSS, TRANSPAC, DATAPAC, TYMNET) Datagram Interface, Datagram operation (e.g., CYCLADES, AUTODIN II,ARPANET type 3 packets) The obvious fourth combination (Virtual circuit interface, datagram opera- tion) is possible but is not, to the author's knowledge, in use anywhere. Such a net would require that subscribers set up the ends of a virtual circuit at source and destination DCE's, but would not attempt to deliver packets in sequence. The builders of public or commercial packet networks have been and con- tinue to be motivated by the marketplace. The typical customer of a packet network is looking for lower cost alternatives to leased lines and is not very interested in building special software simply to accommodate packet network operation. A predictable (though not necessarily desirable) con- sequence of this replacement strategy is that the replacement technology offer equivalent or nearly equivalent service at lower cost. Other arguments favoring the virtual circuit interface/operation mode appear when typical existing computer network applications are examined. Most of these appli- cations involve time-sharing, remote job entry and bulk file transfer services requiring the equivalent of dial-up, hard-wire, or leased lines. It is not surprising to find that most commercial or public packet switching services have been tailored to be attractive to existing applications. Virtual circuits are not real circuits, of course. For one thing, they exhibit variable delay and for another, they usually require that the sub- scriber "packetize" his traffic. Handling terminal traffic is an exception since most existing terminals are serial, character-oriented devices. Thus, packet assembly and disassembly (PAD) functions are often offered by packet network service suppliers to support terminal access to time-sharing systems. Speed and character conversion services can easily be incorporated into the PAD devices as well, making the packet service even more attractive. Many issues in packet network interfacing can only be understood in the context of computer communication protocol design. In the next section, a model of protocol architecture is offered as an aid to thinking about inter- faces. The model is not new, having been developed at least by 1968, when the ARPANET was being constructed, and most likely, long before that. ----------------------------------------------------------- Protocol Layering Figures 1 and 2 illustrate the basic model of packet network structure upon which our arguments are based. In figure 1, we show a network struc- ture which places PAD functions outside the packet network boundary and above the host level of protocol. Of course, this does not mean that suppliers of packet service cannot or should not offer PAD services, but simply that- PAD services should reside outside the host/network interface layer. We will return to this point when we discuss .virtual terminal protocols. Figure 1 also shows "gateways" between networks. We will discuss this in a later section on packet network interconnection. Figure 2 offers a conceptual view of the layers of protoco] and interfaces we can expect to find in packet networks. The layers are connected vertically by tea] interfaces which carry data and control physScally from one layer to the next. The layers are connected horizontally by logical or conceptual paths which constitute virtua] interfaces carrying embedded control and data. The conceptual embedding is illustrated in figure S. In real networks, of course, some optimizations can be found which avoid the need to actually carry in each packet all the control needed. Generally speaking interfaces define ways of carrying (and distinguishing) control information and data. Physical interfaces may use different paths to distinguish control from data (e.g., control and data lines on an X.21 interface). Virtual interfaces usually employ formatting to embed control and data in the same transmission medium. The CCITT recommendation X.25, as apparently used in TœLENST, EPSS, DATA- PAC, and TRANSPAC, imposes an unnecessary restriction on subscribers with respect to protocol layering. Virtual circuits are identified with a 12 bit identifier. For transaction applications in which these may be tens or hundreds of thousands of sources or destinations (e.g., point of sale services), the intrusion of virtual circuit numbering on the subscriber seems unnecessary. The minor efficiency obtained through this imposition (shorter DTœ to DCE packets) is lost when packets are internally carried with full source and destination addressing anyway, so it is not apparent that much is gained through this design. Conclusion 1: X.25 cannot concurrently support transaction services involving arbitraily large numbers of sources and destinations. The argument that virtual circuits are required to deal with flow ,ontrol is simply invalid. To be sure, source and destination packet switches must protect their buffer resources. They can do this at the subnetwork level by exercising flow control based on source and destination packet switch pairs or, if desired, source and destination subscriber (i.e., host interface) pairs. There is no reason for the subnet to care about the number of logical connections between internal proces&es of two subscribers. The ARPANET implementation has even demonstrated that flow control information between source and destination packet switches can be dynamically destroyed and recreated, if need be, to prevent dormant pairs of subscribers from consuming valuable resources in their respective packet switches. ----------------------------------------------------------- HoT MoJet o akec Ne+work ----------------------------------------------------------- VtuI Ap pl i+ion l- - .... t J,--I'L. [A ppI c con ] I I v s.= I r'e,,-,oi:e job entry C Hel----------------------------- i i I I I i  I I  I I in ,a ----------------------------------------------------------- Virtual Terminals One of the most important notions arising out of packet network research is the idea that all terminal handling should be accomplished through the use of a virtual terminal standard. A conceptual virtual terminal is defined with certain characteristics such as character set, page size, line length, format control (backspace, line feed, tabs, vertical tabs, end-of-line indicator) and editing functions (character deletion, word deletion, line deletion). Any particular terminal is interfaced to the virtual terminal level of protocol (PAD in figure 1, application level in figure 2). The physical terminal characteristics are translated into the standard virtual terminal representation for transmission through the packet network. Specific parameters about real terminals may be exchanged through the virtual terminal protocol so that hosts serving virtual terminals can maintain a model of service requirements at the user end. Negotiations to decide which end should echo characters typed or to adapt to terminal line or page size can be conducted using the virtual terminal protocol. The commercial and public network community has recognized the value of this concept and the X. 25network interface standard provides for special "virtual terminal" virtual circuits. X.2S does not, however, exhibit the layering shown in figure 2. Indeed, this is not surprising. To achieve the layering of that figure, a common host level protocol must be postulated which will support application protocols such as virtual terminals. Since few manufacturers were or are prepared to offer a common host protocol, the network purveyors were forced to "emulate" the host-to-host through the use of virtual circuits which would provide sequencing, flow control, duplicate detection, end-to-end retransmission and so on. It is our view that this is a reasonable short-term solution, but that eventually, these functions must be agreed upon, supplied, nd supported by computer equipment manufacturers. This need will become more apparent when we discuss network interconnection. Conclusion 2: X.25 places terminal handling functions at the wrong protocol layer. Multihomed Hosts In figure 1, we have shown one host which is connected to two different packet switches in the same network. If virtual circuit concepts are used to support such hosts, then one of two possible scenarios can be predicted. Either one of the connections is viewed as a primary link, with all traffic specifically addressed to it [the others being unused until the primary link fails) or all links are used, but packets associated with a particular virtual circuit are always delivered over the same link. The virtual circuit concept requires that the network sequence packets before delivery to the host. This can only be achieved if all packets for a given virtual circuit are ----------------------------------------------------------- 9 re-sequenced at a single destination packet switch. An alternative strategy which permits packets to be arbitrarily delivered on either link requires that sequencing, duplicate detection, and retrans- mission occur outside of the network in the host or a front-end which is connected to two or more packet switches. If the latter idea is pursued, then multihomed hosts need have only one name. The source host need not know that there are two (or more) connections between the destination host and the network, leaving the routing decision to the packet network. It should be obvious that this can be accomplished if a pure datagram facility is offered by the network (i.e., no assumption of sequencing, no binding of packet delivery to any particular host/network link). Virtual circuit methods are restricted to less flexible use of the multiple links. If virtual circuits are used to serve multihomed hosts, and the primary connection breaks, there is no way for the source packet switch to distinguish between the case that a packet was successfully delivered to the host but the acknowledgement was lost by the broken connection and the case that the packet in fact was not delivered. Thus, any attempt at repair by switching to an alternate link will require host level protocols to sort out duplicates. To properly deal with this case, host-host protocols must employ their own level of sequence numbering, end-to-end acknowledgement, retransmission, and duplicate detection. Conclusion 3: Dual-homing of hosts and gateways is make-shift at best under the virtual circuit strategy. Conclusion 4: The X.25 network interconnection strategy does not accommodate non-sequencing or lossy nets. Network Interconnection Finally, we must come to grips with the problem of network interconnection. We strongly agree with the designers of X. 2S that network interface standards will be of great help in solving this problem. However, we feel equally strongly that the correct set of standard network services required to effect inter- connection should be minimized to allow for the maximum range of network implementations and to admit very flexible internetwork routing and error recovery strategies. In figure 1 we illustrate the conceptual notion of interconnecting networks through a "gateway." It should be kept in mind that the following arguments do not depend on a monolithic device to interconnect two networks, although the notion of a gateway box is one possible realization of the concept. Other possibilities include the implementation of the gateway function in two separate "halves" (or "thirds", if three networks are involved) which might ultimately share the hardware of a packet switch. One of the most important notions of network interconnection to emerge from research in this area is the concept of terminating or "cauterizing" internal network protocols at the gateway. Since this is analogous to the termination of internal protocols at the point where hosts connect to networks, we are led to the idea that a gateway should interface to a network in the same way a host does. This does not preclude a network from distinguishing between hosts and gateways. To give a simple example, a ----------------------------------------------------------- 10 gateway might be associated with any number of networks ,(i.e., the internal routing and addressing functions of the network might be aware of internet addresses; packets containing destination addresses outside the local network could be routed to an appropriate gateway). Hosts would generally have only one name (although the network might also know that more than one interface exists to that host in the multi-homed case). Packet switching with adaptive routing mechanisms allows the network to recover from internal failures by automatic re-routing of packets around broken links or nodes. This is sparable from the notion of re- routing around congested areas although networks like the ARPANET have combined these capabilities in one routing mechanism. The most fundamental issue concerning network interconnection is gateway reliability. Public and private networks can seek to improve matters by building redundant, multiple processor, multiply-interconnected gateways at a given location. For military networks, and probably even for commercial and privc networks, simply building more reliable gateways is not a sufficient solution. Under hostile conditions, gateways may be destroyed or access to them may be denied (e.g., through jamming in radio nets). Consequently, it is essen- tial that network interconnection strategies naturally allow the adaptive routing of packets through multiple gateways, regardless of the end-to-end "circuit" associated with the packet. It could be argued that the problems faced by the military are unique and need not have any impact on commercial or public nets. In fact, standards for data communication are of central concern to the military both because equipment and systems are supplied to the military by commercial manufac- turers and because, in many countries, military data communication facilities are supplied by the Post, Telephone and Telegraph (PTT) organizations which also supply public facilities. In the U.S., the Department of Defense is largely required to use commercial facilities whenever possible. It is essential that special military facilities and commercial facilities be compatible. The cost of providing for increased flexibility in network interconnection strategies is negligible and in some cases, could lead to less expensive commercial systems as well. Arguments have been offered to the effect that networks exhibiting X.2S interfaces can easily be interconnected by "gluing together" virtual circuits at a gateway. If this notion is taken literally, then the gateway becomes a critical link in the internet virtual circuit. At the gateway, status information (flow control, local virtual circuit number - which may be different for each net, local source/destination addresses and perhaps internet source/destination addresses, accounting information, etc.) about the virtual circuit must be kept up-to-date. If the gateway fails or becomes isolated, a new virtual circuit must be created. It does not appear likely that this can be done entirely without the awareness of the subscriber, in particular since it involves the potential loss or duplication of packets which were in the gateway when it failed. ----------------------------------------------------------- 11 An alternative interpretation of the X.2S internet argument suggests ' that the gateway can transparently pass packets (in X.25 format) from one net to another and that the ultimate packet switches at the source and destination can cooperate to achieve an end-to-end virtual circuit. It is further argued that the gateway can manipulate the end-to-end flow control mechanism so as to achieve intergateway or source packet switch-to-gateway flow control. This model leads to the conclusion that a gateway must maintain status information about every virtual circuit passing through it. For networks supporting substantial internet traffic, the number of virtual circuits could reach on the order of the square of the number of subscribers. Although international tariff barriers may initially limit the amount of traffic between national networks, it is clear that electronic mail and file transfer types of service will be in high demand. Eventually this will constitute a majorshare of the internet traffic among all interconnected networks. Any network interconnection strategy which depends on state information in gateways will be subject to major recovery problems after a gateway crash. Other methods of interconnection have been developed and demonstrated which do not require gateways to maintain internal state information about the subscriber-level traffic passing through (except for accounting information which is periodically extracted from the gateway anyway). One example of this interconnection strategy is found in the interconnection of the U.S. ARPANET, Packet Radio Net and Packet Satellite Net through "state-free" gateways. Conclusion 5: Flexible network interconnection with dynamic alternate gateway routing is unsupported by X.25. It must also be recognized that not all networks will utilize the same transmission technology. Some will employ satellites, some leased lines of differing rates, some ground radio systems, some involving mobile sub- scribers, some using twisted pair or coaxial rings, some using multi-access coaxial CATV cables and so on. The various media, transmission rates, error characteristics and so forth will dictate differing packet sizes. In order to deal with evolving technology, we take the view that it should be possible for a subscriber to emit a datagram which, on passing through a gateway, can be "fragmented" into smaller pieces which can later be reassembled. No matter what fragmentation strategy is employed, the destination subscriber must still be prepared to reassemble fragments produced by the last gateway. There is consequently little point in putting a reassembly function in the internet gateway. To formulate an abstract model of this view, we must modify figures 1, 2, and 3 to reflect a gateway layer of ,protocol for internerring. As shown in Fibre 4, a gateway between two networks is composed of an internet gate?a part which exchanges routing, congestion control, status, and accounting information between networks and a ]ocal gateway part which is aware of the characteristics of the network[s) to which"it 'is connected. Internet datagrams leaving the internet gateway may be fragmented by the ]ocal gateway, and incoming fragments may be re-assembled. ----------------------------------------------------------- FtoT ps ?roto e{'wor A end  Loc[ 9ewa  N'wor i Gct'ew¾ Fnciznc 'Fiqure r ----------------------------------------------------------- The destination subscriber's local gateway should be prepared to re-assemble datagrams which may have been multiply- fragmented or whose fragments have been routed through different internet gateways to get to the destination. This assumption allows for maximum freedom in fragmenting and routing datagrams through multiple networks. The datagram format must obviously accommodate this operation, while at the same time, allowing for intermediate re-assembly without loss of boundary marking infor- mation. We take it as essential, furthermore, that end-to-end checksumming over the datagram header and text must be possible so as to assure that datagramm delivered to the higher level protocol are without errors (to within a very small probability). One conceptual strategy for achieving this goal is to adopt a datagram format which includes an end-to-end sequence number, length, checksum, and two flags meaning "beginning of segment" (BOS) and "end of segment" [EOS). As shown in Figure S, it is possible to fragment and reassemble fragments while preserving an end-to-end check on the validity of the data as long as the BOS and EOS flags are properly handled. In figure 5(a) we illustrate a datagram made up of an internet header and 200 bytes (8 bits/byte) of data. A checksum has been computed over the header and all data. Each byte of data is associated with a unique sequence number. The next datagram (not shown) will start with sequence number SO0 (i.e., 100 + 200) to preserve this uniqueness. The two fragmentation control flags, BOS, and EOS, have been set, indicating that the datagram is complete and contains an end-to-end checksum for verffications. If the datagram must be fragmented, as is shown in Figure S(b), the internet headers are slightly modified to indicate which sequence numbers (i.e., which bytes) are contained in the data. The EOS flag is reset in all but the last fragment. The sequence number and length of each fragment's internet header have been modified to reflect the fragmentation. At an intermediate or destination local gateway, the fragments can be re-ordered using the sequence numbers and reassembled to verify the end-to-end checksum. The strategy works, even if the source local gateway retransmits the original datagram and it is fragmented differently as a result of pasing through a different set of gateways because of the unique asociation of data bytes and sequence numbers. Fragmentation at any byte boundary is thus permissible. The strategy outlined above allows for complete freedom to route and fragment packets passing through multiple nets, placing few constraints on subnet implementation. Minimizing these constraints will permit the interconnection of a wide variety of data networks and allows for adaptation to new transmission media and network organizations. ----------------------------------------------------------- 14 e. Len h ln th -IO byi:e ZClCi D+almm Fra]menl[on Gch!ul. ----------------------------------------------------------- IS Another aspect of the X.25 virtual circuit interface is of some concern for higher level protocol desigmers. Although it is not entirely certain, it appears that the X.25 interface would allow a network to accept several packets from a subscri.ber, form a larger subnet packet from these, and deliver them in one packet to the destination. At first glance this is attractive because it improves efficiency. However, if there is no mechanism for indicating the original boundaries on delivery, the receiving subscriber may be forced to search the incoming packet to find the relevant boundaries. Even worse, when certain kinds of privacy transformations are employed, the artificial coalescing of two subscriber packets on delivery can lead to deadlocks in which the transformations cannot be correctly undone. If subscribers using the X.25 virtual circuit interface are, in fact, going to be faced with this problem, it is clear that additional control information. must pass from end-to-end within the network(s) to allow both subscribers to stay synchronized. Conclusion 6: End-to-end encryption services may fail if the X.25 interface arbitrarily recombines packets before delivery to a host. Packet fragmentation and reassembly under X.25 appears to lose important end-end boundary infor- mation. For example, if subscribers are trying to ezchange packets containing subscriber level headers, but X.25 delivers these in arbitrary units, without any indication of the original subscriber boundaries, it may be necessary to employ in-band flag characters, and bit-stuffing (as in HDLC) to maintain data transparency. A properly formulated network interface would assure that useful subscriber boundary information is conveyed from end to end, eliminating the need for line-level protocol tricks at the host-host level of protocol. New Technology and Services As computers become more widespread in business applications and as their cost decreases, we can safely predict an increase in the demand for inter- computer communication services. Many services such as Electronic Funds Transfer, point-of-sale transaction management and credit card verification require only that short messages or packets be sent from one place to a variety of different places. Setting up virtual circuits to transmit a single message imposes needless inefficiency and overhead on the subscriber and makes the existing public and commercial packet switching services less attractive. The Bell Transaction Network uses a datagram interface, for example, precisely because it fits the application more appropriately. If public or commercial packet networks are to support real-time services requiring low delay but not sequencing or guaranteed delivery, then the typical virtual circuit service must be modified. For example, a virtual circuit, because it is implemented using store-and-forward methods in a packet switched net, exhibits very good undetected bit error rate characteristics (less than 1 bit in a trillion). Each packet is error checked as it is forwarded from node to node and retransmitted if it is received in error. For added.reliability, most virtual circuit services also employ end to end [DCE to DCE) retransmission to protect against packet loss within the network due to a node failure. Such reliability measures usually result in an increase in the variance of inter-arrival time of packets delivered to the destination subscriber. ----------------------------------------------------------- As more computer terminal equipments are equipped with built-in microprocessor(s) and memory, the need for FAD services will be reduced because these terminals can perform their own packet assembly and disassembly. From the point of view of the network, the distinction between host and terminal will blur since both will be capable of sending or receiving packets to or from several remote sites. Multidestination addressing, longin use in the business world (in the form of carbon or photocopies) and in the military world (particularly in Autodin I), has an obvious place in packet networks to support electronic mail, distributed file systems, distributed operating systems, voice conferencing (or mixed media conferencing) and so on. Some applications may even require that a particular packet or sequence of packets be delivered to all sites in the net. For example, some information sources (weather instruments, highway traffic sensors) may not know exactly which sites should receive data, so it might be broadcast to all of them. If it were necessary to "set up" a virtual circuit to every possible destination before doing a multidestination broadcast, the potential delay and overhead to explicitly remember each destination at the source DCE would be very high. One alternative is to create "multi-destination" names. Intermediate nodes in the network would have routing table entries for these multiple-site names. Of course, these entries would have to be created and destroyed dynamically. Similarly, a particular name might be reserved to mean "all destinations". Maintaining virtual circuit characteristics (reliable, sequenced data) in the presence of multi-destination broadcasting to many sites will be impossible, owing to the amount of acknowledgement traffic which. would be required and the amount of table space needed at the source DCE to keep track of end-to-end acknowledgements. Conclusion 7: Packet broadcasting is inefficient at best mud impossible, at worst, if virtual circuits are used to achieve it. Real-time Data Transfer Services (e.g., packet speech) Although it is very unlikely that packet networks could support the volume of voice traffic that circuit-switched networks typically handle, a limited speech capability in packet nets may be useful to augment existing computer-based teleconferencing systems. Experiments with "packet speech" conducted with support by the Defense 'Advanced Research Projects Agency, for example, have demonstrated the feasi- bility of carrying small amounts of compressed, digitized voice through the ARPANET. Indeed, advances in digital voice compression using linear pre- dictive coding [LPC), continuous variable slope delti modulation (CVSD), and adaptive delta modulation (ADM), homomorphic and channel vocoders demonstrate that relatively low rate speech (on the order of 1000 bit$/sec on the average with peak rates around $000 bits/second) is feasible. If speaker silence is detected at the digitizer, then it is straightforward not to transmit during the silence periods. Packet networks do not require continuous transmission to keep both subscriber ends in synchrony and thus, the removal of silence becomes straightforward. ----------------------------------------------------------- 17 For compressed packet speech to work well, it is far more important to achieve low delay and low inter-arrival time variance than ultra- reliability, provided that a sufficient number of packets actually do make it through. Some adaptive delta modulation schemes have been tested at packet loss rates as high as 10% with resu]ts equivalent to a bit error rate of under 1%. In fact, if the source subscriber can provide suitable time- stamps on each compressed speech packet, it is desirable not to attempt to resequence packets at the destination DCE but to let the destination subscriber decide, based on the timestamps, whether to "play" or discard the incoming packet, or to buffer it in the hope that a missing packet will arrive soon enough that both can be "played". me conc]usion, in this instance, is that compressed, packet speech, integrated with data services, requires a different mode of operation than typical virtual circuit systems offer. Conclusion 8: Real-time applications requiring low delay but not requiring guaranteed or sequenced data delivery will be inefficient and possibly inoperable through X.2S virtual circuits. Conclusions We have shown that the packet network virtual circuit interface concept, as characterized in the CCI/7 X.2S recommendation does not satisfactorily meet all forseeable packet communication requirements of commercial, public, private, and military networks. In addition to the eight conclusions developed thu far it is quite apparent that to achieve reliable and controllable end-to-end communication at the host level, it will be necessary to implement end-to-end flow Control at that level. Furthermore, for logical messages larger than the maximum "packet" accepted by the network to which the host is attached, fragmentation and reassembly procedures will be needed. These will require some form of sequence numbering to assure reliable communication in the event of virtual circuit "resets" within the packet network, hosts must be prepared to retransmit packets which have not been'acknowledged by the destination host (or for which the network has reported "non-delivery"). This latter requirement implies that the host must also provide duplicate detection facilities. All these facilities would also be needed if the host were to use a datagram service rather than a virtual circuit service. We are therefore led to a final conclusion: Conclusion 9: Regardless of the use of virtual circuits or datagrams, host level protocols must provide sequencing, retransmission, duplicate detection, fragmentation, reassembly, and flow control techniques to assure reliable and controlled host-level intranet and internet communication. For reasons of national and international security, it is imperative that the standards set for public and international packet networking accommodate both public and military requirements. ----------------------------------------------------------- Recommendations The addition of a datagram interface mode has been proposed in the past and several alternatives have been offered for its realization, maintaining compatibility with the current X.25 recommendation. It is essential that a datagram mode of operation be included in the X.25 packet network interface standard to correct the deficiencies outlined above and to generally accommodate the evolution of computer communications technology. -----------------------------------------------------------