Limit eCAL UDP Package size to MTU size?

[KerstinKeller]

eCAL Fragments UDP data to be send (be it on the data or monitoring layer) to the maximum UDP package size. However, on some systems, the default max udp package size is lower, atm it can be adjusted in ecal.ini

[FlorianReimold]

Let's first clarify what this issue is about:

• Limit UDP datagram size to system maximum
• Limit UDP datagram size to MTU

Those 2 things are different. Or is this meant to be a discussion?

[KerstinKeller]

This is part of #1165. The current default (which seems to be configurable via ecal.ini), causes problems on MacOS. So I guess this is somewhat of a discussion, if we should limit to system maximum (however we want to find out which is the system maximum), or try and limit to MTU size, and see where this leads us performance wise.

Also we need to evaluate anyways, if eCAL differentiates betwwen application (payload) and registration samples. The problems on MacOS suggested that there is already a problem with registration samples.

[FlorianReimold]

1. Actual MTU:

   • Very difficult to detect
   • can change when the route changes
   • Will always result in the most efficient datagram size
   • there is no such thing as the route for multicast, so one would probably have to detect the smallest MTU of all routes

2. Estimated MTU (hardcoded)

   • Will probably be 1500byte - a couple of headers, that we expect
   • Easy to implement
   • Probably sufficient for almost all use cases
   • Our chosen size will rarely be the optimum:
     • We cannot make use use of jumbo frames
     • We either always substract all headers (like VLAN, IPSec etc.) that we know of and therefore usually not fill the entire ethernet frame
     • ... or we don't substract those, but that will lead to IP fragmentation in cases when they are present
     • I think localhost traffic isn't bound to 1500byte MTU (but not sure)

3. System maximum

   • Probably harder to implement than a hardcoded estimated MTU
   • Will be different from OS to OS at least (see the reason why this ticket exists)
   • Can systems with smaller Datagram Size Maximums still read big UDP datagrams?
     • If not, we would have to implement a Max-UDP-Datagram-Size-Announcement-Service
   • We still get low-efficiency IP fragmentation

I already hate solution 1 and 3 and thus vote for 2 😊

[FlorianReimold]

Entire Ethernet Frame size: max 1518 bytes

Here is what I think we should actually consider:

• Ethernet header + trailer: 18 bytes.
• VLAN tag (if present): 4 bytes
• IPv6 header (if used): 40 bytes (fixed)
• IPv4 header (if used): Typically 20 bytes for a simple IPv4 header. Can be blown up to 60 bytes with Options
• UDP header: 8 bytes.

There may be other protocols involved, like IPsec or other tunnel protocols.

So we have:

• 1448 bytes (considering IPv6 and everything else, but ignoring that you actually can make the IPv4 header even bigger)
• 1428 bytes (considering a fully populated IPv4 header)