[e2e] Are Packet Trains / Packet Bursts a Problem in TCP?

[Detlef Bosau]

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 
into problems?

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?