Re: TCP Advertised Window Size
On Oct 13, 10:50*am, tmoum...@gmail.com wrote:
> In the Wireshark log I have collected, the "sender" does not open it's
> window at a later stage.[/color]
Probably because it has no reason to think its window size is
affecting performance. It's probably right.
>*It's Window Size is always 5840 even though
> it has the ability to open up to 256KB. *Now, during initial TCP
> connection setup, I thought there is some kind of "negotiation" to
> determine how much data will be sent.[/color]
It's not a negotiation, except do determine if window scaling is
supported. Each side advertises a window that the other side transmits
>*For eg; if the Receiver
> advertises 65535 and the Sender advertises 5840 (but can be up to
> 256kB), then wouldn't the minimum window size used by both sides be
> 65535 ??[/color]
No. Each side will use the window size the other side advertises.
There are two windows, one in each direction.
> I have performed some tests where by changing the Receiver window size
> from 16k to 64k, I have seen an approximate 41% increase in window
I presume you mean an increase in throughput or performance of some
kind. This makes sense. The rate is limited to one window per round-
>*However, by changing the receiver window size from 64k to 128k/
> 256k/512k, the throughput improvements are negligible.[/color]
At some point, the RTT stops being the limiting factor.
>*So, I am
> trying to understand if the sender is now a bottleneck in any way ??[/color]
Why do you think there is a bottleneck? What are you seeing?
Re: TCP Advertised Window Size
> These logs were collected over a wireless network with latencies
> around 200ms on average. So, whilst there was a significant
> throughput improvement from increasing the receiver window size from
> 16k to 64k, I mistakenly assumed moving from 64k to 128k or higher
> would continue to yield additional benefits. However, that is not
> not the case.[/color]
Just to be paranoid, you do see the increase from 64K to 128K
reflected in what appears in the window scaling option and the window
field of the TCP headers yes?
> I believe we have reached a limit where unless the latency is
> reduced, no additional throughput benefits will occur from modifying
> the window sizes.[/color]
Remember that in:
Tput <= WindowEff/RTT
the "effective" window is the lesser of:
a) the receiver's advertised window
b) the sender's SO_SNDBUF size
c) the sender's calculated congestion window
d) the quantity of data the application is willing to send at one time
So, you may not need to lower the river (latency) but raise the bridge
at points b, c, or d. Points b and d are ostensibly under some
control. Point c will depend on the packet loss characteristics of
the path and the congestion control algorithm in use.
No need to believe in either side, or any side. There is no cause.
There's only yourself. The belief is in your own precision. - Jobert
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...