Hi,
I wanted to get clarity on a rather basic question:
When using Kamailio with TCP, is it possible to end up with fragments of multiple SIP messages in a single "on-the-wire" packet?
From what I understand, the purpose of Kamailio's setting TCP_NODELAY is
to prevent such bundling--as much as it is possible to control the fragmentation/packetisation behaviour of the transport protocol from a user-space application.
-- Alex
Alex Balashov abalashov@evaristesys.com writes:
I wanted to get clarity on a rather basic question:
When using Kamailio with TCP, is it possible to end up with fragments of multiple SIP messages in a single "on-the-wire" packet?
From what I understand, the purpose of Kamailio's setting TCP_NODELAY is to prevent such bundling--as much as it is possible to control the fragmentation/packetisation behaviour of the transport protocol from a user-space application.
From a standards point of view, there is no real meaning to the end
applications to what bytes of user payload are in which TCP segments within packets. TCP_NODELAY is a hint that coalescing small writes is not needed, to avoid a time delay waiting until that next chunk of data might arrive. However, that's not a guarantee.
My question to you might be why you care, or if you are having a problem.
On Tue, Jan 07, 2020 at 03:29:13PM -0500, Greg Troxel wrote:
there is no real meaning to the end applications to what bytes of user payload are in which TCP segments within packets.
No, not to the application. But perhaps to third-party packet analysis systems which reconstruct SIP state from what they see on the wire. :-)
-- Alex
Alex Balashov abalashov@evaristesys.com writes:
On Tue, Jan 07, 2020 at 03:29:13PM -0500, Greg Troxel wrote:
there is no real meaning to the end applications to what bytes of user payload are in which TCP segments within packets.
No, not to the application. But perhaps to third-party packet analysis systems which reconstruct SIP state from what they see on the wire. :-)
They need to reassemble segments and cope anyway. There's a long history of evading firewalls by creative fragmentation.
Yes, I understand the formal properties of TCP and that anything is possible. Thank you for explaining.
What I am asking is whether Kamailio takes pains to ensure--I suppose, if one must be labouriously precise, to maximise the probability--that multiple SIP messages are packaged into separate packets. To the extent it can do so.
On Tue, Jan 07, 2020 at 05:50:18PM -0500, Greg Troxel wrote:
Alex Balashov abalashov@evaristesys.com writes:
On Tue, Jan 07, 2020 at 03:29:13PM -0500, Greg Troxel wrote:
there is no real meaning to the end applications to what bytes of user payload are in which TCP segments within packets.
No, not to the application. But perhaps to third-party packet analysis systems which reconstruct SIP state from what they see on the wire. :-)
They need to reassemble segments and cope anyway. There's a long history of evading firewalls by creative fragmentation.
Alex Balashov abalashov@evaristesys.com writes:
Yes, I understand the formal properties of TCP and that anything is possible. Thank you for explaining.
What I am asking is whether Kamailio takes pains to ensure--I suppose, if one must be labouriously precise, to maximise the probability--that multiple SIP messages are packaged into separate packets. To the extent it can do so.
A fair question. I would expect that it would arrange to call write() on an entire message, to avoid multiple packets. I would be surprised to see a deliberate attempt to delay between writes of different messages. I would try using ktrace/ktruss/strace or whatever and look at the write messages and their timing. (I realize you are asking if anyone else really knows.)
Hello Alex,
I just briefly looked into it, did not digged into the code much. Kamailio is doing some queuing in TCP async mode (default) e.g. if there is some delay in sending out the data.
One idea - have a look to the core parameters
- tcp_wq_blk_size
- tcp_conn_wq_max
and change them to see if it makes a difference in your particular situation.
Cheers,
Henning
Am 08.01.20 um 00:39 schrieb Alex Balashov:
Yes, I understand the formal properties of TCP and that anything is possible. Thank you for explaining.
What I am asking is whether Kamailio takes pains to ensure--I suppose, if one must be labouriously precise, to maximise the probability--that multiple SIP messages are packaged into separate packets. To the extent it can do so.
On Tue, Jan 07, 2020 at 05:50:18PM -0500, Greg Troxel wrote:
Alex Balashov abalashov@evaristesys.com writes:
On Tue, Jan 07, 2020 at 03:29:13PM -0500, Greg Troxel wrote:
there is no real meaning to the end applications to what bytes of user payload are in which TCP segments within packets.
No, not to the application. But perhaps to third-party packet analysis systems which reconstruct SIP state from what they see on the wire. :-)
They need to reassemble segments and cope anyway. There's a long history of evading firewalls by creative fragmentation.
Henning,
Thanks a lot for looking into it! I appreciate it.
On Thu, Jan 09, 2020 at 04:51:32PM +0000, Henning Westerholt wrote:
Hello Alex,
I just briefly looked into it, did not digged into the code much. Kamailio is doing some queuing in TCP async mode (default) e.g. if there is some delay in sending out the data.
One idea - have a look to the core parameters
tcp_wq_blk_size
tcp_conn_wq_max
and change them to see if it makes a difference in your particular situation.
Cheers,
Henning
Am 08.01.20 um 00:39 schrieb Alex Balashov:
Yes, I understand the formal properties of TCP and that anything is possible. Thank you for explaining.
What I am asking is whether Kamailio takes pains to ensure--I suppose, if one must be labouriously precise, to maximise the probability--that multiple SIP messages are packaged into separate packets. To the extent it can do so.
On Tue, Jan 07, 2020 at 05:50:18PM -0500, Greg Troxel wrote:
Alex Balashov abalashov@evaristesys.com writes:
On Tue, Jan 07, 2020 at 03:29:13PM -0500, Greg Troxel wrote:
there is no real meaning to the end applications to what bytes of user payload are in which TCP segments within packets.
No, not to the application. But perhaps to third-party packet analysis systems which reconstruct SIP state from what they see on the wire. :-)
They need to reassemble segments and cope anyway. There's a long history of evading firewalls by creative fragmentation.
-- Kamailio Merchandising - https://skalatan.de/merchandising/ Kamailio services - https://skalatan.de/services Henning Westerholt - https://skalatan.de/blog/
-
Alex Balashov -
Greg Troxel -
Henning Westerholt