Re: [tcpm] tcp window size

[William Herrin <[e-mail]>]

On Mon, May 20, 2019 at 9:23 AM Marc <[e-mail]> wrote:
> Take a browser that downloads a file (receiver) and a webserver (sender).
If
> - both sender and receiver support window scaling
> - the receiver advertises a TCP winsize of 256KB
> - the sender advertises a window size of 32KB
> - the sender has enough space in its TCP send buffer
> (/proc/sys/net/ipv4/tcp_wmem on linux)
>
> How much 'outstanding unacked data' is the sender allowed to have,
> 32KB or 256KB ?

256kb. But note the assertion that tcp_wmem is 256kb or larger. If the
transmit buffer is 32kb you'll get 32kb even though the receiver is willing
to accept 256kb.

> Reading https://tools.ietf.org/html/rfc793 also suggests there is no
> such thing like window size 'negotiation' and each end of a TCP
> connection just advertises its own to indicate how much data it can
> receive, independently.
>
> Is that correct ?

Correct but incomplete.

The receiver doesn't describe the window size just once. In every
acknowledged packet, the receiver tells the sender how many more bytes he
may send before he must stop and wait. The receiver can tell the sender to
stop sending entirely by acknowledging each new receipt with a window size
of zero. He can later send a duplicate ack with a non-zero window size when
he wants the sender to resume sending. He WILL do so when the application
stops pulling bytes out of the receive buffer causing the buffer to fill.

Your TCP stack also has a congestion control algorithm. This will
slow-start the window size when you first establish the TCP connection and
will, for a time, reduce the window size in response to retransmissions and
lost packets. This has some wacky interactions with NIC offloading where a
stack that processes a TCP packet coalesced by the NIC will ramp up the
window much faster than one which receives the original smaller TCP
packets. Creates a bit of a mess for middleboxes which have to try to keep
packets for a destination close enough together for the endpoint NIC to
choose to coalesce them.

Regards,
Bill Herrin

-- 
William Herrin
[e-mail]
https://bill.herrin.us/