Start sending out packets as soon as we receive ACKs making congestion_window - bytes_in_flight > 1MSS

[mb]

We don't utilize the full congestion window even with all patches applied. What I see is that we do have phases:

• one where we receive ACKs, but don't send out packets
• and one where we send out packets.
  Ideally we want to start sending out packets with the first ACK that we arrive and get into a state where we.
  The same pattern still holds true in congestion avoidance.

Currently not sure how important it is. Will take another look after implementing RACK. It might also be a Necko issue instead of a neqo. Would move to bugzilla in that case.

[martinthomson]

This really smells like an issue in the driver code. Or even just down to timer resolution (the peaks are about 16ms apart).

This code doesn’t really decide what it is going to be doing. It is possible that we hit a point where the driver is stuck either reading or writing for an extended period. I can’t say why that would happen, but we might have a structural issue there.

This is probably unavoidable with our solution for pacing (or lack thereof) in the driver. We might perform better if we can enable GSO or equivalent; that would allow things to proceed in parallel in essence. The change we might need in that case is to allow us to receive packets after having scheduled packets for sending in the “future”.