RouterOS already supports MLPPP as a client but I really think Mikrotik should implement MLPPP server. For those who are unaware of what MLPPP is, from Mikrotik wiki:
Multi-Link Point to Point Protocol (MP, Multi-Link PPP, MultiPPP or MLPPP) is a method of splitting, recombining, and sequencing data across multiple logical data links.
In a situation where we have multiple DSL links a pair of devices, performance by “widening the pipe” between two devices can be increased by using Multi-Link PPP, without going to a newer, more expensive technology.
Large packets are actually split into bits and sent evenly over ALL logical data links. This is done instantaneously with NO loss of bandwidth. It is important to understand that other end of the link needs to use the same protocol to recombine your data.
So it is better than load balance, because a single TCP connection (example, a download or a streaming) can be splitted between all internet connections while load balance would use only one upstream connection.
Mikrotik is widely used in developing countries and rural areas. By supporting MLPPP a RouterOS could be deployed in the field (rural or low density area) with many DSL or 3G (HDSPA) links and another one in a big city where the connectivity is better anoter RouterOS will join all packets splitted from all the connections and make them reach the internet. Providing MLPPP server would increase Mikrotik sales because it would place Mikrotik among only few products and competitors that provide this solution.
Can someone from mikrotik co. say anything about MLPPP server on mikrotik? Working, not possible, we are not working and we will never work on that, Work in progress, this option will be no available in ROS 6.xx, maybe in 7? Something???
MLPPP is really an underestimated feature, generally spoken. if anyone make a MLPPP implementation, capable of bundling different connection speeds, and to multiple servers at once, it could be one of the most valued redundancy and bundling protocol/feature ever made.
if MLPPP is so minor then cisco and juniper should abandoned that function. I have use MLPPP since ISDN dialup but those cisco routers are limited by aging and slow CPU, and to buy new cisco only for that and spend >5k $ is nonsense.
IMHO in ECMP scenario every single stream is forced onto single link (route decision first, route cache for subsequent packets with same src/dst).
Maybe better to spread at layer 2 with bonded EoIP links ..or even better vpls. Multiple IP on both side are probably needed for correct setup.
@Zorro - Bonding is ok to a degree and if you can get 2 or 3 lines with equal latency then you’ll end up with a bond performance somewhere near what you’re expecting. The problem comes when one of those lines differs by even a couple of ms and then you get out of order TCP packets and eventually it slowly falls apart. MLPPP would have a buffer of some form and would be able to re-order those packets correctly before sending them on their way. This is only really an issue for Round-Robin packet-level bonding but that’s the only way you’ll achieve bonded throughput on a single TCP stream.
YMMV, but we usually prefer per packet load-sharing (ppls), especially for customer-connections.
typically because: a) lower cpu overhead, b) independent layer3 connections (monitoring is easy), c) policies can decide for different paths in case
then again, while activating ppls is just an interface command on cisco or a policy-statement on juniper, in RouterOS it’s quite a combination of packet-marking and associated routes to achieve ppls.
