| Message ID | 1565221950-1376-1-git-send-email-johunt@akamai.com |
|---|---|
| State | Changes Requested |
| Delegated to: | David Miller |
| Headers | show |
| Series | [v2,1/2] tcp: add new tcp_mtu_probe_floor sysctl | expand |
On 8/8/19 1:52 AM, Josh Hunt wrote: > The current implementation of TCP MTU probing can considerably > underestimate the MTU on lossy connections allowing the MSS to get down to > 48. We have found that in almost all of these cases on our networks these > paths can handle much larger MTUs meaning the connections are being > artificially limited. Even though TCP MTU probing can raise the MSS back up > we have seen this not to be the case causing connections to be "stuck" with > an MSS of 48 when heavy loss is present. > > Prior to pushing out this change we could not keep TCP MTU probing enabled > b/c of the above reasons. Now with a reasonble floor set we've had it > enabled for the past 6 months. I am still sad to see you do not share what is a reasonable value and let everybody guess. It seems to be a top-secret value. > > The new sysctl will still default to TCP_MIN_SND_MSS (48), but gives > administrators the ability to control the floor of MSS probing. > > Signed-off-by: Josh Hunt <johunt@akamai.com> Signed-off-by: Eric Dumazet <edumazet@google.com>
On Wed, Aug 7, 2019 at 7:55 PM Josh Hunt <johunt@akamai.com> wrote: > > The current implementation of TCP MTU probing can considerably > underestimate the MTU on lossy connections allowing the MSS to get down to > 48. We have found that in almost all of these cases on our networks these > paths can handle much larger MTUs meaning the connections are being > artificially limited. Even though TCP MTU probing can raise the MSS back up > we have seen this not to be the case causing connections to be "stuck" with > an MSS of 48 when heavy loss is present. > > Prior to pushing out this change we could not keep TCP MTU probing enabled > b/c of the above reasons. Now with a reasonble floor set we've had it > enabled for the past 6 months. > > The new sysctl will still default to TCP_MIN_SND_MSS (48), but gives > administrators the ability to control the floor of MSS probing. > > Signed-off-by: Josh Hunt <johunt@akamai.com> > --- Acked-by: Neal Cardwell <ncardwell@google.com> Thanks, Josh. I agree with Eric that it would be great if you are able to share the value that you have found to work well. neal
On 8/7/19 11:12 PM, Eric Dumazet wrote: > > > On 8/8/19 1:52 AM, Josh Hunt wrote: >> The current implementation of TCP MTU probing can considerably >> underestimate the MTU on lossy connections allowing the MSS to get down to >> 48. We have found that in almost all of these cases on our networks these >> paths can handle much larger MTUs meaning the connections are being >> artificially limited. Even though TCP MTU probing can raise the MSS back up >> we have seen this not to be the case causing connections to be "stuck" with >> an MSS of 48 when heavy loss is present. >> >> Prior to pushing out this change we could not keep TCP MTU probing enabled >> b/c of the above reasons. Now with a reasonble floor set we've had it >> enabled for the past 6 months. > > I am still sad to see you do not share what is a reasonable value and let > everybody guess. > > It seems to be a top-secret value. Haha, no sorry I didn't mean for it to come across like that. We are currently setting tcp_base_mss to 1348 and tcp_mtu_probe_floor to 1208. I thought I mentioned it in our earlier mails, but I guess I did not put the exact #s. 1348 was derived after analyzing common MTU we see across our networks and noticing that an MTU of around 1400 would cover a very large % (sorry I don't have the #s handy) of those paths. 1400 - 20 - 20 - 12 = 1348. For the floor we based it off the v6 min MTU of 1280 and subtracted out headers, etc, so 1280 - 40 - 20 - 12 = 1208. Using a floor of 1280 MTU matches what the RFC suggests in section 7.7 for v6 connections, we're just applying that to v4 right now as well. I guess that brings up a good point, would per-IP proto floor sysctls be an option here for upstream (the RFC suggests different floors for v4 and v6)? For now I'm not sure it makes sense b/c of the problems we see with lossy connections, but in the future if that can be resolved it seems like it would give some more flexibility. I'd like to investigate this all further at some point to see if we can make it work better for lossy connections. It looks like one of the problems is there are a # of conditions which cause us to not probe in the upward direction. I'm not sure if any of those can be relaxed/changed and if so would help these connections out. Thanks Josh
From: Josh Hunt <johunt@akamai.com> Date: Wed, 7 Aug 2019 19:52:29 -0400 > The current implementation of TCP MTU probing can considerably > underestimate the MTU on lossy connections allowing the MSS to get down to > 48. We have found that in almost all of these cases on our networks these > paths can handle much larger MTUs meaning the connections are being > artificially limited. Even though TCP MTU probing can raise the MSS back up > we have seen this not to be the case causing connections to be "stuck" with > an MSS of 48 when heavy loss is present. > > Prior to pushing out this change we could not keep TCP MTU probing enabled > b/c of the above reasons. Now with a reasonble floor set we've had it > enabled for the past 6 months. > > The new sysctl will still default to TCP_MIN_SND_MSS (48), but gives > administrators the ability to control the floor of MSS probing. > > Signed-off-by: Josh Hunt <johunt@akamai.com> Applied.
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt index df33674799b5..49e95f438ed7 100644 --- a/Documentation/networking/ip-sysctl.txt +++ b/Documentation/networking/ip-sysctl.txt @@ -256,6 +256,12 @@ tcp_base_mss - INTEGER Path MTU discovery (MTU probing). If MTU probing is enabled, this is the initial MSS used by the connection. +tcp_mtu_probe_floor - INTEGER + If MTU probing is enabled this caps the minimum MSS used for search_low + for the connection. + + Default : 48 + tcp_min_snd_mss - INTEGER TCP SYN and SYNACK messages usually advertise an ADVMSS option, as described in RFC 1122 and RFC 6691. diff --git a/include/net/netns/ipv4.h b/include/net/netns/ipv4.h index bc24a8ec1ce5..c0c0791b1912 100644 --- a/include/net/netns/ipv4.h +++ b/include/net/netns/ipv4.h @@ -116,6 +116,7 @@ struct netns_ipv4 { int sysctl_tcp_l3mdev_accept; #endif int sysctl_tcp_mtu_probing; + int sysctl_tcp_mtu_probe_floor; int sysctl_tcp_base_mss; int sysctl_tcp_min_snd_mss; int sysctl_tcp_probe_threshold; diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c index 0b980e841927..59ded25acd04 100644 --- a/net/ipv4/sysctl_net_ipv4.c +++ b/net/ipv4/sysctl_net_ipv4.c @@ -820,6 +820,15 @@ static struct ctl_table ipv4_net_table[] = { .extra2 = &tcp_min_snd_mss_max, }, { + .procname = "tcp_mtu_probe_floor", + .data = &init_net.ipv4.sysctl_tcp_mtu_probe_floor, + .maxlen = sizeof(int), + .mode = 0644, + .proc_handler = proc_dointvec_minmax, + .extra1 = &tcp_min_snd_mss_min, + .extra2 = &tcp_min_snd_mss_max, + }, + { .procname = "tcp_probe_threshold", .data = &init_net.ipv4.sysctl_tcp_probe_threshold, .maxlen = sizeof(int), diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c index d57641cb3477..e0a372676329 100644 --- a/net/ipv4/tcp_ipv4.c +++ b/net/ipv4/tcp_ipv4.c @@ -2637,6 +2637,7 @@ static int __net_init tcp_sk_init(struct net *net) net->ipv4.sysctl_tcp_min_snd_mss = TCP_MIN_SND_MSS; net->ipv4.sysctl_tcp_probe_threshold = TCP_PROBE_THRESHOLD; net->ipv4.sysctl_tcp_probe_interval = TCP_PROBE_INTERVAL; + net->ipv4.sysctl_tcp_mtu_probe_floor = TCP_MIN_SND_MSS; net->ipv4.sysctl_tcp_keepalive_time = TCP_KEEPALIVE_TIME; net->ipv4.sysctl_tcp_keepalive_probes = TCP_KEEPALIVE_PROBES; diff --git a/net/ipv4/tcp_timer.c b/net/ipv4/tcp_timer.c index c801cd37cc2a..dbd9d2d0ee63 100644 --- a/net/ipv4/tcp_timer.c +++ b/net/ipv4/tcp_timer.c @@ -154,7 +154,7 @@ static void tcp_mtu_probing(struct inet_connection_sock *icsk, struct sock *sk) } else { mss = tcp_mtu_to_mss(sk, icsk->icsk_mtup.search_low) >> 1; mss = min(net->ipv4.sysctl_tcp_base_mss, mss); - mss = max(mss, 68 - tcp_sk(sk)->tcp_header_len); + mss = max(mss, net->ipv4.sysctl_tcp_mtu_probe_floor); mss = max(mss, net->ipv4.sysctl_tcp_min_snd_mss); icsk->icsk_mtup.search_low = tcp_mss_to_mtu(sk, mss); }
The current implementation of TCP MTU probing can considerably underestimate the MTU on lossy connections allowing the MSS to get down to 48. We have found that in almost all of these cases on our networks these paths can handle much larger MTUs meaning the connections are being artificially limited. Even though TCP MTU probing can raise the MSS back up we have seen this not to be the case causing connections to be "stuck" with an MSS of 48 when heavy loss is present. Prior to pushing out this change we could not keep TCP MTU probing enabled b/c of the above reasons. Now with a reasonble floor set we've had it enabled for the past 6 months. The new sysctl will still default to TCP_MIN_SND_MSS (48), but gives administrators the ability to control the floor of MSS probing. Signed-off-by: Josh Hunt <johunt@akamai.com> --- Documentation/networking/ip-sysctl.txt | 6 ++++++ include/net/netns/ipv4.h | 1 + net/ipv4/sysctl_net_ipv4.c | 9 +++++++++ net/ipv4/tcp_ipv4.c | 1 + net/ipv4/tcp_timer.c | 2 +- 5 files changed, 18 insertions(+), 1 deletion(-)