On Oct 13, 11:06*am, David Schwartz wrote:
> 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.

> 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.

> 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 ??

> 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.

> 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-
> trip-time.
> >*However, by changing the receiver window size from 64k to 128k/
> > 256k/512k, the throughput improvements are negligible.

> 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 ??

> Why do you think there is a bottleneck? What are you seeing?
> DS

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