What is a minimum MTU?

[Guus Sliepen]

On Tue, Oct 12, 2010 at 05:44:47PM -0500, Rob Townley wrote:

> I know MTU is Maximum Transmission Unit, but what is a "minimum
> Maximum Transmission Unit"?
> Shows up in tinc.log as "Packet for PC5 (ip.x.y.z port 655) larger
> than minimum MTU, forwarding via TCP".

Tinc tries to discover the actual MTU of the path between two nodes by sending
probe packets of various sizes.  It can detect a lower bound and upper bound
for the true MTU. The lower bound (minimum MTU) is the biggest probe that has
been succesfully sent and received back, the upper bound (maximum MTU) is
decreased whenever a RFC compliant router sends an ICMP Packet Too Big message
in response to a probe that is larger than the true MTU.

Tinc will only send UDP packets that are smaller than the minimum MTU to the
destination, because there is no guarantee that larger packets will arrive.
When the packet is bigger than the maximum MTU, it will either send its own
ICMP Packet Too Big messages, or fragment the packet (only for IPv4 packets
without DF bit set). For packets that are within the minimum and maximum MTU,
it will forward packets via TCP.

If UDP communication is not possible, no probes will succeed, so the minimum
MTU will be 0 and the maximum MTU will be 1514 by default, and all packets are
thus forwarded via TCP, as it should.

Tinc keeps sending probes after the real MTU has been determined (by default
once a minute) to check whether UDP communication is still possible.

> Ping times between tinc nodes are outrageously slow at times ...
> greater than 1 second.
> Othertimes, the same link will be 1ms.  For entire weekends, i could
> ping from all 3 laptops out the wireless router into a switch into
> another NAT to the Linux tinc server to an inside node without a
> dropped packet and always under 5ms.  Then for no apparent reason, it
> becomes slow - extremely slow and windows takes forever to logon and
> frustrations rise.

I understand. It could be that temporary disruptions of the network that caused
the MTU probes to fail, resulting in tinc falling back to TCP.  It should
normally try to reestablish UDP connections after an hour.

I do not know why it would be so slow. But others have experienced such
behaviour in the past as well. In any case, could you run "tincd -n <netname>
-kUSR2" on the tinc server and send me the results?

-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus at tinc-vpn.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20101013/f77fb94f/attachment.pgp>