Under SpeedFusion, is Forward Error Correction only a consideration for performance to prevent packet retransmission being requested or is it also a consideration for data integrity? With FEC set to off, is there any concern that data could be corrupted over the speedfusion tunnel?
There is a bandwidth and hardware resources overhead to FEC. Have a read of @Erik_deBie 's article here Introducing Forward Error Correction (FEC)
As you say its all about reducing the need for data retransmission (in the case of TCP) and improving the result of UDP stream integrity.
Yes of course, packet loss on any WAN link has the potentially to cause data corruption. Its why WAN smoothing was introduced originally and FEC is in my mind an improvement on WAN smoothing.
2 Likes
I haven’t thought about file corruption in ~20 years so I’m not sure I have this right. I don’t have much bandwidth to spare, so the overhead of FEC is a definite concern.
Back then there was a period of a month or so over a satellite link when downloading or uploading a file via a web browser would occasionally be corrupt. I don’t remember the details though.
If I read the article correctly, the primary purpose of speedfusion FEC is for running applications such as video transmission that send over UDP which doesn’t have a mechanism for checking and requesting retransmit of packets lost, so video frames would be lost, etc. So UDP over the speedfusion UDP tunnel doesn’t have another mechanism for retransmit.
Most of what I use is over TCP - http/https, ftp/ftps, ssh/sftp, imap/smtp
My understanding is that TCP will request retransmit of a lost packet, so with TCP transferring a file over the speedfusion UDP tunnel, the TCP layer will request retransmit if a packet doesn’t make it to the destination.
Is the application level TCP protocol enough here, or is SpeedFusion FEC needed also to make sure no corruption occurs in a browser download or upload for example over https or an ftp or sftp or email transfer over TCP?
With
TCP source → SpeedFusion UDP Wan1 + SpeedFusion UDP Wan2 (?) → TCP destination
if a packet doesn’t make it correctly over Wan2, is there a risk that SpeeFusion would corrupt the file in a way that the destination TCP wouldn’t re-request the packet from the TCP source?
If you have great WAN links with no packet loss and are predominately using TCP you don’t need any additional error correction.
Even if your WAN links suffer a touch of packet loss unless you are doing something very real time (eg VoIP Call or Live Video broadcast), then typically if data integrity is a requirement the protocol in use is TCP and it will re-transmit lost packets / frames as needed.
However, TCP re-transmission can be clunky, time consuming and can have serious bandwidth implications - reducing the amount of usable bandwidth because of the amount of data that has to be re-transmitted…
What I do for small office deployments over single cellular is this : deploy and monitor. If the customer complains VoIP is robotic - turn on WAN smoothing (or nowadays with FE 8 FEC) in a sub tunnel just for VoiP traffic.
Do the same for any additional applications suffering the effects from packet loss - if its every app add more cellular connectivity (different mobile operators)/ WANs and turn on suspension time after packet loss on each WAN link so that lossy links don’t affect the tunnel(s) as a whole.
4 Likes