Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utcs!mnetor!seismo!brl-adm!caip!nike!ucbcad!ucbvax!A.ISI.EDU!CERF
From: CERF@A.ISI.EDU.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Re: RING vs. ETHER - Theory and practice.
Message-ID: <[A.ISI.EDU]20-Jul-86.23:30:12.CERF>
Date: Sun, 20-Jul-86 23:30:00 EDT
Article-I.D.: <[A.ISI.EDU]20-Jul-86.23:30:12.CERF>
Posted: Sun Jul 20 23:30:00 1986
Date-Received: Mon, 21-Jul-86 07:42:19 EDT
References: <12224206784.24.JNC@XX.LCS.MIT.EDU>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 11
Approved: tcp-ip@sri-nic.arpa

Noel,

Please elaborate on "single ACK" problem. As you know, TCP ACKS are at least
"inclusive" so that subsequent ACK can make up for one lost, if more data
is sent and received. This isn't perfect, of course, since "inclusive" ACK 
doesn't help if data was lost at the receiver. Perhaps you are thinking about
ACKs which cover data received past data lost (selective ACKS)? We looked at
this several times but the complexity of the mechanism did not seem to
buy enough to justify it.

Vint