tcp: Fix TcpWestwood bandwidth estimation

This issue is a follow-up of issue #531 (closed).

Tasks

• Fix TcpWestwood bandwidth estimation
• Create a test suite for TcpWestwood

Bandwidth estimation

Currently, TCP Westwood estimates the bandwidth after an ACK is received. However, @tomhenderson reported the following:

"Section 3.1 implies that Westwood should wait for all dupacks to be processed before calculating a new ssthresh. The current code does not make this easy since PktsAcked is called incrementally. What I have in mind is to possibly use m_bwEstimateEvent also for the Westwood case, and ensure that estimate BW is not called too frequently. For instance, if PktsAcked is called and m_bwEstimateEvent is not running, schedule EstimateBW for some very small amount of processing delay such as 10 us in the future. If m_bwEstimateEvent is running, do nothing."

Test suite

TCP Westwood requires a test suite to validate its behavior. @tomhenderson suggested the following:

"For Westwood, I would lean on tracing and checking EstimatedBW and Ssthresh at key time points, such as just before a loss event, and immediately after a loss event. Tests that explicitly check the pseudocode conditions in section 2.3 and 3.1 would be important. Also, a check that the virtual null sample in Section 2.2 is being inserted when needed. Finally, tests to reproduce the figures of the paper would be useful."

References

The westwood paper is here: https://www.researchgate.net/publication/220926747_TCP_Westwood_Bandwidth_Estimation_for_Enhanced_Transport_over_Wireless_Links