Bug #2283

High retransmissions level problem

Added by Peter Gusev over 5 years ago. Updated over 5 years ago.

Start date:
Due date:
% Done:


Estimated time:


Sometimes (quite often), NDN-RTC demonstrates big amount of interest retransmissions (up to 50%).
During analysis, it turned out that the main reason for retransmissions is not lost data or interests, rather - lack of consumer's synchronization with producer.
Consumer doesn't know how early interests are issued for the new data. This affects generation delay (time interval between interest arrival and data generation) for each data segment to be bigger than interest's retransmission timer and eventually causes interest retransmission.

Picture 1 (test1.png) shows graph of generation delays for individual segments. The buffer size for this run was set to be 1000ms. Average value for generation delay is 607.4790658 and the percentage of retransmissions is 47.85%, i.e. almost each interest was retransmitted. Such big generation delay explains these retransmissions, as, according to the algorithm, retransmission timer for interests is set to be half of the size of the buffer (i.e. 500ms). That's why average generation delay of ~600ms invokes retransmissions. This situation could be avoid if only consumer knew that she's issuing interests too early for consumer and hold back interests generation till some moment (maybe ~550ms).

Picture 2 (2.png) shows the same graph of the same test case, but different run. This time consumer got closer to the actual data generation point - average generation delay is 310ms and retransmissions are only 0.95% (i.e. almost none). This case can be considered more desirable than the first one. However, consumer didn't do any adjustments or synchronizations with producer. Better synchronization happened accidentally.

There is a need in robust synchronization mechanism which exploits as much data producer can publish as possible and does not involve direct producer-consumer interaction.


2.png (696 KB) 2.png Low generation delay Peter Gusev, 12/09/2014 05:41 PM
test1.png (581 KB) test1.png High generation delay Peter Gusev, 12/09/2014 05:41 PM

Updated by Peter Gusev over 5 years ago

  • Category set to Task
  • Assignee set to Peter Gusev

Updated by Peter Gusev over 5 years ago

  • Status changed from New to Closed
  • % Done changed from 0 to 100

Also available in: Atom PDF