What is a minimum MTU?

[Rob Townley]

On Wed, Oct 13, 2010 at 10:25 AM, Guus Sliepen <guus at tinc-vpn.org> wrote:
> 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.

i am not sure i understand, i would have thought there is minimum
packet size as there is a minimum ethernet size.
>
> 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.
Again, this just seems backwards, i will have to research more.

>
> 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.

Sometimes, it is even 5 seconds.  This may have come across as too
negative.  i think tinc is cool and enjoy it, i am frustrated i have
not figured it out yet.


> 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.

Is there some way to ask tinc to reestablish UDP connections much more
frequently?
The Tablets (including wireless card) may go into a low power mode on
battery, but the network itself is never down.


>
> 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?

Attached are too files, one is when it seems normal.  The other is
probably when the multisecond echo requests occur.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BUGS-Jitter.log
Type: application/octet-stream
Size: 2378 bytes
Desc: not available
URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20101013/5946212e/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BUGS-Jitter-pmtu.log
Type: application/octet-stream
Size: 3532 bytes
Desc: not available
URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20101013/5946212e/attachment-0001.obj>