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 over 5 years ago.
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.
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.
- Assignee set to Ryan Wickman
- 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
- Status changed from New to Code review
- Assignee changed from Ryan Wickman to Anonymous
- Related to Bug #4861: ndncatchunks: improve performance on high-delay or low-quality links added
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
- 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
- % Done changed from 0 to 100
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by Anonymous