[sr-dev] [kamailio/kamailio] Path MTU handling - suggested solution for IPv6 (Issue #3119)

[vanrein]

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](https://gitlab.com/0cpm/mtugames/-/blob/master/veth/experiment.md) repo.


### Notes:

  * It is not currently meaningful to configure `udp_mtu` but not `udp_mtu_try_proto`.  Indeed, the [code confirms](https://github.com/kamailio/kamailio/blob/d5c1b4693b6e47b4123b5f9417b5fd88d4dafd1f/src/core/msg_translator.c#L126-L129) 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](https://github.com/kamailio/kamailio/blob/d5c1b4693b6e47b4123b5f9417b5fd88d4dafd1f/src/core/msg_translator.c#L2177-L2217) 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()`](https://github.com/kamailio/kamailio/blob/c282b5812c9e9badb4c99fe8ce3bd5cce927044f/src/core/forward.c#L210) finds a [`struct socket_info`](https://github.com/kamailio/kamailio/blob/a0d89214cf8296d30bacdf10a8732bc8826b2418/src/core/ip_addr.h#L111-L135) 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()`](https://github.com/kamailio/kamailio/blob/a1ea2c0d49f56154af5ba1028d7340ea3ed1ae42/src/core/socket_info.c#L1011) to locate a configured socket.
  * It would be possible to have [`socket`](https://github.com/kamailio/kamailio/blob/a0d89214cf8296d30bacdf10a8732bc8826b2418/src/core/ip_addr.h#L112) 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()`](https://github.com/kamailio/kamailio/blob/a0d89214cf8296d30bacdf10a8732bc8826b2418/src/core/udp_server.c#L277) 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 or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3119#issuecomment-1140227414
You are receiving this because you are subscribed to this thread.

Message ID: <kamailio/kamailio/issues/3119/1140227414 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-dev/attachments/20220528/d220fa04/attachment.htm>