Subject: [tcpm] tcp window size

From: Marc <[email-masked]>
Date: Mon, 20 May 2019 18:23:22 +0200

Hello experts,

I've been trying to find definitive information about tcp window size
negotiation, and if it exists at all.

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 ?

I can't see any logic for it being limited to the window size of the
sender (32KB), I think it depends on both the receiver winsize and the
sender TCP Send Buffer Size, but I need to be sure.

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 ?

Thanks!

---

From: Yuchung Cheng <[email-masked]>
Date: Mon, 20 May 2019 09:53:40 -0700

> connection just advertises its own to indicate how much data it can
That's correct. It's FYI not negotiated.
>
> Thanks!
>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 20 May 2019 12:37:19 -0700

Hi Marc,

> How much 'outstanding unacked data' is the sender allowed to have,

advertised window is receiving buffer size on each side.

> connection just advertises its own to indicate how much data it can

yep, correct.
--
Yoshi

---

From: William Herrin <[email-masked]>
Date: Tue, 21 May 2019 06:30:43 -0700

> How much 'outstanding unacked data' is the sender allowed to have,

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.

> connection just advertises its own to indicate how much data it can

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
[email-masked]
https://bill.herrin.us/