Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!decvax!ucbvax!ICARUS.RIACS.EDU!leiner From: leiner@ICARUS.RIACS.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Analyzing Acknowledgement Strategies Message-ID: <8612241909.AA20672@phun.riacs.edu> Date: Wed, 24-Dec-86 19:44:06 EST Article-I.D.: phun.8612241909.AA20672 Posted: Wed Dec 24 19:44:06 1986 Date-Received: Wed, 24-Dec-86 22:35:28 EST References: <8612241603.AA05839@icarus.riacs.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 18 Approved: tcp-ip@sri-nic.arpa Craig, Of course. This is basically the same as ARQ on a noisy channel, and there has been considerable analysis of such things. Also, comparisons with forward error correction. The thing that makes it difficult in the case of packet networks is the uncertainty on both the error characteristics (which can be handled via adaptive error detection/correction techniques) and delay. The latter is what makes the packet network ARQ problem different than the link error problem. On a link, the delay is pretty much constant, and so you know how long to wait for a time-out. In a packet network of the sort we typically deal with, that delay is statistical and must be dealt with as such (estimated, tracked, use maximum, etc.) Barry ----------