netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Leonard Crestez <cdleonard@gmail.com>
To: Neal Cardwell <ncardwell@google.com>,
	Matt Mathis <mattmathis@google.com>
Cc: "David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Willem de Bruijn <willemb@google.com>,
	Jakub Kicinski <kuba@kernel.org>,
	Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
	David Ahern <dsahern@kernel.org>,
	John Heffner <johnwheffner@gmail.com>,
	Leonard Crestez <lcrestez@drivenets.com>,
	Soheil Hassas Yeganeh <soheil@google.com>,
	Roopa Prabhu <roopa@cumulusnetworks.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [RFC 0/3] tcp: Improve mtu probe preconditions
Date: Tue, 11 May 2021 15:04:15 +0300	[thread overview]
Message-ID: <cover.1620733594.git.cdleonard@gmail.com> (raw)

According to RFC4821 Section 7.4 "Protocols MAY delay sending non-probes
in order to accumulate enough data" but in practice linux only sends
probes when a lot of data accumulates on the send side.

Bigget improvement is to make tcp_xmit_size_goal (normally used for TSO)
take the probe size into account. This makes probes more likely to be
sent when applications use short writes. This should introduce no delays
beyond existing autocork heuristics.

TCP RACK allows timely loss detection with fewer outstanding packets
than fast transmit, if enabled we can use this to shrink the probe size
and require much less data for probing.

Successive mtu probes will result in reducing the cwnd since it's
measured in packets and we send bigger packets. The cwnd value can get
stuck below 11 so rework the cwnd logic in tcp_mtu_probe to be based on
the number of packets that we actually need to send.

Signed-off-by: Leonard Crestez <cdleonard@gmail.com>

---

Previous RFCs:
* https://lore.kernel.org/netdev/d7fbf3d3a2490d0a9e99945593ada243da58e0f8.1619000255.git.cdleonard@gmail.com/
* https://lore.kernel.org/netdev/c575e693788233edeb399d8f9b6d9217b3daed9b.1619403511.git.lcrestez@drivenets.com/

The sysctls can probably be dropped, they're there for easy
experimentation.

It is possible that I misunderstood the meaning of "return 0 to wait"
from tcp_mtu_probe.

This introduces a bunch of mtu-to-mss calculations inside
tcp_xmit_size_goal which is called on every write. It might make sense
to cache the size of a pending probe inside icsk_mtup.probe_size. Right
now it's zero unless a probe is outstanding; a separate bit could be
used intead.

Leonard Crestez (3):
  tcp: Consider mtu probing for tcp_xmit_size_goal
  tcp: Use mtu probes if RACK is enabled
  tcp: Adjust congestion window handling for mtu probe

 Documentation/networking/ip-sysctl.rst | 10 ++++
 include/net/inet_connection_sock.h     |  4 +-
 include/net/netns/ipv4.h               |  2 +
 include/net/tcp.h                      |  1 +
 net/ipv4/sysctl_net_ipv4.c             | 14 +++++
 net/ipv4/tcp.c                         | 11 +++-
 net/ipv4/tcp_ipv4.c                    |  2 +
 net/ipv4/tcp_output.c                  | 72 +++++++++++++++++++++-----
 8 files changed, 102 insertions(+), 14 deletions(-)


base-commit: 3913ba732e972d88ebc391323999e780a9295852
-- 
2.25.1


             reply	other threads:[~2021-05-11 12:04 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-11 12:04 Leonard Crestez [this message]
2021-05-11 12:04 ` [RFC 1/3] tcp: Consider mtu probing for tcp_xmit_size_goal Leonard Crestez
2021-05-11 13:04   ` Eric Dumazet
2021-05-17 13:42     ` Leonard Crestez
2021-05-11 12:04 ` [RFC 2/3] tcp: Use mtu probes if RACK is enabled Leonard Crestez
2021-05-11 12:04 ` [RFC 3/3] tcp: Adjust congestion window handling for mtu probe Leonard Crestez

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=cover.1620733594.git.cdleonard@gmail.com \
    --to=cdleonard@gmail.com \
    --cc=davem@davemloft.net \
    --cc=dsahern@kernel.org \
    --cc=edumazet@google.com \
    --cc=johnwheffner@gmail.com \
    --cc=kuba@kernel.org \
    --cc=lcrestez@drivenets.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mattmathis@google.com \
    --cc=ncardwell@google.com \
    --cc=netdev@vger.kernel.org \
    --cc=roopa@cumulusnetworks.com \
    --cc=soheil@google.com \
    --cc=willemb@google.com \
    --cc=yoshfuji@linux-ipv6.org \
    /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;
as well as URLs for NNTP newsgroup(s).