Are segments being sent full-sized, or is there perhaps some Nagle
component in it as well? I.e., are the applications using TCP_NODELAY?
I think somebody, probably Alexey, enabled sending of ACK on every 2nd
segment. Previously small segment senders playing with Nagle were
complaining every now and then about performance because two small
segments did not generate ACKs but one had to accumulate, IIRC, half MSS
worth of data before ACK was sent. Could this be related to your case?
...In case you're having too much time, you can always try bisecting it
which finds out the causing commit... :-)
Congestion control is basically ACK clocked math for cwnd, ssthresh, etc.
state, which then results in permission to send new segments out etc.
(except for RTO part of course, which I'll ignore in the next statement).
Any delay gaps to sent packet after ACK receival, which triggered the
state changing math, isn't there due to congestion control but due to
other factors! 40ms is much below MIN_RTO (200ms), so it shouldn't be due
to RTO either... Note that also delayed ACKs are exception to the general
rule.
Congestion control is controlled like your CPU is. In your CPU there's
this whatever GHz clock which determines when the state changing events
take place, state changes don't just happen arbitarily but are _clocked_
(ACK _clocked_ in case of congestion control). Of course there will be
some propagation delay after the change to put in effect all the state
changes that are result of what occurred at clock edge (and this delay
assimilating to processing delay in the context of congestion control).
--
i.
-
