Allow congestion window to grow even when the window is not completely full and determine window utilization in on_packet_sent

[WesleyRosenblum]

Issue: #458

To address the congestion window growing too slowly (as detailed in #458), this change introduces two improvements:

1. The definition of "under-utilized" is more lenient in the slow start phase, where as long as half the congestion window is being used, the window is allowed to grow. In the congestion avoidance state, as long there is less than 3 * MTU of window available, the window is allowed to grow.
2. The determination of "under-utilized" is made in on_packet_sent instead of on_packet_ack, and is stored in the congestion controller itself. This allows for a burst of acks to grow the window, even if the application is not able to send data during the processing of those acks.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[WesleyRosenblum]

Thought of another approach: Check is_congestion_window_under_utilized() in the on_packet_sent method and store the result on the CubicCongestionController. This value would then be checked in on_packet_ack. Since the change from under_utilized to utilized occurs before the congestion controller prevents sending, I believe this would work, since as long as the application is able to send data, under_utilized should flip to false and on_packet_ack would be allowed to grow the window.

Here is a Gist containing this approach: https://gist.github.com/WesleyRosenblum/6e74c9944e3e27405d047bdf669e62c2

Edit: I've gone ahead and committed this approach. The difference between this approach and the previous RTT based approach can be seen here

[camshaft]

Just a minor thing: it might be best to pin the reference to a commit just in case the line gets shifted:

https://source.chromium.org/chromium/chromium/src/+/master:net/third_party/quiche/src/quic/core/congestion_control/tcp_cubic_sender_bytes.cc;l=23;drc=f803516d2656ed829e54b2e819731763ca6cf4d9

[camshaft]

I'm not sure this actually affects the results but wouldn't it just be the RTT (without / 2)? Like if i send a packet and get an ack back that would be 1 RTT.

[WesleyRosenblum]

Ah yep

[camshaft]

This is much better!