https://redmine.named-data.net/https://redmine.named-data.net/favicon.ico?14759811232017-01-22T10:24:24ZNDN project issue tracking systemNFD - Feature #3931: Implement NDNLP Link Reliability Protocolhttps://redmine.named-data.net/issues/3931?journal_id=181842017-01-22T10:24:24ZEric Newberryenewberry@cs.ucla.edu
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-5 priority-2 priority-default closed child" href="/issues/3823">Feature #3823</a>: Congestion Control: design Local Link Loss Detection</i> added</li></ul> NFD - Feature #3931: Implement NDNLP Link Reliability Protocolhttps://redmine.named-data.net/issues/3931?journal_id=181862017-01-22T10:24:49ZEric Newberryenewberry@cs.ucla.edu
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>In Progress</i></li><li><strong>% Done</strong> changed from <i>0</i> to <i>10</i></li></ul> NFD - Feature #3931: Implement NDNLP Link Reliability Protocolhttps://redmine.named-data.net/issues/3931?journal_id=182222017-01-26T13:09:00ZEric Newberryenewberry@cs.ucla.edu
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Code review</i></li><li><strong>% Done</strong> changed from <i>10</i> to <i>100</i></li></ul> NFD - Feature #3931: Implement NDNLP Link Reliability Protocolhttps://redmine.named-data.net/issues/3931?journal_id=182822017-02-04T20:50:42ZEric Newberryenewberry@cs.ucla.edu
<ul></ul><p>I noticed that the current implementation of NDNLP in ndn-cxx does not put repeatable fields of the same TLV-TYPE in the order they were added to the packet. I will submit a patch shortly that changes this behavior. I believe that inserting them in the order they are added works best for unit testing Acks in the reliability feature.</p>
NFD - Feature #3931: Implement NDNLP Link Reliability Protocolhttps://redmine.named-data.net/issues/3931?journal_id=185832017-03-21T21:16:32ZAlex Afanasyev
<ul></ul><p>I still have a question about <a href="https://gerrit.named-data.net/#/c/3626/">https://gerrit.named-data.net/#/c/3626/</a>. When this commit is merged, what are the implications? Is reliability gets suddenly enabled on all/some links? If not, how can it be enabled?</p>
NFD - Feature #3931: Implement NDNLP Link Reliability Protocolhttps://redmine.named-data.net/issues/3931?journal_id=185842017-03-22T07:42:52ZEric Newberryenewberry@cs.ucla.edu
<ul></ul><p>Alex Afanasyev wrote:</p>
<blockquote>
<p>I still have a question about <a href="https://gerrit.named-data.net/#/c/3626/">https://gerrit.named-data.net/#/c/3626/</a>. When this commit is merged, what are the implications? Is reliability gets suddenly enabled on all/some links? If not, how can it be enabled?</p>
</blockquote>
<p>Like the other link services, this feature is enabled using a boolean value in GenericLinkService::Options. In this case, the option is further nested under LpReliability::Options. By default, the feature is disabled. Eventually, there should be a flag or option added to the faces/update management command to control this feature.</p>
NFD - Feature #3931: Implement NDNLP Link Reliability Protocolhttps://redmine.named-data.net/issues/3931?journal_id=185852017-03-22T09:09:20ZEric Newberryenewberry@cs.ucla.edu
<ul></ul><p>I was thinking that it might be better to enable reliability by default for certain types of links (depending on the Transport type - perhaps UnicastUdpTransport and EthernetTransport). In addition, I think that it should be possible to enable/disable this feature through FaceMgmt. However, I believe this should be an issue for a later commit, since the current implementation of LpReliability in <a href="https://gerrit.named-data.net/#/c/3626">https://gerrit.named-data.net/#/c/3626</a> is disabled by default.</p>
NFD - Feature #3931: Implement NDNLP Link Reliability Protocolhttps://redmine.named-data.net/issues/3931?journal_id=185862017-03-22T09:15:23ZJunxiao Shi
<ul><li><strong>Blocks</strong> <i><a class="issue tracker-2 status-5 priority-2 priority-default closed" href="/issues/4003">Feature #4003</a>: FaceMgmt: enable link reliability</i> added</li></ul> NFD - Feature #3931: Implement NDNLP Link Reliability Protocolhttps://redmine.named-data.net/issues/3931?journal_id=186002017-03-22T11:45:13ZEric Newberryenewberry@cs.ucla.edu
<ul></ul><p>Eric Newberry wrote:</p>
<blockquote>
<p>I was thinking that it might be better to enable reliability by default for certain types of links (depending on the Transport type - perhaps UnicastUdpTransport and EthernetTransport).</p>
</blockquote>
<p>I realized that EthernetTransport is multicast, so disregard that one.</p>
NFD - Feature #3931: Implement NDNLP Link Reliability Protocolhttps://redmine.named-data.net/issues/3931?journal_id=187592017-03-30T12:47:01ZEric Newberryenewberry@cs.ucla.edu
<ul><li><strong>% Done</strong> changed from <i>100</i> to <i>80</i></li></ul><p>Most of the code for the reliability feature has been merged, although Klaus, Beichuan, and I have agreed to change the retransmission design again. I will post more details about the design change in <a class="issue tracker-2 status-5 priority-2 priority-default closed child" title="Feature: Congestion Control: design Local Link Loss Detection (Closed)" href="https://redmine.named-data.net/issues/3823">#3823</a> soon.</p>
NFD - Feature #3931: Implement NDNLP Link Reliability Protocolhttps://redmine.named-data.net/issues/3931?journal_id=188932017-04-14T19:07:46ZEric Newberryenewberry@cs.ucla.edu
<ul><li><strong>% Done</strong> changed from <i>80</i> to <i>100</i></li></ul><p>The new design using TxSequence numbers in Acks has been uploaded for code review.</p>
NFD - Feature #3931: Implement NDNLP Link Reliability Protocolhttps://redmine.named-data.net/issues/3931?journal_id=194112017-06-04T20:23:04ZJunxiao Shi
<ul></ul><p>I'm looking at <a href="https://gerrit.named-data.net/3848">https://gerrit.named-data.net/3848</a> patchset7 and I feel that the data structure is inefficient.<br>
Having separate <code>m_unackedFrags</code> and <code>m_netPkts</code> containers and linking them via TxSequenceNumber result in unnecessary lookups: you'll need a <code>std::map</code> lookup to find a linked entry.<br>
Instead, they can be linked via iterators and pointers:</p>
<ul>
<li>UnackedFrag has a <code>shared_ptr</code> to NetPkt. NetPkt has a set of iterators into <code>m_unackedFrags</code>.</li>
<li>When a fragment is acknowledged, find it in <code>m_unackedFrags</code>, delete its iterator in the NetPkt.
If this the last TxSequenceNumber of a NetPkt, the set of iterators in NetPkt would be empty, and it's time to increment NetPkt-level counters.
Finally, delete from <code>m_unackedFrags</code>.</li>
<li>When the algorithm retransmits a fragment, a new TxSequenceNumber would be assigned.
In this operation, the fragment's iterator in NetPkt should be updated.</li>
<li>When the algorithm decides to give up on a fragment, other fragments belonging to the same NetPkt should be discarded as well.
They can be found via the set of iterators in NetPkt.</li>
</ul>
<p>The above procedure also makes no assumption on a particular fragmentation protocol that uses the SequenceNumber field, and eliminates the conditionals about whether the NetPkt is fragmented or unfragmented.<br>
It simply treats the fragments passed to handleOutgoing call as belonging to the same NetPkt.</p>
NFD - Feature #3931: Implement NDNLP Link Reliability Protocolhttps://redmine.named-data.net/issues/3931?journal_id=195772017-06-26T02:46:17ZJunxiao Shi
<ul></ul><p>From <a href="https://gerrit.named-data.net/#/c/3848/25/daemon/face/lp-reliability.cpp">https://gerrit.named-data.net/#/c/3848/25/daemon/face/lp-reliability.cpp</a>:</p>
<pre><code> pkt.list<lp::AckField>(); // If this isn't here, the next add will cause all other fields to not encode
pkt.add<lp::AckField>(ackSeq);
</code></pre>
<p>I cannot reproduce this problem using the minimal snippet below:</p>
<pre><code>// g++ -std=c++11 -o x x.cpp $(pkg-config --cflags --libs libndn-cxx)
#include <ndn-cxx/lp/packet.hpp>
#include <iostream>
int
main()
{
ndn::lp::Packet lpPacket;
lpPacket.set<ndn::lp::FragIndexField>(0x8000);
lpPacket.add<ndn::lp::AckField>(0x7001);
lpPacket.add<ndn::lp::AckField>(0x7002);
ndn::Block b = lpPacket.wireEncode();
std::cout.write(reinterpret_cast<const char*>(b.wire()), b.size());
}
</code></pre>
<p>Its output is as expected:</p>
<pre><code>64 LpPacket 10
52 FragIndex 02
80 00
fd 03 44 Ack 02
70 01
fd 03 44 Ack 02
70 02
</code></pre>
<p>You may try to find the problem by:</p>
<ol>
<li>Collect the sequence of function calls invoked on the <code>lp::Packet</code> in question.</li>
<li>Confirm the problem exists in this sequence. If it doesn't, this is possibly a memory error (dangling pointer, etc), use <code>valgrind</code> to debug the original program.</li>
<li>Reduce the sequence until the problem disappears.</li>
<li>Find the minimal sequence that causes the problem. If you haven't found the problem by then, post a snippet of that minimal sequence and I'll have a look.</li>
</ol>
NFD - Feature #3931: Implement NDNLP Link Reliability Protocolhttps://redmine.named-data.net/issues/3931?journal_id=195822017-06-26T12:16:19ZEric Newberryenewberry@cs.ucla.edu
<ul></ul><p>It appears that inserting an Ack was causing all later non-Ack elements to be removed from the packet. I found that adding "m_wire.parse()" to <code>lp::Packet::add</code> just before finding the position of the new sub-element fixed the issue. I'll push a patch to Gerrit shortly.</p>
NFD - Feature #3931: Implement NDNLP Link Reliability Protocolhttps://redmine.named-data.net/issues/3931?journal_id=195842017-06-26T16:30:08ZJunxiao Shi
<ul></ul><blockquote>
<p>inserting an Ack was causing all later non-Ack elements to be removed from the packet</p>
</blockquote>
<p>I cannot reproduce this issue.<br>
I'm trying with this snippet:</p>
<pre><code>// g++ -std=c++11 -o x x.cpp $(pkg-config --cflags --libs libndn-cxx)
#include <ndn-cxx/lp/packet.hpp>
#include <iostream>
int
main()
{
ndn::lp::Packet lpPacket;
//lpPacket.set<ndn::lp::FragIndexField>(0x8000);
lpPacket.add<ndn::lp::AckField>(0x7001);
lpPacket.add<ndn::lp::AckField>(0x7002);
lpPacket.set<ndn::lp::FragCountField>(0x9000);
//lpPacket.add<ndn::lp::FragCountField>(0x9000);
//lpPacket.set<ndn::lp::TxSequenceField>(0x9800);
//lpPacket.add<ndn::lp::TxSequenceField>(0x9800);
ndn::Block b = lpPacket.wireEncode();
std::cout.write(reinterpret_cast<const char*>(b.wire()), b.size());
}
</code></pre>
<p>I've tried commenting and uncommenting the FragIndex line, using one of four lines to set/add a "later" field in which "later" is interpreted as "added later" or "appears later in encoding".<br>
None of them makes any field disappear.</p>
<p>In any case, this belongs to a separate issue. Please report a bug in ndn-cxx tracker with a minimal snippet to reproduce, before attempting any fix.</p>
NFD - Feature #3931: Implement NDNLP Link Reliability Protocolhttps://redmine.named-data.net/issues/3931?journal_id=195872017-06-26T21:36:01ZEric Newberryenewberry@cs.ucla.edu
<ul></ul><p>Junxiao, try putting</p>
<pre><code>std::cout << lpPacket.wireEncode().size() << std::endl;
</code></pre>
<p>between the Ack adds. The size of the packet should become 8, only including the LpPacket TLV-TYPE and TLV-LENGTH, as well as the Ack.</p>
NFD - Feature #3931: Implement NDNLP Link Reliability Protocolhttps://redmine.named-data.net/issues/3931?journal_id=195942017-06-27T17:29:27ZEric Newberryenewberry@cs.ucla.edu
<ul><li><strong>Blocked by</strong> <i><a class="issue tracker-1 status-5 priority-2 priority-default closed" href="/issues/4156">Bug #4156</a>: Encoding LpPackets after adding repeating field causes other fields to be lost</i> added</li></ul> NFD - Feature #3931: Implement NDNLP Link Reliability Protocolhttps://redmine.named-data.net/issues/3931?journal_id=197942017-07-09T10:23:22ZJunxiao Shi
<ul><li><strong>Status</strong> changed from <i>Code review</i> to <i>Closed</i></li><li><strong>Start date</strong> deleted (<del><i>01/22/2017</i></del>)</li></ul>