Connection Oriented Routing by Michael Blizek
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% auto conf environment without any central administration. This is necessary 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
Connection oriented
Cor keeps a soft state of connections on every router. The reasons are basically:
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).
The drawback of keeping this state is besically memory usage. However, people sometimes to the same with IP (NAT, stateful packet inspection, transparent proxying, ...).
Source routed
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.
Current state
MAC address randomisation: TODO
Bandwidth management: TODO
Testing/Benchmarking/Optimizing: TODO
Routing daemon - applications interface: TODO
Routing daemon runtime network topology changes: TODO
Multi-link connectivity to a single neighbor: TODO
Resilience: TODO
Encryption: TODO
In the upcoming articles i will be posting about
1.how I expect cor to scale
2.details about the protocol
3.internet exit strategies
4.comparison to other protocols
Help me with your up votes for development of COR too
thanks and lets build steem together
@blocktrades @dantheman