Keeping An Ey e On Those Branch Office Routers By Bill Alderson and J. Scott Haugdahl   Q: As we deploy remote routers to support our branch offices, we are getting reports that file transfers from our headquarter's Windows NT servers take "forever." Actually, the transfer times are anywhere from several seconds to several minutes, depending on the amount of data. Some sites have full T1 bandwidth service, and all the local segments are Ethernet. We hope our problem doesn't reside in the frame relay cloud we have chosen as our WAN transport. Scott: Yup, your problem is frame relay. Dump it and get leased lines. End of column. Bill: No fooling! Scott: I guess our readers won't take a short column v ery seriously, so let's try another approach. Bill: For starters, a simple calculation of throughput at a remote site showed average throughput to be a whopping 4 KB per second or about 32 Kbps. Assuming for the moment that latency in the frame relay cloud could be the culprit, what ingredients would we need for maximum throughput? Scott: Cold weather and low pressure? Bill: It's actually more along the lines of the application layer asking for big chunks of data and the underlying transport layer implementing a sliding window or packet burst protocol to fulfill the request. Scott: In this case, a Windows95 workstation was using the Server Message Block (SMB) application-layer protocol over NetBIOS on top of IPX to communicate with the NT server at HQ. Bill: So much for our key ingredients. Scott: Even though our application was asking for reasonably sized chunks of file data (10 KB per SMB "Read B lock Raw" request), NetBIOS was breaking this into a set of datagrams for the IPX layer. Bill: So there's no transport layer, per se, doing sliding window or packet burst. Scott: One option would be to move to NetBIOS over TCP/IP. Bill: Rumor had it that even TCP/IP users were experiencing slow file transfers, and we really wanted to find out what was wrong with the situation. Scott: Not only that, but the remote site we picked for analysis was in the same city as HQ, and round-trip latency was less then 10 milliseconds. Bill: A packet trace gave us our first clue. Scott: Our trace showed that throughput from reading a file from the NT server at headquarters was capable of peaking at nearly 1 Mbps, despite the overall 32-Kbps average noted earlier. Bill: 1 Mbps is still short of T1 speeds, but it's orders of magnitude better than 32 Kbps. So, either there was a heck of a lot of contention for network resources or contention for the NT server, or...

The Networkologist by Patricia Schnaidt FreeWire by Bill Frezza Corporate View by Brian Walsh In The Middle by Bruce Robertson Updated March 25, 1997