How to Monitor Cwnd and Ssthresh Values for a Tcp Connection

How to monitor cwnd and ssthresh values for a TCP connection?

I disagree with the answer given by Nemo. Wireshark (as well as dumpcap, tcpdump) are not capable of measuring/logging the cwnd and the ssthresh, as those are not field in the tcp datagrams but are only values that reside inside the kernel as kernel structures. Congestion control data is not transmitted over the wire, only flow control data is.

To monitor those values, either implement get_info and sample the data periodically, or take a look at the tcp_probe kernel module (see: http://www.linuxfoundation.org/collaborate/workgroups/networking/tcptesting)

UPDATE: I've created a patched version of the tcp_probe module that can be used for monitoring the cwnd and ssthread, see https://github.com/Dynalon/tcp_probe_fixed

Get cwnd of my TCP connection from a program

It turned out getsockopt() is able to return the same tcp_info when called with TCP_INFO option:

  tcp_info tcpi = {};
  socklen_t len = sizeof(tcp_info);
  getsockopt(tcp_socket, SOL_TCP, TCP_INFO, &tcpi, &len);
  tcpi.tcpi_snd_cwnd;  // <-- CWND

How to find out on Windows what ssthresh and cwnd it has computed for the connection

You can do that in Windows, but you have to program it yourself. Have a look at this: http://msdn.microsoft.com/en-us/library/windows/desktop/bb485738%28v=vs.85%29.aspx

The GetPerTcpConnectionEStats function (available since Vista) can get you all kinds of info, like cwnd, ssthresh, dupack's, rtt's, sack's and much more about TCPv4 connections. Use GetPerTcp6ConnectionEStats for TCPv6.

Edit: The SDK has a utility that can show you this information. Here it is in c:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\tcpanalyzer.exe. I think it's the Platform SDK from Microsoft ( http://www.microsoft.com/en-us/download/details.aspx?id=8279 ).

TCP versions and AIMD

What you've said is correct, let me reexplain it with details:

Slow Start

Any TCP congestion control algorithm starts from congestion window size cwnd = 1 MSS (Maximum Segment Size as congestion window size is scaled by bytes) then it starts an additive increase according to the number of received acknowledgements until it reaches the slow start threshold value ssthresh that's the intial advertised window size.

So, let's suppose ssthresh = 8. TCP starts sending the first segment according to cwnd = 1 if an acknowledgement is received cwnd is additively increased by the number of acknowledgements received according to the formula cwnd = cwnd + MSS (this means that the congestion window size is increased by 1 segment).

when cwnd >= ssthresh then each time an ACK is received, increment cwnd as follows: cwnd = cwnd + MSS(MSS/ cwnd) (don't forget that cwnd is in bytes). So cwnd is increased by one segment (=MSS bytes) only if all segments have been acknowledged, e.g.:

let's suppose last cwnd was 8.

cwnd = 8 + 1 * ( 1 / 8) and this is repeated 8 times (because all segments have been acknowledged). So after adding 1 / 8 to cwnd 8 times, the result is 1 MSS added to the last known cwnd which is 8 i.e. new cwnd is 9.

Slow Start Algorithm

If cwnd < ssthresh then
    Each time an Ack is received:
    cwnd = cwnd + MSS
else /* cwnd >= ssthresh */
    Each time an Ack is received :
    cwnd = cwnd + MSS. MSS / cwnd
endif

Response to Congestion

There is 2 ways to detect loss:

1. TCP retransmission timer has a timeout
2. Receipt of duplicate ACK

TCP Reno

• Case 1: Timer Timeout

  Reno drops to cwnd to 1 then reinitialize a slow start with ssthresh = last_cwnd / 2.

• Case 2: 3 Duplicate Acknowledgemnts
  Reno do:

  1. sshresh = cwnd /2
  2. cwnd = cwnd / 2
  3. Enters Fast Retransmission state: retransmits the missing packet that was signaled by three duplicate ACKs, and waits for an acknowledgment of the entire transmit window before returning to congestion avoidance.

TCP Tahoe

For both cases, Tahoe always drops cwnd to 1 then reinitialize a slow start with ssthresh = last_cwnd / 2.

Could you therefore identify whether a TCP version was Tahoe or Reno
from the sawtooth?

TCP congestion algorithms are always implement in the OS level. Windows and Linux implements the following algorithms (according to this paper):

Would it be correct to state that Tahoe does not do AIMD?

Tahoe only implements Additive Increase and doesn't implement Multiplicative Decrease. Reno implements them both.

---

Related Topics