Carrying The Workload With TCP By Bill Alderson and J. Scott Hau gdahl Q: Our mission-critical application is based on online analytical processing (OLAP), designed for ad hoc data access and analysis. Our OLAP database is updated in a batch fashion, collecting data (nine files) from each of seven remote sites. We then analyze the data. One of our big problems is that we feel the initial data collection (using TCP) is taking much longer than it should, considering the amount of data we are transferring. We have lightly utilized full T1 leased-lines connecting the remote sites. Once our data is collected and analyzed by our OLAP application, response time is excellent, even when the application has to perform queries to the remote databases for additional information. Scott: Let's start by looking at the big picture. Bill: According to our client's network documentation, we saw that the workstation collecting the data resided on a Token-Ring. The Token-Ring was interfaced directly to a router that interfaced to DSU/CSUs connecting to the T1 lines that went to the remote sites. Scott: So everything looked straightforward on the user end, without too many sources of potential latency. Bill: And the remote sites are straightforward in that they consist of workstations connected to the same LAN segment as the router. The only difference is that the remote LAN segments are Ethernet. Scott: Since the T1s were leased lines that connect "directly" to the remote site and don't hop around the country, we assumed for the moment that everything was cool up to the remote site. Bill: We confirmed this by analyzing s everal ping packets, which showed a round-trip time of 10 milliseconds (ms) or less to and from the remote routers. Scott: Yet, our analysis of the OLAP application during batch file updating showed a throughput of only 220 Kbps, or approximately 28 KB per second. Bill: One of the obvious deficiencies we saw during the update was the underlying transport for the application, TCP, which was only sending a maximum of 512 bytes of TCP data in the largest packets. Scott: So, either the application was only sending data to the TCP layer 512 bytes at a time (unlikely), or the TCP maximum segment size (MSS) was only 512 bytes (more likely). Bill: Going back to the TCP connection initiation (SYN or synchronize), we saw that the data-collecting device was a Unix server that announced its MSS of 512 bytes to the remote end. Scott: Bear in mind that this is sometimes erroneously referred to as "negotiating" the MSS. TCP only announces, or tells the other side of the connection, what segment size it is capable of handling. There is no negotiation whatsoever. Bill: The remote site's TCP sent a maximum of 512 bytes back to the server collecting the OLAP data. Scott: The data was "drowning" by taking more "LAPs" then necessary.

Networkologist by Patricia Schnaidt FreeWire by Bill Fr ezza Coporate View by Robert Moskowitz In the Middle by Bruce Robertson Updated January 24, 1997