Bug #4861
closed
ndncatchunks: improve performance on high-delay or low-quality links
Added by Anonymous about 5 years ago.
Updated over 4 years ago.
Description
We found that ndncatchunks performs very poorly compared to TCP when there is delay, jitter, or packet loss.
With a sufficiently bad channel (which sometimes means just using a WiFi network), the throughput can be up to 10x lower than TCP and catchunks will often exceed the default retransmission limit of 3.
I've attached Chavoosh's preliminary results and will update this thread when I make progress.
Also, if you noticed any real-world performance issues with catchunks, please let me know.
Files
- Subject changed from Fix catchunks performance issues to catchunks: improve performance on lossy links
Lan reported a second problem that occurs with very low bandwidth-delay products.
Here's the scenario description:
10 consumers behind a wireless link with a bw*delay of 27KB, a little over 6 segments assuming default segment size for ndnputchunks.
If you use minindn, you can have several consumers sharing a slow ethernet connected to the producer. Then run ndncatchunks. Make sure that the bw-delay product of the link is just several segments so the consumers will definitely congest the link.
And the results:
Total # of lost/retransmitted segments: 147 (caused 159 window decreases)
We disabled the conservative window adaptation. Is it strange that the number of window decreases is more than the number of retransmitted segments?
Also we didn’t observe any congestion marks in any of the experiments even though it’s turned on and we are using udp multicast which should support congestion marks. There should be quite a bit of congestion with many consumers using a low bandwidth*delay link (the scenario I mentioned in another email).
- Subject changed from catchunks: improve performance on lossy links to ndncatchunks: improve performance on lossy links
Total # of lost/retransmitted segments: 147 (caused 159 window decreases)
We disabled the conservative window adaptation. Is it strange that the number of window decreases is more than the number of retransmitted segments?
See #4603
- Subject changed from ndncatchunks: improve performance on lossy links to ndncatchunks: improve performance on high-delay or low-quality links
- Related to Bug #4603: ndncatchunks: number of lost packets does not always match number of pipeline window decreases added
- Status changed from New to In Progress
- Related to Feature #3860: ndncatchunks: Implement CUBIC algorithm added
- Related to Bug #4866: ndnputchunks consumes a large amount of RAM added
- Related to deleted (Bug #4866: ndnputchunks consumes a large amount of RAM)
- % Done changed from 0 to 50
Anything else to do here?
- Status changed from In Progress to Closed
- % Done changed from 50 to 100
- Related to Feature #5036: catchunks: improve CUBIC performance on lossy networks added
Also available in: Atom
PDF
Updated by