cor - connection oriented routing
Cor is a linux kernel patch (in development) which implements a layer 3+4 protocol for free community mesh networks. It is built operate in a 100% autoconf environment without any central administration. This is neccesary in order to both maintain freedom and make setup simple+quick. Cor tries to be resilient to failures, (D)DoS attacks and graceful under high load. It also tries to protect the privacy of its users, even tough this is rather weak.
How cor operates
Cor keeps a soft state of connections on every router. The reasons are basically:
The drawback of keeping this state is besically memory usage. However, people sometimes to the same with IP (NAT, stateful packet inspection, transparent proxying, ...).
- Packet headers are much smaller. Source routing and onion routing would otherwise cause huge header. Increasing the packet size to compensate is not possible for many realtime applications.
- The source address can be rewritten on every router, like IP NAT. This increases privacy.
- Flow-control can be done using windowing instead of congestion avoidance algorithms. This decreases reaction time on changing network conditions, like bursts. There are no retransmits which can waste bandwidth on earlier routers. Latency does not suffer from losses and becomes more deterministic.
- Packets can be split and reassembled on every router if their size does not much what the interface wants. Doing the same on layer 2 would cause more overhead and higher latencies. This is especially interesting for media like wlan where good performance may depend on feeding them with packet of their prefered size (which may be variably depending on link quality).
IP networks usually calculates routes in the network. In a cor network, they are calculates by the clients. This is called source routing. There reasons are:
- Good resilience requires either source routing or other (more invasive) ways to get feedback to the routing daemon.
- If you do the routing in the network, every router has to use the same metric. Otherwise you can get routing loops and netsplits. In cor there is a simple "list neighbor" command in the kernel, which will allows you to find routes. You can use any metric you want.
- Onion routing/encryption can only be done source routed. Without onion routing every router sees where you are connecting to. This would mean that a small fraction of misbehaving routers could block connections to nodes they do not like.
- Each client knows how much of the network it needs to know. If a client only wants to connect to next internet exit, there is no need to discover a potentially big network.
- The traffic for route discovery can be accounted to the clients.
- If you want to do routing in the network you can still do it. Just send the route back to the client and let the client establish the connection.
- Neighbor detection: DONE
- Connection establishing: DONE
- Route discovery: DONE
- Neighbor disconnect handling: DONE
- Improve memory handling and some other stuff: DONE
- Improve retransit/ACKs: DONE
- Limit control message queue size/soft queue full behaviour: DONE
- Buffer limits + QoS/Credit system: TESTING
- Project/Protocol docs: WIP
- Kernel <-> routing daemon interface: TESTING
- End-to-end error correction: TODO
- Runtime address changing: TODO
- Encryption: TODO