Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!columbia!rutgers!ames!ucbcad!UCBVAX.BERKELEY.EDU!karels%okeeffe
From: karels%okeeffe@UCBVAX.BERKELEY.EDU (Mike Karels)
Newsgroups: mod.protocols.tcp-ip
Subject: Re: 4.2/4.3 TCP and long RTTs
Message-ID: <8612081815.AA09027@okeeffe.Berkeley.EDU>
Date: Mon, 8-Dec-86 13:15:31 EST
Article-I.D.: okeeffe.8612081815.AA09027
Posted: Mon Dec  8 13:15:31 1986
Date-Received: Tue, 9-Dec-86 06:19:08 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 17
Approved: tcp-ip@sri-nic.arpa

Bob,
The timeout for TCP on 4.2/3 is rather longer than 30 sec.
The actual time depends on the round-trip time, as the limit
is on the number of retransmissions.  On 4.3, the timeout
is at least 108 sec. with short RTT's.  The limit on 4.2
was nearer 45 sec.  As Van Jacobson says in his message,
the keepalive time will have to be adjusted for long RTT's
as well, but I doubt that Craig is using the keepalive timer.

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.

		Mike