Project

General

Profile

Actions

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.

Status:
Closed
Priority:
Normal
Assignee:
-
Start date:
03/02/2019
Due date:
% Done:

100%

Estimated time:

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

chavoosh_perf_measurements.xlsx (11.3 KB) chavoosh_perf_measurements.xlsx Anonymous, 03/02/2019 03:45 PM
chavoosh_perf_measurements.pdf (91.2 KB) chavoosh_perf_measurements.pdf Anonymous, 03/02/2019 03:57 PM
catchunks_perf.pdf (2.32 MB) catchunks_perf.pdf Anonymous, 03/12/2019 10:34 PM

Related issues 3 (0 open3 closed)

Related to ndn-tools - Bug #4603: ndncatchunks: number of lost packets does not always match number of pipeline window decreasesClosed

Actions
Related to ndn-tools - Feature #3860: ndncatchunks: Implement CUBIC algorithm Closed

Actions
Related to ndn-tools - Feature #5036: catchunks: improve CUBIC performance on lossy networksClosed10/27/2019

Actions
Actions #1

Updated by Davide Pesavento about 5 years ago

  • Subject changed from Fix catchunks performance issues to catchunks: improve performance on lossy links
Actions #2

Updated by Anonymous about 5 years ago

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).

Actions #3

Updated by Davide Pesavento about 5 years ago

  • Subject changed from catchunks: improve performance on lossy links to ndncatchunks: improve performance on lossy links
Actions #4

Updated by Davide Pesavento about 5 years ago

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

Actions #5

Updated by Anonymous about 5 years ago

  • Subject changed from ndncatchunks: improve performance on lossy links to ndncatchunks: improve performance on high-delay or low-quality links
Actions #6

Updated by Anonymous about 5 years ago

Uploaded the slides from the Hackathon.

Also here's a first part of the implementation: https://gerrit.named-data.net/c/ndn-tools/+/5314

Actions #7

Updated by Anonymous about 5 years ago

  • Related to Bug #4603: ndncatchunks: number of lost packets does not always match number of pipeline window decreases added
Actions #8

Updated by Davide Pesavento about 5 years ago

  • Status changed from New to In Progress
Actions #9

Updated by Anonymous about 5 years ago

Refactoring commit before adding CUBIC pipeline: https://gerrit.named-data.net/c/ndn-tools/+/5323

Actions #10

Updated by Anonymous about 5 years ago

  • Related to Feature #3860: ndncatchunks: Implement CUBIC algorithm added
Actions #11

Updated by Anonymous about 5 years ago

  • Related to Bug #4866: ndnputchunks consumes a large amount of RAM added
Actions #12

Updated by Davide Pesavento about 5 years ago

  • Related to deleted (Bug #4866: ndnputchunks consumes a large amount of RAM)
Actions #13

Updated by Anonymous about 5 years ago

Commit to implement Cubic window adaptation: https://gerrit.named-data.net/c/ndn-tools/+/5341

Actions #14

Updated by Davide Pesavento almost 5 years ago

  • % Done changed from 0 to 50
Actions #15

Updated by Davide Pesavento over 4 years ago

Anything else to do here?

Actions #16

Updated by Anonymous over 4 years ago

  • Status changed from In Progress to Closed
  • % Done changed from 50 to 100

Should be done.

Actions #17

Updated by Davide Pesavento over 4 years ago

  • Related to Feature #5036: catchunks: improve CUBIC performance on lossy networks added
Actions

Also available in: Atom PDF