Netdev List
 help / color / mirror / Atom feed
From: Heath Caldwell <hcaldwel@akamai.com>
To: Eric Dumazet <edumazet@google.com>
Cc: netdev <netdev@vger.kernel.org>,
	Yuchung Cheng <ycheng@google.com>, Josh Hunt <johunt@akamai.com>,
	Ji Li <jli@akamai.com>
Subject: Re: [PATCH net-next 4/4] tcp: remove limit on initial receive window
Date: Tue, 12 Jan 2021 08:02:52 -0800	[thread overview]
Message-ID: <24573.51244.563087.333291@gargle.gargle.HOWL> (raw)
In-Reply-To: <CANn89iLheJ+a0AZ_JZyitsZK5RCVsadzgsBK=DeHs-7ko5OMuQ@mail.gmail.com>

On 2021-01-12 09:30 (+0100), Eric Dumazet <edumazet@google.com> wrote:
> I think the whole patch series is an attempt to badly break TCP stack.

Can you explain the concern that you have about how these changes might
break the TCP stack?

Patches 1 and 3 fix clear bugs.

Patches 2 and 4 might be arguable, though.

Is you objection primarily about the limit removed by patch 4?

> Hint : 64K is really the max allowed by TCP standards. Yes, this is
> sad, but this is it.

Do you mean the limit imposed by the size of the "Window Size" header
field?  This limitation is directly addressed by the check in
__tcp_transmit_skb():

	if (likely(!(tcb->tcp_flags & TCPHDR_SYN))) {
		th->window      = htons(tcp_select_window(sk));
		tcp_ecn_send(sk, skb, th, tcp_header_size);
	} else {
		/* RFC1323: The window in SYN & SYN/ACK segments
		 * is never scaled.
		 */
		th->window	= htons(min(tp->rcv_wnd, 65535U));
	}

and checking (and capping it there) allows for the field to not overflow
while also not artificially restricting the size of the window which
will later be advertised (once window scaling is negotiated).

> I will not spend hours of work running  packetdrill tests over your
> changes, but I am sure they are now quite broken.
> 
> If you believe auto tuning is broken, fix it properly, without trying
> to change all the code so that you can understand it.

The removal of the limit specifically addresses the situation where auto
tuning cannot work: on the initial burst.  There is no way to know
whether an installation desires to receive a larger first burst unless
it is specifically configured - and this limit prevents such
configuration.

> I strongly advise you read RFC 7323 before doing any changes in TCP
> stack, and asking us to spend time reviewing your patches.

Can you point out the part of the RFC which would be violated by
initially (that is, the first packet after the SYN) advertising a window
larger than 64KB?

> If you want to do research, this is fine, but please do not break
> production TCP stack.
> 
> Thank you.

  reply	other threads:[~2021-01-12 16:03 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-11 22:24 [PATCH net-next 0/4] Fix receive window restriction Heath Caldwell
2021-01-11 22:24 ` [PATCH net-next 1/4] net: account for overhead when restricting SO_RCVBUF Heath Caldwell
2021-01-11 22:24 ` [PATCH net-next 2/4] net: tcp: consistently account for overhead for SO_RCVBUF for TCP Heath Caldwell
2021-01-11 22:24 ` [PATCH net-next 3/4] tcp: consistently account for overhead in rcv_wscale calculation Heath Caldwell
2021-01-11 22:24 ` [PATCH net-next 4/4] tcp: remove limit on initial receive window Heath Caldwell
2021-01-12  8:30   ` Eric Dumazet
2021-01-12 16:02     ` Heath Caldwell [this message]
2021-01-12 17:05       ` Eric Dumazet
2021-01-12 19:25         ` Heath Caldwell
2021-01-12 20:26           ` Eric Dumazet
2021-01-12 20:43             ` Heath Caldwell
2021-01-12 20:56               ` Eric Dumazet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=24573.51244.563087.333291@gargle.gargle.HOWL \
    --to=hcaldwel@akamai.com \
    --cc=edumazet@google.com \
    --cc=jli@akamai.com \
    --cc=johunt@akamai.com \
    --cc=netdev@vger.kernel.org \
    --cc=ycheng@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox