Path: utzoo!attcan!uunet!mcsun!inria!mirsa!jerry.inria.fr!huitema From: huitema@jerry.inria.fr (Christian Huitema) Newsgroups: comp.protocols.tcp-ip Subject: Re: Reliable Broadcasts? (was Re: Reliable Datagram ??? Protocols) Message-ID: <8900@mirsa.inria.fr> Date: 26 Oct 90 13:30:36 GMT References: <9010221418.AA03839@ftp.com> <1990Oct24.094329.5037@gec-rl-hrc.co.uk> Sender: news@mirsa.inria.fr Reply-To: huitema@jerry.inria.fr (Christian Huitema) Organization: INRIA, Sophia-Antipolis (Fr) Lines: 41 The subject of reliable broadcast protocols had been adressed in the early 80's in two different contexts, i.e. satellite networks and distributed systems. An interesting approach to the use of broadcast addresses for distributed systems (in fact, broadcast LANs) is that of Dr. Maxemchuck, which proposed a token passing "conference" protocol. Basically, the station which receives the token synchronize first with the previous stations, requesting a copy of all "missed" messages; options are to deliver this copy "point to point" or globally. The procedure uses a single packet counter, and maintains a global ordering of the messages -- which is indeed very useful for managing consistently a given systems. It sort of minimizes the ack flow, as acks are only transmitted during the token exchange; there is however a large overhead in semi silent systems, due to the rotations of the token. As far as satellite network are concerned, a quite exhaustive work was conducted at INRIA in the NADIR project between 1981 and 1985, for devolopping a performant and reliable "bulk broadcasting" protocol. In this protocol, the need for "1 ACK per station per packet" was alleviated by assuming a constant (unidirectional) message flow; the ACK are explicitly requested at well spaced "check points", e.g. at end of file. An option is to use unsollicited "NACKs" in order to request rapid resynchronisation of a particular recipient; another option to pass a list of "missing packets ids" upon a check point. These protocol variants have been described in several papers by the members of the project, e.g. J-L. Grange', I. Valet, J. Radureau or myself. The project is now terminated, and I am not aware of any continuation work. The use of either of these techniques in an internet (by constrast with a simple LAN or a controlled satellite channel) would pose at least two severe problems: * a group composition problems: in order to control the reception by "a group", one must be able to individually identify all the members of a group. What if this membership changes in the course of time? * a potentially severe flow control problem: when the routes to the members of the group have widely different capacities, how does one organize the slow down of the transmission to match the most constrained channel? Anyhow, this could be the basis of an interesting research work... Christian Huitema