10/28/03: The default for numPkts_ was changed from 3 to 1, as a quick fix to the bug reported in the 12/17/02 entry below.
12/19/02: Corrected behavior with data-limited applications, so that TFRC doesn't have to wait for a timer to expire to send a new packet. Also, make a correction so that when the timer expires because no packets had been sent by the sender, the allowed sending rate is not reduced below two packets per RTT. The validation test for these changes is "./test-all-quiescent".
12/17/02: After introducing numPkts_ to Agent/TFRCSink (see entry below), the default was changed from 1 to 3. This resulted in a serious problem, in that with numPkts_ set to 3, and with frequent packet drops, it is possible for TFRC to completely ignore loss events. This bug was not discovered until 10/28/03, after reports from Wing-kai Lin. At that time the default for numPkts_ was changed from 3 to 1, pending a better solution to the bug.
12/17/02: Adding numPkts_ to Agent/TFRCSink, to set the number of non-sequential data packets before a missing packet is counted as a loss. The default is set to 1, which gives no change in performance for TFRC.
3/2/02: Added hooks for applications with intermittent demand. Examples are in "./test-all-quiescent".
1/19/01: Added ECN capability.
8/9/00: Although our paper states that the sending rate is never allowed to be more than twice the receiving rate in the previous round-trip time, this was not fully implemented. Added the parameter "maxHeavyRounds_" to specify the number of rounds for which the sending rate is allowed to be more than twice the receiving rate. By default, "maxHeavyRounds_" is currently set to 1. If it were set to 0, then the sending rate would never be allowed to be more than twice the previous receiving rate.
7/24/00: A bug fix for the initialization of the loss interval array at the receiver after the first drop. The validation test is in "./test-all-friendly printLosses".
5/12/00: The bug fix for the initial slow-start itself had a bug that could result in TFRC being locked out if the first few packets of the flow were dropped. This has been fixed by changing the slow-start behavior, and by again changing the value for the initial rate to a value that more closely conforms to the initial behavior of TCP. This is illustrated in the following tests: "./test-all-friendly twoDrops", "./test-all-friendly manyDrops".
4/10/00: The performance problem of overly-aggressive behavior with very low data rates has been fixed on April 10 by changing the value for the initial rate. This is illustrated in the following test: "./test-all-friendly slow".