This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

how can i get congestion window from traces

0

i have wireshark trace of uploading a file and i want to know congestion window at different times how can i know this??

asked 02 Dec '13, 01:07

sync2013's gravatar image

sync2013
11114
accept rate: 0%


2 Answers:

1

If you mean CWND by 'congestion window' as defined in RFC 2581, the answer to your question is: You can't 'get' that value directly from the capture file, as it is not advertized.

   CONGESTION WINDOW (cwnd):  A TCP state variable that limits the
      amount of data a TCP can send.  At any given time, a TCP MUST NOT
      send data with a sequence number higher than the sum of the
      highest acknowledged sequence number and the minimum of cwnd and
      rwnd.

To be more specific:

The CWND is just an internal variable on the sender side to manage the amount of bytes that it is allowed to send at any time. The value of CWND is calculated according to a certain algorithm (see the RFC). Basically the value is increased for every 'good' ACK (in time, not duplicate) and decreased for a 'bad' ACK (timeout, DUP ACK). So, during a TCP connection the value of CWND is somewhere between a defined start value (depends on the algorithm) and the Receiver Window Size (RWND), as advertized by the receiver. In a capture file you can see the RWND (advertized value: tcp.window_size_value, with scaling factor: tcp.window_size) but not the CWND, as it is only calculated within the senders TCP implementation.

However: You can 'estimate' the CWND at any time during a TCP connection, if you know the senders congestion algorithm and the configuration values (amount of bytes for increase/decreas), by looking at the sent frames and the received ACKs. There is no such functionality in Wireshark, but with some scripting (tshark) it should be possible to calculate the CWND, at least as an estimation.

Regards
Kurt

answered 02 Dec '13, 03:02

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

edited 02 Dec '13, 03:19

thanx i knew about this but i thought we can get estimate using sender side traces.

(02 Dec '13, 12:51) sync2013

As I said, you can estimate the CWND, by doing the calculation yourself. What you need: a pretty good insight into the TCP implementation of the sender OS.

BTW: Why do you need that value? There is not much information you can gain from it...

(02 Dec '13, 13:21) Kurt Knochner ♦

Hint: If you want to automate the CWND estimation, you could use tcptrace, which contains a module to estimate a CWND value, kind of....

http://www.tcptrace.org/manual/node10_ct.html

(02 Dec '13, 13:25) Kurt Knochner ♦

Thanks for your help. actually i was studying congestion control algorithms, mainly westwood and cubic and since both implement sender side congestion window modification for faster recovery so i thought congestion window is a good parameter to compare them.

(03 Dec '13, 11:13) sync2013

you probably know this already, but if you google for 'comparison Westwood cubic' you'll find some papers that did the comparison based on the congestion window, by reading Linux kernel values. Maybe those papers will inspire your own studies...

(03 Dec '13, 11:38) Kurt Knochner ♦

0

Having a trace at the sender I'm using the IO-Graph and draw the tcp.analysis.bytes_in_flight vs. the advertized tcp.window_size over the time. If the bytes in flight is well below the advertized, then this is dominated by the congestion window size (I assume...) alt text

answered 03 Dec '13, 10:18

mrEEde's gravatar image

mrEEde
3.9k152270
accept rate: 20%

If the bytes in flight is well below the advertized, then this is dominated by the congestion window size (I assume...)

not necessarily. bytes_in_flight are un-ACKed bytes for Wireshark. So, if bytes_in_flight is below the advertized window size, it can also mean that the receiver ACKed before the receive window was full.

(03 Dec '13, 10:25) Kurt Knochner ♦

advertised tcp window size is basically receive window which is generally high. however time-sequence number graph can give a better idea about congestion and how fast is the recovery. it doesn't give you numerical values to perform calculations. anyways thanx

(03 Dec '13, 11:21) sync2013