Gary Kaiser About the Author

Gary is a Subject Matter Expert in Network Performance Analytics at Dynatrace, responsible for DC RUM’s technical marketing programs. He is a co-inventor of multiple performance analysis features, and continues to champion the value of network performance analytics. He is the author of Network Application Performance Analysis (WalrusInk, 2014).

Understanding Application Performance on the Network – Part VII: TCP Window Size

In Part VI, we dove into the Nagle algorithm – perhaps (or hopefully) something you’ll never see. In Part VII, we get back to “pure” network and TCP roots as we examine how the TCP receive window interacts with WAN links.

TCP Window Size

Each node participating in a TCP connection advertises its available buffer space using the TCP window size field. This value identifies the maximum amount of data a sender can transmit without receiving a window update via a TCP acknowledgement; in other words, this is the maximum number of “bytes in flight” – bytes that have been sent, are traversing the network, but remain unacknowledged. Once the sender has reached this limit and exhausted the receive window, the sender must stop and wait for a window update.

TCP Window Size: The sender transmits a full window, then waits for window updates before continuing. As these window updates arrive, the sender advances the window and may transmit more data.

The sender transmits a full window, then waits for window updates before continuing. As these window updates arrive, the sender advances the window and may transmit more data.

Long Fat Networks

High-speed, high-latency networks, sometimes referred to as Long Fat Networks (LFNs), can carry a lot of data. On these networks, small receive window sizes can limit throughput to a fraction of the available bandwidth. These two factors – bandwidth and latency – combine to influence the potential impact of a given TCP window size. LFNs networks make it possible – common, even – for a sender to transmit very fast (high bandwidth) an entire TCP window’s worth of data, having then to wait until the packets reach the distant remote site (high latency) so that acknowledgements can be returned, informing the sender of successful data delivery and available receive buffer space.

The math (and physics) concepts are straightforward. As the network speed increases, data can be clocked out onto the network medium more quickly; the bits are literally closer together. As latency increases, these bits take longer to traverse the network from sender to receiver. As a result, more bits can fit on the wire. As LFNs become more common, exhausting a receiver’s TCP window becomes increasingly problematic for some types of applications.

Bandwidth Delay Product

The Bandwidth Delay Product (BDP) is a simple formula used to calculate the maximum amount of data that can exist on the network (referred to as bits or bytes in flight) based on a link’s characteristics:

  • Bandwidth (bps) x RTT (seconds) = bits in flight
  • Divide the result by 8 for bytes in flight

If the BDP (in bytes) for a given network link exceeds the value of a session’s TCP window, then the TCP session will not be able to use all of the available bandwidth; instead, throughput will be limited by the receive window (assuming no other constraints, of course).

The BDP can also be used to calculate the maximum throughput (“bandwidth”) of a TCP connection given a fixed receive window size:

  • Bandwidth = (window size *8)/RTT

In the not-too-distant past, the TCP window had a maximum value of 65535 bytes. While today’s TCP implementations now generally include a TCP window scaling option that allows for negotiated window sizes to reach 1GB, many factors limit its practical utility. For example, firewalls, load balancers and server configurations may purposely disable the feature. So the reality is that we often still need to pay attention to the TCP window size when considering the performance of applications that transfer large amounts of data, particularly on enterprise LFNs.

As an example, consider a company with offices in New York and San Francisco; they need to replicate a large database each night, and have secured a 20Mbps network connection with 85 milliseconds of round-trip delay. Our BDP calculation tell us that the BDP is 212,500 (20,000,000 x .085 /8); in other words, a single TCP connection would require a 212KB window in order to take advantage of all of the bandwidth. The BDP calculation also tell us that the configured TCP window size of 65535 will permit approximately 6Mbps throughput (65535*8/.085), less than 1/3 of the link’s capacity.

