Re: TCP Advertised Window Size
On Oct 13, 11:06*am, David Schwartz <dav...@webmaster.com> wrote:[color=blue]
> 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
> to fill.
> >*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
> > size.[/color]
> 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?
Thanks a lot for the comments. 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.
I believe we have reached a limit where unless the latency is reduced,
no additional throughput benefits will occur from modifying the window