28 May
2022
28 May
'22
1:08 p.m.
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/d5c1b4693b6e47b4123b5f9…
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/d5c1b4693b6e47b4123b5f941…
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/a0d89214cf8296d30ba…
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(a)github.com>