readme.txt

关于ns2的一些源码和资料

Documentation of TCP Fast for NS2 (version 1.1b)

Revision history

Version 1.1b, 23 June, 2005:

Based on TCP Fast for NS2 version 1.1a, the following bugs have been fixed:

1. fast_pace always incremented cwnd_ by one.
   This bug came from  acks_per_rtt  never being updated.  It is now updated
   in  fast_cc.

2. Packet loss could cause  cwnd_ <= 0
   This bug occurred if  t_seqno > tcph->seqno() in  recv(),  which occurred
   when an ACK was received beyond the end of the current transmit window.
   This can occur when an the window size has been reduced after a packet loss.
   The fix can be tested by defining  FASTTCPAGENT_DEBUG  in tcp-fast.h
   and running the script  verify-cwnd-positive.tcl  from the full archive.
   Defining  FASTTCPAGENT_DEBUG  causes a message to be printed whenever
   cwnd < 0.

Besides the fixes, the following new features have been added:

1. The "multiplicative increase" threshold is now tunable.
   In order to achive fast convergence on high bandwidth-delay product networks,
   FAST uses multiplicative increase (MI) when the observed queueing delay is
   very small.

   The new TCL variable  mi_threshold_  specifies the delay (in milliseconds)
   below which MI is used.  The default value is  0.01ms.

   Setting  mi_threshold_  to small may result in slow convergence, but
   setting it too high may result in instability.
   We recommend the heuristic of setting  mi_threshold_  less than one fifth
   of the target queueing delay  (alpha divided by the bottleneck link
   capacity in packets per second).  For example, if  alpha  is 10 packets
   each of 8000 bits and the capacity is 100Mbps, then the target queuing
   delay is 0.8ms. In this case,  mi_threshold_  should less than 0.16ms.

   The value of  mi_threshold_  can be changed during a simulation.
   This variable is tested in  simulation 6  of the full archive.

2. There is the option to update  cwnd  every other round trip time.
   This module is based on the Infocom 2004 paper,
   Cheng, Wei, Low, "Fast TCP: Motivation, Algorithm and Performance".
   That paper states that  cwnd_  is updated every other RTT. That means that
   if  cwnd_  is updated during one RTT, it is frozen in the following RTT.
   This was an experimental feature, seeking to allow stable estimates to be
   made.  However, it does not seem to be the optimal setting, and in some
   cases can cause FAST to become unstable.

   If the macro  UPDATE_CWND_EVERY_OTHER_RTT  is defined in  tcp-fast.cc
   then the behaviour of the Infocom paper is implemented.

3. Use three different ways to calculate cwnd_:
   To allow experimentation into the effect of roundoff on the FAST update
   rule, the variable  cwnd_  can be calculated in one of three different ways,
   controlled by the TCL variable  high_accuracy_cwnd_.

   If  high_accuracy_cwnd_ == 0,  then  cwnd_  is calculated using simple
   integer arithmetic.

   If  high_accuracy_cwnd_ == 1,  then  cwnd_  is calculated using integer
   arithmetic, but considering remainders.  If the  cwnd_  value calculated
   in  fast_calc_cwnd  is consistently greater than the integer value
   returned by that function, the remainders accumulate and  cwnd_  is
   eventually increased.

   If  high_accuracy_cwnd_ == 2,  then  cwnd_  is calculated using
   double precision arithmetic.  Even though the actual congestion window
   must be an integer number of packets, using fractional arithmetic in
   the calculations allows the queue occupancy to be kept closer to the target
   value.

   This new variable is tested in  simulation 7  of the full archive.
   (When interpreting the output of this simulation, note that  ns2  does
   not include the packet currently being transmitted as part of the queue.
   Thus, a single flow with  alpha=10  should yield a queue size of 9.)