A link’s BDP and a receiver’s TCP window size are two factors that help us to identify the potential throughput of an operation. The remaining factor is the operation itself, specifically the size of individual request or reply flows. Only flows that exceed the receiver’s TCP window size will benefit from, or be impacted by, these TCP window size constraints. Two common scenarios help illustrate this. Let’s say a user needs to transfer a 1GB file:

  • Using FTP (in stream mode) will cause the entire file to be sent in a single flow; this operation could be severely limited by the receive window.
  • Using SMB (at least older versions of the protocol) will cause the file to be sent in many smaller write commands, as SMB used to limit write messages to under 64KB; this operation would not be able to take advantage of a TCP receive window of greater than 64K. (Instead, the operation would more likely be limited by application turns and link latency; we discuss chattiness in Part VIII.)

Transaction Trace Illustration

To evaluate a trace for this window size constraint, use the Time Plot view. For Series 1, graph the sender’s payload in transit (i.e., bytes in flight); for Series 2, graph the receiver’s advertised TCP window, using a single y axis scale for reference. If the payload in transit reaches (or closely approaches) the receive window size, then it is likely that an increase in the window size will allow for improved throughput.

TCP Window Size: This Time Plot view shows the sender's TCP Payload in Transit (blue) reaching the receiver's advertised TCP window (brown); the window size is limiting throughput.

This Time Plot view shows the sender’s TCP Payload in Transit (blue) reaching the receiver’s advertised TCP window (brown); the window size is limiting throughput.

The Bounce Diagram can also be used to illustrate the impact of a TCP window constraint, emphasizing the impact of latency on data delivery and subsequent TCP acknowledgements.

TCP Window Size: Illustration of a TCP window constraint; each cluster of blue frames represents a complete window's worth of payload, and the sender must then wait for window updates.

Illustration of a TCP window constraint; each cluster of blue frames represents a complete window’s worth of payload, and the sender must then wait for window updates.

Note that the TCP window scaling option is negotiated in the TCP three-way handshake as the connection is set up; without these SYN/SYN/ACK handshake packets in the trace file, there is no way of knowing whether window scaling is active, or more accurately, what the scaling value might be. (Hint: if you observe window sizes in a trace file that appear abnormally small – such as 500 bytes – then it is likely that window scaling is active; you may not know the actual window size, but it will be greater than 64KB.)

Corrective actions

For a TCP window constraint on a LFN, assuming adequate available bandwidth, primary solution options focus on increasing the receiver’s TCP window or enabling TCP window scaling. Reducing latency – which in turn reduces the BDP – will allow greater throughput for a given TCP window; relocating a server or optimizing path selection are examples of how this reduction in latency might be accomplished.

Is TCP window scaling enabled for your key applications – especially those that serve users over LFNs? Are your file transfers and replications performing in harmony with the network they traverse?

In Part VIII, the final entry in this series, we’ll talk about application chattiness – the more common app turns kind, but also a behavior I call application windowing. Stay tuned and feel free to comment below.

