Most Read This Week
Understanding Application Performance on the Network | Part 2
Bandwidth and Congestion
By: Gary Kaiser
Jul. 9, 2014 07:45 AM
When we think of application performance problems that are network-related, we often immediately think of bandwidth and congestion as likely culprits; faster speeds and less traffic will solve everything, right? This is reminiscent of recent ISP wars; which is better, DSL or cable modems? Cable modem proponents touted the higher bandwidth while DSL proponents warned of the dangers of sharing the network with your potentially bandwidth-hogging neighbors. In this blog entry, we'll examine these two closely-related constraints, beginning the series of performance analyses using the framework we introduced in Part I. I'll use graphics from Compuware's application-centric protocol analyzer - Transaction Trace - as illustrations.
Bandwidth effect = [ [# bytes sent or received] x [8 bits] ]/ [Bottleneck link speed]
For example, we can calculate the bandwidth effect for an operation that sends 100KB and receives 1024KB on a 2048Kbps link:
For better precision, you should account for frame header size differences between the packet capture medium - Ethernet, likely - and the WAN link; this difference might be as much as 8 or 10 bytes per packet.
Bandwidth constraints impact only the data transfer periods within an operation - the request and reply flows. Each flow also incurs (at a minimum) additional delay due to network latency, as the first bit traverses the network from sender to receiver; TCP flow control or other factors may introduce further delays. (As an operation's chattiness increases, its sensitivity to network latency increases and the overall impact of bandwidth tends to decrease, becoming overshadowed by latency.)
Transaction Trace Illustration: Bandwidth
This FTP transfer is frequently limited by the 10Mbps available bandwidth.
Networks are generally shared resources; when there are multiple connections on a link, TCP flow control will prevent a single flow from using all of the available bandwidth as it detects and adjusts for congestion. We will evaluate the impact of congestion next, but fundamentally, the diagnosis is the same; bandwidth constrains throughput.
For a given flow, congestion initially reduces the rate of TCP slow-start's ramp by slowing increases to the sender's Congestion Window (CWD); it also adds to the delay component of the Bandwidth Delay Product (BDP), increasing the likelihood of exhausting the receiver's TCP window. (We'll discuss TCP slow-start as well as the BDP later in this series.)
As congestion becomes more severe, the queue in one of the path's routers may become full. As packets arrive exceeding the queue's storage capacity, some packets must be discarded. Routers employ various algorithms to determine which packets should be dropped, perhaps attempting to distribute congestion's impact among multiple connections, or to more significantly impact lower-priority traffic. When TCP detects these dropped packets (by a triple-duplicate ACK, for example), congestion is the assumed cause. As we will discuss in more depth in an upcoming blog entry, packet loss causes the sending TCP to reduce its Congestion Window by 50%, after which slow-start begins to ramp up again in a relatively conservative congestion avoidance phase.
For more on congestion, and for further insight, click here for the full article.
Reader Feedback: Page 1 of 1
Subscribe to the World's Most Powerful Newsletters
Today's Top Reads