Re: 4.2/4.3 TCP and long RTTs


Robert Cole (rhc%hplb.csnet@RELAY.CS.NET)
Fri, 12 Dec 86 9:21:18 WET


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.



This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:37:00 GMT