TCP Westwood and Westwood+ Implementation

TCP Westwood and Westwood+ Implementation

Westwood and Westwood+ employ the AIAD (Additive Increase/Adaptive Decrease) congestion control paradigm.  When a congestion episode happens, instead of halving the cwnd, these protocols try to estimate the network's bandwidth and use the estimated value to adjust the cwnd.  While Westwood performs the bandwidth sampling every ACK reception, Westwood+ samples the bandwidth every RTT.

Both Westwood and Westwood+ are implemented in the same class that is inherited from the base TcpSocketBase class similar to other exisiting TCP variants.  The protocol type is made an EnumValue and can be accessed using the global variable m_pType.  The two main methods in the implementation are CountAck() and EstimateBW(). The CountAck() method calculates the number of segments acknowledged by a currently received ACK.  The EstimateBW() method estimates the bandwidth based on the value returned by CountAck() and the sampling interval.  For Westwood, the sampling interval is the time between two consecutive ACK receipts.  For Westwood+, the sampling interval is the last estimated RTT.  Under no loss, Westwood and Westwood+ behave the same as TCP Reno.  In terms of implementation, this means that the NewAck() methods in the Westwood class and the Reno class are the same.  The difference is in the DupAck() and the Retransmit() methods in which Westwood and Westwood+ use the estimated bandwidth (m_currentBW) to adjust m_cWnd and m_ssThresh. 

The implementation was validated using different scenarios and compared against the original papers [Mascolo 2001, Mascolo 2004].  Details about our testing can be found in our WNS3 2013 paper titled Tcp Westwood Protocol Implementation in ns-3.

[bpswenson, 2013-02-08 15:54:11]

Great stuff!

I had a question about countAck.  See inline.  Perhaps I'm missing something.

Can you add Westwood and WestwoodPlus tests to
src/test/ns3tcp/ns3tcp-loss-test-suite.cc?

Thanks

https://codereview.appspot.com/7227059/diff/1/src/internet/model/tcp-westwood.cc
File src/internet/model/tcp-westwood.cc (right):

https://codereview.appspot.com/7227059/diff/1/src/internet/model/tcp-westwood...
src/internet/model/tcp-westwood.cc:224: int
Does this correctly handle acks received out of order? 

For simplicity sake say the receiver sends back ACK=1 and then ACK = 2 and ACK =
1 takes the long way back home.  Won't cumul_ack be negative when 1 arrives
after 2?  Then when ACK = 3 arrives it looks like it will give it credit for 2
segments instead of 1.  I believe TCPSocketBase checks for old acks on
ReceivedAck but that isn't called until after this runs.

Perhaps I'm missing something.

https://codereview.appspot.com/7227059/diff/1/src/internet/model/tcp-westwood...
src/internet/model/tcp-westwood.cc:304: m_ssThresh = std::max
(static_cast<double>(2 * m_segmentSize), m_currentBW.Get() *
static_cast<double>(m_minRtt.GetSeconds()));
From looking at other code it looks like the standard wants a space between
<double> and (m_minRtt).

[tomh_tomh.org, 2013-02-09 02:25:07]

On 02/08/2013 07:54 AM, bpswenson@gmail.com wrote:
> Great stuff!
>
> I had a question about countAck.  See inline.  Perhaps I'm missing
> something.
>
> Can you add Westwood and WestwoodPlus tests to
> src/test/ns3tcp/ns3tcp-loss-test-suite.cc?
>
> Thanks
>

(off list)

Siddharth and Anh, could you please send Brian and me your revised 
(submitted) Westwood paper?  It will help with the review.

Thanks,
Tom

[Anh Nguyen, 2013-02-25 18:18:22]

TCP Westwood and Westwood+ Implementation

Westwood and Westwood+ employ the AIAD (Additive Increase/Adaptive Decrease)
congestion control paradigm.  When a congestion episode happens, instead of
halving the cwnd, these protocols try to estimate the network's bandwidth and
use the estimated value to adjust the cwnd.  While Westwood performs the
bandwidth sampling every ACK reception, Westwood+ samples the bandwidth every
RTT.

