10-FEB-81 17:25:18-PST,24168;000000000000 Mail from OFFICE-3 rcvd at 10-FEB-81 1725-PST Date: 10 Feb 1981 1725-PST Sender: STEFFERUD at OFFICE Subject: MSGGROUP#1592 FCC Notice of Inquiry for General Docket 80-756 From: STEFFERUD at OFFICE To: MsgGroup at ECL Cc: Maxwell at ISI, MJMarcus at ISI Message-ID: <[OFFICE-3]10-Feb-81 17:25:04.STEFFERUD> The following is an unofficial copy of an FCC Notice Of Inquiry for General Docket Number 80-756. The content has been proofed in an attempt to be as accurate as possible, but none-the-less, this must not be construed in any way to be an official copy. An official copy will be mailed to you via USPS if you send a mailing label with your request to MJMarcus@@ISI. This copy is being circulated via MsgGroup to allow individuals with ARPANET access to comment informally on the NOI. Interested parties may file comments on or before March 16, 1981. You may file informal comments by sending messages to MJMarcus@ISI. To be considered by the FCC, your informal comment should include your full name and US Postal Service Address. All such message comments will be forwarded to the Secretary for filing in the Docket, as stated in paragraph 23 of the NOI where informal comments are solicited from DEAF-NET users via netmail. If you have any questions about this procedure, you may question Mike Marcus privately, or with MsgGroup distribution so we may share your questions and the answers. The format of the NOI is changed from the official printed version. Underscores have been omitted, all footnotes are moved to the end of the document, rather than including them on each page where they are cited, and the pagination is different because of this. To assure that your comments are traceable to the content of the NOI, please cite the text by paragraph number rather than by page number. Any discussion of this NOI in the regular manner of group discussion via MsgGroup distribution will also be made available to the FCC as informal public comments in response to the NOI, and as such will be forwarded to the Secretary for filing in the Docket. Again, inclusion of your name and USPS address on your comments will be desireable. This is a new kind of activity for MsgGroup and we hope that it might afford some progress in the use of network facilities for this kind of inquiry. This use of MsgGroup is not sponsored by the FCC, though it is understood that FCC staff members are aware of our undertaking. Best Regards, Einar Stefferud (STEF) BEFORE THE FEDERAL COMMUNICATIONS COMMISSION FCC 80-702 WASHINGTON, D.C. 20554 28507 In the Matter of ) ) General Docket 80 - 756 Digital Communications ) Protocols ) ) ) NOTICE OF INQUIRY Adopted: December 4, 1980 Released December 8, 1980 By the Commission: 1. In the Final Decision of Amendment of Section 64.702 of the Commission's Rules and Regulations (Second Computer Inquiry)[1] hereafter referred to as the FINAL DECISION we adopted a dichotomy for network services, with basic services being subject to our Title II regulation and enhanced services not so subject. The FINAL DECISION also provided that certain common carriers[2] must set up separate subsidiaries if they wished to provide enhanced services and that such subsidiaries must have separate personnel and facilities from that portion of the carrier that provides basic services.[3] 2. In the FINAL DECISION, an enhanced service is defined in part as one in which "Computer processing applications are used to act on the content, code, protocol, and other aspects of the subscribers information".[4] We pointed out that "while comments in this proceeding (Docket 20828) do not address protocol conversion in any depth, the question arises as to whether some flexibility should be afforded a basic service provider that is subject to the separation requirement, in view of the structure we are setting forth".[5] We also stated that we would consider a NOTICE OF INQUIRY on this question. There may be reasons for allowing a carrier subject to the separation requirement to have certain protocol conversions within its network rather than in a separate subsidiary's facilities. 3. While the comments in Docket 20828 prior to the Final Decision did not address protocol conversions in depth, the comments filed by various parties in the reconsideration phase of the docket have commented on the conversion issues in terms of our basic/enhanced definition. These comments will be included in the docket in this proceeding; the parties are welcomed to elaborate or comment on them insofar as they relate to issues addressed here. -2- 4. In the FINAL DECISION we defined protocols as "governing the methods used for packaging the transmitted data in quanta, the rules for controlling the flow of information, and the format of headers and trailers surrounding the transmitted information and of separate control messages".[6] A carrier would be providing a protocol conversion if the information exiting its network at the destination(s) of a transmission is in a different protocol than that given the network at the point of origination. Protocol conversions internal to the network do not, how- ever, constitute an enhanced services long as information is delivered in the same protocol in which it is received. 5. The FINAL DECISION suggests that protocol conversions can be accomplished in the device external to a basic network with little or no impact on the efficiency and throughput of transmission in the network as compared to a case where protocol conversions are wholly internal to the network. It may be true in the future that if protocol conversions must be performed external to the network it may limit the throughput and efficiency of a carrier's network. For example, if a carrier subject to the separation requirement chooses to offer a basic packet switched service, it must deliver packets of information to the destination in the same size as it received them even if it might be efficient in some cases to deliver other size packets constituting the same information. The basic policy question involved in this inquiry is to weigh the magnitude of the benefit (if any) of allowing certain protocol conversions to be performed by the carrier providing basic service against the regulatory implications of allowing exceptions to our structural separation of enhanced services for AT&T.[7] 6. In its Petition for Reconsideration, the National Telecom- munications and Information Administration (NTIA) agreed with the FINAL DECISION in the possible need for some protocol conversions stating: "Certain enhanced services may be economically feasible if implemented in conjunction with basic service, but not otherwise..in providing a basic level compatibility between dissimilar terminals and computers in a data communications network, it may not be economically feasible to interface with a low level protocol and code conversion compatibi- lity machine owned by a separate subsidiary and located in a separate facility".[8] -3- 7. The Computer Corporation of America (CCA) also questions the conversion prohibition, stating that: "Basic services should include code and protocol conversion functions..Data users have come to regard speed, code, and protocol conversions as important essential components of data communications service. These functions offer the means of achieving a compatible path or channel between two points in a data communications network..To the data user, the speed, code, and protocol operations performed by a packet carrier are used only to facilitate the transmission of the users information from its point of origin to its destination".[9] 8. The American Telephone and Telegraph Company (AT&T) has asked that we consider protocols in the context of the seven level hierarchy proposed by the International Organization for Standardization (ISO) [10] and that "basic service be permitted to include lower level conversions through level (4) immediately".[11] 9. The International Business Machine Corporation (IBM) has taken specific exception to these views. IBM states "it is not true that protocol conversion must be performed as part of basic service ..There is no basis in the record or in experience for concluding that the provision of code and protocol conversion as part of enhanced rather than basic service would impose significant losses in efficiency on AT&T or the public or would result in a loss of ubiquitous service".[13] 10. The Associated Data Processing Service Organization, Inc. (ADAPSO) argues that "if AT&T is allowed to perform protocol conversion, then AT&T could selectively choose which protocols and codes it utilizes and thus could destroy the competitiveness of equipment and service offerings of others". ADAPSO further argues that the provision of protocol conversions would duplicate existing enhanced services in the basic network and "would create immeasurable opportunities for cross- subsidization".[14] 11. In the same vein, Tymnet, Inc. argues that allowing AT&T and GTE to offer conversions as part of a basic service would allow them to offer services equivalent to those now offered by Tymnet without any structural safeguards to prevent anticompetitive conduct.[15] -4- Discussion 12. In order to focus comments in this proceeding better, we shall discuss three specific areas in which the lack of protocol conversions might affect network efficiency should in the future AT&T decide to offer packet switched basic service as part of its network. We specifically request comments on these examples but also ask the parties to raise and discuss any other examples. 13. The first example, deals with the interconnection of multiple packet switched networks. Our general competitive policy supports the existence of multiple national and regional packet networks. In such an environment, a user may chose not to subscribe to all available networks, but may wish to communicate with those who are not connected to the same network(s) it is connected to. This need would require network interconnection. There are three basic technical approaches for network interconnection.[16] These are a common switching node, a common host (a computer common to both networks) or an internode device or gateway. If the multiple networks are of different ownership, the common switching node solution would be organizationally difficult. This method is also the most complex as "it involves implementing in the same device all the switching capabilities of each network as well as the mapping from one protocol to the other".[17] Thus this approach is both complex and involves a protocol conversion device that is joint to the interconnected networks. This approach has been rarely used even when there has been no regulatory concerns. 14. The common host approach on the other hand is the "simplest and most straight forward".[18] All messages destined to the second network go to a common host that is connected to both. However, each network treats this common host as an explicit point of origination or destination for messages. Thus, from the point of view of both networks, no protocol conversions are needed as a part of the network. However, as McQuillan and Cerf have observed, this type of implementation has certain penalties, for "reassembly of segments at each (common host) gateway leads to increases in delay and in packet interarrival time variance, which may seriously affect the performance of real time application software (e.g., slow scan video, compressed packet speech, etc.).[19] -5- 15. We note, however, that there is some disagreement within the technical community on this point. The "Pup internetwork architecture" [20] uses what is effectively the common host approach and avoids inefficiencies by requiring certain standards of the interconnected networks. 16. The third alternative is the internode device or gateway that translates "between the internal packet format of its own network and some common internetwork format".[21] This type of interconnection implicitly leads to protocol translation as the network gives information to the gateway in internal network format and the gateway outputs the information in internetwork format. This would happen in both the case where the gateway was part of the basic network or the case where it is external to the network. In the case where the gateway is considered part of the basic network, it is converting from the internal protocol to internet protocol, and such translation would be prohibited in AT&T's basic network under the FINAL DECISION. In the case where the gateway is external to the network, the network is outputting information in internal protocol; whereas it received it in external protocol, again constituting a protocol conversion.[22] Thus, some type of protocol conversion flexibility may be needed in basic networks to allow for efficient network interconnection. We specifically request comments on this formulation of the network interconnection question and would welcome discussion of alternative methods of network interconnection. 17. We also note that the CCITT recommended X.25 protocol allows for the originator of a connection to request a packet size different than that used at the destination. (While the draft February 1980 revision of X.25 provides for negotiated packet sizes between the originating and terminating user data terminal equipment (DTE), it does not require it).[23] Thus the terminating network data communications equipment (DCE) may be required to split a packet before it can deliver it to the terminating DTE. -6- 18. As mentioned above in paragraph 5, there are other types of protocol conversions that could clearly be done in separate units from the network with little or no impairment of performance. These involve simple transformations on the data stream such as changing the physical representation of the data. In the ISO/OSI model these would generally be equivalent to what are called the physical layer and the data link layer. We specifically request comments on the correctness of this view. 19. In the record of Telecommunications Services for the Deaf and Hearing Impaired, CC Docket No. 78-50, we have learned much about the needs of the deaf community. In particular we have learned o two different teletypewriter standards for the deaf which have evolved. These are the original Baudot code combined with a Weitbrecht modem and the ASCII code combined with a 103-equivalent modem.[24] While the Baudot/Weitbrecht standard is predominant in the deaf community, many more pieces of ASCII/103 equipment exist as this is common in both the commercial and home computer markets. Therefore, it may be in the public interest to encourage the offering of services that interconnect the two types of equipment. As such an interconnection involves code and protocol conversion it would not be allowed under the terms of the FINAL DECISION. We specifically request comments on this issue. Matters to be addressed in this Inquiry 20. The subjects listed below are not exhaustive. They merely typify the Commission's areas of concern. Information not directly responsive to these questions but relevant to the general subject matter of the inquiry is welcome and invited. To facilitate staff review each response should clearly state the precise topic or question being addressed. A. Under what circumstances would the protocol conversion prohibition of the FINAL DECISION inhibit the efficient interconnection of packet switched networks? In this case what would be the minimum amount of conversion needed to allow efficient interconnection? Should a carrier subject to the separation requirement be allowed to perform this conversion? B. Is the ISO/OSI model appropriate for classifying different levels of protocols in this proceeding? If it is, is it appropriate to allow carriers subject to the separation requirement to use different "physical layer" protocols at the input and output of a con- nection? Is it appropriate to allow such carriers to perform "data link layer" protocol conversions? C. To date this Commission has had little role in the formulation or recommendation of CCITT protocols such as X.25. Should we take a more active role in this area? If so, what should it be? D. Should the Commission allow AT&T, within its common carrier network to offer the packet size modification features of the X.25 protocol? -7- E. Should the Commission allow offerors of basic service subject to the separation requirement to offer services in their network that include interconnect of Baudot/Weitbrecht terminal and ASCII/103 terminal? F. The main emphasis of the discussion in the Notice and consequently in the above questions has been upon the static, operating efficiency of digital networks. We recognize that the offering of protocol concapabilities has implications beyond static operational efficiency. Allowing one or more types of conversions within AT&T's common carrier network may discourage competitive entities from offering similar services. This may ultimately reduce the options available to customers and increase their costs. We therefore seek specific comments on the dynamic effects of these alternatives, especially their impact on the provision of enhanced services and the incentives created for AT&T. Comment Filing and Ordering Clause 21. In view of the foregoing, we seek to obtain information from interested members of the public in order to assist the Commission in resolving the regulatory and policy questions presented by the protocol conversion issue. We specifically request respondents to address the questions in paragraph 20. 22. Accordingly, pursuant to Sections 4(i), 4(j), 403 and 404 of the Communications act of 1934, as amended, IT IS ORDERED that the aforementioned inquiry IS HEREBY INSTITUTED. 23. Interested parties may file comments on or before March 16, 1981. Reply comments must be filed on or before May 15, 1981. Pursuant to the procedures set forth in Section 1.51(c)(1) of the Commission's Rules (47 CFR 1.51(c)(1)) an original and five copies should be filed with the Secretary of the Commission. If you would like each Commissioner to have a copy, you should include six additional copies. All comments and replies should be clearly marked with the designation General Docket No. 80-756, and will be available for public inspection in the Docket Reference Room at the Commission's Headquarter's. Parties who wish to file informal comments by deaf standard (Baudot/Weitbrecht) TTY may send messages to the Commission's unattended TTY 24 hours per day by calling (202)-254-9292. DEAF-NET users may file informal comments by sending messages to MJMARCUS@USC-ISI. All such message comments will be forwarded to the Secretary for filing in the Docket. All written comments should be sent to: Secretary, Federal Communications Commission, Washington, DC 20554. For further information, please contact Michael Marcus at (202)-632-7073. For general information on how to file comments please contact the F.C.C. Consumer Affairs Office at (202)-632-7000. Federal Communications Commission William J. Tricarico Secretary -8- FOOTNOTES [1] 77 F.C.C. 2d 384. [2] This provision presently applies only to AT&T. See Final Decision at para. 290 and Memorandum Opinion and Order adopted October 28, 1980 FCC 80- , at para. [3] 47 CFR 64.702(c). [4] FINAL DECISION at para. 97. [5] FINAL DECISION at fn. 37. [6] FINAL DECISION at fn. 33. Such protocols are used in digital communications and are essential when packet switching is used in a network. [7] The purpose and scope of this proceeding is not to re-examine whether the offering of protocol conversion should be classified as a basic service. This proceeding is premised on the classification of such services as set forth in the FINAL DECISION. [8] Petition of NTIA (July 12, 1980) pg. 8. While those comments and others were essentially addressing the classification of protocol offerings as enhanced services, we believe consideration should be given as to the need for protocol conversion within AT&T's network even though enhanced. [9] Petition of CCA (June 11, 1980) pg. 10-11. [10] See Hubert Zimmerman, "OSI Reference Model - The ISO Model of Architecture for Open Systems Interconnection", IEEE Transactions on Communications, Vol. COM-28 No. 4, Pg. 425-432, (April 1980). The seven levels in this architecture model are as follows: 1. Physical control, 2. Link control, 3. Network control, 4. Transport end to end control, 5. Session control, 6. Presentation control, 7. Process control. [11] Reply of AT&T (Sept. 5, 1980) at pg. 50. [12] Footnote not utilized. [13] Opposition of IBM (August 4, 1980) at pg. 25-27. [14] ADAPSO Opposition (August 4, 1980) at pg. 14. [15] Tymnet Opposition (August 4, 1980) at pg. 11. -9- [16] See Ira W. Cotton, "Computer Network Interconnection" reprinted in Marshall Abrams, et. al, Computer Networks: A Tutorial, IEEE Computer Society, 1978, pg. (4-38)-(4-52). [17] Id. at pg (4-50). [18] Id. at pg. (4-49). [19] John M. McQuillan and Vinton G. Cerf, Tutorial: A Practical View of Computer Communications Protocols, IEEE Computer Society, 1978, pg. 169. [20] David R. Boggs, et. al. "Pup: An Internetwork Architecture", IEEE Transactions on Communications, Vol. COM-28, No. 4, (April 1980) p. 612-623. [21] McQuillan and Cerf, op. cit. at p. 15. Most networks use an internal protocol that is different than the external protocol that it presents to its users. This is done for internal efficiency and the choice of internal protocol depends on factors such as user characteristics, desired response time, and type of communication facilities used (as transmission delays are a key factor). [22] If it outputed the information in external protocol to avoid the conversion, it would really be a "common host" system, subject to the limitation and penalties mentioned above. [23] The X.25 protocol describes connections between user data terminal equipment (DTE) and network data communications equipment (DCE). See Antony Rybczynski, "X.25 Interface and End-to-End Circuit Service Characteristics", IEEE Transactions on Communications, Vol. COM-28, No. 4, (April 1980), p 500-509 and Draft Revised CCITT Recommendation X.25, reprinted in Computer Communication Review, Vol. 10, No. 1+2 (January/April 1980) p. 48-55. [24] Named after the Western Electric model number that established the de facto standard.