In Part V, we discussed processing delays caused by "slow" client and server
nodes. In Part VI, we'll discuss the Nagle algorithm, a behavior that can
have a devastating impact on performance and, in many ways, appear to be a
Common TCP ACK Timing
Beyond being important for (reasonably) accurate packet flow diagrams,
understanding "normal" TCP ACK timing can help in the effective diagnosis of
certain types of performance problems. These include those introduced by the
Nagle algorithm, which we will discuss here, and application windowing, to be
discussed in Part VII.
A slightly simplified but useful rule of thumb is as follows:
A receiving node will:
Acknowledge every second packet immediately Acknowledge a single packet if
the Delayed ACK timer expires before a second packet arrives
The Delayed ACK timer typically defaults to 200 milliseconds, at le... (more)
We know that losing packets is not a good thing; retransmissions cause
delays. We also know that TCP ensures reliable data delivery, masking the
impact of packet loss. So why are some applications seemingly unaffected by
the same packet loss rate that seems to cripple others? From a performance
analysis perspective, how do you understand the relevance of packet loss and
avoid chasing red herrings?
In Part II, we examined two closely related constraints - bandwidth and
congestion. In Part III, we discussed TCP slow-start and introduced the
Congestion Window (CWD). In Part IV, we'... (more)
As a network professional, one of your newer roles is likely troubleshooting
poor application performance. For most of us, our jobs have advanced beyond
network "health," towards sharing - if not owning - responsibility for
application delivery. There are many reasons for this more justifiable than
the adage that the network is first to be blamed for performance problems.
(Your application and system peers feel they are first to be blamed as well.)
Two related influencing trends come to mind:
Increased globalization, coupled with (in fact facilitated by) inexpensive
bandwidth me... (more)
In Part II, we discussed performance constraints caused by both bandwidth and
congestion. Purposely omitted was a discussion about packet loss - which is
often an inevitable result of heavy network congestion. I'll use this blog
entry on TCP slow-start to introduce the Congestion Window (CWD), which is
fundamental for Part IV's in-depth review of Packet Loss.
TCP uses a slow-start algorithm as it tries to understand the characteristics
(bandwidth, latency, congestion) of the path supporting a new TCP connection.
In most cases, TCP has no inherent understanding of th... (more)
In Part IV, we wrapped up our discussions on bandwidth, congestion and packet
loss. In Part V, we examine the four types of processing delays visible on
the network, using the request/reply paradigm we outlined in Part I.
Server Processing (Between Flows)
From the network's perspective, we allocate the time period between the end
of a request flow and the beginning of the corresponding reply flow to server
processing. Generally speaking, the server doesn't begin processing a request
until it has received the entire flow, i.e., the last packet in the request
message; similarly, th... (more)