[Nfd-dev] Redundant data transmissions on error-prone links

[Philipp Moll]

Dear NDN Developers,

I’m currently thinking of methods for redundant data transmission for 
real-time applications. In the case of (some) real-time applications a 
retransmission of lost packets is not reasonable. Therefore I would like 
to investigate redundant data transmission over multiple links. I think 
this could be useful especially in wireless access networks with higher 
loss rates.

My idea is, to duplicate Interests and send them out over multiple faces 
(similar to Multicast). This duplication means, that the same Interest 
will also arrive over multiple faces on some hosts. In order to achieve 
a redundant data transmission, it is necessary that the Interest is 
registered in the PIT from all in-faces.

I recognized, that the design of the Interest processing pipeline only 
allows that one Interest arrives from one face. If it arrives from two 
or more faces, only the first is processed, the others are classified as 
looping Interests, what is disadvantageous for my intent.

I was thinking and testing a lot in order to understand this pipeline 
design, but I can’t see, why Interests with the same nonce are 
classified as looping if they arrive over different faces. In my 
opinion, a loop can only occur if two Interests with the same nonce 
arrive over the same face.

This behavior also brings disadvantages in other cases. Imagine two 
nodes are connected over two links, a low latency low-bandwidth link, 
and a high latency high-bandwidth link. If a forwarding strategy like 
Multicast is used, only the low bandwidth link would be used because the 
Interest is faster at the receiver at this link. The Interest which 
traveled over the high bandwidth link is classified as looping, which 
means that the high-bandwidth link is not used, even if there are 
congestions on the low-bandwidth link.

I would like to ask, if anyone can explain the reason for this pipeline 
design or could give me advices for implementing redundant data 
transmissions.

Best regards,

Philipp Moll

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20161128/e7505152/attachment.html>