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