The congestion window is not a field inside the packet - it's a value
completely local on the sender side. You can't see it directly from a
network trace like you can the acknowledgement window (receive
window), which is what the "Win" value you see is. To plot its value
reliably you'd need some sort of instrumentation in the transmitting
system.
In the case of ns-3, the software is specifically controlling the size
of cwnd, and so can report its size over time accurately.
However, you can sometimes INFER the value of cwnd from a network
trace. This can be impossible or at least tricky, depending on
conditions.
You CAN plot the amount of data that the sender has in flight - the
amount of "unacknowledged" data on the network at any given time. The
sender will never transmit more unacknowledged data than the size of
its cwnd, so plotting the "unacknowledged" data can give a good
approximation of cwnd. Newer versions of Wireshark calculate this for
you automatically in the filterable field
"tcp.analysis.bytes_in_flight", and you can plot its value over time
in a number of different ways, including using the "IO Graphs" feature
in Wireshark. However, it may not accurately show you the size of
congestion window if:
- There's not much network latency and/or the source transmit slowly.
If the sending system can't transmit a full congestion window before
it starts getting ACKs back from the other side, then you'll never see
"bytes_in_flight" grow to reach cwnd (or will see it grow and reach
some limit, but that limit isn't the cwnd).
- The protocol you're looking at doesn't STREAM data - instead it's
starting and stopping a lot (that is, it transmits some data, then
stops and waits for the remote side to send back some reply or
acknowledgement at the application level, then transmits data again,
and so on). In that case you're not going to be streaming at TCP
level and not filling the congestion window, so you won't see the
source transmit to the cwnd reliably.
- If the congestion window is smaller than the acknowledgement (receive) window.
- If the network trace wasn't taken at or near the source system,
especially if there's network congestion (you'll see TCP
acknowledgements faster than the source sees them, plus if there's
congestion you may see data arrive more slowly than the sender sent
it)
- Other reasons (like if you've taken the capture on a system using
"large segment offloading" feature, and other minor things)
...But I've been able to approximate CWND from a network trace pretty
well in certain cases, so it is possible. Just potentially difficult.
-Ian
