Re: Fwd: [RFC] tcp: Delay sending non-probes for RFC4821 mtu probing

From: Leonard Crestez
Date: Sun Apr 25 2021 - 22:32:56 EST


On 4/21/21 7:45 PM, Matt Mathis wrote:
(Resending in plain text mode)

Surely there is a way to adapt tcp_tso_should_defer(), it is trying to
solve a similar problem.

If I were to implement PLPMTUD today, I would more deeply entwine it
into TCP's support for TSO. e.g. successful deferring segments
sometimes enables TSO and sometimes enables PLPMTUD.

The mechanisms for delaying sending are difficult to understand, this RFC just added a brand-new unrelated timer. Intertwining it with existing mechanisms would indeed be better. On a closer look it seems that they're not actually based on a timer but other heuristics.

It seems that tcp_sendmsg will "tcp_push_one" once the skb at the head of the queue reaches tcp_xmit_size_goal and tcp_xmit_size_goal does not take mtu probing into account. In practice this would mean that application-limited streams won't perform mtu probing unless a single write is 5*mss + probe_size (1*mss over size_needed)

I sent a different RFC which tries to modify tcp_xmit_size_goal.

But there is a deeper question: John Heffner and I invested a huge
amount of energy in trying to make PLPMTUD work for opportunistic
Jumbo discovery, only to discover that we had moved the problem down
to the device driver/nic, were it isn't so readily solvable.

The driver needs to carve nic buffer memory before it can communicate
with a switch (to either ask or measure the MTU), and once it has done
that it needs to either re-carve the memory or run with suboptimal
carving. Both of these are problematic.

There is also a problem that many link technologies will
non-deterministically deliver jumbo frames at greatly increased error
rates. This issue requires a long conversation on it's own.

I'm looking to improve this for tunnels that don't correctly send ICMP packet-too-big messages, the hardware is assumed to be fine.

--
Regards,
Leonard