Try wifi-shadow-rtt

[huitema]

This is an attempt to mitigate issue #1481.

An annoying side effect of "wifi-spikes" (in fact, wi-fi suspensions) is that the congestion window soon becomes exhausted, causing the stack to stop the "prepare packets" callbacks. The proposal adds a "shadow rtt" API, that could be used to tell BBR to allocated CWIN credits for at least that duration.

[huitema]

This is probably not ready for merging yet. Let's first get report of field trials with actual wi-fi networks.

[huitema]

I am thinking about this some more. There are a few open issues. For example, BBR reevaluates the data rate at the end of each "epoch", understood as "one RTT", but this is not well defined during error conditions. It could be:

• time based: use the RTT measured at the beginning of the epoch to limit the epoch's duration.
• packet based: receipt of an ACK for any packet sent after the beginning of the epoch. This is arguably better than time-based, because it adapts to changing RTT, queues, etc. In our case, it would only trigger after the end of the outage.
• packet based, with loss tracking: end epoch if any packet sent after the beginning of the epoch being declared lost.

I tried changing this in the implementation before, but it is one of those subtle changes with cascading effects, with some test cases improving and other worsening. Maybe we need to reconsider that if the "shadow RTT" is set, so the epoch only ends if either a packet is acked, or if a timer that includes the shadow RTT elapses. But then, that probably also requires including the shadow RTT in the management of repeat timers.

Before we do any of that, it would be good to get some practical results.