IEN # 10 William W. Plummer
Supercedes: None BBN
Replaces: None 7 March 1977
Section: 2.2.4.1
Internet Broadcast Protocols
William W. Plummer
Bolt Beranek and Newman, Inc.
50 Moulton Street
Cambridge, Mass. 02173
7 March 77
Internet Broadcast Protocols Plummer, 7MAR77 1. The Applications At least two applications of a broadcast mechanism have come into view: a "news wire" service, where error-free delivery is required, and a "network speech" protocol where a small percentage of dropped or corrupted messages is permitted. TCP is applicable to the former since it is designed to provide highly reliable connections, perhaps with some penalty in time. To use TCP for network speech however, would required adding features specifically to defeat parts of the protocol. The question of using a modified TCP for speech-type applications will be deferred for further study. TCP does provide some useful features (reliable establishment of connections, a way of naming connections, ability to reset half-open connections, etc.) which would be required in any application, but the issues which surface when partial reliability is permitted are complex. TCP is a good choice for the "news wire" application. Here, a receiver may "tune in" to a source of reports and while he is connected, will receive continuous, error-free delivery. In the following a mechanism for doing this will be proposed. 2. An Assumption and its Consequences A fundamental assumption of internet protocols (not only TCP) is that no special requirements may be placed on the participating networks. All they must be able to do is deliver a minimum sized packet with some semblance of reliability (Packet Radio Network is designed about a 10 percent loss rate). Various networks such as Packet Radio and Packet Satellite are fundamentally broadcast in nature and it would seem that some advantage of this could be taken. However, to rely on these properties in order to make a broadcast mechanism work would imply retrofitting wired, single receiver networks such as the ARPANET so that their subnets had similar features. This would violate the above stated assumption about internetting. Having to cope with single-receiver subnets suggests two ways to implement broadcasting. One is the "read-this-and-pass-it-on" arrangement, and the other uses one or more distribution agents ("distributors"). The former solution has a major flaw in that service to all receivers will be interrupted should any host, intermediate network, or gateway fail, because acknowledgments from the last host cannot be returned to the broadcast source. This is just too fragile; the distributor concept offers much better reliability.
Internet Broadcast Protocols Plummer, 7MAR77 3. Distributor Building a distributor involves writing a distribution server program which implements a layer of protocol not only above the subnet, but above TCP! This a is highly desirable property since it separates the connection maintenance function from the broadcast function. A distribution server operates as follows: It "listens" for a connection from anyone wishing to initiate a broadcast. Once this connection has become bound, the broadcast source supplies a distribution list (exact form and content will be described later). If all goes well, the distribution server will respond with the name of a specific input connection to itself to be used by the broadcasting process. The distribution server then establishes as may secondary connections as it sees fit -- some of which may go to other distributors in the same or different networks. The process run by the distributor for each specific connection simply reads a message from the broadcast source over the input connection and sends it out over each of the output connections. As previously mentioned, some of the output connections will be directly to specific receivers, but others will be to secondary distributors. In order to prevent hang-ups, it is required that each output connection address a set of receivers which is more specific than the input distribution list. Thus it would be improper for a distribution server to accept an input list of "Net 3, all hosts" and open two output connections, one to "Net 3, Host 100" and the other to a distributor for the purpose of broadcasting to "Net 3, all hosts". This secondary distribution list is not more specific than the input list and results in "Net 3, Host 100" being covered twice, most likely resulting in a hang-up if only one process is receiving the broadcast. 4. Connection Closing and Errors Connections out of a distributor may be closed at any time by the receiver. When all of the output connections have closed, the distributor will close its input connection. Retransmission timeouts are to be treated as connection closings if they address a specific receiving process. On the other hand a timeout on an output connection to a secondary distributor might be handled by attempting to reestablish communications via some different distributor, or if resources permit, to make specific output connections to each of the intended receivers.
Internet Broadcast Protocols Plummer, 7MAR77 5. Flow Control Flow is governed by the window announced by the distributor to the broadcaster. This window is a reflection of the amount of buffer space available in the distribution server itself, which in turn is a function of the number of output connections and the amount of unacknowledged information of each of these. This automatically provides a safeguard against any particular output connection tying up buffer space in the distributor by telling the distributor that it is able to receive a vast amount of data and then being very slow at processing it -- this situation cannot arise because the distributor will not send anymore than it has received, and it will not have received much if its buffer space is committed to waiting for ACK for packets on slow output connections. 6. Resynchronization, etc. Resynchronization, sending ARQs, letter size management, and segment reassembly are handled inside the distributor, transparently to the broadcaster. Only connection opening and closing, and data acknowledgement involve any communications back to the broadcaster. 7. Multiple Distributors and the Billboard Any host should be able to run a distribution server and a potential broadcaster could select any one that he can contact. Which one(s) will be dictated by other, outside constraints such as privacy, accounting, etc. On the other hand a potential receiver may want to find out where a good, relatively local source of some type of broadcast information is -- say weather information, but not airline flight information. To handle this need, each distribution list will contain a title. Upon setting up an instance of the distribution function, the title from the distribution list will be copied into a server-wide table along with the name of a local listening connection which is intended to service new output connections. In addition to the normal listening connection for new distribution lists, the distributor will maintain a listening connection for its billboard function. This will be on a well-known socket. A potential receiver looking for a specific kind of broadcast would do it by polling the distributors that it knows about, establishing a connection to the billboard function on each, and looking at what is listed to see if the desired information is being broadcast at that moment.
Internet Broadcast Protocols Plummer, 7MAR77 If so, the distributor (output) socket listed will be used to tap the information. Should the broadcast cease before the data connection is established, it is desirable to have the data connection attempt fail. However, it must also be the case that establishing the data connection does not pick up a newer instance of a distribution list. So, some simple additional protocol is needed to resolve this issue. This most likely will take the form of verifying the data connection attempt on the basis of a random key passed out by the billboard function. 8. Knowing Distributor Addresses The problem of knowing the identity (Network, Host) where distribution servers are running is common to both potential receivers and potential broadcast senders. This problem is not peculiar to to the broadcast mechanism; it is the same one as a user faces when he want to use a FORTRAN system on some (i.e., any) host. A master service directory must be consulted. This could be a printed list like a telephone book or it could be implemented by a program, but it not a problem to be solved by the broadcast mechanism. 9. Controlled Unreliability Although it is felt that TCP is not well suited for the net speech type of service, there are a few considerations which might make this possible. First, the broadcast source can "clear the pipe" at any time by sending a TCP level interrupt (INT) which forces all receivers to flush their current receive buffers. The broadcaster would do this if the rate of delivery had dropped below some predetermined rate. Notice that if the rate had gotten slow due to some host in the tree of distributors and receivers having crashed, then the INT will not be acknowledged, the distributor before the failed host will suffer a retransmission failure on the INT, and will mark that output connection as closed. This has the overall effect of causing a momentary loss of data to many (if not all) receivers, but permanently removes the slow or crashed receiver from the distribution. Another possiblity is that acknowledgements could be faked either by the sources TCP or by distributors. The problems involved are that control bytes can never by covered by fake ACKs, and that window information must be carefully handled.
mirror server hosted at Truenetwork, Russian Federation.