This is very interesting. There are already Error Correcting Codes used widely from ECC RAM, to HDDs, to CDs. These are generally statically generated, ie the data is not streaming - you know up front the data that is going to be written and protected.
Protecting streaming data packets up to 1500 bytes in length, by using previous and later packets is something I've never even imagined. Kudos to the scientists behind it!
The magnitude of gains are interesting - perhaps partially due to lack of retransmissions at the MAC level, and perhaps due to TCP re-transmissions that would be triggered across the entire network.
They seem to be keeping the mechanism under wraps and licensing it out under NDA - that makes me a bit sad and skeptical about when we'll get to actually benefit from this - but these scientists have definitely earned their reward...
Wonder what encoding they're using, and if it reduces the error detection within a single packet.
This kind of idea is already used quite extensively in video conferencing (at the UDP layer), known as "forward error correction". If enabled, every n packets are XORed together, allowing the receiver to recover from a single lost packet in that group, at the cost of a 1/n increase in bandwidth.
I am interested in the size of the gains as well, and hope more details come out.
In Video, unless you are talking about MPEG2, packets are not equal. There are I (Intra) and P (predicted) frames. I-frames are a large spatially compressed frame, while P-frames are small and temporally compressed.
Other than that, depending on motion compensation, the size of the video frames may vary, i.e., high motion may create larger sized frames and low motion will create smaller sized frames.
Size of frames are also dependent on resolution so, if you vary that then you get even higher variability in frame sizes.
Furthermore, if you vary the frame rate then you will see packet generation times are irregular. The same logic of motion can be applied here. If there is low motion, reduce the frame rate, and if there is high motion then increase the frame rate.
Typically, audio has equal-sized packets and regular packetization intervals (however, even with audio there are exceptions, for instance silence suppression in audio telephony)
Comments
This is very interesting. There are already Error Correcting Codes used widely from ECC RAM, to HDDs, to CDs. These are generally statically generated, ie the data is not streaming - you know up front the data that is going to be written and protected.
Protecting streaming data packets up to 1500 bytes in length, by using previous and later packets is something I've never even imagined. Kudos to the scientists behind it!
The magnitude of gains are interesting - perhaps partially due to lack of retransmissions at the MAC level, and perhaps due to TCP re-transmissions that would be triggered across the entire network.
They seem to be keeping the mechanism under wraps and licensing it out under NDA - that makes me a bit sad and skeptical about when we'll get to actually benefit from this - but these scientists have definitely earned their reward...
Wonder what encoding they're using, and if it reduces the error detection within a single packet.
This kind of idea is already used quite extensively in video conferencing (at the UDP layer), known as "forward error correction". If enabled, every n packets are XORed together, allowing the receiver to recover from a single lost packet in that group, at the cost of a 1/n increase in bandwidth.
I am interested in the size of the gains as well, and hope more details come out.
Presumably video packets have the advantage of being fixed in size, and repeating in regular intervals.
Dealing with irregular sized packets at irregular intervals is a more interesting problem :)
In Video, unless you are talking about MPEG2, packets are not equal. There are I (Intra) and P (predicted) frames. I-frames are a large spatially compressed frame, while P-frames are small and temporally compressed.
Other than that, depending on motion compensation, the size of the video frames may vary, i.e., high motion may create larger sized frames and low motion will create smaller sized frames.
Size of frames are also dependent on resolution so, if you vary that then you get even higher variability in frame sizes.
Furthermore, if you vary the frame rate then you will see packet generation times are irregular. The same logic of motion can be applied here. If there is low motion, reduce the frame rate, and if there is high motion then increase the frame rate.
Typically, audio has equal-sized packets and regular packetization intervals (however, even with audio there are exceptions, for instance silence suppression in audio telephony)