[Xorp-hackers] TCP sockets and packet splitting

[Bruce Simpson]

Hi Victor,

Thanks for your question about the socket4.xif interface.

I'm assuming that you are using XRL encapsulated in TCP over the 
loopback interface, as these are the default settings for the libxipc 
library, and you are sending UDP packets (raw IP uses a different XRL 
interface, and host based TCP would perform MTU discovery for you).

Normally the use of TCP as the IPC transport for XRL shouldn't have any 
issues, other than the issues which already exist with TCP to do with 
head-of-line blocking, and those are endemic to the TCP protocol anyway. 
With most TCP/IP implementations, the MTU of the loopback interface will 
be 65535 bytes. As you probably know already, the segment size used by a 
TCP session is going to be negotiated upfront during the 3 way handshake.

Victor Faion wrote:
> Hello,
>
> I've been using XORP's socket library through the XrlSocket4V0p1Client 
> interface. I've noticed that when sending large packets sometimes XORP 
> will split them up into smaller ones and then on the receiving end I 
> have to piece them together manually. Is this the expected behaviour 
> of the FEA or just a configuration mismatch between my interface's MTU 
> and XORP? Also when sending the same packet it is not always split the 
> same way. On the sending end, the FEA accepts the whole packet without 
> complaining so I expected it would piece it together on the receiving 
> end. Is the programmer suposed to deal with these fragmentation issues?

The socket4.xif interface will *not* perform any MTU based fragmentation 
for your sending interface to the best of my knowledge. I believe you 
still need to use the IfMgrXrlMirror classes to get information about 
the interface you are trying to use, i.e. the MTU.

This is pretty analogous to using a host's TCP/IP stack directly using 
the BSD sockets API -- you would still need to know the MTU anyway, even 
if you were writing a simple UDP/IP application, and even in that 
instance, a host stack would not perform Path MTU Discovery for you.

I had to look though. This code is *not* going to coalesce the buffers 
used by UDP transmission as this may break message boundaries:
    
http://cvsweb.xorp.org/cgi-bin/cvsweb.cgi/xorp/fea/data_plane/io/io_tcpudp_socket.cc?rev=1.27
...see function IoTcpUdpSocket::send().

In summary, I believe the behaviour you are seeing is expected, and that 
you need to ensure the packets you are trying to send fit in the 
interface's MTU.

thanks,
BMS