Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!decvax!ucbvax!EDDIE.MIT.EDU!gds
From: gds@EDDIE.MIT.EDU.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Re: 4.2/4.3 TCP and long RTTs
Message-ID: <8612120507.AA06682@EDDIE.MIT.EDU>
Date: Fri, 12-Dec-86 00:07:53 EST
Article-I.D.: EDDIE.8612120507.AA06682
Posted: Fri Dec 12 00:07:53 1986
Date-Received: Mon, 15-Dec-86 00:36:06 EST
References: <8612090834.AA13766@ucbvax.Berkeley.EDU>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 34
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.
> 

There are some Unix applications, like the 4.2 version of telnet,
which do a close() if they get something like ETIMEDOUT, which can
occur if a TCP timer has gone off.  In the 4.2 BBN TCP/IP, the timer
going off does not cause the connection to be closed.  Instead, a
routine called advise_user lets the higher layers know about the
problem and lets them deal with it.  I was rather surprised to see
that 4.2 telnet was giving up when the actual connection was not
remotely closed.  With a quick patch to telnet to prevent it from
closing for errors when a TCP timer has gone off, you can maintain
telnet connections for hours.  The reconstitution protocols required
that connections remain open for long periods of time during network
dynamics.

I haven't looked at 4.3 telnet or TCP to see if this is fixed or
handled differently.

--gregbo