About The Author
Gary Kaiser
Gary Kaiser Gary is a Subject Matter Expert in Network Performance Analytics at Dynatrace, responsible for DC RUM’s technical marketing programs. He is a co-inventor of multiple performance analysis features, and continues to champion the value of network performance analytics. He is the author of Network Application Performance Analysis (WalrusInk, 2014).


  1. Nick Fiekowsky says:

    Optimal real world TCP window size can be far larger than bandwidth-delay product (BDP) – latency doesn’t end at the RJ-45. We had a 20 Mb/sec MPLS link between Japan and US east coast with 192 msec RTT. BDP would be just under 512 KBytes. Optimal sustained throughput achieved when receiving host advertised 2.7 MByte receive window.

    Back in WIndows XP & NetWare era we discovered that TCP tuning for larger window size significantly reduced boot time for a PC one flight up from the data center.

    Unless you’re running iPerf, additional latency stems from time taken for:
    – Application on the receiving host to be dispatched by OS
    – Time for receiving application to move data from receive buffer to disk or screen
    – Time for sending application to be dispatched by OS when send buffer empties
    – Time for sending application to marshall data to move into send buffer

    We found that larger TCP windowsize can measurably reduce host processing time while shrinking transfer time.

  2. Gary Kaiser says:

    Hi Nick,
    Thanks for your comment, and sharing your experience; often, theory and experience conflict, in which case the latter wins out.
    I like your point that latency may not end at the RJ-45; often, we (meaning I) usually abstract the definition of end-to-end delay, even incorrectly referring to it as “NIC-to-NIC.” I think a better definition – pertinent to this discussion, at least – would be “TCP stack to TCP stack.”
    If we think about the BDP and a large TCP flow, then we really are concerned with the timings of TCP ACKs; application-specific delays at the sender (which I’ve previously referred to as “starved for data” conditions) and at the receiver (which reduce the advertised TCP window size due to delays reading from the buffer) shouldn’t affect the calculation itself. But – especially on the systems you mention – the TCP stacks themselves could be OS-bound (since they would run entirely in the OS), delaying the acknowledgement of data by the receiver and/or reading the window update at the sender. So the net effect would be a delay value (for the BDP) that could be significantly greater than the physical NIC-to-NIC RTT.
    Having said that, I struggled for a while trying to explain the faster user-perceived performance. A slow app is a slow app; increasing the receive buffer can allow the data to traverse the network faster (shrinking transfer time), but if the app were slow, delays reading the data from the buffer would still remain. What if the TCP stack were slow (delaying the ACKs and increasing the BDP), and the app fast? Then the theory would seem to match the experience.
    But I defer to the real world….

    • Nick Fiekowsky says:

      Hello Gary,

      My view is that big TCP buffers provide slack that allows many components to operate in efficient “stream” mode most of the time rather than “start and stop.”

      – The disk drive can stream big chunks of data into the transmitting app since there’s a big TCP buffer ready to catch the bytes.

      – The transmitting TCP stack has a big pile of bytes on hand to sustain a max speed stream, avoiding pauses and subsequent slow start.

      – The receiving TCP stack has lots of buffer space to hold the arriving bytes, likely eliminating window freezes.

      – The receiving application stays active for long stretches since it can work through MBytes of data at a time.

      – The receiving application can feed long streams of data to its storage. The writing disk head thus stays in one track, or quickly moves to an adjacent tracks, for rapid data storage.

      Confirming experience – some years back my ancient single-core, small-memory laptop with mild TCP tuning could outperform a colleague’s shiny new dual-core, 4 GByte memory laptop in downloads. My colleague didn’t believe it at first, but disk defragmentation made the difference. I regularly defragmented my hard drive, his had never been defragmented. His laptop outperformed mine once the disk was adequately defragmented.

      Conclusion – the network is one component of an end-to-end system. Poor tuning can cripple end-to-end performance, good tuning helps. Strong network tuning allows other components to deliver their best performance, too.

  3. Hello Gary, could you please advise some for following problem:

    we have slaw bitrate link with B=32 kbps (this is power line carrier communiction) RTT is app. 200 ms. TCP WINDOW is 800 bytes, IEC 60870-5-104 ctransmit data with very small payload – 46 bytes. It means that in one TCP WINDOW we have 17 packets.

    Are there some ways how to reduce amount of ACKs, because it is bad to wait all of 17 ACKs before new send…
    Is it possible to use Nagle algorithm for collection of all ACKs in one packet?

    ALso could you please clarify, I find some articles where after receive few TCP-segments receiver send ACK only for last one with the maximal number. Is it possible to use such approach for example for TCP_DELAY mode. Wait for 500 ms and send ACK only for one segment?

    Best regards,


  4. Gary Kaiser says:

    Hi Anton,

    If your interest is to improve data transfer throughput, then it would appear that TCP is tuned quite well to your environment. The BDP = 32000*0.200 = 6400 bits in flight; divide by 8 = 800 bytes in flight. This is the maximum carrying capacity of the network, so in theory, a TCP window size of 800 bytes (or greater) would allow the link to be fully utilized.
    As the ACKs for earlier packets are received, the sender should be able to stream more data – without waiting until the ACKs are received for the remaining data; however, this is true only if the application is streaming data. The behavior you describe – send a block of data in 17 packets, then wait until all of these packets have been acknowledged, then send the next block of data – would appear to be what I call application windowing. In this case, the application (or perhaps the power line protocol you are using) is ensuring that each block of data has been successfully received before sending the next block.
    I discuss this behavior in more detail in Part VII of this blog series –
    Hope this helps you narrow down the issue.

  5. HI
    Which is the optimal value for TCP Window size for 1Gbps NIC and 600ms RTT?

  6. Hi,
    Plugging your numbers into the formula, we get (1,000,000,000 x .6)/8, or 7,500,000; 7.5MB. But the formula requires the minimum (limiting) bandwidth between the client and server, which may be significantly different than your 1Gbps NIC speed. Also, remember that the formula describes the optimum TCP window size for a network path, and assumes the application is capable of filling the pipe with large network writes.

  7. Should we calculate Latency based on what the perceived average is or what we see for the high end? Or top 10%, 20% etc. We have a 20Mbps link between sites but I’m only getting around 5Mbps max on large file transfer tests, our latency bounces from 50-70ms. Even at the top end I should be seeing over 7Meg, although I can’t be 100% positive the link is totally quiet when I’m running my tests. Don’t have solarwinds or ptrg set up to monitor yet but I can test when when there are no users and it’s the same.

  8. Gary Kaiser Gary Kaiser says:

    The calculation is intended to identify the “ideal” TCP window size, one which would allow a TCP session to use all of the bandwidth – in the absence of other traffic. So the latency value should be the minimum, measured on an idle link.
    For your 20Mbps link, a latency variance of 20 milliseconds is pretty significant; on a simple queued link, there would need to be at least 30 or more packets queued to add this delay, indicating quite high utilization. There may also be other reasons for the variance; packet shaping or QoS policies, or a poorly performing firewall are examples.
    Such congestion will of course reduce the throughput in your file transfer tests; you may be luck to achieve the 5 – 7 Mbps.

  9. I see it differently – turn it up to 11! I would define very large maximum windowsize for the following reasons:

    1. We’re looking to deliver a robust business solution, not answer an exam question.

    2. The business wants to see maximum throughput rain or shine – low latency or high. Might as well configure to deliver.

    3. For sustained maximum throughput, use the TCP buffers to compensate for latency in the network and also in the devices at both ends.

    4. Modern TCP stacks use auto-tuning so TCP buffers are only as big as necessary. Large TCP windows do not waste resource as they would have 15 years ago.

    An extreme real-world example: Bandwidth-Delay product was 500 KBytes for a trans-Pacific connection. WindowSize was nearly 2.5 MByte to get full throughput. What makes the business more effective – data trickling through with the textbook solution or optimum throughput?

  10. Gary Kaiser Gary Kaiser says:

    Hi Nick,
    Thanks for your comments; you’re points are well-taken.
    I interpreted the question a little differently; given an existing production environment, why is throughput lower than expected? The Bandwidth Delay calculation can help determine if the TCP window may be the problem – or if it makes more sense to look elsewhere. There remain many environments where TCP window scaling can’t be applied – due to server configuration, firewalls, load balancers, etc., leaving us with the 65535 byte limit. For the example above (20Mbps, 70ms), a 65535 byte window would limit throughput to about 7Mbps, which to some degree matches the casual observation. Understanding the constraint allows for confidence in choosing a solution, which may not be simple to implement.
    But as modern networks more frequently permit window scaling, your approach will become the only correct answer; thanks again.

  11. Gary,

    Your point is also valid – reviewing actual network traffic is first step in performance improvement. Many factors can make traffic slow, the packets show you the facts.

    On the other hand, too many people apply bandwidth-delay calculation and prematurely conclude TCP tuning is complete.

    Two wrongs don’t make a right, but two rights make a better answer.

  12. Igor Livshin says:

    Hi Gary,

    For a long time I am trying to find a way that would allow me to monitor socket’s backlog queue (seing how many requests stay there waiting for a WebContainer thread becomes available). Any suggestion what abject a dynaTrace sensor should monitor to get this info?

    Appreciate your help.


    • Hi Igor
      Dynatrace provides a JMX based monitoring inteface. Your Web Container most likely exposed this metric via JMX – so – dynatrace can simply pick it up. By default dynatrace automatically captures total number of handles for your JVM/CLR process – that obviously includes more than jjust socket handles – but – it also is a good health indicator.
      Let me know if you need to know more. Also – feel free to post questions like this on our community portal where we have a dynatrace open Q&A forum to discuss these sorts of product related questions

      • Igor Livshin says:

        Hi Andreas,

        Thanks for your response

        I need to set monitoring for the IBM JVM’s inbound socket for the container transport. That is the point where requests arrive to be processed bt JVM. Specifically I need to monitor the socket’s backlog queue. When a request arrives to the socket to be processed by JVM, if there is no free thread available, it will be placed in the socket’s backlog queue. If this happens frequently and many requests are placed in the queue this is an indication of the system being overloaded.

        Can this be done? This all is the inner area of JVM native processing and I do’t now the method/backlog queue to be monitored.

        Can this be done?

        Appreciate your advice

        Igor Livshin

        • Hi Igor
          I am pretty sure this can be done as I assume there is a JMX Metric for that. I am however not an expert when it comes to the internals of the IBM JVM. I would therefore I suggest to post a similar question on an IBM related forum to figure out what the JMX Metric is called. You can also ask it on the dynatrace community forum as there might be other dynatrace users that have solved that problem already

          • Igor Livshin says:

            The problem is that dynaTrace does not instrument WebSphere code and what is available in JMS Metric is not applicable.

  13. Hi Gary,

    I am working in a lab, and testing TCP performance with delays. We are using NetBSD code, and TCP performance is getting dropped with increasing delays. I don’t see anything wrong with the window advertisement, window is increasing based on the delay.

    One thing, I obseved is that, if I am disabling the congestion window, I am seeing a bit improvemnt in the perfomance, because congestion avoidance alogorithm is limiting the congestion window.

    Can you suggest me any other thing to find where the bottleneck is?

    Thanks and Regards,

  14. Nick Fiekowsky says:

    Hello Kiran,

    Your problem may reflect a sub-optimal TCP congestion/fast start algorithm. TCP stacks use different algorithms to determine how quickly to ramp up transmission rate, and how much to reduce transmission rate in the face of packet loss.

    For example, Microsoft Windows Vista / Server 2008 and later allow the Admin to specify “CongestionProvider”. Changing from default to “CTCP” improves sustained throughput in high latency / high bandwidth situations such as yours. Linux provides similar choices. Some years ago, “NewReno” had a good reputation.

    Also, if in Linux, try specifying a larger Default TCP send & receive windowsize. Changing that value to 64 KBytes from typical default of 8 KBytes or 16 KBytes, for example, could reduce time needed to ramp up to wire speed.

    Thank you,

    Nick Fiekowsky

  15. Hi
    Which is the optimal value bandwidth for 64kB tcp window size and 5ms RTT?
    Best regards

  16. Gary Kaiser Gary Kaiser says:

    The formula would be this:
    Window size * 8 / RTT
    So 65535 * 8 / 0.005, or about 100Mbps
    What this means in practical terms is that a single TCP connection with a window size of 65535 should be able to realize about 100Mbps throughput – given, of course, no other bottlenecks. Or maybe this interpretation: if throughput is less than 100Mbps, then there is a performance constraint unrelated to TCP window size.

    • jaehong says:

      Thanks to the answers
      I work in South Korea
      Your website is very helpful
      I would like to continue to help.

  17. Quentin Gurney says:

    Being a bit of a math geek I’ve been reading these articles and thinking that you could build a spreadsheet with values for each of the parameters discussed and build a model of what expected response time might be given the factors. A simple model of course would just give a single answer and I don’t care for that for a lot of reasons. I think you could use a mean and standard deviation for each parameter and then do some Monte Carlo simulation to provide statistical ranges of outcomes and use that to set confidence intervals. I’m going this direction because I think that would be an excellent tool to predict performance of Software as a Service (SaaS) type applications prior to deploying them. You could gather some simple data like circuit speed, number of users, number of transactions generated by each user, screen size (data contents), ping times, etc. Some of the means/standard deviations could be set initially to some range of “normal”, and then adjusted to fit measurements if necessary. Maybe someone has already done all the hard work and has a web based calculator or a spreadsheet already done. Are there any tools like that?

    • Nick Fiekowsky says:

      Hello Quentin,

      I’ve done the math many times, however the result is useful only for bandwidth testing apps that generate random data to fill buffers, then discard the data when it is received. And then only if the test servers at each end are lightly loaded.

      The bad news: Latency is rife in IT implementations. Disk delays; latency to get the data from disk to processor; latency for VM manager to start up a server when data arrives; latency for the OS to dispatch the application… Fixing TCP buffer size “by the book” guarantees your solution will not be able to fully utilize available bandwidth.

      The good news: Nearly all modern Operating Systems have TCP auto-tuning so they will use the appropriate amount of buffer. Modern servers nearly all have generous memory configurations, so can spare a few MBytes for TCP buffers.

      This is one of the few areas where appropriate configuration can make up for delays elsewhere.

  18. Mathias Nussbaum says:

    Hi !!!
    I want to calculate my Receive Window Size or RWIN but i couldn’t know my LATENCY. Since i’v researched around and they use CMD ping and i tried this but it shows different of Average = 247ms or something higher or lower.
    Q: Is and are there the best way to find exact LATENCY?


  19. Gary Kaiser Gary Kaiser says:

    Hi Mathias,
    Ping is certainly the most common approach. If you take enough ping samples, you could start to assume that at least one of the RTT measurements represents the minimum latency; in other words, the ping with the fastest time was probably not delayed by queuing at a router hop. Accuracy increases with larger samples, a quieter network, and fewer hops. Ping has a bad reputation since many routers will treat ICMP packets with a low priority, delaying forwarding the packet until other work has been completed. There are a number of TCP-based utilities that don’t have this same consideration; for example, But precision is likely not critical. Take the minimum ping delay and calculate the ideal receive window size; any forwarding delay caused by queuing or router processing will simply add a little extra receive buffer space in your calculation. And remember that the calculation is designed to identify a theoretical window size that would allow a single TCP connection to utilize all of the limiting bandwidth; other background traffic will limit throughput to something less.

  20. Allaite Sanchez says:

    We seem to be impacted by tcp windows size. We have a pc running windows 7 writing/reading from a network attached storage device. All devices are 10gig connected to the network. Latency is below 1ms (all in data center) and we cannot get the transfer rate expected when reading. TCP windows does not seem to be scale. Staying at 128k and therefore limiting the throughput. This sound logical looking at the formula, latency is too small.
    As we increase latency, the transfer rate increases considerably. Any suggestions for a workaround? Looks like our great infrastructure is not worthwhile.

    We are wrting from the W7 pc a 10gig files with about 900MB/s transfer and only can reach about 400MB/s when reading.

    I appreciate your ideas

    • Gary Kaiser says:

      Hi Allaite,
      The write throughput seems to match the BDP limitation; therefore, increasing the window size should improve throughput – or at least expose the next bottleneck. The read throughput seems to be throttled by some other factor, as its value is closer to the expected throughput with a 65K receive window.
      Are you using SMB to write and read the file? It could be that the read and write block sizes are limited by SMB rather than the TCP window; if you can examine a trace file, look at the read and write sizes. For example, the read block size might be 64K (not uncommon), meaning you’d never reach the TCP window limit. The write block size might be significantly larger, at which point you’d then run into the 128K receive window limit. If there’s a possibility to compare with FTP throughput this could also provide additional clues.
      If it is possible to share a trace file – ideally, one that includes the initial TCP connection setup – I’d be happy to take a closer look.

  21. Hi gents,

    I am facing the problem with Linux kernel.osrelease = 2.6.32-431.el6.x86_64.
    I want to increase RWIN and CWND (number of bytes in flight) i.e. congestion window. So far, server is always advertising RWIN=393216 (window size value=96, scaling factor 2^12=4096). We tried with different algorithms, increasing net.core.r(w)mem_default, net.ipv4.tcp_r(w)mem,…. Auto tuning is ON. CWND is not going above 550 KBytes even remote side advertises 2 MBytes. I understand it is TCP behavior, not to overflow the network, but wondering if there is way that will guarantee congestion avoidance will start only after RWIN is full. Almost all TCP parameters are defaul and normally we shouldn’t face this problem.

    Feedback is really appreciated.


  22. Gary Kaiser Gary Kaiser says:

    Hi Dragan,
    I’m sorry but I don’t have any experience at this configuration level. I simply have one question – what is the bandwidth delay product? It seems like the system tuning overrides your attempts at manual configuration.

  23. Hi Gary,

    Thanks for feedback. This might be the case, I believe as well. The main problem that we are testing with another server from different provider using the same mobile access network. That server is providing higher CWIN, this is why I think there is something to be tweaked in configuration.


  24. Hi Gary,

    thanks for the article!
    One question, you don’t seem to consider packet loss. Is that negligible, or should we add the overhead of lost packets having to be retransmitted?
    Thanks in advance,

    • Gary Kaiser Gary Kaiser says:

      Hi Peter,
      Thanks for your comment. Packet loss can have a significant impact, reducing the sender’s congestion window and limiting throughput well below the BDP. There’s a discussion about packet loss in Part IV of this blog series; you can backtrack using the links at the beginning of each blog post. Alternatively, you can find the slightly more comprehensive eBook on Amazon titled Network Application Performance Analysis.

  25. Hey Peter,

    A debt of gratitude is in order for your remark. Parcel misfortune can have a critical effect, decreasing the sender’s blockage window and constraining throughput well underneath the BDP. There’s a dialog about bundle misfortune in Part IV of this online journal arrangement; you can backtrack utilizing the connections toward the start of every blog entry. On the other hand, you can discover the somewhat more complete eBook on Amazon titled Network Application Performance Analysis.

  26. Cong BIAN says:

    Hello Gary,

    Thanks for these articles. That explain the details of TCP transfer. I’m actually working for an ISP. We provide Point to Point links by using VLAN.

    We are facing serveral times a TCP file transfert problem by iperf. The client test the link by iperf by launching a large file transfer. The link bandwidth is 100M, and the latency is about 10ms. So it is not a LFN.

    We observed always the speed of transfer is about 70Mbps to 80Mbps, we surgest that is causing by the congestion control and the TCP window. But at the time we ask the client to configure the transfer speed by blocking at the server to 100M, we can get almost 100Mbps transfer.

    May you please help us to find it is which part (congestion or window size) that the speed is limited at 70Mbps? And what tuning should I do to get the 100M please?

    Thank you in advance.


  27. You have a typo in the calculation of the ideal window size in your example: “BDP is 212,500 (20,000,000 x .085 *8)” — that should be divided by 8 rather than multiplied by 8. Your answer is correct, though.

  28. Hello Gary,

    thanks for the post. From the RFC, a TCP sender can only send min(cwnd, rwnd)

    So, if I am not wring even the large advertised receiver windows size, does not matter if the cwnd is smaller than 64KBytes.

    Maybe can you share your thoughts on this in relation to the congestion window?

    Thanks in advance!

  29. Gary Kaiser Gary Kaiser says:

    Hi Tilak,
    If you are never writing more than the receive window (rwnd), you will not encounter a receive window constraint on throughput. The congestion window (cwnd) is dynamic, controlled by the sending node. It may start small (typically 2 packets), and increase until one of two conditions is met:
    1. It reaches the rwnd value. Since you’re never writing this much data, this will not happen.
    2. Congestion is detected by evidence of a dropped packet. Of course you have no control over this, as it is managed by the sending TCP stack.
    So the cwnd throughput constraint for these small writes would occur only during slow start at the beginning of a new connection, or if congestion is detected.
    If you own the network, and you have high-bandwidth links, it may make sense to configure an aggressive slow start algorithm – essentially a larger initial congestion window (CWD). The default cwnd of 2 packets can require 7 or 8 round-trips to reach maximum throughput for a write size of 64KB. If you’re opening and closing a lot of TCP connections, this could make a difference. On the other hand, if you are using long-lived persistent TCP connections, it probably isn’t worth the effort.

Speak Your Mind


Do the math so we know you are human *