I have been exploring the code to find a place to send with a lower MTU than the MRU for a socket. That is probably more efficient than learning about Path MTU on every sending attempt. Feedback welcomed!

I think an extension to struct socket_info with socket as default socket and a new field socket_mtu as an outbound override could help. It could be setup when udp_mtu is set (or maybe when listen has an extra mtu 1234 parameter). Cleanup would recognise socket != socket_mtu as a special case in which the secondary needed cleanup. The extra field could be setup in udp_init() and trivially copied in the other core/xxx_server.c variants, so sending can always use socket_mtu instead of the receiving side, socket itself, with its unbounded MTU.

My work now is to construct dual sockets, set different MTUs and see this idea work. I will do that in the MTU games repo.

Notes:

It is not currently meaningful to configure udp_mtu but not udp_mtu_try_proto. Indeed, the code confirms ignoring that situation. Precisely this configuration could give rise to transmission over a secondary socket with reduced MTU. This code might therefore set a flag FL_MTU_UDP_FB (that is part of the FL_MTU_FB_MASK).
This flag is used to determine the sending socket for a message, via di.proto and di.send_sock and delivered into send_info->proto and send_info->send_sock. An extra case for FL_MTU_UDP_FB could be added here.
The routine get_send_socket2() finds a struct socket_info to send over. Assuming non-forced socket, for single-homed systems, this is the static value in sendipv6, for multi-homed systems it is determined with get_out_socket() which uses find_si() to locate a configured socket.
It would be possible to have socket for its current use, but for UDP allow an alternative socket socket_mtu to be set to the same coordinates (in the remainder of the structure) but a lower MTU value, namely to the udp_mtu value. Sending would prefer this socket (if set, that is, if >= 0) but receiving would continue to use the default MRU (namely the interface MTU). Being conservative in what we send, liberal in what we accept.
This additional socket_mtu element would be added in udp_init() when udp_mtu is set.
Future options mtu 1234 after a listen declaration may set a socket-specific MTU (and leave the MRU unchanged).
I doubt if such conservative-low MTU knowledge would benefit TCP and TLS. If it is, then this approach could be replicated. But more likely is that the interactive nature of these protocols benefits from an explicit in-situ learning process.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.