Closed flohoff closed 4 years ago
For what it's worth - I think this patch should be committed, but I also think this is - as it were - the least of your problems. The loss calculator currently looks - at an instant - what the current 'loss' is, but some things might (of course) arrive our of order. Hence, for a perfectly normal, working system, with no "loss" you might see e.g. a 5% 'noise' in your loss statistics. The real problem is that to adjust your flows correctly between two paths, ideally, you need to watch the loss very closely, and back of a lossy path fast - for that, you need a more accurate measure....
The point is that with 8 links your minimum loss is 82% so when a single link gains 1% of packet loss you go from 82% to 83%. In case a link is lossy and goes out of service your loss jumps around wildly. So currently the loss detection is completely useless when using "a lot of links". I'd consider a link with 5% loss to be unusable for anything with TCP.
Totally agree, but actually, I think its fairly broken even for only a small number of links unfortunately :-(
I've made my re-written mlvpn (ubond) public, please rip it appart it here https://github.com/markfoodyburton/ubond
@zehome If you think it's helpful, by all means put a link to it somewhere more prominent... and by all means have a go with it !
Ubond uses queues everywhere, and has a very different re-order buffer. (But it's documentation hasn't been updated)
Your milage WILL vary :-(
Hi, using the global sequence number to calculate the loss ratio for individual tunnels does not work. In case of a 8 tunnel setup the min loss is 82% as only every 8th packet will be on THAT tunnel.
Use the proto.seq not data_seq for loss calculation.
Flo