Re: TCP Advertised Window Size - TCP-IP

This is a discussion on Re: TCP Advertised Window Size - TCP-IP ; 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. ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Re: TCP Advertised Window Size

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


    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

  2. Re: TCP Advertised Window Size

    tmoumts1@gmail.com wrote:
    > 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.


    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.


    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.

    rick jones
    http://www.netperf.org/
    --
    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...

+ Reply to Thread