This technique is known as RLNC. It works quite well but it's not the only optimal erasure code, there are others.
Unfortunately, RLNC implementations are patent-encumbered in the US, so good luck using this "simple" linear algebra.
Is your satellite link oscillating? Improving goodput using network coding
11–15 of 15 posts
Re: Is your satellite link oscillating? Improving goodput using network coding
#12Congratulations, you have rediscovered a problem described in a 14 year old RFC: http://tools.ietf.org/html/rfc3135
Re: Is your satellite link oscillating? Improving goodput using network coding
#13Clever solution to a unique problem! > So how does this help with queue oscillation? Simple: We generate a few extra "spare" combination packets, so that we now have more equations than variables. This means we can afford to lose a few combination packets in overflowing queues or elsewhere – and still get all of our original packets back. If I understand correctly, this would also work with a more traditional coding…
"Network code" as described here isn't the academic definition, I think he's just describing colloquially "i'm using a code in my network". The technical definition is a Packet Erasure Channel [1], which any erasure code [2] can deal with. Network coding is a more unexplored technique where routers in the network combine packets in various ways that are better than regular routing: see the example at [3]. [1] http://…
Their phrasing appears to state they use TCP/NC, a network coding-based variant of TCP introduced in an academic paper by (some of) the same people behind this initiative:
Re: Is your satellite link oscillating? Improving goodput using network coding
#14A few random thoughts/questions:
- This sounds similar to the incast problem which occurs in datacenters, but this happens on consumer Internet - cool.
- After reading both this post and the TCP/NC paper, it seems to me like TCP/NC is unfair to vanilla TCP. If all TCP/NC does is send the same number of packets, but the packets are "more sophisticated" encodings of the original data, link utilization would be the same. So apparently, TCP/NC is more aggressive than vanilla TCP, and that's fine, but I think it should be acknowledged (haha). When they say stuff like "TCP doesn’t see the packet loss, and as a result there’s no need for the TCP senders to reduce their sending rates", it's a bit unclear what they mean - you can just as well modify the TCP stack to ignore the packet loss and not reduce the sending rate, without network coding.
- Why not use TCP termination? You could install a performance-enhancing proxy at the Sat gate, and make sure the link is always 100% utilized.
- "Let’s increase the queue memory" - I thought this should theoretically work. See for example http://yuba.stanford.edu/~nickm/papers/sigcomm2004.pdf. If folks familiar with the apnic effort are reading, I would love to know if they tried such measures and what happened.
- Could CoDel improve the situation here?
Re: Is your satellite link oscillating? Improving goodput using network coding
#15Thank you for the interesting questions and thoughts on this topic!
We tried to answer some of these in a longer comment on the APNIC blog:
https://blog.apnic.net/2015/03/13/is-your-satellite-link-osc...
Disclaimer: I am one of developers of the RLNC kernel module at Steinwurf ApS.