TCP Advertised Window Size - TCP-IP

This is a discussion on TCP Advertised Window Size - TCP-IP ; Hi, I am slightly confused about the values for Window Size that I am seeing from a recent Wireshark capture. Here are snippets from the capture. The part I am getting confused at is the Sender (10.176.2.180) is advertising a ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: TCP Advertised Window Size

  1. TCP Advertised Window Size

    Hi,

    I am slightly confused about the values for Window Size that I am
    seeing from a recent Wireshark capture. Here are snippets from the
    capture. The part I am getting confused at is the Sender
    (10.176.2.180) is advertising a window size of 5840 but it also has
    Window Scaling set to 2 ?? The Receiver (10.178.205.253) is
    advertising a value of 65535 with windows scaling not in use,
    correct ?

    So, does this mean that even though the Receiver can accept 65535
    bytes of data, the sender will only send
    5840 * 4 = 23360 bytes of data. Why does the Sender need to have the
    Windows Scaling option set if it does not intend to send more than
    65535 bytes of data anyway.

    I haven't tried this yet but would increasing the sender's window size
    to 65535 increase the overall throughput

    No. Time Source Destination
    Protocol Info
    62196 687.278257 10.176.2.180 10.178.205.253
    TCP ftp-data > fmpro-internal [SYN] Seq=0 Win=5840 Len=0 MSS=1460
    TSV=795315960 TSER=0 WS=2

    Frame 62196 (74 bytes on wire, 74 bytes captured)
    Ethernet II, Src: 52:c0:20:00:06:00 (52:c0:20:00:06:00), Dst:
    06:00:06:00:00:00 (06:00:06:00:00:00)
    Internet Protocol, Src: 10.176.2.180 (10.176.2.180), Dst:
    10.178.205.253 (10.178.205.253)
    Transmission Control Protocol, Src Port: ftp-data (20), Dst Port:
    fmpro-internal (5003), Seq: 0, Len: 0
    Source port: ftp-data (20)
    Destination port: fmpro-internal (5003)
    Sequence number: 0 (relative sequence number)
    Header length: 40 bytes
    Flags: 0x02 (SYN)
    Window size: 5840
    Checksum: 0xf7df [correct]
    [Good Checksum: True]
    [Bad Checksum: False]
    Options: (20 bytes)
    Maximum segment size: 1460 bytes
    SACK permitted
    Timestamps: TSval 795315960, TSecr 0
    NOP
    Window scale: 2 (multiply by 4)

    No. Time Source Destination
    Protocol Info
    62197 687.278257 10.178.205.253 10.176.2.180
    TCP fmpro-internal > ftp-data [SYN, ACK] Seq=0 Ack=1 Win=65535
    Len=0 MSS=1260 WS=0 TSV=0 TSER=0

    Frame 62197 (78 bytes on wire, 78 bytes captured)
    Ethernet II, Src: 06:00:06:00:00:00 (06:00:06:00:00:00), Dst:
    52:c0:20:00:06:00 (52:c0:20:00:06:00)
    Internet Protocol, Src: 10.178.205.253 (10.178.205.253), Dst:
    10.176.2.180 (10.176.2.180)
    Transmission Control Protocol, Src Port: fmpro-internal (5003), Dst
    Port: ftp-data (20), Seq: 0, Ack: 1, Len: 0
    Source port: fmpro-internal (5003)
    Destination port: ftp-data (20)
    Sequence number: 0 (relative sequence number)
    Acknowledgement number: 1 (relative ack number)
    Header length: 44 bytes
    Flags: 0x12 (SYN, ACK)
    Window size: 65535
    Checksum: 0xb47d [correct]
    [Good Checksum: True]
    [Bad Checksum: False]
    Options: (24 bytes)
    Maximum segment size: 1260 bytes
    NOP
    Window scale: 0 (multiply by 1)
    NOP
    NOP
    Timestamps: TSval 0, TSecr 0
    NOP
    NOP
    SACK permitted
    [SEQ/ACK analysis]

    No. Time Source Destination
    Protocol Info
    62202 687.558660 10.176.2.180 10.178.205.253 FTP-
    DATA FTP Data: 1248 bytes

    Frame 62202 (1314 bytes on wire, 1314 bytes captured)
    Ethernet II, Src: 52:c0:20:00:06:00 (52:c0:20:00:06:00), Dst:
    06:00:06:00:00:00 (06:00:06:00:00:00)
    Internet Protocol, Src: 10.176.2.180 (10.176.2.180), Dst:
    10.178.205.253 (10.178.205.253)
    Transmission Control Protocol, Src Port: ftp-data (20), Dst Port:
    fmpro-internal (5003), Seq: 1249, Ack: 1, Len: 1248
    Source port: ftp-data (20)
    Destination port: fmpro-internal (5003)
    Sequence number: 1249 (relative sequence number)
    [Next sequence number: 2497 (relative sequence number)]
    Acknowledgement number: 1 (relative ack number)
    Header length: 32 bytes
    Flags: 0x10 (ACK)
    Window size: 5840 (scaled)
    Checksum: 0x75da [correct]
    [Good Checksum: True]
    [Bad Checksum: False]
    Options: (12 bytes)
    NOP
    NOP
    Timestamps: TSval 795316181, TSecr 0

    No. Time Source Destination
    Protocol Info
    62203 687.558660 10.178.205.253 10.176.2.180
    TCP fmpro-internal > ftp-data [ACK] Seq=1 Ack=2497 Win=65535
    Len=0 TSV=9974 TSER=795316181

    Frame 62203 (66 bytes on wire, 66 bytes captured)
    Ethernet II, Src: 06:00:06:00:00:00 (06:00:06:00:00:00), Dst:
    52:c0:20:00:06:00 (52:c0:20:00:06:00)
    Internet Protocol, Src: 10.178.205.253 (10.178.205.253), Dst:
    10.176.2.180 (10.176.2.180)
    Transmission Control Protocol, Src Port: fmpro-internal (5003), Dst
    Port: ftp-data (20), Seq: 1, Ack: 2497, Len: 0
    Source port: fmpro-internal (5003)
    Destination port: ftp-data (20)
    Sequence number: 1 (relative sequence number)
    Acknowledgement number: 2497 (relative ack number)
    Header length: 32 bytes
    Flags: 0x10 (ACK)
    Window size: 65535
    Checksum: 0x048e [correct]
    [Good Checksum: True]
    [Bad Checksum: False]
    Options: (12 bytes)
    NOP
    NOP
    Timestamps: TSval 9974, TSecr 795316181
    [SEQ/ACK analysis]

    No. Time Source Destination
    Protocol Info
    62204 687.698862 10.178.205.253 10.176.2.180
    TCP qt-serveradmin > ftp [ACK] Seq=120 Ack=300 Win=65236 Len=0
    TSV=9976 TSER=2529407431

    Frame 62204 (66 bytes on wire, 66 bytes captured)
    Ethernet II, Src: 06:00:06:00:00:00 (06:00:06:00:00:00), Dst:
    52:c0:20:00:06:00 (52:c0:20:00:06:00)
    Internet Protocol, Src: 10.178.205.253 (10.178.205.253), Dst:
    10.176.2.180 (10.176.2.180)
    Transmission Control Protocol, Src Port: qt-serveradmin (1220), Dst
    Port: ftp (21), Seq: 120, Ack: 300, Len: 0
    Source port: qt-serveradmin (1220)
    Destination port: ftp (21)
    Sequence number: 120 (relative sequence number)
    Acknowledgement number: 300 (relative ack number)
    Header length: 32 bytes
    Flags: 0x10 (ACK)
    Window size: 65236
    Checksum: 0xecb9 [correct]
    [Good Checksum: True]
    [Bad Checksum: False]
    Options: (12 bytes)
    NOP
    NOP
    Timestamps: TSval 9976, TSecr 2529407431
    [SEQ/ACK analysis]


    Thanks

  2. Re: TCP Advertised Window Size

    On Oct 11, 7:53*pm, tmoum...@gmail.com wrote:
    > Hi,
    >
    > I am slightly confused about the values for Window Size that I am
    > seeing from a recent Wireshark capture. *Here are snippets from the
    > capture. *The part I am getting confused at is the Sender
    > (10.176.2.180) is advertising a window size of 5840 but it also has
    > Window Scaling set to 2 ?? The Receiver (10.178.205.253) is
    > advertising a value of 65535 with windows scaling not in use,
    > correct ?


    Yes, that's what the Wireshark capture shows.

    > So, does this mean that even though the Receiver can accept 65535
    > bytes of data, the sender will only send
    > 5840 * 4 = 23360 bytes of data.


    What it says is that the sender is starting out slow, sending 5840
    window sizes initially. But that the sender is willing to use a window
    size that is scaled to 2, which means 2^2 bigger than the 16-bit
    Window field in the TCP header allows. So the sender is telling the
    receiver that it is prepared scale that 16-bit Window field by 4,
    allowing it to send 4 times as many bytes as the 16-bit field would
    otherwise allow.

    But the receiver is instead more prudent, evidently. Not willing to go
    so fast.

    RFC 1323.

    Bert

  3. Re: TCP Advertised Window Size

    On Oct 11, 4:53*pm, tmoum...@gmail.com wrote:

    > I am slightly confused about the values for Window Size that I am
    > seeing from a recent Wireshark capture. *Here are snippets from the
    > capture. *The part I am getting confused at is the Sender
    > (10.176.2.180) is advertising a window size of 5840 but it also has
    > Window Scaling set to 2 ?? The Receiver (10.178.205.253) is
    > advertising a value of 65535 with windows scaling not in use,
    > correct ?


    Yes.

    > Why does the Sender need to have the
    > Windows Scaling option set if it does not intend to send more than
    > 65535 bytes of data anyway.


    The sender doesn't know it's a sender, it just knows it's establishing
    a TCP connection. What you are calling the "Sender" is leaving its
    options open so that it can later, if it wants to, open up its own
    window to a maximum of 256KB instead of a maximum 64KB.

    DS

  4. Re: TCP Advertised Window Size

    On Oct 12, 9:14*pm, David Schwartz wrote:
    > On Oct 11, 4:53*pm, tmoum...@gmail.com wrote:
    >
    > > I am slightly confused about the values for Window Size that I am
    > > seeing from a recent Wireshark capture. *Here are snippets from the
    > > capture. *The part I am getting confused at is the Sender
    > > (10.176.2.180) is advertising a window size of 5840 but it also has
    > > Window Scaling set to 2 ?? The Receiver (10.178.205.253) is
    > > advertising a value of 65535 with windows scaling not in use,
    > > correct ?

    >
    > Yes.
    >
    > > Why does the Sender need to have the
    > > Windows Scaling option set if it does not intend to send more than
    > > 65535 bytes of data anyway.

    >
    > The sender doesn't know it's a sender, it just knows it's establishing
    > a TCP connection. What you are calling the "Sender" is leaving its
    > options open so that it can later, if it wants to, open up its own
    > window to a maximum of 256KB instead of a maximum 64KB.
    >
    > DS



    Thanks for the responses so far. A couple of follow-up questions for
    further understanding:

    In the Wireshark log I have collected, the "sender" does not open it's
    window at a later stage. 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. 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 ??

    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. However, by changing the receiver window size from 64k to 128k/
    256k/512k, the throughput improvements are negligible. So, I am
    trying to understand if the sender is now a bottleneck in any way ??

    Thanks

  5. Re: TCP Advertised Window Size

    One of the systems is Linux-based yes? If an application does not
    make an explicit setsockopt() call linux will "autotune" the socket
    buffers and will attempt to determine the sender's congestion window
    and advertise that plus some fudge factor. If one makes explicit
    setsockopt() calls that will not happen. Also, if an app makes
    explicit setsockopt() calls, the default limit is much lower than with
    the autotuning path.

    If the throughput has not increased, it suggests that 5840*4 was
    "large enough" for what the sender was willing/able to send. Remember
    that from the beginning of the connection it will be calculating a
    "congestion window" trying to see how much it can put out on to the
    network at one time without congesting it. If the connection is
    "short" the congestion window may not grow all that large.

    Also, if the sender has a limited SO_SNDBUF size that may keep it from
    putting out much at one time.

    Tput <= WindowEff/RTT

    Where WindowEff (effective window) will be the minimum of:

    *) the receiver's advertised window
    *) the sender's calculated congestion window
    *) the sender's SO_SNDBUF size
    *) what the application is willing to send at one time

    The two sides of the TCP connection to not negotiate window size.
    They simply advertise it. What does get "negotiated" (more or less,
    by convention if not actual spec) is the Maximum Segment Size (MSS).

    rick jones
    http://www.netperf.org/
    --
    The computing industry isn't as much a game of "Follow The Leader" as
    it is one of "Ring Around the Rosy" or perhaps "Duck Duck Goose."
    - Rick Jones
    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