wangyu-
commented
4 years ago
- Since there will not be packet losses always, how can I turn FEC off and on dynamically? Otherwise, I can modify OpenVPN config on the fly and reload the tunnel. My scenario is Hub-Spoke where there is one Hub and 70+ spokes. I can not turn FEC off at server side as at a given time one of the spokes will be experiencing packet loss. Please advise.
there is an option --pipe allows you to change parameters without restart the program. Although at the moment it doesn't allow you toggle the disable-fec option (I can consider add this in furture), but it allows you to change parameter to --mode 1 --f1:0 which is similar to completely disable fec.
- Latency increasing from 10-15 ms without UDPSpeeder to 27-30 ms with UDPSpeeder is normal with 1:3,2:4,8:6,20:10?
This is completely as expected. There is an option name --timeout with a default value of 10(ms). That option means, UDPspeeder will try to collect as many packet as possible in the 10ms before doing the FEC. Before doing FEC all packets are held in UDPspeeder buffer, so a maximum latency of 10ms is introduced for both direction.
ping measures roundtrip latency, so 10ms maximum is doubled to 20ms maximal. (might be less, just 20ms maximal)
- Is 1:3,2:4,8:6,20:10 with default timeout value is an overkill when we only want to manage 10% packet loss?
I think it depends on what is the max after-FEC-packet loss you can accept. If you are sure the max packet loss is 10%, and never increase above, then it might be a bit overkilled.
The after-FEC packet loss is calculate-able, please check this link: https://github.com/wangyu-/UDPspeeder/wiki/FEC%E4%B8%A2%E5%8C%85%E7%8E%87%E8%AE%A1%E7%AE%97
- How to choose ideal values depending on bandwidth available and the upper limit of packet loss that we want to mitigate? e.g. if a link has more than 20% packet loss, I would tear the tunnel down over that link and prefer traffic over the other tunnel to keep CPU and bandwidth utilisation in check.
This is a similiar question as above, I don't have a general answer. Depends on how much packet loss can you accept, and how much bandwidth do you have, how much computing power do you have. Maybe you need to findout what is the bottleneck(bandwidth or cpu?), and you balance between the bottoleneck and packet-loss.
- Why do I get low transfer rate on SCP over UDPSpeeder as compared to a direct OpenVPN tunnel?
according to your measurement on the second link:
Tunnel 2:
The other link belongs to different ISPs at both the ends, hence there is jitter of 42ms, ~7% loss, max latency 445 ms, avg latency 59.837 ms and min latency 9.543 ms for a long duration ping (over 450 pings)
The jitter value over UDPSpeeder is 329.92 ms while max latency rises to 7643 ms without any packet loss.The speed of TCP depends on both packet-loss and RTT(latency). In this case you reduced packets, but increased a lot of RTT. Althouth I can't really unserstand why your latency increased so much, but the speed of TCP is kind of explainable.
Below are some comments not directly answering your question:
1
--fix-latency is currenly marked as a developer option, it doesn't fully implement what it claims to do. It might signifcantly increase latency in some case, I suggest you to not use it.
2
on your first link the latency is fully explainable, but it's not very explainable on the second. I will try to explain a bit:
The average lantency is explainable. In mode 0, all packet in a FEC group are equal. For example, if you have 20 packets, and you are using -f20:10, then on the encoding side UDPspeeder generated 30 equal packets for the original packets and send them via internet (the original 20 packets are NOT send). On the decoding side, UDPspeeder will collect at least 20 FEC packets (of the 30) to recover the 20 original. Since the redunancy of 20:10 is small. You after-FEC-latency is detemined by the slowest packet of the first 20 FEC packets you collect. You lanteny is kind of dragged back by the slowest one (in first 20 of 30).
I suggest you to remove --fix-latency and test with a very high reduncy such as -f10:30 (just for a test, I am not suggesting you to use this on a production environment). I think in this case, your average latency may be significantly reduce. This might help you understand the relation between latency and redundancy on a high jitter link, then you can figure out more by yourself.
The max latency increased is very unexplainable, unless:
- your CPU is full
- your link has a larger latency when you are sending more packets. (this is common on wifi environments)
3
--mode 1 can protentially reduce latency. In the above example, the after-FEC-latency is no longer (fully) determinged by the slowest packet of the first 20 FEC packets you collect.
The disadvantage of mode 1 over mode 0 is that mode 1 doesn't support user space packet fragmenting. With --mode 1 you have to guarentee the packets you feed into UDPspeeder is smaller than MTU. But since you are using openvpn, openvpn itself can do user space packet fragmenting, so there is no problem for your case.
Currently there is no good english document that explains the difference of --mode in-depth, I will add some later. (there are serveral in chinese though.)
codemarauder
Hello,
This is not an issue, but question / clarification. I couldn't find any mailing list or forum for UDPSpeeder, thus posting here.
I am testing OpenVPN over UDPspeeder in a live setup as below:
OpenVPN has following parameters on both the tunnels:
UDPSpeeder arguments for Tunnel 1 are as below:
/usr/bin/udpspeeder -s --fec 1:3,2:4,8:6,20:10 --fix-latency --disable-obscure -l 1xx.x7x.x8x.xx:4095 -r 127.0.0.1:443 --mode 0 --report 10 --interval 0 --mtu 1250 --sock-buf 1024 --decode-buf 2000 --queue-len 200 --log-level 4 --fifo /tmp/udpspeeder-hotunnel.fifo/usr/bin/udpspeeder -c --fec 1:3,2:4,8:6,20:10 --fix-latency --disable-obscure -l 0.0.0.0:3333 -r 1xx.x2x.8xx.1xx:4095 --mode 0 --report 60 --interval 0 --mtu 1250 --sock-buf 1024 --decode-buf 2000 --queue-len 200 --log-level 4 --fifo /tmp/udpspeeder-hotunnel.fifoPing without UDPSpeeder:
Ping with UDPSpeeder:
The jitter value over UDPSpeeder is 329.92 ms while max latency rises to 7643 ms without any packet loss.
Below are the arguments for UDPSpeeder for Tunnel 2:
/usr/bin/udpspeeder -s --fec 1:3,2:4,8:6,20:10 --fix-latency --disable-obscure -l 2xx.2xx.2xx.2x4:4096 -r 127.0.0.1:444 --mode 0 --report 10 --interval 0 --mtu 1250 --sock-buf 1024 --decode-buf 2000 --queue-len 200 --log-level 4 --fifo /tmp/udpspeeder-hotunnel2.fifo/usr/bin/udpspeeder -c --fec 1:3,2:4,8:6,20:10 --fix-latency --disable-obscure -l 0.0.0.0:3334 -r 2xx.x6x.x2x.2xx:4096 --mode 0 --report 60 --interval 0 --mtu 1250 --sock-buf 1024 --decode-buf 2000 --queue-len 200 --log-level 4 --fifo /tmp/udpspeeder-hotunnel2.fifoPing without UDPSpeeder on Tunnel 2:
Ping with UDPSpeeder on Tunnel 2:
SCP over UDPSpeeder on Tunnel 2:
SCP without UDPSpeeder on Tunnel 2:
UDPSpeeder report from server side:
I can see that packet is not lost and UDPSpeeder tries hard though latency increased to 7643 ms.
The questions:
1:3,2:4,8:6,20:10?1:3,2:4,8:6,20:10with default timeout value is an overkill when we only want to manage 10% packet loss?Thanks in advance.
PS: I have created init script and uci config file for OpenWrt. Will submit a PR soon.