-
Notifications
You must be signed in to change notification settings - Fork 833
mode 0 vs mode 1
Yancey Wang edited this page Oct 1, 2024
·
5 revisions
In UDPspeeder. we have 2 fec modes:
-
--mode 0
, which has a user-space packet merger-and-splitter, which tries to merge and cut udp datagrams to equal size packets. -
--mode 1
, which doesn't have merger-and-splitter. This mode is similiar to what kcptun does.
because of packet merger-and-splitter:
- FEC will be more traffic-efficient, since we don't need to consider packet of unequal size
- user usually don't need to consider MTU problems at upper level application (e.g openvpn/wireguard/shadowsocks). If UDPspeeder see packet too large, it will automatically cut it into smaller size.
- in this sense
--mode 0
is much more trouble-free and user friendly - whether too large or not is determined by the
--mtu
option
- in this sense
- it follows a "if FEC fails, original packets also lost scheme".
- For example assume there is 20 original packets + redundant 10 packets, if >=11 packets are lost, all the 30 are lost.
- Because of this reason, UDPspeeder might make your packet-loss worse.
- This is the reason why
-f 20:1
is not a good idea with--mode 0
because of no packet merger-and-splitter:
- typically more bandwitdh because fec need to encode packet of unequal size
- upper-level program need to guaranteed the packet sending to UDPspeeder doesn't exceed certain MTU
- the
--mtu
option only works in warning purpose. It doesn't have real effect.
- the
- it follows a "if FEC fails, original packets not lost scheme".
- parameter like
-f 20:1
is fine with--mode 0
- parameter like
for calculating after-fec packet loss for mode 0 and mode 1, see:
https://github.com/wangyu-/UDPspeeder/wiki/After-FEC-Packet-loss