R. Benjamin Kessler wrote: > > You could be experiencing the "long, fat network" (LFN) problem.
Could be a long, fat network problem, if this is indeed a long network (or long-delay network). To learn more about LFNs and the TCP window scale option for use on LFNs, see RFC 1323. The issue is that the largest window size you can have with TCP is 65 KBytes since the Window size field is only 2 bytes. The window scale extension expands the definition of the TCP window to 32 bits and then uses a scale factor to carry this 32-bit value in the 16-bit Window field of the TCP header The scale factor is carried in a new TCP option, Window Scale. This option is sent only in a SYN segment (a segment with the SYN bit on), hence the window scale is fixed in each direction when a connection is opened. Lately, I have actually seen devices using this scale extension, so I think it is supported on modern operating systems. It's more likely that it's not an LFN-related issue, though. It's more likely that the TCP window size isn't set to its possible max (65 Kbytes) even without window scaling. To start with, he should max it out to 65 Kbytes and not worry about the scaling factor, which could cause problems if not supported on all hosts. Benjamin and MADMAN gave good answers, but I have a few more comments below. This is a good chance to learn about capacity versus throughput. See below.... > > How far apart are these locations? (average round-trip time > with ping?) > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:nobody@;groupstudy.com] On > Behalf Of > Kim Seng > Sent: Thursday, October 31, 2002 11:57 AM > To: [EMAIL PROTECTED] > Subject: Question on ATM OC-3 WAN connection and TcpWindowSize > [7:56612] > > Hi all, > > I have an OC-3 155Mbps UBR WAN link between two sites. > When I transfer files between these two sites using > windows explorer or ftp, I only have about 8Mbps. You still have 155 Mbps. That's your capacity, in other words, the capability for sending bits at a certain rate. Your output interface could send bits that fast, if the host applications gave it bits that quickly. Throughput is not the same thing as capacity. Capacity is the capability. Throughput is a measurement of the actual amount of data transferred in a certain amount of time. Network protocols packetize data. They don't whip out bits at the rate specified by the capacity. The following items affect throughput: * Packet size. Bigger packets result in higher throughput for bulk transfers. HTTP tends to not use a full size packet. FTP usually does. * Inter-packet gap. There's time between packets when no data is sent. * Turn around time at the client and server to process data and send the next request for more data. The CPU speeds of the clients and servers affect this, as do many other factors. * Hard disk access time. Depending on the application, no data will be sent while the client or server read/write from the hard drive, a mechanical device that can contribute heavily to throughput. * The amount of memory on the clients and servers can affect throughput. At what point does the application have to write to disk to free up RAM to receive more data? * Protocol behavior. Is it a request/response (ping/pong) protocol? Does it require an ACK per packet or does it support windowing? * Error rates. Are packets getting dropped and needing to be retransmitted? > Sprint told me I need to change the registry: > TcpWindowSize to get better throughput. Have anyone > experienced this before? That would help TCP applications. Think about how TCP works. Each side specifies a window size. The other side can output numerous packets to fill that window, without stopping and waiting for an ACK. When it fills the window, it must stop and wait for an ACK. It's this stopping when your throughput is 0 bps that causes your throughput for the entire file/data transfer to be low. If the host has a big window size, the other side can send and send and send, without stopping as much. _______________________________ Priscilla Oppenheimer www.troubleshootingnetworks.com www.priscilla.com > > Thanks in advance. > > Kim. > > __________________________________________________ > Do you Yahoo!? > HotJobs - Search new jobs daily now > http://hotjobs.yahoo.com/ > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=56620&t=56614 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
