I don&#x27;t know about G.709, but in general coding, including FEC, is used on link layer, as there it is possible to finely adjust it to achieve throughput close to channel capacity and nearly zero packet loss ratio. It is the problem of channel estimation and rate control. In ideal world where users don&#x27;t contend and always transmit at the same rate, it would be enough.<p>TCP solves another problem: it adjusts source rate. It assumes that link layer works correctly and packets are not lost because incorrect rate (aka MCS) is used. Instead, packet loss is used as the indicator of congestion: users send data faster then it is possible to transmit it through bottleneck. It is hard to predict and packets are not lost with the same probability on the TCP timescale (RTT, around 50ms), so TCP can&#x27;t react in time and select the code that would correct losses without adding too much overhead. Thus, coding is not used on TCP layer.<p>That is why Google focuses on <i>latency</i>, not throughput. It is the area where you can benefit from FEC on transmission layer. Another problem QUIC can solve is bad rate control, such as Wi-Fi rate control on old Windows systems, but as wireless internet usage moves to mobile, and Google controls android, it becomes less of a problem as Google can just improve Wi-Fi rate control in Linux if it fails.