westwood擁塞控制仿真

 The congestion window adjust rule of westwood is[1]:
$w \leftarrow\begin{cases} w+\frac{1}{w} & \text{When an ack is received} \\ w-(w-B\cdot rtt_{min})& \text{When packet loss happens} \end{cases}\tag{1}$
 The expected increment of the congestion window cwnd per update step is then:
$\Delta w=\frac{1-p}{w}-(w-B\cdot rtt_{min})\cdot p \tag{2}$
 The time between update steps is $\Delta t=\frac{rtt}{w}$.
 Accoding to [2], the diffential equation of TCP throughput ($x=\frac{w}{rtt}$) is :
$\dot x=\frac{x}{rtt}\{I\cdot(1-p)-D\cdot p\}$
 For westwood, $I=\frac{1}{w}$, $D=w-B\cdot rtt_{min}$.
$\dot x=\frac{1-p}{rtt^2}+p\cdot x\cdot\frac{B\cdot rtt_{min}}{rtt}-p\cdot x^2 \tag{3}$
  Let $\dot x=0$, $x^{westwood}=\frac{B\cdot rtt_{min}}{2\cdot rtt}+\sqrt{(\frac{B\cdot rtt_{min}}{2\cdot rtt})^2+\frac{1-p}{p\cdot rtt^2}}$.
  By assuming $B\approx x$, with equation (3), we could:
$x=\frac{1}{\sqrt{rtt\times(rtt-rt_{min})}}\times\sqrt{\frac{1-p}{p}}$
 The performance of westwood is tested on ns3 platform. But the implementation of westwood [3] in ns3 has some bug. The logic to estimate bandwidth for each received ack is not right,since the current implmentation will get $\frac{m\_ackedSegments}{rtt}$.
Some interval is needed to trigger bandwidth estimation. It is easy to correct such error, please refer to the code in linux [4].

void
TcpWestwood::PktsAcked (Ptr<TcpSocketState> tcb, uint32_t packetsAcked,
                        const Time& rtt)
{
  NS_LOG_FUNCTION (this << tcb << packetsAcked << rtt);

  if (rtt.IsZero ())
    {
      NS_LOG_WARN ("RTT measured is zero!");
      return;
    }

  m_ackedSegments += packetsAcked;

  if (m_pType == TcpWestwood::WESTWOOD)
    {
      EstimateBW (rtt, tcb);
    }
  else if (m_pType == TcpWestwood::WESTWOODPLUS)
    {
      if (!(rtt.IsZero () || m_IsCount))
        {
          m_IsCount = true;
          m_bwEstimateEvent.Cancel ();
          m_bwEstimateEvent = Simulator::Schedule (rtt, &TcpWestwood::EstimateBW,
                                                   this, rtt, tcb);
        }
    }
}

void
TcpWestwood::EstimateBW (const Time &rtt, Ptr<TcpSocketState> tcb)
{
  NS_LOG_FUNCTION (this);

  NS_ASSERT (!rtt.IsZero ());

  m_currentBW = m_ackedSegments * tcb->m_segmentSize / rtt.GetSeconds ();

  if (m_pType == TcpWestwood::WESTWOODPLUS)
    {
      m_IsCount = false;
    }

  m_ackedSegments = 0;
  NS_LOG_LOGIC ("Estimated BW: " << m_currentBW);

  // Filter the BW sample

  double alpha = 0.9;

  if (m_fType == TcpWestwood::NONE)
    {
    }
  else if (m_fType == TcpWestwood::TUSTIN)
    {
      double sample_bwe = m_currentBW;
      m_currentBW = (alpha * m_lastBW) + ((1 - alpha) * ((sample_bwe + m_lastSampleBW) / 2));
      m_lastSampleBW = sample_bwe;
      m_lastBW = m_currentBW;
    }

  NS_LOG_LOGIC ("Estimated BW after filtering: " << m_currentBW);
}

 And I implement my own version on ns3, the code is public available [4].
 A point to point channel (3Mbps, 100ms one way delay, 300ms queue delay) is built. Three flows are involved in experiment.

When all flows takes westwood for rate control

 All flows enter the netowork at the same time.
 sending rate dynamic:

 Received rate dynamic (calculated every 5 seconds):

  One way transmission delay:

 All flows enter the netowork at different time.
 Received rate dynamic:

Sharing link with other protocols

 When flow1 takes westwood for rate control while flow2 and flow3 take reno as rate control.
 Received rate dynamic:

 Due to the fat buffer in link, Reno flow gain higher throughput.
 Another test, flow3 take cubic as rate control.
 Received rate dynamic:

 Reduce the link buffer to be 3Mbps*200ms. flow3 take cubic as rate control.
 Received rate dynamic:

[1] Mathematical analysis of Westwood+ TCP congestion control
[2] AIMD吞吐量公式的推導
[3] westwood in ns3
[4] westwood in linux
[5] 更加精確的TCP Westwood擁塞控制算法