[Nfd-dev] Fwd: Redundant data transmissions on error-prone links
Klaus Schneider
klaus at cs.arizona.edu
Mon Nov 28 17:11:20 PST 2016
Hi Philipp,
I agree with everything Hila said below. A loop is loosely defined as an
Interest that comes back to the router that sent it, whether it's on the
same interface or not.
However, there's a solution for your problem:
> 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.
>
So it sound like you not only want to duplicate the Interest, but also
the Data that comes back?
The default behavior is to have duplicated Interests, but only send back
the fastest arriving Data packet. Sometimes this is exactly what people
want.
> 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.
That's true when sending Interests on both parts redundantly. I think
the reason why people haven't complained about this earlier is that most
of the time, the forwarding strategy doesn't send Interests in parallel,
but either tries a "best" face first with the second as backup, or
splits up Interests to balance the load like in Multipath TCP.
> 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.
The easy solution is: At the forwarding strategy which duplicates the
Interests, give them a new nonce!
This presumably happens only once in the network and somewhere at the
edge (wireless access networks), so looping is not a problem.
You can do that by the "newNonce" option in the sendInterest() function:
> this->sendInterest(pitEntry, outFace, true);
Here's very simple implementation:
-
https://github.com/schneiderklaus/ndnSIM/blob/master/NFD/daemon/fw/broadcast-newnonce-strategy.hpp
-
https://github.com/schneiderklaus/ndnSIM/blob/master/NFD/daemon/fw/broadcast-newnonce-strategy.cpp
We have developed a more sophisticated strategy that uses this sort of
redundant forwarding, called the "Selective Parallel Strategy". It sends
interests out on multiple faces, but only when the expected payoff to
the application exceeds the cost of doing so:
http://conferences2.sigcomm.org/acm-icn/2015/proceedings/p137-schneider.pdf
Best regards,
Klaus
On 11/28/2016 11:55 AM, Hila Ben Abraham wrote:
>
> Hi Philipp,
>
> In the following topology a loop can be created when both A and D
> forward an Interest with the same nonce to B. In this topology the
> Interest can be received on two different faces.
> A-->B-->C-->D
> ^ |
> -----------
>
> Saying that, I agree that there might be cases in which processing
> 'looped' Interests can be helpful. The challenge in those cases is to
> identify those packets and prevent forever forwarded Interests. We
> started exploring differentiating strategy transmissions fron app
> transmissions as a possible solution to the problem, but it is still
> work in progress. You can find some more information in this report
> <http://openscholarship.wustl.edu/cse_research/910/> (section 5.2).
>
> Hila
>
> On Mon, Nov 28, 2016 at 11:24 AM Gusev, Peter <peter at remap.ucla.edu
> <mailto:peter at remap.ucla.edu>> wrote:
>
> Hi Philipp,
>
> On related note - I used forward error correction in NDN-RTC and
> published redundant data under “_parity” namespace for every video
> frame. This is not related to the problem with Interests you
> described, but relates to lossy links and retransmission/redundant
> data trade off.
>
> Thanks,
>
> --
> Peter Gusev
>
> peter at remap.ucla.edu <mailto:peter at remap.ucla.edu>
> +1 213 5872748 <tel:+1%20213-587-2748>
> peetonn_ (skype)
>
> Software Engineer/Programmer Analyst @ REMAP UCLA
>
> Video streaming/ICN networks/Creative Development
>
>> On Nov 27, 2016, at 11:35 PM, Philipp Moll
>> <philipp.moll at itec.aau.at <mailto:philipp.moll at itec.aau.at>> wrote:
>>
>>
>>
>> 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
>>
>> _______________________________________________
>> Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.edu <mailto:Nfd-dev at lists.cs.ucla.edu>
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu <mailto:Nfd-dev at lists.cs.ucla.edu>
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
>
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
More information about the Nfd-dev
mailing list