Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!decvax!ucbvax!hplb.CSNET!rhc From: rhc@hplb.CSNET.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: 4.2/4.3 TCP and long RTTs Message-ID: <9203.8612120921@hplb.lb.hp.co.uk> Date: Fri, 12-Dec-86 02:21:18 EST Article-I.D.: hplb.9203.8612120921 Posted: Fri Dec 12 02:21:18 1986 Date-Received: Mon, 15-Dec-86 20:14:48 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Robert ColeOrganization: The ARPA Internet Lines: 29 Approved: tcp-ip@sri-nic.arpa I would like to enforce Bobs concern at the Internet layer. As an ex-UCL person I am also concerned at the current tradeoff in TCP implementations towards LAN-specific high performance and away from Internet-general robustness. The maximum packet size on SATNET is 256 bytes. If you are sending large (>576) TCP packets then the gateway to the ARPANET will fragment, then the ARPANET/SATNET gateway will fragment each of these again. The result is a large number of fragments bursting onto SATNET, pinging off Goonhilly (Why do you have to use the busiest European earth station anyway) then each fragment tries to get back across the ARPANET. At the SATNET/ARPANET gateway we have the ARPANET flow control problem. It is quite likely that every packet sent from the host has turned into at least 4 and possibly 6 packets for the return! Have you considered your reassembly timeout! I have seen packets hang around in these gateways for 16 minutes (yes thats right MINUTES). After a little while the gateway queues will fill up and the TCP will timeout because the IP reassembly is not able to get enough fragments to build enough packets to keep the TCP happy. Now if the TCP was able to use the same IP packet number for all retransmissions then the situation will improve - and I suspect that this is where RDP is winning! Just because the TCP connection is failing does not mean that the TCP layer is the only one that is broken. Happy satellites, Robert.