Re: [tcpm] tcp window size

William Herrin <> Tue, 21 May 2019 13:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 447E0120086 for <>; Tue, 21 May 2019 06:31:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5GkRPnWnMQZO for <>; Tue, 21 May 2019 06:31:31 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 39D9312015E for <>; Tue, 21 May 2019 06:31:16 -0700 (PDT)
Received: from ([]) by (8.14.3/) with ESMTP id x4LDV0cX001102 for <>; Tue, 21 May 2019 06:31:00 -0700
X-Really-To: <>
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 421FFEBEB0 for <>; Tue, 21 May 2019 06:31:00 -0700 (PDT)
Received: by with SMTP id d30so8610274pgm.7 for <>; Tue, 21 May 2019 06:31:00 -0700 (PDT)
X-Gm-Message-State: APjAAAUe+Aj2cOss0D4W94BWvRQN7hNBOyf+Y+OqdyjmfG6Ip2RKoUAO r5Ov1vuOiBTh17+KVGBWvdPpm2uSboWUMqs0BUE=
X-Google-Smtp-Source: APXvYqwGX2mifia1hxuzqesY5buJfHXeKHEkScAqVcVO7Xxk1Uccd9xMRziQnopOZjmJoCLxTdae03HaPZfYfE7Yxtw=
X-Received: by 2002:a65:6145:: with SMTP id o5mr82136083pgv.262.1558445460025; Tue, 21 May 2019 06:31:00 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: William Herrin <>
Date: Tue, 21 May 2019 06:30:43 -0700
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Marc <>
Cc: " Extensions" <>
Content-Type: multipart/alternative; boundary="0000000000000bf773058965dc43"
Archived-At: <>
Subject: Re: [tcpm] tcp window size
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 21 May 2019 13:31:33 -0000

On Mon, May 20, 2019 at 9:23 AM Marc <> wrote:
> Take a browser that downloads a file (receiver) and a webserver (sender).
> - 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 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.

Bill Herrin

William Herrin