HyStart++ implementation [RFC 9406]

[hfstco]

WORK IN PROGRESS

RFC 9406

To avoid big changes in the testbed, prevent problems in currently running research using picoquic and I also want to compare SS, HyStart and HyStart++ for my research, HyStart++ can be enabled as an option. Current HyStart implementation is still the default option.

alg_number:
0 = HyStart disabled (Slow Start)
1 = HyStart enabled (default option)
2 = HyStart++ enabled

./picoquicdemo -H <alg_number>
picoquic_set_default_hystart_algorithm(quic, alg_number)
picoquic_set_hystart_algorithm(cnx, alg_number)

HyStart++ is only implemented into CUBIC currently. I want to implement it for more CC algos and write some test cases before the code is merged into the master branch.

Will update this PR with more information and results.

#1694

[huitema]

I will look at the link failure issue, that should be simple using Visual Studio. Then prepare a PR for your branch.

[hfstco]

I will look at the link failure issue, that should be simple using Visual Studio. Then prepare a PR for your branch.

Thank you! I am not using Windows/Visual Studio and haven't enough time today to fire up my VM.

[huitema]

Seems to be working now. I only had to add hystart_test.c to the picoquictest project.

[huitema]

Question: how do you expect to specify "use of cubic and hystart++" in a run of picoquic_ns?

[hfstco]

Question: how do you expect to specify "use of cubic and hystart++" in a run of picoquic_ns?

I think the best idea is to create an additional variable to st_picoquic_ns_spec_t(e.g. int hystart_algo) and set the default HyStart algorithm in picoquic_ns_create_ctx() for the quic contexts by using picoquic_set_default_hystart_algorithm() or picoquic_set_hystart_algorithm().

Edit: Maybe it is good idea to introduce a enum instead of using an int for hystart_algo.
Edit: Have added an example.

[huitema]

Is this still a work in progress?

[hfstco]

Is this still a work in progress?

I will give an update on this next week. Implementation is ready so far.

[huitema]

We have a conflict between this and PR #1856 on the use of the "-H" flag. Also with the Hybla PR. You use it to specify an Hystart++ flag; Hybla uses it to specify Hybla parameters; PR #1856 defines it as a generic flag for carrying options of the congestion control parameter. Maybe I should merge PR #1856 first, so you can use the generic parameter to set options in various protocols. This would remove the need for adding set up functions in the general code.

[hfstco]

We have a conflict between this and PR #1856 on the use of the "-H" flag. Also with the Hybla PR. You use it to specify an Hystart++ flag; Hybla uses it to specify Hybla parameters; PR #1856 defines it as a generic flag for carrying options of the congestion control parameter. Maybe I should merge PR #1856 first, so you can use the generic parameter to set options in various protocols. This would remove the need for adding set up functions in the general code.

Yes, I saw it yesterday. More and more characters are used by picoquic. It's hard to find a "comprehensible" character for further options.

I will change my code to use the generic CC parameters introduced in #1856.

Do we want to follow a specific scheme for this CC option string? I think every CC has its own options and parameters. (e.g. We don't need the RTT0 parameter in CUBIC.) Of course, there are some in common too. (e.g. HyStart)
Therefore, we define an CC option string for each CC independently, right?
Perhaps we should open an issue to discuss and/or document these different options anywhere.

[huitema]

Do we want to follow a specific scheme for this CC option string? I think every CC has its own options and parameters. (e.g. We don't need the RTT0 parameter in CUBIC.) Of course, there are some in common too. (e.g. HyStart) Therefore, we define an CC option string for each CC independently, right? Perhaps we should open an issue to discuss and/or document these different options anywhere.

For BBR, I wrote a simple parser with the syntax:

option = option [ options ]
option = letter [ digits [ '.' digits ] ] [:]
letter = 'A' ... 'Z'
digits = *digit
digit = '0' ... '9'

If you need a single option for Hystart, we could reserve the letter 'Y', followed by digits, or something more complex followed by column. Each Hystart user could then ask Hystart to parse the option and update the Hystart state, with the Hystart parser returning something like a pointer to the next character.

[hfstco]

Just wanted to let you know that I'm currently taking measurements. Everything is taking longer than expected.