Project

General

Profile

Actions

Bug #4603

closed

ndncatchunks: number of lost packets does not always match number of pipeline window decreases

Added by Nicholas Gordon over 6 years ago. Updated almost 6 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Start date:
Due date:
% Done:

100%

Estimated time:

Description

To avoid a long title:

When running ndncatchunks with --aimd-disable-cwa, which should cause each lost packet to cause a pipeline window size decrease, this is not always the case. Doing some experiments, we can collect logs like this:

Total # of lost/retransmitted segments: 147 (caused 159 window decreases)

We don't know if this is a bug or not.


Related issues 1 (0 open1 closed)

Related to ndn-tools - Bug #4861: ndncatchunks: improve performance on high-delay or low-quality linksClosed03/02/2019

Actions
Actions #1

Updated by Davide Pesavento over 6 years ago

tl;dr: I don't think it's a bug.

Explanation:

Total # of lost/retransmitted segments: 147 (caused 159 window decreases)

(The "lost" in there can be misleading, we should probably delete it. Or maybe it wasn't a good idea to combine the two counters in one line like that.)

The 1st number in that line is in fact the number of segments that have been retransmitted.
The 2nd number is the number of loss events, i.e. the number of times that the pipeline considered a segment as timed out, based on RTO. Note that # of "loss events" is not necessarily equal to # of "window decreases" (I believe it should be "window decreases" >= "loss events") because of congestion marks, which cause a decrease but are not "loss events".

The reason why the # of retransmitted segments can be lower than the # of loss events is that a Data reply can still be received after the pipeline has timed out the corresponding Interest and queued it for retransmission. At that point, the loss event counter has been incremented but the retransmission counter is incremented only if the retransmission actually takes place. The retransmission might not happen immediately because there might not be space in the cwnd. The retransmission is cancelled if the Data is received before the retransmission is attempted.

Actions #2

Updated by Nicholas Gordon over 6 years ago

  • Assignee set to Ryan Wickman
Actions #3

Updated by Davide Pesavento over 6 years ago

  • Subject changed from chunks: Number of lost packets does not always match number of pipeline window decreases to ndncatchunks: number of lost packets does not always match number of pipeline window decreases
Actions #4

Updated by Anonymous almost 6 years ago

  • Status changed from New to Code review
  • Assignee changed from Ryan Wickman to Anonymous
Actions #5

Updated by Anonymous almost 6 years ago

  • Related to Bug #4861: ndncatchunks: improve performance on high-delay or low-quality links added
Actions #6

Updated by Anonymous almost 6 years ago

https://gerrit.named-data.net/c/ndn-tools/+/5314 will add better statistics to show skipped retransmissions.

Example:

All segments have been received.
Time elapsed: 19123.6 milliseconds
Segments received: 8066
Size: 10485.8kB
Goodput: 4.386531 Mbit/s
RTO Timeouts: 637 (caused 6 window decreases)
Retx segments: 562, skipped: 75
Packet loss rate: 6.51368%
Total # of received congestion marks: 3
RTT min/avg/max = 200.872/212.969/283.336 ms
Actions #7

Updated by Anonymous almost 6 years ago

  • Status changed from Code review to Closed

Should be fixed now. New example output:

All segments have been received.
Time elapsed: 3572.61 milliseconds
Segments received: 23832
Total size: 104858kB
Goodput: 234.803426 Mbit/s
Congestion marks: 36 (caused 36 window decreases)
Timeouts: 8 (caused 2 window decreases)
Retransmitted segments: 3 (0.0125865%), skipped: 5
RTT min/avg/max = 0.351/4.683/31.021 ms
Actions #8

Updated by Davide Pesavento almost 6 years ago

  • % Done changed from 0 to 100
Actions

Also available in: Atom PDF