congure_reno: initial import of TCP Reno congestion control

[miri64]

Contribution description

This provides an implementation for CongURE of the congestion control mechanism of classic TCP congestion control (TCP Reno) as specified in RFC 5681.

Testing procedure

Tests are provided for which riotctrl (at least v0.2.2) is required for them to run. If installed,

make -j -C tests/congure_reno flash test

should succeed.

Issues/PRs references

Requires #15951 (merged), #16111, and #16119 (merged). When merged, I will adapt the test framework to use the turo framework introduced in #15950, which was the original idea to begin with (which is why it is already printing JSON strings).

[miri64]

Same as with #15952: Rebased to current master, needs some adaptions to the changes done in #15951, so I am marking this WIP temporarily.

[miri64]

Adopted tests, however on real boards, there seems to be a problem with the shell: even though I increased the input buffer for stdio_uart to 512, the shell only reads up to 64 characters and then garbage after that :-/. Anyone has any idea why? In tests/emcute (where there is also large input) this does not seem to be a problem.

[kaspar030]

This is probably caused by the uart usb converter that is provided by the on-board debugger.

[miri64]

This is probably caused by the uart usb converter that is provided by the on-board debugger.

But why does it work with tests/emcute then?

[miri64]

This is probably caused by the uart usb converter that is provided by the on-board debugger.

Ok, there might be something to it though. On IoT-LAB M3 it succeeds.

[miri64]

Latest round of commits finishes adopting to the changes from #15951. If the error I am facing really stems from the hardware I might need to rethink my test frame work.

[miri64]

(mostly for the report_msgs_timeout method, but still)

[miri64]

Same treatment as in #15952: Rebased to current master and dependencies and added #16119 as new dependency.

[miri64]

Might be the good old line-off-by-one error I encountered in the past with RIOTCtrl :-/ We might need to fix that in the backend.

[benpicco]

The code looks fine though, so what do we do about the test?

[miri64]

The code looks fine though, so what do we do about the test?

Fix the framework, once I have some time to look into it :-) (or maybe @fjmolinas can have a look as well). Maybe its also just a matter of usage. I remember that for congure_test I needed to do some adaptations after the fact as well, maybe these are required here as well and I just did not integrate them here yet (and in #15952)

[miri64]

Fixed the same issue here.

[benpicco]

So the only remaining failure are due to missing Makefile.ci (maybe #16109 could come in handy here 😉 But then again the list is small enough to be created manually)

Please squash!

[miri64]

From what I observed locally, there will be similar errors in the tests as in #15952 ;-) 95% they are test errors, not module errors, but still need an hour or two of spare time to check it for sure.

[OlegHahm]

@miri64 ping :)

[miri64]

Squashed

[miri64]

And rebased (in the hopes that something in the current master will fix the murdock issues :P)

[miri64]

@OlegHahm If Murdock fails, don't bother to push for it to get into the release. Sadly, I don't have time for bug hunting today :(.

[miri64]

Mh... all related test failures only seem to be connected to RAM overflows. Allow me to fix that!

[miri64]

@benpicco can this still be merged?

[benpicco]

Sure!