Random Linear Encoding

An interesting development for those of a geeky disposition but with potentially significant benefits for data transmission in complex and bandwidth constrained networks.

Watch the video

Get yer bloody hair cut!


Read more

[browser-shot width=”600″ url=”http://www.en.aau.dk/News+and+Events/News//math-can-make-the-internet-5-10-times-faster.cid102747″] [browser-shot width=”600″ url=”http://www.gizmag.com/random-linear-network-coding/33038/”]



Newest Most Voted
Inline Feedbacks
View all comments
Red Trousers
Red Trousers
August 5, 2014 1:28 am

Oddly, I understood about 30% (I probably exaggerate) of that. Sad day for a Cavalry officer, but I need to get bread on the table for some extremely brainy people that I work with, and this sort of stuff is what we do, so I need to understand a bit and to be able to open doors for them.

Software Defined Networks are getting critical mass.

TD, there are far weirder academics.

August 5, 2014 7:53 am

Well, this has applications, but they are going to be on the margins of the internet rather than in the core: no one will adopt anything patentable and the data rates in the core are such additional processing is not going to be welcomed. I’m surprised they were using video as an example of a TCP application, since this stuff is usually sent via UDP to avoid TCP slowdowns due to packet loss, with forward error correction layered on top.

For CNR, this would be very useful for data transmission. Speaking as an “operator”, I’d want to know how we can constrain the packet routing for debugging purposes, and worry about the fragments of encrypted traffic that will inevitably arrive at “bad” nodes being used to break keys over the long term.

Will Sheward
Will Sheward
August 5, 2014 8:19 am

OK, interesting but not as relevant to the constrained network situations that military deployments have to contend with as you might think. There are three problems that these sort of networks (using HF or SatCom as the bearer) have to cope with; lack of bandwidth, latency and the unreliable nature of the connection.

Bandwidth is the least of the three problems. SatCom systems actually have pretty good bandwidth availability, at least for the text based messaging systems that militaries rely on (I could write a book about why they’ll continue to use text over video) and the recent adoption of wideband HF (WBHF) is giving SatCom denied environments (and militaries) a decent sized pipe.

Latency is a real issue that no amount of clever tech is going to fix, unless someone finds a way around the laws of physics. Data travels at a certain speed and SatCom entails very long physical round trips to get a data packet from A to B even if A and B are close together, as the data has to go via C (a satellite which could be thousands of miles away).

Then there’s the unreliable nature of the connection. In messaging, a lot of the data cost is establishing the link between A and B in the first place (lots of handshakes, checking security etc) so if the link goes up and down a lot then you can end up waiting a long time to resume a conversation and you’d be surprised how unreliable even SatCom is (HF’s a nightmare). We’ve done a bunch of trials messaging over an Iridium connection from NATO E3s and the connection drops every time they do an air to air refuelling, when they bank in certain directions and quite often when the handover occurs from one satellite in the constellation to another. It’s a real pain, especially when the operator is half way through sending a message to “fire” or “stop firing” :-)

Military messaging systems already do a lot of very clever stuff to get around these limitations, like prioritising data packets so that urgent messages leapfrog less urgent ones in a message queue and insisting on proper message acknowledgements.

So, although better handling of data to improve bandwidth is going to be of some use, it’s surprising how little relevance some commercial developments have in the weird world of military messaging.

August 5, 2014 10:04 am

@RT: software defined networks may be getting big within servers, but over the WAN it’s only a few massive players using them. Facebook and Google may traffic engineer dynamic MPLS LSP’s, but no one else really has those sorts of requirements, and building massive virtual chassis’s out of commodity switches happens but is nuts :-)

On the other hand, if you are talking more about radios and software defined waveforms, you are probably right. I assume you are anyway, given who I think you work for :-)

August 5, 2014 10:29 am

TD – fine by me – defence technology doesn’t always start with an MOD contract. Anyway if this wasn’t here you’d only be posting something about RAF 2030 (this week’s JDW reports) or some such.

August 5, 2014 8:07 pm

Um,…yeah. What wf said.

Dangerous Dave
Dangerous Dave
August 11, 2014 2:19 pm

Yup, I’m good with general comms and data tech. making it’s way in here (also general automotive engineering and, of course ISO Containers :-) ). What is appearing in the non-military world usually appears in Green/Blue at some point up to a decade or so later, anyway.