Now MIT-MULTICS is constrainted to not send packets greater then 200
bytes (because if it does, the IMP it is plugged into crashes... a problem
(unresolved now for over two years) with message mode HDH support in
the IMP). So chances are now that CISL is sending you 572 byte packets
which are being fragmented by MIT-MULTICS. It is quite possible that
either your reassembly code is bad or MIT-MULTICS's fragmentation code
is bad (MIT-MULTICS's TCP arranges never to send segments that would
be fragmented by the IP layer). Some IP tracing would probably help.
-Jeff
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