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". 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. Here is the log contents during a simple ping (when in Debug 5) usually associated (not 100%) with very long echo times about 1 second for what essentially is a LAN. Receiving packet of 62 bytes (tun mode) Sending packet of 90 bytes (tun mode) Packet for PC5 (ip.x.y.z port 655) larger than minimum MTU, forwarding via TCP tinc 1.13 on windows clients to tinc 1.13 on Linux server behind a NAT. So essentially the Tablets require (at times) more than 20x the time for an echo request to a local "LAN" node than to www.google.com. Google is 40ms, the local node is 800ms - 5000ms.
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>
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>
On Wed, Oct 13, 2010 at 2:21 PM, Rob Townley <rob.townley at gmail.com> wrote:> 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.So maximum MTU is the theoretical maximum packet size which may not include all headers needed along the route. The following terminology could substitute for "minimum MTU": - "true MTU" - "empirical MTU" - "actual MTU" - "known MTU" - "tested 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.Makes perfect sense.>> 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.i notice MYSELF (the Linux sever) has a minimum MTU of 0 at times and will watch for a corresponding increase in latency. Not sure why it would change, but it does.>> Tinc keeps sending probes after the real MTU has been determined (by default >> once a minute) to check whether UDP communication is still possible.If those are the PING PONG probes, i do not see them once a minute. What setting is determines the 1 minute interval?>> 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.Guus, after printing out your email and reading while on walk outside in beautiful weather here in Omaha, NE, i realized it made perfect sense and that you wrote it extremely well. Thank You.
On Wed, Oct 13, 2010 at 05:00:46PM -0500, Rob Townley wrote:> >> 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. > i notice MYSELF (the Linux sever) has a minimum MTU of 0 at times and > will watch for > a corresponding increase in latency. Not sure why it would change, > but it does."MYSELF" should always have a minimum MTU of 0, since a node does not send packets to itself, and hence never performs PMTU discovery on itself. Whatever the value is, it should not have any effect on packets to other nodes.> >> Tinc keeps sending probes after the real MTU has been determined (by default > >> once a minute) to check whether UDP communication is still possible. > > If those are the PING PONG probes, i do not see them once a minute. > What setting is determines the 1 minute interval?The "PING PONG probes" are sent to test whether the TCP connections are still alive. Both TCP and UDP probes are sent with PingInterval seconds inbetween.> Guus, after printing out your email and reading while on walk outside > in beautiful weather here in Omaha, NE, i realized it made perfect > sense and that you wrote it extremely well. Thank You.Fresh air is always good :) -- 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/20101014/0b6b31ff/attachment.pgp>