Thread (11 messages) 11 messages, 3 authors, 2015-03-03

Re: [PATCHv3 net-next 3/4] ipv4: shrink current mss for tcp PMTU blackhole detection

From: John Heffner <hidden>
Date: 2015-03-02 20:32:24

On Mon, Mar 2, 2015 at 4:29 AM, Fan Du [off-list ref] wrote:
quoted hunk ↗ jump to hunk
Timeout indicates search_high should be set to the new mtu corresponding to
current_mss no
matter how we change search_low. So the best shot here IMO would be updating
search_high
with current_mss, which in return makes the search window *slide* from right
to left, and
the probing will converge in good speed eventually.

So my thoughts is:
@@ -113,6 +113,7 @@ static void tcp_mtu_probing(struct inet_connection_sock
*icsk, struct sock *sk)
                        struct tcp_sock *tp = tcp_sk(sk);
                        int mss;

+                       icsk_mtup.search_high = tcp_mss_to_mtu(sk,
tcp_current_mss(sk));
                        mss = tcp_mtu_to_mss(sk, icsk->icsk_mtup.search_low)
quoted
quoted
1;
                        mss = min(net->ipv4.sysctl_tcp_base_mss, mss);
                        mss = max(mss, 68 - tp->tcp_header_len);
Search_high should be adjusted downward only when you're quite certain
that you've gotten a negative signal.  There are many possible reasons
for successive timeouts including intermittent disconnection, and they
should not have a persistent (or very long-term) effect on MTU.  Leave
search_high where it is until a working MTU can be established, then
probe upward until probing can give you confidence you've found a new
ceiling, or gotten back to the old one.

If you think the current approach is broken, it would help to see a
concrete demonstration of how it's deficient (a real packet trace is
good!), and how a different approach work better.

Thanks,
  -John
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help