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

TCP features for congestion window (cwnd)

0

Which among the following features are very important (critical ones) for estimating a TCP congestion window (cwnd) from a passive trace?

   [_id]
  ,[_timestamp]
  ,[parent_ip]
  ,[tcp_srcport]
  ,[tcp_dstport]
  ,[tcp_port]
  ,[tcp_stream]
  ,[tcp_len]
  ,[tcp_seq]
  ,[tcp_hdr_len]
  ,[tcp_window_size_value]
  ,[tcp_window_size]
  ,[tcp_ack]
  ,[tcp_window_size_scalefactor]
  ,[tcp_nxtseq]
 ,[tcp_analysis_bytes_in_flight]
 ,[tcp_analysis_lost_segment]
 ,[tcp_analysis_out_of_order]
 ,[tcp_analysis_retransmission]
 ,[tcp_analysis_rto]
 ,[tcp_analysis_rto_frame]
 ,[tcp_analysis_zero_window_probe]
,tcp_flags (ack, psh, fin, syn, res, cwr,...etc) 
,tcp_time_stamps

asked 22 Apr '17, 01:59

armodes's gravatar image

armodes
16●18●19●23
accept rate: 0%

edited 22 Apr '17, 02:15

You can only guess it. But Bytes_in_flight and window_size can be used for this guessing.

(22 Apr '17, 02:22) Christian_R

But the tcp_window_size is pretty consistent. It doesn't vary much. For example: in my case i have around 300,000 capture packets the window size varies only 2 times (it starts with 29312 and stays pretty the same and then changes to 30336 at the end).

(22 Apr '17, 02:54) armodes
1

Yes, but there is still no way to determine cwnd from a trace. You can guess what it is, but it's not possible to get a 100% correct value from packets. It all depends on what the sending stacks thinks about the situation, and that's not in the packets.

(23 Apr '17, 09:15) Jasper ♦♦

One Answer:

2

Bytes in Flight is probably the best estimate. It tells us what the sender has actually decided to transmit.

The receiver's advertised "Receive Window" is the maximum that a sender can ever have in flight. It is usually fairly consistent - unless the receiving application gets into trouble.

The sender's "Transmit Window" must be equal or less than the Receive Window. In congestion avoidance mode, the transmit window (bytes in flight) will be sender's CWND.

Note that Wireshark has an outstanding "bug" in that it doesn't include data in its count if the packets weren't in the trace.

answered 23 Apr '17, 10:56

Philst's gravatar image

Philst
431●1●6●16
accept rate: 27%

I also thought of that but the problem is since bytes_in_flgiht is a calculated value from tcpdump (or wireshark) - i mean not part of the TCP header, how can we derive its relation with the cwnd? I am joining the passive trace from the monitor to a TCP kernel state of the sender where we get the value of the cwnd that have the same sequence number.

tcp_seq=1256867582, tcp_nxt_seq=1256869030, tcp_len=1448, tcp_window_size=29312, tcp_bytes_in_flight=11622, cwnd=16

Is there anyway to derive (or estimate sort to say) the value of the congestion window (cwnd=16) from the bytes_in_flight or the sequence number? I am so confused. The receiver window size is constant for all packets.

(25 Apr '17, 06:30) armodes