Bug #4603
closed
ndncatchunks: number of lost packets does not always match number of pipeline window decreases
100%
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.
Updated by Davide Pesavento almost 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.
Updated by
Updated by Davide Pesavento over 5 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
Updated by Anonymous about 5 years ago
- Status changed from New to Code review
- Assignee changed from Ryan Wickman to Anonymous
Updated by Anonymous about 5 years ago
- Related to Bug #4861: ndncatchunks: improve performance on high-delay or low-quality links added
Updated by Anonymous about 5 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
Updated by Anonymous about 5 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