[e2e] Are Packet Trains / Packet Bursts a Problem in TCP?
detlef.bosau at web.de
Tue Oct 3 07:06:17 PDT 2006
John Heffner wrote:
> 2) Compressed acks
> 3) Big writes or reads (i.e., big window updates) from inherently
> bursty applications. An example would be a filesystem-limited
> transfer, where you have frequently have to to stall a few ms for disk
> seeks. A CPU-bound application on a time-slicing system would be
> another example.
Please correct me if I´m wrong and I thought about it a few days now,
but doesn´t this put the whole ACK clocking principle in question?
If we have greedy sources, anything is fine. Ideally there is one packet
taken from the network and one packet sent to the network every certain
period of time.
But if a sender spends large periods of time to gather the information
which is to be sent, e.g. it seeks for files or does database requests
to answer requests to an SAP system placed by some WWW interface, it
"spares up" ACKs for future use - and may send a more or less large
burst of data when the information becomes available.
I see two possible problems here:
1.: Depending on CWND the burst may become large.
2.: Particularly when the sender has to wait, say, several seconds for
the information to become available (again I refer to a database
request), it is not clear whether the capacity indicated by CWND and /
or the amount "of spared ACKs" (which indicate the amount of data taken
from the network) is still available. When a sender is suspended for a
certain time and thus does not occupy path capacity, competing flows
will continue probing and thus occupy the unused capacity.
Perhaps these problems are not disjoint: If the sender takes some time
for information gathering, the line runs out of data and the whole
"available" path capacity is available for the next burst of data.
It´s a provocative question and perhaps it was answered dozens of time,
but is the ACK clocking approach feasible
for "inherent bursty applications"? Or is it well suited for greedy
flows with non bursty applications but in other scenarios it may run
And I´m not even sure whether this could be solved by pacing, as pacing
implicetely assumes a certain rate to be available for a flow. But what
happens if a flow did not send anything for a while and the path
capacity is occupied by competing flows then?
Which rate is appropriate for the flow when it continues sending?
More information about the end2end-interest