Thanks for pointing out that part of RFC 3261. I wonder how this this would work with a UDP-registered phone, and an assumption that it will have taken precautions to also be reachable over TCP. Not an issue in IPv4 if you Do Fragment, but possibly breaking for IPv6 reachability. (That's why I reported as a bug, not a feature request.) -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3119#issuecomment-1132635313 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3119/1132635313(a)github.com>

Iirc, TCP is mandatory, but I can say that many phones don't do it. For more details on UDP-To-TCP specs, you may ask on IETF SIP Core group or SIP Implementors mailing lists. I labeled it feature request because it is not a bug in the existing C code per se, but something missing as an implementation. After all there are many IETF RFCs that are not implemented in Kamailio, lack of having them is not a bug, but missing features. We work based on community collaboration, usually who needs a feature implements it and makes PRs to get it merge or helps to implement it (e.g., collaborates with other developers). We also close the feature requests that don't get interest from developers, because the tracker is open for everyone to submit and it will get filled with requests which will make it hard to focus on actual issues after a while. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3119#issuecomment-1132652411 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3119/1132652411(a)github.com>

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>

I got one thing wrong, and that saves bundles of work. Here's from [experimental code](https://gitlab.com/0cpm/mtugames/-/blob/master/submit-mtu-hilo.c), ``` /* * Confusingly, ip(7) states * * IP_MTU (since Linux 2.2) * Retrieve the current known path MTU of the current socket. * Returns an integer. IP_MTU is valid only for getsockopt(2) and * can be employed only when the socket has been connected. * * Similarly, ipv6(7) states * * IPV6_MTU * getsockopt(): Retrieve the current known path MTU of the current * socket. Valid only when the socket has been connected. Returns * an integer. * * setsockopt(): Set the MTU to be used for the socket. The MTU * is limited by the device MTU or the path MTU when path MTU * discovery is enabled. Argument is a pointer to integer. * * This suggests that IP_MTU is a socket property. However, it makes * more sense as a shared global property, which indeed seems to apply: * * The ipv6(7) entry for IPV6_MTU_DISCOVER references IP_MTU_DISCOVER; * the ip(7) entry for IP_MTU_DISCOVER states * * IP_MTU_DISCOVER (since Linux 2.2) * When PMTU discovery is enabled, the kernel automatically keeps track * of the path MTU per destination host. When it is connected to a * specific peer with connect(2), the currently known path MTU can be * retrieved conveniently using the IP_MTU socket option (e.g., after * an EMSGSIZE error occurred). The path MTU may change over time. * For connectionless sockets with many destinations, the new MTU for a * given destination can also be accessed using the error queue (see * IP_RECVERR). A new error will be queued for every incoming MTU update. * * While MTU discovery is in progress, initial packets from datagram * sockets may be dropped. Applications using UDP should be aware * of this and not take it into account for their packet retransmit strategy. * * Retransmission is common in UDP applications. Ideally, the IP_RECVERR or * IPV6_RECVERR are used to immediately resend, without wait for timers to * expire; and without limiting the number of Path MTU lessens learnt to the * number of timer rounds. * * For IPv6, where fragmenttion is required to accomodate the Path MTU, and * for unconnected applications, the lessons from Path MTU discovery are of * major impact on their behaviour; we should always let the socket fragment * frames when so desired, so: * * IP_MTU_DISCOVER (since Linux 2.2) * IP_PMTUDISC_WANT will fragment a datagram if needed according to the * path MTU, [IPv4-only: or will set the don't-fragment flag otherwise]. * * Path MTU discovery value Meaning * IP_PMTUDISC_WANT Use per-route settings. * IP_PMTUDISC_DONT Never do Path MTU Discovery. * IP_PMTUDISC_DO Always do Path MTU Discovery. * IP_PMTUDISC_PROBE Set DF but ignore Path MTU. * */ ``` *I'm documenting it here, so that the knowledge is not lost on the project. This is difficult stuff.* It would seem that Path MTU discovery is not maintained per socket (which would benefit locality and proper cleanup of the knowledge) but as a global kernel property for the route (which benefits reuse of the knowledge, IWO a useful form of caching). ## Conclusions for Kamailio on IPv6 1. The idea to [set different MTU values for two sockets](https://gitlab.com/0cpm/mtugames/-/blob/master/submit-mtu-hilo.c) failed for unconnected sockets. And to have multiple MTUs you need unconnected sockets. 2. This means that the idea of a secondary socket is not going to work in Kamailio either. 3. It does seem to be true that the kernel keeps track of Path MTU *if asked*. 4. For IPv6, not learning from Path MTU feedback (ICMPv6 Packet too Big) always leads to the same effect; once a frame is dropped it is *always lost, regardless of resends*. Kamailio comes across as unstable, especially because SIP message sizes vary and make some things works while others fail. 5. Note that it *never causes packet drops* if Path MTU discovery is enabled for IPv6; there is just a reason for fragmentation, which at most is an efficiency issue. Note that IPv6 has no "Don't Fragment" option; this behaviour is always active. 6. And it means that it *can only add value* to enable Path MTU discovery for IPv6. Even if `sysctl()` could make such a setting, Kamailio stability demands this for IPv6, AFAIK. 7. Path MTU discovery for IPv4 continues to be an option and a matter of taste, unlike for IPv6. ## Perfection for Kamailio over IPv6 1. The first contact with an IPv6 host may drop with *Packet too Big* over ICMPv6 messages. This may happen when the kernel drops knowledge. Some SIP processing is an hour apart, and may cause this dropping of knowledge. 2. Use of `IPV6_RECVERR` enables immediate resending, with improved Path MTU knowledge. This involves an extra polling mechanism, which is beyond my reach. This also links into the `tm` logic and goes beyond my reach. For `sl` replies there will probably be a 2nd round if Path MTU problems arise, because the reply was sent-then-forgotten, and needs to wait for another round. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3119#issuecomment-1152876570 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3119/1152876570(a)github.com>

Probably this should be closed, if there is anything new to be discussed/added, a new item can be created. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3119#issuecomment-1228372046 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3119/1228372046(a)github.com>

Closed #3119 as completed. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3119#event-7267039983 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issue/3119/issue_event/7267039983(a)github.com>