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

----------