Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!columbia!rutgers!ames!ucbcad!ucbvax!HARVARD.HARVARD.EDU!walsh From: walsh@HARVARD.HARVARD.EDU (Bob Walsh) Newsgroups: mod.protocols.tcp-ip Subject: Re: 4.2/4.3 TCP and long RTTs Message-ID: <8612090834.AA13766@ucbvax.Berkeley.EDU> Date: Mon, 8-Dec-86 13:32:44 EST Article-I.D.: ucbvax.8612090834.AA13766 Posted: Mon Dec 8 13:32:44 1986 Date-Received: Tue, 9-Dec-86 10:57:56 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 23 Approved: tcp-ip@sri-nic.arpa Mike, How can the TCP "just" inform the application about the problem? Unless there's a control channel to the application that allows the passage of status data, a send call must return an error. After that error, the application can't tell how much of the data, if any, was transmitted. "Reliable byte stream with possible gaps in case of error" isn't very satisfying. Informing the application that the networking system is having trouble getting acknowledgements does not mean that the networking system has given up on sending that data. My intent was to point out that such a decision should be left up to the application, which may in turn defer the decision to the user. This was one of the qualities of the BBN TCP/IP software, as you know. It is one of the reasons Bob Gilligan used the BBN software for his demos. Whether it is 30, 45 or 108 seconds doesn't matter. What does matter is that Craig is preserving the RDP connection for a longer time under such circumstances and therefore is less likely to see the connection fail. There is also the point of extended acknowledgements. Bob Walsh