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