MTU and Fragmentation

2 posts / 0 new
Last post
Last seen: 10 years 10 months ago
Joined: 06/14/2013
Posts: 1
MTU and Fragmentation


We are using a 3G cellular link to send data back from a remote device. I had a problem where I was seeing Readers/Writers being discovered by Spy, but no samples would ever come through. Upon closer inspection, it appeared that discovery wasn't in fact ever completing, although Spy showed the readers/writers. Turning on verbosity showed that there was some strange errors on type matching. Our typecode is roughly ~3-4k.

What I finally determined is that the MTU over the cellular link is not 1500, but is 1438. I ran some tests between Windows DDS apps and found everything worked great after I set the network adapters to 1438.

The problem is, our actualy endpoint is running a prebuilt version of VxWorks 6.3 and is fixed at a 1500 MTU. Is there any way I can force DDS to fragment data at a lower size, or does the network interface take care of that? Keep in mind it's not just the data that needs to be fragmented at a lower MTU, but all the discovery traffic also.



Gerardo Pardo's picture
Last seen: 1 week 2 days ago
Joined: 06/02/2010
Posts: 601

Hello Graham,

I believe this is possible with RTI Connext DDS version 5.0.0, but not in previous versions.

The approach I suggest below will force RTI DDS to fragment at a configured message size. This is not the same as the IP fragmentation that the IP layer normally does at 1500 bytes. Instead the approach below forces DDS to never send to the transport a message larger than the specified size.  In other words, normally on a UDP transport DDS will give the transport messages up to the 64KB limit that UDP can handle. Then the IP layer fragments it into multiple IP fragments each no larger than the 1500B MTU and re-asembles them on the other side. To RTI DDS this looks like the transport is able to send the whole 64KB so from RTI  DDS's point of view the MTU of the UDP transport is 64KB.

RTI DDS allows you to modify the transport MTU meaning the max size of any message that it will ask the transport to send. Using this feature you can force DDS to never ask the transport to send a message larger than the 1438 Bytes you mentioned. In this situation the IP layer will not be doing any fragmentation/reassembly.

As far as I recall you would need to do two things:

1) Configure yoru transport to have the desired MTU.  This is done using the transport property  dds.transport.UDPv4.builtin.parent.message_size_max, see Table 15.2 Properties for the Builtin UDPv4 Transport in the RTi Connext DDS User's Manual

2) Configure discovery, specifically the built-in Publication and buill-in Subscription DataWriters, to use an asynchronous publisher such that it is able to fragment the data. You do this using the DiscoveryConfigQosPolicyin the DomainParticipant. Specifically setting the attributes publication_writer_publish_mode, subscription_writer_publish_mode, and asynchronous_publisher.