Report actual send window as well?

[he32]

Hi,

I wonder ... would it be interesting to report the actual send window in use, i.e. the
one the receiver announces to the sender? The problem is that the default display
on platforms doing TCP_INFO is quite wide, so there's no room for an additional coloumn,
within 80 characters, ref.

[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  6]   0.00-1.00   sec  3.46 MBytes  29.0 Mbits/sec    0    512 KBytes       
[  6]   1.00-2.01   sec  3.38 MBytes  28.2 Mbits/sec    0    512 KBytes       
[  6]   2.01-3.00   sec  3.44 MBytes  29.0 Mbits/sec    0    512 KBytes       
[  6]   3.00-4.00   sec  3.46 MBytes  29.0 Mbits/sec    0    512 KBytes       

I have some possibly hackish changes which changes this into

[ ID] Interval        Transfer  Bandwidth   Retr  Cwnd      Swnd
[  6]   0.00-1.00   s  3.45 MB  28.9 Mb/s    0    512 KB   32.5 KB   
[  6]   1.00-2.00   s  3.44 MB  28.8 Mb/s    0    512 KB   31.1 KB   
[  6]   2.00-3.00   s  3.46 MB  29.1 Mb/s    0    512 KB   32.5 KB   
[  6]   3.00-4.00   s  3.45 MB  28.9 Mb/s    0    512 KB   31.1 KB   

(and here we can see that it's the receiver's window which is limiting the performance.)

If someone wants take a peek, I can create a branch in my forked repository and commit
the change there for inspection.

Regards,

Håvard

[bltierney]

check and see if this is in the JSON output. If so, that should be good enough, as not that many folks will need this.

[bmah888]

We don't seem to have this in JSON, and I think this is probably the right place to put that information.

Just so I understand, the variable we're talking about is tcpi_rcv_space in struct tcp_info?

[he32]

We don't seem to have this in JSON, and I think this is probably the right place to put that information. Just so I understand, the variable we're talking about is `tcpi_rcv_space` in `struct tcp_info`?

My diff uses `tcpi_snd_wnd` from `struct tcp_info`, and since the Linux API apparently expresses this in number of segments, you need to multiply by `tcpi_snd_mss` to get the window in bytes. The NetBSD kernel does ``` /* Linux API wants these in # of segments, apparently */ ti->tcpi_snd_cwnd = tp->snd_cwnd / tp->t_segsz; ti->tcpi_snd_wnd = tp->snd_wnd / tp->t_segsz; ``` I can put together the change I have for this in a pull request so that it's easier to discuss and apply. Regards, - Håvard

[hoang-tranviet]

Looks like there is no explicit snd_wnd in Linux, but it can be infered as the min(cwnd, rcv_space).
So, is it better to report tcpi_rcv_space instead, which anyway give more information?

[he32]

Really? I would have thought that rcv_space has nothing to do with the actual opening of the send window, which is specifically what this is trying to monitor.

[bltierney]

perfSONAR project would like this in the JSON as well.

[bmah888]

@bltierney and I discussed this issue at some length yesterday. Out of that discussion came several things (I think):

1. We'd really like to add new output variables in the JSON only. The human-readable output is pretty cluttered already, and if we add a number or two from this issue, there are probably other things that could justifiably be added as well.

2. We still need to get some clarity about what quantity or quantities we're trying to get at here. Right now we print tcpi_snd_cwnd, which is the sender's congestion window. We don't have the receiver's window advertisement (@he32 you called this the "actual send window")...that's what @hoang-tranviet mentioned above as being tcpi_rcv_space. The sender can only send data if permitted by its congestion window and if the receiver has enough buffer space. So I would agree with @hoang-tranviet that these are probably the most meaningful values to record (assuming that they're expressed in the appropriate units).

3. It's OK to not support this on every platform, but if we try to get this additional quantity (or quantities) we need to try to do it accurately (see my comment about units above).

4. Related to that is that we have a generic request to get "some" other parts of TCP_INFO in issue Additional TCP_INFO items #99.