Both Westwood and Westwood+ are implemented in the same class that is inherited
from the base TcpSocketBase class similar to other exisiting TCP variants.  The
protocol type is made an EnumValue and can be accessed using the global variable
m_pType.  The two main methods in the implementation are CountAck() and
EstimateBW(). The CountAck() method calculates the number of segments
acknowledged by a currently received ACK.  The EstimateBW() method estimates the
bandwidth based on the value returned by CountAck() and the sampling interval. 
For Westwood, the sampling interval is the time between two consecutive ACK
receipts.  For Westwood+, the sampling interval is the last estimated RTT. 
Under no loss, Westwood and Westwood+ behave the same as TCP Reno.  In terms of
implementation, this means that the NewAck() methods in the Westwood class and
the Reno class are the same.  The difference is in the DupAck() and the
Retransmit() methods in which Westwood and Westwood+ use the estimated bandwidth
(m_currentBW) to adjust m_cWnd and m_ssThresh. 

The implementation was validated using different scenarios and compared against
the original papers [Mascolo 2001, Mascolo 2004].  Details about our testing can
be found in our WNS3 2013 paper titled Tcp Westwood Protocol Implementation in
ns-3.

[annguyen_ittc.ku.edu, 2013-02-25 18:42:09]

Hi Brian,

We are sorry for the late response.  We have been busy with some class work
and paper deadline.  We have tried to address your comments.  Please see
inline for more details.

Thank you.

Best,

Anh

On Fri, Feb 8, 2013 at 9:54 AM, <bpswenson@gmail.com> wrote:

> Great stuff!
>
> I had a question about countAck.  See inline.  Perhaps I'm missing
> something.
>
> Can you add Westwood and WestwoodPlus tests to
> src/test/ns3tcp/ns3tcp-loss-**test-suite.cc?
>

We tried to add Westwood and WestwoodPlus in that test suite.  However, we
couldn't run the test successfully.  We think it's because we don't have
.pcap files for Westwood and WestwoodPlus.  We are not sure how to obtain
such files.  Could you please give us some advice on how to get this part
done?


>
> Thanks
>
>
>
> https://codereview.appspot.**com/7227059/diff/1/src/**
>
internet/model/tcp-westwood.cc<https://codereview.appspot.com/7227059/diff/1/src/internet/model/tcp-westwood.cc>
> File src/internet/model/tcp-**westwood.cc (right):
>
> https://codereview.appspot.**com/7227059/diff/1/src/**
>
internet/model/tcp-westwood.**cc#newcode224<https://codereview.appspot.com/7227059/diff/1/src/internet/model/tcp-westwood.cc#newcode224>
> src/internet/model/tcp-**westwood.cc:224: int
> Does this correctly handle acks received out of order?
>
> For simplicity sake say the receiver sends back ACK=1 and then ACK = 2
> and ACK = 1 takes the long way back home.  Won't cumul_ack be negative
> when 1 arrives after 2?  Then when ACK = 3 arrives it looks like it will
> give it credit for 2 segments instead of 1.  I believe TCPSocketBase
> checks for old acks on ReceivedAck but that isn't called until after
> this runs.
>
> Perhaps I'm missing something.
>

You were right.  The CountAck() itself does not handle out-of-order ACKs
correctly.  To fix this, we added another if condition in
TcpWestwood::ReceivedAck() to ignore old ACKs before calling CountAck().


>
> https://codereview.appspot.**com/7227059/diff/1/src/**
>
internet/model/tcp-westwood.**cc#newcode304<https://codereview.appspot.com/7227059/diff/1/src/internet/model/tcp-westwood.cc#newcode304>
> src/internet/model/tcp-**westwood.cc:304: m_ssThresh = std::max
> (static_cast<double>(2 * m_segmentSize), m_currentBW.Get() *
> static_cast<double>(m_minRtt.**GetSeconds()));
> From looking at other code it looks like the standard wants a space
> between <double> and (m_minRtt).
>

Fixed.


>
>
https://codereview.appspot.**com/7227059/<https://codereview.appspot.com/7227...
>