n2n
n2n copied to clipboard
ntop
Consider about add FEC(Forward Error Correction)
n2n v2.4 it good enough in most network enviroment,but in some occasion(slow connection or long distance) it cause packet loss. consider about FEC please, thanks!
refer: https://github.com/wangyu-/tinyfecVPN https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction I hope it will help
Can you please test the development version of n2n (2.5?). Since n2n encapsulates TCP traffic, TCP itself is expected to handle retransmissions
I have to confess that Reed-Solomon Forward Error Correction would indeed be a charming thing to see in n2n... have thought about it, too. But would it really help to prevent the packet loss you describe? Is the resulting packet overhead worth it?
In a first approach, I would wish for a more sophisticated checksum or message hash or signature just to at least realiably detect transmission errors (#82).
So basically you are suggesting to send some crafted packets with redundant information in order to be able to rebuild a possibly lost datagram? Please note that doing this in a network with systematic packet drops could increase the overall network load and further deteriorate the network performance. I think it is a job for the transport protocol (TCP) to schedule retransmissions properly.
Just wondering: Do you plan to send FEC data in-band, i.e. mingled with payload, or out-of-band?
Before talking about the implementation, what are the advantages of implementing FEC? Delivering/resending the packets is a job of the transport protocol. Are you focused on UDP-only use cases? I can't see why FEC is needed on a TCP connection being tunneled into n2n.
+1 for leaving handling of completely lost packets to encapsulated TCP, or more general, to the encapsulated protocol. In case of UDP, somebody made a choice and might have known about connection-less protocol's risks. I am not sure if n2n should be held accountable for encapsulated protocol's properties.
The only benefit I can see would materialize on a per-packet basis: FEC allowed to detect (#82 ...) and additionally correct transmission errors within that very same packet – possibly eliminating the need to re-transmit or discard this specific packet. How often might this happen?
However, tamper detection (not necessarily correction) is important also from a security point of view.
Plus FEC with UDP could lead to lower latency (skip re-transmission) and possible higher bandwidth, even more with IPv6 due to less hops. I think this would be useful as an option additional to standard TCP.
https://github.com/skywind3000/kcp kcp used FEC. I support Logan007's idea.
FEC should happen after encryption, on already encrypted data, right?
Maybe Reed-Solomon? Any other preferences?
Shall FEC bits be distributed all over the bit stream or concentrated at some point in the packet (header, start of data, end of data)?
In case of Reed-Solomon, any suggestions for a reasonable block size?
While digging through Error Detection, ECC, and FEC, I also took a look on already existing mechanisms in UDP/IP. And it seems that UDP/IPv4 optionally contains a checksum whereas IP itself check-sums the header only. So, the whole UDP/IPv4 stack relies on error detection and/or correction performed on the layers below. For example, ethernet frames use some 32-bit CRC.
But then, the following question arises: At what point in the stack errors could occur? Of what good would a packet-wise FEC on UDP level be? My guess is, that erroneous packets will most probably never see the light of the IP layer, they will be dropped before.
So, I need to revise my own view to the whole FEC topic. FEC might not make sense on a per packet basis. FEC could only be of help if it is distributed over several packets to reconstruct dropped packets as initially proposed by @ChangeTheWorld.
This feature – if still desirable – requires some overview of several packets' complete content including their headers plus some management such as to count them, deciding after how many packets a missing one will be reconstructed from the FEC data to inject it in the network stack. So, an implementation can only be connected to the more general packet assembly process.
In addition to the computation overhead of FEC such as Reed-Solomon, the data overhead is not negligible and will lead to a lower MTU. In case of encapsulated TCP, this all might not be worth the efforts because the sender will resend the packet anyway as soon as the retransmission timeout occurs. Even if the total amount of FEC data overhead would hit the (optimum) size of saved retransmissions, there is no bandwidth saving. Only latency could drop below the retransmission time, as @0xA1B2 already pointed out. Is it worth it?
Putting that potential advantage aside, FEC would only make sense for encapsulated UDP (and maybe others, do not know much about those). In that case, n2n would need to parse the packets for their payload, not to mention MTU related implications for dividing packet handling into pure TCP in full packets on the one hand and UDP with additional FEC data on the other hand.
As of now, my own cost-benefit analysis of FEC tends to become more uncertain and slightly turns towards more cost than benefit.
I am curious about other thoughts and – acknowledging the possibility of being spoiled in this respect – especially keen on experiences of link-quality and packet drop rates.
This might be interested for gamers which uses n2n for VLAN. KCP was originly used a lot in [?] to defeat the QoS by ISP when access oversea servers(no longer the case,but still useful to battle againt the random drop from some cheap ISP). According to https://github.com/skywind3000/kcp#商业案例 A lot game now uses it. The original KCP code is aggressive so might be not just take it.
This seems a rare use case,but atleast in some scenario it's nice to have it.
