Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA Path: utzoo!watmath!clyde!cbosgd!ihnp4!ucbvax!bbna.arpa!CLYNN From: CLYNN@BBNA.ARPA Newsgroups: fa.tcp-ip Subject: Re: problems getting to CISL-SERVICE-MULTICS Message-ID: <[BBNA.ARPA]30-Sep-85.09:36:43.CLYNN> Date: Mon, 30-Sep-85 09:36:00 EDT Article-I.D.: <[BBNA.ARPA]30-Sep-85.09:36:43.CLYNN> Posted: Mon Sep 30 09:36:00 1985 Date-Received: Wed, 2-Oct-85 07:39:47 EDT References:Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 37 Welcome to the world of gsteways. I have observed problems with the same symptoms. They resulted from a combination of two factors. One, you are not getting any flow control; the imps are very good at not accepting more data than they can handle. (Are you getting any ICMP Source Quench messages from the gateway? What does your TCP do with them?) Several TCPs run in bang-bang mode: sending everything they can until they either run out of data or fill the window. Going from an ethernet to an 1822 net with such an implementation is bound to flood the gateway (which has to process packets from all the TCP connections as well as any UDP traffic). The second factor which I have observed relates to fragmentation. Most fragmentation algorithms split a single packet into two or more fragments and queue them sequentially for the output interface. This increases the number of packets for a particular destination by at least a factor of two. 1822 nets have limits on the number of packets for an 1822 connection. The fragments cause this limit to be reached more quickly. Also, some receivers do not seem to be capable of receiving back-to-back packets, which frequently result from fragmented packets. Note that in such a situation no amount of TCP retransmissions will ever get the fragmented packet through. What can you do? Are the TCPs exchanging maximum segment size options? If you are not receiving any, your maximum packet size should be 576, so fragmentation should not be needed. The option works well if one of the hosts is on the network with the minimum MTU. Does TCP get information from IP about the size of the maximum IP packet received; it is a useful "hint" about the MTU of intermediate networks. Make sure that ICMP source quench messages are being processed. Consider algorithms to monitor traffic flow to give some feedback to TCP about how much data it is reasonable to have in transit at one time (when is the retransmission timer started for a given packet; hopefully not before the packet preceeding it has been acked). Think about flow control in an internet environment (maybe some students might like to work on the problem). Charlie