NFD » ndn-tools

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

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

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

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

Anything else to do here?