Fix cubic start bounce

[huitema]

Fix issue #1830

[huitema]

@hfstco there are 4 fixes in this PR:

1. Tighten the bound of the satellite_cubic and satellite_cubic_loss case. The maximum duration parameters were set at 10 seconds, while the actual value was much better. Reflecting the actual value helped detect a potential regression noticed in the discussion of issue Cubic needs multiple stabilization steps after Hystart #1830.

2. When exiting startup with HyStart, use path->cwin/2 instead of the full value. This is in line with the discussion in issue Cubic needs multiple stabilization steps after Hystart #1830, and avoids the succession of packet losses and window decrease observed on the traces.

3. After reducing the CWIN, enter recovery. This is logical, because we expect to experience packet losses. The window was 'just right' when the packet acknowledgment provided an RTT measurement, but it doubled between the moment this packet was sent and the moment the ack was received. We have to wait until after recovery to see signals that match the new value of CWIN.

4. Update the "ack frequency" test. It expect to observe an ACK interval of at least 1500us (in fact 1800), but we now observe an interval just above 1000us. This is 100 times the 10us RTT, probably triggered by the 1ms floor for the ACK frequency. The previous value was probably inflated due to excess delays after HyStart.

[hfstco]

Just for clarification. We are entering recovery when HyStart trigger?

[huitema]

Yes. It is logical. On one hand, we know that Hystart triggered based on the CWIN one RTT before, that the CWIN will generally have doubled, and thus that there is very high risk of observing congestion losses after that. On the other hand, we just reduced the CWIN, so these likely losses do not reflect the new state of congestion control. That's the classic reasoning behind recovery.

[hfstco]

Tighten the bound of the satellite_cubic and satellite_cubic_loss case. The maximum duration parameters were set at 10 seconds, while the actual value was much better. Reflecting the actual value helped detect a potential regression noticed in the discussion of issue #1830.

Sounds good.

When exiting startup with HyStart, use path->cwin/2 instead of the full value. This is in line with the discussion in issue #1830, and avoids the succession of packet losses and window decrease observed on the traces.

After reducing the CWIN, enter recovery. This is logical, because we expect to experience packet losses. The window was 'just right' when the packet acknowledgment provided an RTT measurement, but it doubled between the moment this packet was sent and the moment the ack was received. We have to wait until after recovery to see signals that match the new value of CWIN.

Shared my thoughts in #1830.
But in general I like these changes. Let's see if HyStart++ does better.

[huitema]

You are correct about Hystart++. I did not want to mix two issues in one PR, but there is definitely a risk of exiting the slow start too soon due to some transient condition. And then Cubic takes a long time to ramp up and recover.