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

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
16181923
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 ♦♦

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.

permanent link

answered 23 Apr '17, 10:56

Philst's gravatar image

Philst
4311616
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
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×1,620
×752
×16
×8

question asked: 22 Apr '17, 01:59

question was seen: 5,365 times

last updated: 25 Apr '17, 06:31

p​o​w​e​r​e​d by O​S​Q​A