Path: utzoo!attcan!uunet!timbuk!cs.umn.edu!ub.d.umn.edu!rutgers!mcnc!decwrl!sgi!rpw3@rigden.wpd.sgi.com From: rpw3@rigden.wpd.sgi.com (Rob Warnock) Newsgroups: comp.protocols.tcp-ip Subject: Re: Reliable Broadcasts? (was Re: Reliable Datagram ??? Protocols) Message-ID: <73238@sgi.sgi.com> Date: 25 Oct 90 14:15:07 GMT References: <9010221418.AA03839@ftp.com> <1990Oct24.094329.5037@gec-rl-hrc.co.uk> Sender: guest@sgi.sgi.com Reply-To: rpw3@sgi.com (Rob Warnock) Organization: Silicon Graphics, Inc., Mountain View, CA Lines: 85 In article <1990Oct24.094329.5037@gec-rl-hrc.co.uk> fddi@hrc63.UUCP (FDDI Group (Ian Wakeman - A26)) writes: +--------------- | although it may be heresy to say it in this group, XTP has some reliable | multicast features inside of it, although I doubt whether they've been | tested on a WAN,... +--------------- True. All of the XTP/multicast applications I know of are on LANs. But XTP incorporates most of the current thinking about "slow-open", RTT estimation, and congestion control [shamelessly borrowed from TCP!], so XTP/multicast ought to work on a WAN (except there aren't any XTP routers... yet). +--------------- | ...and claiming reliable multicast without group management | facilities is a trifle absurd - how do you know that all possible respondees | have replied? +--------------- In XTP's "mostly reliable" mode, you set a service parameter (called "E" in Appendix "B" of the XTP 3.5 spec) which is how many *consecutive* negative-ACKs from any *single* station you want to be able to tolerate losing. The XTP "bucket algorithm" then ensures that at least that many attempts have been made to hear from everyone before releasing data from retransmisison buffers. Larger values of "E" require larger retransmission buffers (or you can keep the size of the retranmission buffers down by cranking up another parameter "N", at the cost of more control packet and ACK traffic -- nothing's free). If the probability of dropping an ACK from a given station is "p" (presumably much less than 1), then the probability of that station falsely being "left behind" is not worse than p^E. As long as you have a finite error rate and enough memory for retransmission buffers (or enough spare network bandwidth), you can make p^E "as small as you like". For example, you might choose to set E such that p^E was less than the probability that the station will spontaneously crash before the connection completes. In that case, "mostly" reliable is as reliable as it gets. ;-} +--------------- | (Yes, I know that group management is then delegated to the session | management :-) | ian +--------------- Not really. There is *no* group management in the "mostly reliable" mode. Stations can join and drop out of a connection, while getting reliability "as good as they like" during the time that they're joined. Maybe the following [admittedly loose anthropomorphic] analogy will help: When you first arrive at a cocktail party, you aren't a member of, say, "that conversation over there", and no-one pays any attention to whether you are hearing or missing what's being said. But if you like, you can walk over and stand within hearing range. Still, you have done nothing overt to "join" the conversation. But now it is possible for you to send negative-ACKs ["excuse me? what did you say?"] to cause retransmission. Provided the speaker is willing to back up often and far enough for you [his "retransmission buffers" are large enough] and your ACK traffic does not exceed what is considered good taste, you can get reliability "as good as you like". Yet all you have to do to leave the conversation is walk away and cease sending NACKs. Again, no overt group membership protocol was utilized. In fact, the only effect on the conversation may be, especially if you were slow or hard of hearing, that the average data rate goes up somewhat after you leave as the RTT or congestion estimators adapt to the new set of listeners [i.e., minus you]. (Of course, if you had a good receiver [ears], a high input processing rate, and a bit of patience, you may never have had to send a NACK -- someone else may have always beat you to it. I mentioned this in a previous message about XTP's "damping" and "slotting" of ACKs.) Anyway, the "cocktail party" analogy is intended to indicate why the "mostly reliable" mode of multicast might have some domains of applicabililty. In fact, this is the mode in which most of the known XTP multicast users are operating. -Rob p.s. There is an XTP TAB sub-group activity on group management stuff to support "fully reliable" XTP multicast, but it looks to me like a longer-term standards activity... ----- Rob Warnock, MS-9U/510 rpw3@sgi.com rpw3@pei.com Silicon Graphics, Inc. (415)335-1673 Protocol Engines, Inc. 2011 N. Shoreline Blvd. Mountain View, CA 94039-7311