warning: the freebsd monitor

Cheng's monitor uses mtx_trylock to get the lock.
So, it might miss some samples if the lock is by other pipes. In this case, the the average/max/min will be not accurate.

Now Linux has the "abc" option in 2.6.16

This option is set to "on" by default which allows the window to grow as quick as if there were no delay ack...
good feature though:)

rtt measurement in loss recovery state

when we use rtt for pacing. the rtt measurement is usually too conservative for loss recovery state.

"strange case 2" in FACK.

OK. now it's clear. Most (if not all) the NS2 implementation of scoreboard ignores DSACK, which is generated by the Sacker.

If a DSACK is generated, one SACK block is created for highest_ack_+1 (which is actually never retransmitted.)

To fix this bug, check DSACK in Scoreboard before creating a block.

paced tcp suffers from more timeout?

em... this seems to be a problem.
SACK likes the loss of an interval of packets instead of a scatter of packets even if there is a few scatter of paced packets... The loss of one burst of packets can be recovered by one SACK but the loss of 4 paced packets have to be recovered by more than two SACK...
This often leads to more timeout for paced flows.

default queue-limit for each queue is 50pkt

em... it's not unlimited by default. So, packets may be dropped in such queue if
1. the window is large.
2. the side bw is similar to the core bw

inconsistency between delsnd timer and burstsnd timer in ns2

If we turn on delsnd timer (overhead_, random overhead in tcp) and burstsnd timer in ns2 at the same time, we will probably have inconsistency.

If overhead_ is turned on, the send_much() function only sends one burst of packets when force is set to be true. If at this time the burst-timer is pending, the packet is not sent (the whole event is canceled). Even if the burst timer is off, paced tcp can only send one packet for this burst, and suffers from another delsnd timer for the next packet. But non-paced flow can send the whole burst into the network for this delsnd expiration. So, paced flows suffer cwnd*overhead_ more delay each rtt, but non-paced flow suffer only about overhead_ delay each rtt.

The intrinsic problem is that overhead should be in IP layer. But implementation of a real delsnd requires a certain amount of buffer -- this complicates the process and ns2 makes it in tcp layer (the source).

Be careful when we turn on both of these functions.

double check some results

steven's suggestion:
1. check cwnd convergence with a longer duration of the simulation (done. due to a script bug which grab cwnd_ and cwnd_cut_ into cwnd. Other results are all valid).
2. single flow to see what's the queue distribution
3. use c/n, instead of c, to recalculate the burst size.
4. measure the RTT loss rate for small flow and for large flow.