tinc - Mar 2014 - Routing

Hello,


I think routing could be improved in several ways, at least, there lacks some
documentation describing how Tinc routes packets.

In order to test Tinc, I setup the following virtual network:
- tinc 1.1pre9 with ExperimentalProtocol=yes
- use of network namespaces (actually python-nemu[1])
- star topology, where all nodes runs tinc except the center, which I use to
filter communications, simulating cuts or delays between specific nodes (use of
NFQUEUE)
- tinc TCP graph:

  m1 -- R ---- m3
         \    /
          `m6'
  with 100ms delay between R & m3

Here are my observations.

- UDP tunnels

Tinc only uses UDP for direct communication. What I mean is that if a source
node can't establish a UDP tunnel to the destination node, the packet will
go through TCP tunnels, even if there are UDP tunnels between intermediate
nodes.

- edge weight ignored ?

Tinc measures latency of edges but only when establishing a connection and then,
it even ignores it.

In the above example, packets between m1 & m3 should go via m6 for better
performance.


Regards,
Julien


[1] https://github.com/TheTincho/nemu/wiki

On Tue, Mar 25, 2014 at 07:56:57PM +0100, Julien Muchembled wrote:
> I think routing could be improved in several ways, at least, there lacks
some documentation describing how Tinc routes packets.
> 
> In order to test Tinc, I setup the following virtual network:
> - tinc 1.1pre9 with ExperimentalProtocol=yes
> - use of network namespaces (actually python-nemu[1])
> - star topology, where all nodes runs tinc except the center, which I use
to filter communications, simulating cuts or delays between specific nodes (use
of NFQUEUE)
> - tinc TCP graph:
> 
>   m1 -- R ---- m3
>          \    /
>           `m6'
>   with 100ms delay between R & m3
> 
> Here are my observations.
> 
> - UDP tunnels
> 
> Tinc only uses UDP for direct communication. What I mean is that if a
source node can't establish a UDP tunnel to the destination node, the packet
will go through TCP tunnels, even if there are UDP tunnels between intermediate
nodes.
If you don't use ExperimentalProtocol, then it will use UDP for intermediate
nodes. Forwarding SPTPS packets via intermediate nodes using UDP is not
implemented yet.
> - edge weight ignored ?
It is used, but paths with less hops are always preferred, even if the total
weight of a path with more hops would be less.
> Tinc measures latency of edges but only when establishing a connection and
then, it even ignores it.
It doesn't ignore it, but indeed it is only measured once.
> In the above example, packets between m1 & m3 should go via m6 for
better performance.
That would indeed be better. However, finding the optimum path in very large
VPNs would mean trying out every possible path and measuring the bandwidth
and/or latency. Currently, either a direct connection can be established, or
tinc falls back to the known-to-be working graph of meta-connections. If you
have any suggestions for an algorithm that can improve the routing decisions
tinc makes, let me know.

Note that tinc 1.1 has an AutoConnect option, which will automatically try to
make meta-connections. You can give it a number that tells tinc the number of
meta-connections to maintain. A good value is 3. This way, you automatically
create a graph without a star structure. With the latest 1.1pre version, tinc
will exchange public ECDSA keys (more on that in the next email) with other
nodes, so the meta-connections can be made without requiring to manually
distribute public keys beforehand.


-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus at tinc-vpn.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL:
<http://www.tinc-vpn.org/pipermail/tinc/attachments/20140325/22596b07/attachment.sig>